Design Thinking Vs. Lean Start-up Vs. Business Model Canvas


Which one should I chose? 

When talking about innovation, we are often confronted with different schools of thought, each defending its turf: Business Model Canvas “aficionados", Design Thinking “experts" and Lean Start-up “evangelists". One might get confused enough without including the myriad of others innovation methods like Agile, Scrum, Open Innovation, or combinations thereof like the “Lean Canvas". Is one better suited for innovation than the others? That’s probably the wrong question, as they all excel at something, and should therefore considered in that light. While for example in the case of incremental innovation just some aspects of Design Thinking, Lean or the Canvas could be used effectively, the same cannot be said about proper radical innovation that aims at creating something truly novel. They are tools, and not strategies. When it is difficult to forecast consumer behaviour or technological feasibility, each helps in providing a crucial piece of the answer to how to innovate under real uncertainty.

None is enough by itself 

How to synergistically integrate them? First of all, one must understand where they excel, and where they fall short:  

  • Design Thinking excels at the deep understanding of the customer’s problem, yet its effectiveness fades when iterating on the business model to bring the solution to the final user. 
  • The Lean Start-up approach is great in its well defined cycles of prototyping around the solution, yet provides less guidance in the generation of ideas themselves.  
  • The Business Model Canvas provides a great overview of all components for delivering to and capturing value from the user, yet it gives little guidance in iteratively understanding a problem worth solving and the validity of the solution.

 Design Thinking + Lean Start-up + Business Model Canvas = ? 

Furr and Dyer in their 2014’s book integrate the different approaches into what they call the “The Innovator’s Method”. The core of the method relies on a series of experimentations cycles that, through an iterative validation, gradually resolve uncertainty. In the first cycle we experiment around the problem we are trying to solve, then move on to the solution we propose, and finally experiment on the business model to take said solution to the market.

1 – In the first phase, the goal is to understand what the problems around “job to be done” by the user are – be it functional, social or even emotional. If there is no problem, there is no opportunity – nobody pays for solving a nonproblem. While trivial, it is difficult for managers to not jump right in the solution development, and postpone the “creative” phase only after the challenge has been defined. For example, I don’t need an expensive drill – the outcome I seek is a simple hole in my wall. Is this a problem worth solving? How could I solve this? Tools within the Design Thinking space like ethnography, pain-storming or the 5-why analysis are good places to start. 

2 – Once a problem worth solving has been stated, one should move on and fully leverage different types of prototypes to probe different dimensions of the solution space. The goal is first to create a minimum viable prototype: the simplest, cheapest prototype that we can put in front of a user and that thus provide us with the quickest learning cycle. Eventually we want to create a a minimum awesome product, more elaborate and closer to delivering that awesomeness that will matter to the user. In both cases, as Eric Ries of the Lean Start-up says, “if you show a prototype and you are not embarrassed, it means you’ve done too much work” (without knowing if it was worth it).

3 – Having nailed the solution, one can progress to validate the other necessary components of the business model, among which are the pricing strategy, customer acquisition strategy and the cost structure strategy. Experiments in this phase are still key, you want to keep this learning cycles quick – for example, take any fixed cost in your business plan and figure out a way to turn them variable (through outsourcing, crowd-sourcing, licensing or substituting a component for the time being) so that you validate before scaling.  


by Giacomo Cattaneo, former employee


Get in touch
with Linda :

Get in touch with Linda :