Benjamin Kampmann, a reputable hacker and product manager, relays his experience with the Lean Canvas over the past few years, in particular how it removed his attention from the customers that actually wanted his product:
The likelihood of the end technology still being a great fit for the market you decided on at the beginning is rather small.
Lean Thinking emphasises the principle of minimizing waste. The common interpretation of Lean Startup assumes that the lead cause of waste is always a lack of commercially-viable demand. But research shows there's a wider range of causes of startup failure. In addition to customer demand, early-stage startups often die from team problems and a lack of connections. Later-stage startups from weak industry positions.
Benjamin goes further, explaining that even with a market-first, rather than product-first approach, assuming he knew his first customer segments, rather than researching them broadly, slowed him down.
Even worse, overly focussing on a [single] market creates a harmful narrowing of your focus: Deciding on how and to whom to sell a technology that hasn't even been developed yet, leads to focusing on building something sellable rather than exploring the actual impact your technology could have.
Indeed, the Lean Startup approach is often misinterpreted as talk-to-customers-first, rather than find-the-right-market-first, and the way the Lean Canvas is taught re-inforces that.
It's worth looking at Lean's origins in Toyota. Their approach to early-stage product design is much closer to how Benjamin describes exploring needs and possibilities. Rather than picking a single market and determining their needs, there is a wide exploration phase, narrowing down on actual opportunities from multiple angles.
Customer conversations vs product experiments
Even though I've been in favour of taking potential markets into account from early on, the reality is that there is little point in doing that when you just started coding: This is an experimental stage, there is nothing to see, test or prove for weeks or months after you started your project.
This is true, but not in every case, which makes it dangerous advice to apply without consideration.
Depending on what you need to learn, another Lean Startup principle - iterating the product quickly - might give you regular and actionable learning faster. But if you start with tech, your experiments and releases need be fast enough. That's hard at first.
There are further issues. When building smaller products as experiments, there's more than the build time to take into account; you need a reasonable amount of time for the market to respond. You can fall prey to the Immediate Response Fallacy, where you don't leave the right amount of time for the market to respond, and incorrectly conclude the experiment failed.
Business model problems
Benjamin also considers his experience with multi-sided models, not just SaaS.
By narrowing your focus to build something you can sell, you can easily forget to make it attractive to the people actually using it - which aren't your customers per se. This doesn't only apply to ad-driven social networks, it is equally true for building a platform for fund-raising or petitions: if you don't have active users, why would any "customer" ever want to run a campaign on your platform?
And lastly, he warns how using the Lean Canvas as his main de-risking tool led him away from noticing some fatal assumptions:
Ergo, instead of thinking of the "market" when building a tech venture, you should think about those who'll ultimately benefit from the technology first.
Though the initial build is a vital part of a tech venture cycle, you have to hide it to make the Lean Startup Canvas work. Awkward.
Building a functional prototype gives you real data. You can actually observe user behaviour, rather than rely on people's descriptions of their behaviour. If you have an open mind, rather than a narrow focus on your idea of their stated "top 3" problems, that data can lead you in the right direction. In Benjamin's case, it's led him to completely new customers.
Choosing the right tool for the job
The key lesson I get from Benjamin that he chose the tool he liked better, but wasn't the right tool for the job. It's possible he didn't make himself aware enough of his options.
Often, the Lean Canvas is chosen because it covers keywords that people think are important at first, like "Problem" and "Metrics," or simply because it's called the Lean Canvas.
This reasoning doesn't answer: is this the right tool for the job I have?
My experience with a large number of startups in accelerators is that the Lean Canvas and Business Model Canvas are helpful in seeing key assumptions as a whole, and to spot gaps in thinking.
One problem is that both give the impression of being thorough and complete, but aren't. Other equally-important assumptions are covered in The Assumptions Exercise, Business Model Environment, and Seven Domains Framework.
In practice, canvases are also awful dashboards - you'll notice they're commonly abandoned when used that way - old post-its gathering dust on the wall.
For early-stage and market driven assumption spotting, I've found Giff Constable's Assumptions Exercise to be much faster and more effective.
The original Business Model Canvas is particularly useful in prototyping and exploring a range of options quickly. It's stood the test of time, for companies that have started and expanded in a range of directions. I've noticed more coherent and innovative business models from startups who use the BMC this way.
When considering the impact of trends, competition, and other aspects that investors scrutinise, the business model environment is effective.
A good tech creation canvas has to assists developers in thinking about their benefactors and user base early, without narrowing the focus of the technology to what can be sold only.
Alex Osterwalder, the creator of the Business Model Canvas, has also recognized the need for finding product / market fit - and from both directions. His new Value Proposition Canvas is actually designed to be split in two, product ideas and customer segments explored more independently of each-other, with customer problems and their jobs-to-be-done as the glue to finding the right match.
There are other great tools out there too, but as always, you need to look at your options.
If you read this far, you should follow me on twitter here.
