When, which … Design Thinking, Lean, Design Sprint, Agile?
Many people are-understandably so-very uncertain about methodologies, systems and strategies for innovation. Questions such as: "How do we use Design Thinking? "What is the Design Sprint 's purpose? "" Is Lean Startup for startups only? "How is Agile fitting in? "What happens after the process of < a certain methodology >? "The questions are all very general.
(How) does it all connect?
When browsing the Internet for answers, one notices quickly that others too are struggling to understand how it all works together.
Gartner (as well as many others) tried to imagine how methodologies such as Design Thinking, Lean, Design Sprint and Agile flow seamlessly from one to another. Most of these visualizations include a variety of beautifully colored and linked circles but seem to miss the mark for me. The position where one approach flows into the next is highly debatable, because there are so many specific methods and so much overlap occurs.
The innovation spectrum
It probably makes better sense to look at Design Thinking, Lean, Design Sprint & Agile as a bunch of tools and strategies in one's toolbox instead of fighting about each other, since they can all add value to the continuum of developments somewhere.
Innovation projects can range from exploring an abstract problem space to experimenting with a variety of solutions, until a more practical approach is continuously developed in a particular market space.
An dimension that sometimes seems to be overlooked is the axis of maturity for the business model. The business models are often very well understood for established products as well as for adjacent ones (think McKinsey's Horizon 1 and 2). However, the business model would need to be tested by trials for startups and revolutionary technologies within an existing enterprise.
1.) Design Thinking
Tech Thinking will shine as we need to better understand the space of the issue and find the early adopters. Project thinking has growing flavors but they all adopt the double-diamond flow. Simplistically the first diamond starts by diverging and collecting loads of insights by talking to our target stakeholders, then converging by clustering these insights and finding key pain-points, challenges or jobs to be done. Until prototyping and evaluating the most promising proposals, the second diamond starts with a divergent exercise to formulate a wide range of potential solutions. Design Thinking is mainly focussed on qualitative rather than quantitative insights.
2.) Lean Startup
The small difference with Design Thinking is that sometimes the developer (or intrapreneur) already knows the problem space well. Lean considers everything to be a hypothesis or inference before it has been tested ... and even a clear understanding of the space of the problem is just a supposition. Lean aims to start by defining the assumptions on a customer-focused (lean) canvas and then prioritizing and validating the assumptions for the entire product according to the highest risk. The process by which assumptions are validated is to create an experiment (build), test it (measure) and learn whether our assumption or hypothesis is still there. Lean makes early use of qualitative observations but later pushes you to identify actionable quantitative data to determine how successful the solution solves the issue and whether the growth plan is on track. Lean Startup is often synonymous with the term "Get out of the house," but the same idea of getting out to the customers clearly often counts for Product Thinking (... and Product Sprint ... and Agile).
3.) Design Sprint
The Google Venture-style Design Sprint method appears to have its origins from a technique mentioned in the Lean UX book. A Design Sprint's key strength is sharing insights, ideating, prototyping and testing a concept all in a 5-day sprint. Given the short timeline, Design Sprints focuses only on part of the solution, but whether you are on the right track or not, it is an excellent way to learn very quickly.
Just like coping with the complexity of our problem, solution and business expectations, agile development is an excellent way to cope with product development instability. The need to define every aspect of a product up front, because there's a lot of assumptions and ambiguity here too. In Lean Startup parlance, Agile is a perfect way to build-measure-learn and test conclusions before producing a Minimum Viable Product. We should identify and prioritize a value backlog to be delivered and function in short sprints, delivering the value as part of each sprint, and check it.
The answer you were looking for probably not, but there is no clear rule on when to start where. There is also no obvious handover point because there is just too much overlap and this significant overlap could be the explanation why some people claim that methodology < x > is better than < y >.
Anyhow, most methodologies of innovation will bring tremendous value and it is really up to the team to determine when to start and when to apply the methods and techniques. The common ground on which everyone will agree is not to fall in love with your own approach and listen to both qualitative and quantitative input from customers.