Many people - understandably - get very confused when it comes to innovation methodologies, frameworks or techniques. Questions such as "When should Design Thinking be used?", "What is the purpose of Design Sprint?", "Is Lean Startup only for start-ups?", "Where can Agile methodology be used?" are very common.
By searching the internet sources, we soon realise that others are lost in the obscurity of innovation methodologies. Gartner (like many others) tried to imagine that methodologies such as Design Thinking, Lean, Design Sprint and Agile were all moving along nicely in succession. This is usually represented by colourful, spectacular, overlapping circles. However, this approach is inaccurate. In reality, the boundaries between methodologies are blurred because there is a lot of overlap between many similar techniques.
Since Design Thinking, Lean, Design Sprint and Agile techniques can all add value to the innovation spectrum, it is not worth ranking them, but rather considering them as part of a toolkit.
The range of innovation initiatives spans a very broad spectrum, from problem identification, through a number of possible solutions, to the sustainable development of a solution in a specific business context.
Many people forget to consider the "maturity" (progress) axis of the business model. For proven and comparable products, business models are usually satisfactorily accurate. However, in the case of start-ups or innovations that are completely new within an older organisation, the business model needs to be validated by experimentation.
Design Thinking is an excellent solution in situations where you need to understand the problem domain thoroughly and identify the first/initial users Double-diamond technique, at the beginning (Research) you identify a situation to be solved (Problem), then you always broaden your horizon: talk to as wide a target group as possible about their needs. Then, condensing the information gathered, we identify the most important and pressing problems and tasks to be done (Problem Definition). Then comes the Design phase, at the beginning of which we try to imagine all possible solutions, prototype and test the most promising ideas. Based on the feedback we receive, refocusing our vision on only the best solutions, we arrive at the second tip of the diamond, the Solution. Design Thinking focuses primarily on quality.
The term refers to development that creates value for the user, using as few resources as possible, and is done "without frills".
Some differences from Design Thinking are that the entrepreneur often already knows the problem domain well. Lean, however, considers everything as a hypothesis until it is confirmed, so even this good situational awareness is only a hypothesis. Lean usually starts by defining its assumptions for a narrow customer-focused set of customers, testing them, and then ranking and validating the assumptions according to the highest risk to the overall product. The process of validating the assumptions is to build an experiment, test it, and draw a lesson about whether our assumption or hypothesis remains valid (build, measure and learn, the triple bottom line). Lean uses qualitative insights early on, but later encourages you to define actionable quantitative metrics to measure how effectively the solution solves the problem and whether the growth strategy is on track. The phrase "Get out of the building" is often associated with Lean Startup, but the same customer-centric approach is clearly relevant to all the methodologies presented in this article.
The Google Venture-style Design Sprint method probably has its roots in the technique described in the book Lean UX. The main strength of Design Sprint is that during a five-day sprint, the team can share new knowledge, ideas, prototypes and test a concept. Given the short duration, the Design Sprint focuses on only part of the solution, but it is a great way to find out very quickly whether you are on the right track or not.
It's not just the problem itself, the solution and the market assumptions that are uncertain - product development is too. Agile development is a great way to deal with this. Under the agile methodology, because there are so many assumptions and uncertainties, it is not necessary to define every detail of the product in advance. For this reason, this framework is an excellent way to build-measure-learn and validate assumptions while creating a Minimum Viable Product (the fastest first working prototype) first. We need to define and prioritise a Product Backlog and work in short sprints, at the end of which we test the delivered value.
There is no clear rule on which innovation methodology can be used when, for how long and under what circumstances. There is also no obvious handover point due to a lot of overlap - this may be the reason why some practitioners believe it is more useful to talk about a methodology than a method.
Most innovation methodologies have a high value and it is up to the team to decide where and when to start applying a particular methodology or technique. It is very important to avoid sticking to your favourite method to ensure common agreement. Remember also to keep listening to user feedback, adapting the workflow as necessary (retrospective).
The author of the original article, Geert Claes, is an innovator, we have worked together on several projects before, we have also led Design Sprints together and he posted the article used as a source about four years ago. Since then it has been translated into several languages and we regularly use his visualisation for explanation. You can read more about his activities at this link.
This article is based on the problem2value’s site.
By: Zsuzsa Danka