Oct 3 2017 > Originally posted on Medium
When, which … Design Thinking, Lean, Design Sprint, Agile?
A lot of people are — understandably so — very confused when it comes
to innovation methodologies, frameworks, and techniques. Questions
like: “When should we use Design Thinking?”, “What is the purpose of a
Design Sprint?”, “Is Lean Startup just for startups?”, “Where does
Agile fit in?”, “What happens after the phase?” are all very common
(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 numerous others) tried to visualise how
methodologies like Design Thinking, Lean, Design Sprint and Agile flow
nicely from one to the next. Most of these visualisations have a
number of nicely coloured and connected circles, but for me they seem
to miss the mark. The place where one methodology flows into the next
is very debatable, because there are too many similar techniques and
there is just too much overlap.
The innovation spectrum
It probably makes more sense to just look at Design Thinking, Lean,
Design Sprint & Agile as a bunch of tools and techniques in one’s
toolbox, rather than argue for one over the other, because they can
all add value somewhere on the innovation spectrum.
Innovation initiatives can range from exploring an abstract problem
space, to experimenting with a number of solutions, before
continuously improving a very concrete solution in a specific market
An aspect which often seems to be omitted, is the business model
maturity axis. For established products as well as adjacent ones
(think McKinsey’s Horizon 1 and 2), the business models are often very
well understood. For startups and disruptive innovations within an
established business however, the business model will need to be
validated through experiments.
Design Thinking really shines when we need to better understand the
problem space and identify the early adopters. There are various
flavors of design thinking, but they all sort of follow the
double-diamond flow. Simplistically the first diamond starts by
diverging and gathering lots of insights through talking to our target
stakeholders, followed by converging through clustering these insights
and identifying key pain-points, problems or jobs to be done. The
second diamond starts by a diverging exercise to ideate a large number
of potential solutions before prototyping and testing the most
promising ideas. Design Thinking is mainly focussed on qualitative
rather than quantitative insights.
The slight difference with Design Thinking is that the entrepreneur
(or intrapreneur) often already has a good understanding of the
problem space. Lean considers everything to be a hypothesis or
assumption until validated …so even that good understanding of the
problem space is just an assumption. Lean tends to starts by
specifying your assumptions on a customer focussed (lean) canvas and
then prioritizing and validating the assumptions according to highest
risk for the entire product. The process to validate assumptions is
creating an experiment (build), testing it (measure) and learn whether
our assumption or hypothesis still stands. Lean uses qualitative
insights early on but later forces you to define actionable
quantitative data to measure how effective the solution addresses the
problem and whether the growth strategy is on track. The “Get out of
the building” phrase is often associated with Lean Startup, but the
same principle of reaching out the customers obviously also counts for
Design Thinking (… and Design Sprint … and Agile).
It appears that the Google Venture-style Design Sprint method could
have its roots from a technique described in the Lean UX book. The key
strength of a Design Sprint is to share insights, ideate, prototype
and test a concept all in a 5-day sprint. Given the short timeframe,
Design Sprints only focus on part of the solution, but it's an
excellent way to learn really quickly if you are on the right track or
Just like dealing with the uncertainty of our problem, solution and
market assumptions, agile development is a great way to cope with
uncertainty in product development. No need to specify every detail of
a product up-front, because here too there are plenty of assumptions
and uncertainty. Agile is a great way to build-measure-learn and
validate assumptions whilst creating a Minimum Viable Product in Lean
Startup parlance. We should define and prioritize a backlog of value
to be delivered and work in short sprints, delivering and testing the
value as part of each sprint.
Probably not really the answer you were looking for, 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 of why some people claim methodology
is better than .
Anyhow, most innovation methodologies can add great value and it’s
really up to the team to decide where to start and when to apply which
methods and techniques. The common ground most can agree with, is to
avoid falling in love with your own solution and listen to qualitative
as well as quantitative customer feedback.