The true job of an entrepreneur is to systematically de-risk their business model over time.
While you might be excited by your idea’s potential, others don’t see what you see. What they see instead is something untested and risky.
- You have to derisk your idea to convince your future co-founders to quit their stable jobs and join your cause.
- You have to derisk your idea to convince customers to take a chance on your product versus the existing alternatives.
- And you have to derisk your idea to convince investors to give you money to grow your business.
It logically follows that you should prioritize tackling what’s riskiest, not what’s easiest, in your business model.
This was the basis for the 2nd meta-principle described in my book: Running Lean.
While tackling what’s riskiest is a simple enough concept to grasp, it’s ironically quite hard to implement.
When you fail to correctly prioritize your risks, it doesn’t matter how many experiments you run. You’ll get sub-optimal results and fail to pierce a certain ceiling of achievement.
This is why I came to realize that “identifying what’s riskiest” is the main Achilles Heel in Running Lean. I’ve spent the last year looking for a more practicable solution which is the main question I address in my next book: The Customer Factory.
But before I jump to the solution, let's first take a look at current approaches for risk prioritization and see where they fall short:
Approach 1: Use your intuition
You could use your intuition and pick what you consider as your riskiest assumption to test.
But testing anything takes time, money, and effort, and it’s not comforting to know that incorrect risk prioritization is one of the top contributors to waste.
In other words, if you fail to correctly identify what’s riskiest, you end up burning needless resources, and you’ll get those sub-optimal results and endless cycles I showed earlier.
Approach 2: Start with the 3 Universal Risks
At the earliest stages of a product, you can rely on tackling some universal risks that apply to almost every product, such as making sure your customer/problem assumptions are valid, making sure these problems represent a monetizable pain (revenue stream) and making sure that you have a path or can build a path to customers (channels).
But as the product matures, no two products and entrepreneurs are the same.
What’s riskiest in one situation may not be what’s riskiest in the other — so it becomes impossible to follow a prescriptive path.
Approach 3: Talk to domain experts
A reasonably good solution is talking to domain experts and advisors. This can help uncover what’s riskiest — provided you have good advisors, and you use them effectively by not just practicing “success theater” with them.
Seasoned advisors are good at pattern recognition, and if you get a group of advisors independently raising the same objections in your model, that’s a pretty good indication that it may be worth investigating.
But the opposite is also true.
In fact, it’s more common to get conflicting advice even from the best advisors. I’ve seen this happen at some of the best accelerators in the world.
You and you alone have to own your business model. Remember that no one has a crystal ball, and a tactic that might have worked for an advisor, such as using AdWords to grow their business, may have outrun its time.
Advisor Paradox: Hire advisors for advice but don’t follow it, apply it.
So you can’t take anyone’s advice on faith. You still have to test it. And the price of picking the wrong thing to test costs you time, money, and effort.
So while each solution gets you part of the way there, none of them is foolproof. The underlying reason for this is that all of them require guessing — either you guess or you have someone with more experience than you guess.
There is a better way that doesn’t require any guesswork: Using a systems-based approach.
I first introduced systems thinking for your business model in this post, and it’s the central idea in my next book: The Customer Factory.
There are three main attributes of systems, and one of them is the concept of system constraints. Or specifically the idea that at any given point in time, a system is limited by a single constraint.
Those of you familiar with Goldratt’s book: The Goal will recognize this as the Theory of Constraints.
To illustrate this concept, consider this system of machines on a factory floor.
Each of these machines can generate a certain number of widgets per day. The market demands 12 units a day. But the system as it’s configured here cannot meet that demand.
If we wanted to increase the system's throughput, we could upgrade all the machines, but that would be very wasteful. What we need to do instead is find the constraint or bottleneck in the system, which is limiting the throughput.
Can you figure out what is the maximum throughput of this system?
Where is the bottleneck or constraint in this system?
The maximum throughput of this system is limited by the constraint, which is at step C because that machine is the slowest.
Many of the units created in the first 2 steps queue up at Step C, waiting to be processed.
So if we manage to increase the throughput of Step C from 7 units a day to 12 units a day, what happens now to the throughput? And what happens to the constraint?
That’s right, the constraint moves. Throughput goes up, but it’s still limited by the next slowest machine, which is at Step D. So even though market demand is at 12 units, this system can still only produce nine units a day.
This is one of the reasons why correctly identifying what’s riskiest is so tricky, especially when your business model is set in motion.
- If you fail to identify the bottleneck in your business model, you get sub-optimal results. While you might still learn something from your experiments, you don’t get to increase the throughput of your business model unless that learning affects a limiting constraint.
- If, on the other hand, you do correctly identify the right bottleneck and address it, you have to know when to stop, or you fall into the premature optimization trap. This is because once the bottleneck is sufficiently addressed, a new bottleneck will appear, and you have to move quickly to plug that hole.
Finding constraints in a “customer factory” is a bit more involved than the traditional factory example because there are a few more moving parts.
This is what I’ll be covering extensively in my next book: The Customer Factory, which is slated for launch in 2015.