From Lean Startup to Domain Mastery Startup

First came the “I have a great idea” startups. A heroic founder will come up with a great idea on how to go about solving a particular problem. A few years and a few millions of dollar later, the team emerges with a product, only to find out that nobody thinks their product really solves the problem; or even worse — that nobody thinks that the problem they have attempted to solve is a real one.

Then came the Lean Startup movement, fully embracing the fact that a startup is an organization meant to search for a sustainable business model, and the best way to do so, is through a disciplined application of the scientific method:

In a nutshell, a startup is a hypothesis testing machine.

While a massive step in the right direction, I believe it is an insufficient one, since the methodology ignores a critical ingredient in this process. To extend the machine metaphor a little further: similar to other machines, the quality of the output (validated/invalidated hypothesis) is not just a factor of the quality of the machine, but also of the quality of the inputs (hypothesis formulated). If you’re making coffee with the best espresso machine out there, but using low quality coffee beans — you’re still going to get bad coffee. The quality of the coffee (output) is constrained by the quality of the beans (input). Or to use a different metaphor: you’re still throwing darts at the dart board turned-around and blindfolded, you just gotten very good at throwing the darts quickly and lifting the blindfold after every throw to see if you’ve hit your mark.

Talking to your customers is the simplistic solution to this problem. Your customers can be incredibly useful in helping you validate your problem hypothesis (after all, it’s their problem you’re trying to solve), and on rare occasions, they can also help you formulate a better problem hypothesis. But more often than not, they will not be able to help you in formulating your solution hypothesis. Just because you have the problem, doesn’t mean that you have any idea how to solve it. To use an intentionally extreme example: just because you have cancer, doesn’t mean that you can help me find what might be the cure. This logic also applies for the people who are part of the startup: just because you suffer from the same problem you’re trying to solve, doesn’t necessarily make you any better than your (future) customers in formulating hypotheses around solutions that might work. Sure, you may get lucky in your guesses, but there’s a better way.

So what is that missing ingredient? I’d argue that it’s true mastery in the problem domain. Deep understanding of the root causes behind the problem, what’s already been tried and worked/didn’t work and under which circumstances, where the ecosystem as a whole is heading and why, etc. You get the point. And if you, dear founder, are not the master of the problem domain in which you operate — find someone who is and get them on your team. Not as a board member. Not as a part-time adviser. But as a full-time member of the team, in there with you, in the trenches, informing and refining your hypothesis testing machine on a daily basis. This is, in my opinion, one of the most critical ways to de-risk your search for a sustainable business model, and one that is well worth investing in.

It’s time to move past Lean Startups, and start moving towards Domain Mastery Startups.

Show your support

Clapping shows how much you appreciated Itamar Goldminz’s story.