Fast track 🏎️ 💨 to learning Design Thinking, Lean Startup, Agile, Pretotyping, and Design Sprint
“When the world around us is changing rapidly, we need principles to guide our work”
Intro 🎬
The purpose of this how-to article is to provide entrepreneurs, innovators, and creative thinkers with a fast track learning curve to understand and practice the most popular innovation methodologies of our time.
In order to do so, we will break down each methodology into the following categories: Origin, Process, Purpose and application, Principles, and lastly, my own point of view (PoV).
While the explanation of each innovation methodology is far from exhaustive, you should be able to get a high-level feel for the process and the purpose of using it. Simultaneously, we will explore the commonalities and differences between each framework, and lastly, we’ll develop an understanding of when to use which methodology.
Our end goal is to learn and be able to practice these frameworks as well as understand the underlying principles that are the true drivers of innovation.
The world’s shortest encyclopedia of innovation methodologies 📚
The innovation methodologies mostly applied, compared, and mutually confused are the following:
Design Thinking
Lean Startup
Agile
Pretotyping
Design Sprint
You: Holy shit! Do I really have to learn all that…?
Me: No, you don’t. But you’ll increase your chances of creating something successful if you understand the underlying principles and primary application of each framework.
Luckily for you, I have done the heavy lifting by reading, practising, and comparing all of them.
Now, let’s address them one-by-one and identify the common denominators and underlying principles that really matter when creating new products, services, and startups.
Origin 🐣
Design Thinking has been slowly developing since the 1960s, when it emerged as a creative way to solve complex problems.
Back then, design was merely an afterthought of the development process and was seen as a way of prettifying what had already been developed.
The emergence of Design Thinking and its deep-rooted focus on understanding human behavior, coupled with qualitative research, and visual thinking- and prototyping techniques has helped re-define not only what design is, but also what it can do.
As a result, more and more designers and design thinkers are now involved in the entire creation process of innovation, moving away from the classic waterfall process.
Today, Design Thinking is often associated with the work of IDEO, who have popularised human-centered design and helped catapult Design Thinking into the mainstream of business- and design schools.
Process 👣
Design Thinking is a solution-oriented process that focuses on the collaboration between designers and users.
It’s a very iterative process by design (no pun intended) and is often described more as a compass than a map or a process.
The reason for this being that you go back-and-forth between developing you and your team’s understanding (abstract understanding) and producing and testing prototypes with users (concrete solutions) until you reach something that users want and are able to use.
Main process:
- Empathising: Understanding the human needs involved.
- Defining: Re-framing and defining the problem with user needs and behavior in mind.
- Ideating: Creating many competing ideas using visual thinking techniques.
- Prototyping: Adopting a hands-on approach in prototyping, often co-creating prototypes with users.
- Testing: Validate your prototypes with real users.
More than anything, Design Thinking is a collection of qualitative research techniques coupled with solution oriented visual thinking- and prototyping techniques.
The qualitative research techniques are in place to make you shift perspective continuously throughout the process and you are encouraged to combine observation, interviews, and participation in order to fully understand the problem and the end-users.
The visual thinking- and prototyping techniques are in place to co-create solutions with users as well as engage the whole team of cross functional disciplines to encourage divergent thinking and solutions.
Here are a few prototyping techniques found in Design Thinking:
- Sketch (handdrawn sketch)
- Franken (build with the materials you have at hand)
- Collage (using images and materials to fuse a concept)
- Scenario (prototype a scene using paper on a real device such as an iPhone)
- Sketch model (Solid foam mockup)
- Experimental model (Design a service)
Design Thinking is all about getting as many different perspectives on the problem and the solution as possible.
Purpose and application 💡
Design Thinking is great for solving complex and ill-defined problems. The purpose is to develop something that is:
- Desirable — do people want it?
- Viable — do people use it?
- Feasible — can we make it?
To borrow an expression from entrepreneur and venture capitalist Peter Thiel, Design Thinking is well suited for “going from 0 → 1”. That is to create something entirely new in circumstances of high uncertainty.
The main difference between Design Thinking and other innovation methodologies is that Design Thinking is applicable even when you are unsure of what problem or challenge, you are trying to solve.
Lean Startup, Pretotyping, and Design Sprint all assume that you know which idea or challenge you want to validate. They spend little time analysing and reframing the problem at hand, and jumps quickly to prototyping and testing the proposed solutions.
As such, Design Thinking puts more emphasis on analysis and synthesising than what we see in other innovation methodologies. Below is a comparison between the Design Thinking and the Lean Startup process.
Principles 🙏
- Iterative process — a very iterative process going back and forth between abstract understanding and concrete solutions until you reach something that users really want and are able to use
- Human centered design — cares deeply about understanding user needs and behavior and continuously seeks their feedback throughout the entire process.
- Cross functional teams — it’s easier to redefine a problem and come up with multiple creative solutions when you have divergent perspectives on a team.
- Visual thinking techniques — the purpose is to stimulate divergent idea creation. When drawing, you activate different parts of your brain, and by doing so you are able to think other thoughts.
- Co-creation — prototyping together with users are essential to get rapid feedback and in many cases leads to better ideas. And if you are wrong, you will often know it even by showing very low fidelity prototypes.
- User testing — test with customers as this is the real benchmark if you have created something meaningful.
My PoV on Design Thinking 🙋
For me, there are two crucial parts in Design Thinking:
1. The proposed shift in perspective, altering between interviews, observations, and participation.
This is especially true if you are not scratching your own itch by solving a problem that you have personal experience with. The further removed you are from the problem, the closer you need to be to your users on a daily basis.
For example, when creating a highly customised B2B solution, let’s say developing a tracking and communication tool for people working at a dock, you need to observe, interview, and to work along side these people on a daily basis.
You need to be close to the daily workflow, to understand their daily tasks, and to see the amount of tacit knowledge that goes into the work which people would never be able to express during interviews.
It’s highly relevant to combine interviews, with observations, and sometimes even to participate yourself in order to feel the problems on your own body. The three different modes (observation, interviewing, and participation), are in place to make you take on different perspectives, and to see the problem in a holistic manner.
2. Working as a cross-functional team throughout the process to be in-sync and helps avoid the classic waterfall process.
By involving the whole team early on and getting everyone to talk to customers, do prototypes, and receive the test-feedback first-hand, you can remove 90% of team meetings down the line.
This elevates people’s ability to work self-directed and eliminates the need for micro-management.
I bet that everybody would pursue this shared understanding more, if they knew how much time, they’d actually save down the line on redundant communication in a team.
And yes, I get it — it seems counterintuitive (…and expensive) to involve the whole team early on and we are afraid to waist people’s time. So, often we leave it to the business people to take the upfront meetings and interviews to understand what is going on and then later, they brief the designers and developers (well hello, classic waterfall).
The Sprint methodology, which we will look at later, provides a very structured and fast-moving approach for engaging the whole team to do customer interviews, prototype, and test in just 5 days (…stay tuned for more!).
Origin 🐣
In 2004, Steve Blank, a now famous Silicon Valley entrepreneur and Adjunct Professor at Harvard, invested in a startup founded by two young students called Eric Ries and Will Harvey.
Steve only had one condition for making the investment; Eric and Will had to attend Steve’s classes on Customer Development and Agile Software Development.
While in class, Eric quickly saw similarities between the emerging set of startup disciplines and the Toyota Production System, which had become known as “lean manufacturing.”
Eric later dubbed the combination of customer development and agile practices the “Lean Startup” and published his now world famous book in 2011. Today, the methodology is taught at more than 25 top universities across the globe.
Process 👣
Launching a new enterprise, whether it’s a startup or an innovation initiative within a large corporation, has always been a hit-or-miss activity.
The odds are stacked against you even before you start, as 75% of all startups fail (Harvard Business Review) and many argue that this number is even higher.
When looking at the succes rate of corporate innovation the story is the same, as 80% of all new product launches are cancelled or deemed a failure within the first year!
But with the introduction of the Lean Startup, the odds are changing. As famous Sillicon Valley entrepreneur and investor Marc Andreessen puts it:
“Eric Ries has created a science where previously there was only art”.
The Lean startup methodology favours experimentation over elaborate planning, customer feedback over intuition, and iterative design over traditional “big up front” development and investments.
Below, you’ll find an explanation of a few key concepts of the Lean Startup process.
Moving from idea to hypotheses
- Rather than engaging in months of planning, entrepreneurs should accept that on day one, their ideas are nothing more than a bunch of untested hypotheses.
- So instead of writing long business plans, founders should sketch out their vision on a business model canvas (cf. Osterwalder and Pigneur: Business Model Generation), which is an overview of how the business plans to create value for itself and its customers.
Get out of the building
- In the early days of a startup, founders should do little else than talking to and testing with potential customers, suppliers, and key partners. They do this in order to get early feedback and to learn more about how to operate their business and who their customers might be.
- In order to elicit that valuable feedback, the founding team design and assemble Minimum Viable Products (MVPs) and test with real customers in real life settings.
Use Agile Software Development
- Whenever software is required, use agile software development to speed up the process, of building small-scale experiments.
As the goal of any startup is to learn in order to reduce uncertainty, and ultimately to reach product/market fit before running out of money, the idea is to get the most bang for your bucks in terms of user testing and feedback.
So, instead of building large scale IT-solutions and only releasing when done, entrepreneurs should build MVPs that take hours or days, not weeks and months and test them with real users in real user settings.
The core engine of this feedback loop is the Build, Measure, Learn-process, visualised below.
Ultimately, you are more likely to succeed the faster and cheaper you can get around the loop, as this will increase your learning by falsifying more of your most critical hypotheses before you run out of money.
Purpose and Application 💡
The ultimate purpose of the Lean Startup is to provide entrepreneurs with a battle-tested method for moving from uncertainty to product/market fit, as quickly and cheaply as possible.
The framework is highly applicable when you have a concrete idea of which problem you are trying to solve, and have a tangible, albeit untested solution in mind.
This differs from the Design Thinking process, which is better suited for tackling very complex and undefined problems.
The Lean process is of course highly applicable for startups but should also find a wide audience inside large corporates looking to solve the classic innovator’s dilemma by setting up innovation activities such as skunk works where innovation is created away from the mothership in order to increase the odds of success.
The Lean process, should not be implemented directly into a large company, as you will need, among other things, a new incentive and governance structure to avoid everything from falling apart quickly.
Principles 🙏
- Hypotheses — treat your idea and potential solution as a collection of untested hypotheses.
- Customer development — go outside of the building (as opposed to desk research) and talk to potential customers and learn all about them and their situation. What tasks are they trying to solve and can you improve the current solution/process?
- MVP — design small and multiple experiments to test your most critical aspects of your business idea.
- Speed — Move as quickly trough the Build, Measure, Lean loop as possible. If you are unsuccessful in creating something that users want and are able to use, make a pivot and pursue another idea.
- Keep it small — don’t build big products/services early on. Try to kill your idea as fast an cheaply as possbile. If you are unsuccessful, in killing your idea, move on to the commercial aspects of building a company around it. Not the other way.
- Cross functional team — the entire founding team should be involved in the validation process.
- Agile — Use Agile software development when building MVP’s where software is required.
My PoV on Lean Startup 🙋
Business model canvas vs Value Proposition Canvas
Personally, I enjoy using the Business Model Canvas (Developed by Osterwalder & Pigneur, 2010) to sketch out my hypotheses.
I view this quick process as nothing more than a visual explanation of my current best guess of how my business should function in order to create value for the users and the company. Whenever I move through the Build, Measure, Learn loop, I update the canvas based on my learnings.
I have however, seen a lot of people struggle with the framework and ultimately abandon it. If you think that it is too cumbersome a process that brings too little value vs time spend on input, I will encourage you to take a look at the Value Proposition Canvas. Here, you only focus on your Customer Segment and Value Proposition, and by such it’s a more accessible framework that people adopt more easily.
Read The Mom Test
If you are not used to interviewing people, it’s easy to fuck up. The quickest way to get better is to read The Mom Test by Rob Fitzpatrick (you should definitely read The Mom Test no matter what innovation methodology you end up using).
Find cues for your micro copy
When talking to potential customers, try to pick up cues on what words your customer are using to describe the pains and daily tasks. Use the same words when writing copy for emails, brochures, and landing pages as this tends to resonate with them.
An MVP is not the first version of your product
I see a lot of people and companies talking about MVPs as the first version of a rather large IT product. They reduce the overall scope by 50% and start building without testing the underlying assumptions along the way.
That is not a MVP.
In fact, it’s simply a bunch of untested hypotheses wrapped into a product that you have little way of knowing whether it will succeed until you launch the whole thing.
That is scary!
When you don’t test often and early, you will fail to remove uncertainty, which is the entire point of the Lean Startup, and any other innovation methodology for that matter.
Most often, MVPs are throw-away experiments, not the first version of your product. Don’t build them to scale, it’s a waist of time and resources.
Minimum Viable Experiment
Don’t worry if your experiment is not a product per se. The objective is to get the required learning to falsify your hypotheses and to keep the experiment small. Nothing else.
Origin 🐣
In the late 1990s, several software development methodologies began to gain public attention. Each methodology had a different combination of old and new ideas but they all emphasised close collaboration between the development team and business stakeholders, frequent delivery of valuable software, and revolved around self-organising teams.
The term “Agile” was applied to this collection of methodologies in early 2001 when 17 software development practitioners gathered in Snowbird, Utah to discuss their shared ideas and various approaches to software development.
Before diving into Agile software development there is something I need to get off my chest…
Agile software development is in fact NOT an innovation methodology… Sorry folks.
It’s a methodology for software development.
Nothing more, nothing less.
Agile doesn’t really belong in an article covering innovation methodologies. But I have included it anyway to make that point clear as I’ve seen numerous people and articles that treat Design Thinking, Lean, and Agile as if they are the same.
They’re not.
However, Agile software development can work very well together with innovation methodologies, and as we saw earlier, it is actually baked into the Lean Startup process.
The other reason for including it is that the underlying principles are very similar to the innovation methodologies that are included here.
Process 👣
The agile development methods break down product development into small time increments, often referred to as sprints or iterations that minimise the amount of up-front planning and design.
Iterations, or sprints, are short time frames that typically last from one to four weeks. Each iteration involves a cross-functional team working in all functions: planning, analysing, design, coding, unit tesiting, and acceptance testing.
At the end of the iteration, a working product is released to stakeholders and users in order to measure success.
This process minimises overall risk and uncertainty and allows the product to adapt to changes quickly based on user feedback.
Key concepts in Agile software development are User stories, Daily meetings, and Incremental development (sprints).
These key concepts all share the same purposes; to remove risk and uncertainty by working in short increments, increase alignment among a cross-functional team, and to produce valuable software that is released often to users to gain relevant feedback. Working software is therefore the primary measure of progress.
Recently, Dave Thomas, one of the creators of the Manifesto for Agile Software Development, proposed a simplified and updated version of the Agile process:
Updated version
- Find out where you are
- Take a small step forward towards your goal
- Adjust your understanding based on what you have learned
- Repeat
This updated process is very similar to the Build, Measure, Learn loop used in the Lean Startup.
Purpose and Application 💡
The main purpose of Agile software development is to reduce risk and uncertainty and increase understanding of users by releasing often. This allows you to rapidly adapt to the feedback that you elicit from your users.
This is a very similar purpose to what we have seen in Design Thinking and the Lean Startup.
In, essence, these innovation and software development methodologies have been developed to mitigate risk, which is also reflected in their processes and underlying principles.
Agile software development goes hand in hand with any innovation methodology, where software is required for developing your experiments, or test designs or MVPs (it’s all the same) to validate your most critical hypotheses.
It’s also a useful process in its own right, if the majority of your uncertainty lies in the feasibility of the technical solution that you are proposing.
Principles 🙏
As the original Manifesto for Agile Software Development is a list of principles, I’ll just copy paste them here.
The Original Manifesto for Agile Software Development:
- Satisfy the customer through early a continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- Face-to-face conversation is the best form of communication (co-location)
- Working software is the primary measure of progress
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility
- Simplicity — the art of maximizing the amount of work not done — is essential
- The best architectures, requirements, and designs emerge from self-organizing teams
- Regularly, the team reflects on how to become more effective, and adjusts accordingly
Notice how there is a special attention to mitigating risk by releasing often and to satisfy customer needs through valuable software. Also, the manifest reflects a very human centered approach to organising and managing a team.
My PoV on Agile Software Development ️🙋
I often see Agile software development being misused as people forget to break down their lofty visions into smaller functional increments. Each increment/feature should be of value to the user in it’s own right, and thus it make sense to create a sprint around it and to release it to users when done.
What I often hear, is people claiming that they are using Agile, as they have broken the development process of a big IT project into small sprints, but at the same time they have no intentions of releasing anything until the whole thing is done.
We should call this uncertainty sprints, as you do multiple sprints in a row without removing any uncertainty, which is the whole point…
No matter how many sprints you divide your project into, you are not using the Agile methodology, if you don’t release self contained functional software often, and hence remove the uncertainty by understanding what users want based on their feedback, and change course if needed.
At the heart of Agile software development, and all the innovation methodologies included here, is a desire to mitigating risk and to create something that users find useful and enjoyable.
Origin 🐣
Pretotyping was coined and developed by Alberto Savoia, who was the first Engineering Director at Google and helped launch the incredible money making machine we now know as Google AdWords.
After developing and using Pretotyping internally at Google for many years, Alberto quit Google in 2012 to devote himself to preaching and practicing Pretotyping.
Pretotyping was founded on the premis of the “Law of Failure” which says that between 75–80% of all startups and product innovations fails, often within the first year….
Alberto saw this pattern when working at Google and wanted to create an experimentation engine that focused solely on finding the right it (Desirability — do people want it) before spending time on feasibility, viability and scalability.
Process 👣
Pretotyping is an actionable framework where data beats opinions. It focuses solely on validating hypotheses early, cheaply, and very fast.
Besides the seven test designs, which will be described later, the two key concepts are ILI and OLI.
ILI = Initial level of interest
Here, you test if there is initial interest from customers and if you have the right solution and if that solution is solving a real problem.
OLI = Ongoing level of interest
Here, you test if your customers are returning and continue to show interest in your offerings.
Each Pretotype consists of 3 key activities:
- Design and Implementation of the Pretotype (D&I )
- Run and Measure the Pretotype (R&M )
- Analyse the results and Decide next steps (A&D )
Pretotyping comes with seven test designs:
- Mechanical turk — Replace complex machines with humans
- Pinocchio — Build a non-functional version of the product
- MVP — Create a functioning version, but strip it down to its core functionality
- The Provincial — Before launching world-wide, run a test on a very small sample.
- The Fake Door — Create a fake “entry” for a product that doesn’t yet exist in any form.
- The Pretend-to-Own — Before investing in buying whatever you need for your it, rent or borrow it first.
- The Re-label — Put a different label on an existing product that looks like the product you want to create.
Pretotyping encourages you to answer the following questions using your test designs:
- Will user use it where they are? (Environment, context).
- Will users adapt in order to use it? (Behavior, switching).
- Will users use it if it looks like this? (Design, gestalt)
- Will users use it if it does/does not have X? (Functionality)
- Will users buy it this way? (Channel)
- Will users buy it if it costs more than X? (Price)
Alberto’s book on Pretotyping is only 71 pages long from cover to cover, so if you find this framework appealing, I highly encourage you to read the free book for yourself, and to possibly expand your vocabulary on test designs and the process behind.
Purpose and application 💡
The purpose of Pretotyping is to find the right it before building it right. That is to test desirability — do people want it — before spending time and money on feasibility, viability, and scalability.
Pretotyping is very useful when you have a good understanding of your users and a concrete, albeit untested idea for a solution.
Pretotyping is a test first, ask later framework, and so it differs a lot from Design Thinking where you spend time researching and defining the problem you are trying to solve, before going into prototyping and test mode.
Pretotyping have a lot in common with the Lean Startup approach, and was developed around the same time. You will find some overlap between the test designs proposed by the two methodologies, however Pretotyping, in my opinion, explains the test designs better.
You should not use pretotyping, initially at least, if you have little understanding of your customers and have a complex and undefined problem. That bridge is best crossed with qualitative research, and so you should dive into Design Thinking.
Also, Pretotyping is not an end-to-end framework covering everything from idea to governance structures of a more mature company, as you can find in the Lean Startup.
Pretotyping only focuses on removing uncertainty and expensive prototypes by testing potential lightweight solutions with customers as fast and cheaply as possible.
Principles 🙏
- Find the right it, before you build it right.
- Fake it before you make it to see if people will actually use/buy the product.
- Create rapid experiments to find the right it, then proceed to building it right, when customer data shows you that they want it and are willing to pay for it.
- Real prototypes are often too slow, Pretotypes should be quick and cheap.
Pretotyping Manifesto
- Innovators beats ideas
- Pretotypes beats productypes
- Data beats opinions
- Now beats later
- Doing beats talking
- Simple beats complex
- Commitments beat commitees
My point of view on Pretotyping 🙋
For me, the real gem of Pretotyping is the seven test designs.
They make test designs tangible and creates a shared and more nuanced language in a team.
While you can find great examples on test designs in the Lean Startup as well as various online courses on Design Thinking, Preotyping simply explains it well and in a very compact format.
If you know the Lean Startup by heart, Pretotyping won’t teach you much new. However, the expanded language and ability around test designs are worth a million when working together as a team, trying to test your hypotheses in a fast and cheap manner.
I often use Pretotyping in combination with qualitative research, so that I first develop an understanding of the users I’m targeting, and have a concrete value proposition/solution in my mind.
I also, find myself going through the list of the seven test designs whenever I hear someone pitching an concrete idea to me with which we need to remove uncertainty (this is always the case).
Origin 🐣
Design Sprint, Google Sprint, or simply Sprint as it is often called, is primarily based on Design Thinking sprinkled with insights from the work of Jason Fried, co-founder of Basecamp and author of Rework and Getting Real.
Just as Pretotyping, the Design Sprint was created inside the walls of Google. This time by Jake Knapp and John Zeratsky who worked together as design partners at Google Ventures, where they helped perfect the Design Sprint by running +150 sprints together with the companies that Google invested in.
In 2016, Jake and John published their now world famous book called Sprint.
Process 👣
A design sprint is a five-day process that tries to answer the most critical business questions through design, prototyping, and testing ideas with real customers.
Monday
- Start at the end
- Agree to a long term goal
- Map the challenge
- Ask the experts
- Pick target
- List sprint questions
Tuesday
- Inspiration, review existing ideas to remix and improve
- Lightning demos
- Sketch solutions, critical thinking over artistry
Wednesday
- Critique solutions
- Decide which one can archive long-term goal
- Create storyboard from winning sketch
Thursday
- Fake it mentality, real enough to test approach
- Turn storyboard into “realistic” prototype
- Prototypes are disposable
- Build just enough to learn, not more
- The prototype must appear real
Friday
- Interview customers
- Learn by watching them interact/react to your prototype
Purpose and application 💡
The Design Sprint is very useful when you have a big and concrete challenge that you want to solve in a short amount of time. The process requires some prep work, as the whole team needs to be involved full time for a whole week.
Furthermore, you need to arrange interviews with key stakeholders and subject matter experts in advance to be able to keep to the tight schedule.
In my opinion, the Sprint framework is especially good if you have not already implemented a successful methodology and therefore, are in need of some early wins to convince people that you can move fast and create tangible outcomes in a short timespan.
I find it especially useful for big companies, where you need a drastic method, almost an intervention, to prove that you can create tangible outcomes in short time.
However, I have also seen it work well with startups, especially in the early days, when you’re trying to solve a key problem or validate if you are on to something.
The big promise that Sprint makes, is that you can test anything in just 5 days, and most often that seems to be true.
Often you need to break down your vision into a very small subset, and test just one core feature. Although tough to do, this is a very helpful restriction and creates a very narrow and easy to test value proposition.
It’s a great framework for onboarding an entire team, creating a common understanding of the problem and solution in a short amount of time.
Principles 🙏
- Understand — discover the business opportunity, the audience, the competition, the value proposition, and define metrics of success
- Diverge — explore, develop and iterate creative ways of solving the problem, regardless of feasibility.
- Converge — identify ideas that fit the next product cycle and explore them in further detail through storyboarding.
- Prototype — design and prepare prototype(s) that can be tested with people.
- Test — Conduct 1:1 users testing. 5 is the magic number, with 5 interviews/tests you will have spottet approx. 85% of all problems you can find at this level.
- Cross functional teams — Get a cross functional team onboard from day one. The Sprint framework is very specific about, which roles should be present throughout the process.
My point of view on Sprint 🙋
Personally, I view the Design Sprint as a lovechild between Design Thinking and Pretotyping. It uses many of the same qualitative interviewing and visual thinking techniques as Design Thinking, and merge that with a fake-it-before-you-make-it mentality found in Pretotyping.
The Design Sprint has many of the same key properties as Design Thinking, where the early exploration and understanding of customers are done by the whole team. With this initial investment of time, you avoid so many meetings down the line by being on the same page from day one.
I highly encourage you to take full days of as a team to complete the Design Sprint. The cross functional team aspect is absolutely key.
Also, in order to spend full 5 days with the entire team, you need quite a big challenge!
Last but not least, if you are a new group of people, just starting to work together on a new project, a Design Sprint is a great way to boost the entire teams understanding of the problem that you are trying to solve.
Wowza! This is getting long… let’s wrap it up 🎁
When to use what
Design Thinking is a great process when trying to solve a complex and ill-defined problem. Its deep-rooted focus on understanding and co-creating with users makes it valuable when you face high uncertainty, both in terms of the problem as well as the solution.
Lean Startup is the right framework when you’re building a startup and need to validate your hypotheses by talking with potential customers and by building and testing MVPs until you reach product/market fit. It assumes that you have a vision and an idea for the product/service that you want to bring to market.
Agile software development is a methodology for writing and releasing software, not an innovation methodology as such. Agile goes hand-in-hand with most innovation methodologies, where you need to build software to validate your most critical hypotheses. Also, the underlying principles are similar to that of the included innovation methodologies.
Pretotyping is the right framework when you have a good understanding of your customers and what you are trying to accomplish, and all you need is the right test to validate if you have found the right it. In Pretotyping, you find seven test designs that are easy to understand and will potentially help you expand your vocabulary on designing users tests.
Design Sprint is especially useful when you have to solve a big challenge in a short time frame, or if you need to convince a group of people, often inside a large company, that you can produce tangible results in just 5 days! I would especially recommend it for teams who have not already implemented a successful innovation methodology.
Common denominators
The common denominator between Design Thinking, Lean Startup, Pretotyping, and Design Sprint is that they all try to answer the same basic question: How to create something new that users actually want and enjoy using when all we have is a bunch of untested hypotheses? How do we reduce uncertainty, mitigate risk and raise our level of understanding?
The unified answer across the board is to gather a cross functional team, take incremental steps forward towards your goal, understand the problem and the people you are trying to create a solution for, and test your core assumptions first by designing tangible experiments called Prototypes, Pretotypes or MVPs (…they are essentially the same). Lastly, learn from the feedback and adjust course if needed, then repeat the process.
The faster and cheaper you can make it around this process, the more hypotheses you are able to test, the more uncertainty you will be able to remove, and the more likely you are of creating a success.
Where they differ
When comparing Design Thinking, Lean Startup, Pretotyping, and Design Sprint the main variables seem to be the extend of qualitative research, ideation and the time frame being used.
On most other accounts, they seem to have a unified view on how to make innovation happen, and thus the underlying principles are very similar.
In the end we need principles, not methodologies to guide our work
While the names of innovation methodologies such as Design Thinking, Lean Startup, Pretotyping, and Design Sprint will inevitably change over time, the underlying principles of innovation are bound to stay the same for much longer.
Without sounding too much like an old fart, the world is changing pretty rapidly. And when presented with rapid change we need principles to guide our work.
So, if you really want to be a proficient innovator, it makes a lot more sense that you study, practice, and truly understand the fundamental principles of innovation, and worry less whether you and your company or startup are up to date with the latest fad that authors are trying to sell us.
In the end, many of the innovation methodologies are teaching us the same thing; how to reduce uncertainty and to create something that users want.
Regardless of the methodology you choose to follow, the process is very context dependent and you should be prepared to spend a considerable amount of time finetuning the process and thinking deeply about how to best unfold innovation in your own company.
Manifesto for Innovation Methodologies 💌
We can summarise the unifying fundamentals of innovation methodologies across Design Thinking, Lean Startup, Pretotyping, and Design Sprint in the following 12 statements:
- Use an incremental and iterative approach to solving problems.
- Deploy a cross-functional team when trying to understand, test, and solve the problem.
- Understand your customers, suppliers, and key partners deeply!
- Treat your ideas as a set of hypotheses that need to be validated with real users.
- Identify and validate your most critical hypothesis first.
- Design a prototype, pretotype, MVP or experiment to get tangible feedback and results on your most critical hypotheses.
- Test with real users, early and continuously.
- Define succes up front (metrics).
- Measure the results.
- Evaluate how your test perform and what you have learned.
- Update your teams understanding of the problem, customers, and the required solution.
- Repeat the process.
Outro 🏁
Thanks for sticking around! I hope you learned something valuable a long the way.
If you have any questions, comments, corrections or simply a better understanding of any of the innovation methodologies, please let me know!
I will be more than happy to update the framework and to give credit to everyone helping out 😀
