I guess if you landed here you are confused. That's okay because it is confusing. Well, at least if you try to look at it from a binary, reductionist, point of view.
Let me start by saying that, in my experience product developing, it is never about choosing between one or another (IMHO).
If you are still here after reading through the first paragraph it means you are also not looking for a silver bullet methodology. Great, me neither. The pursuit of a Holy Grail innovation methodology is a silly narrative that serves the purpose of keeping the lights on at innovation consultancy firms. I'm not rocking this type of business initiative. Nothing to worry here. So, let's get to the bottom of it—no strings attached.
When we look back at the Industrial Revolution, we see the origins of the production processes that evolved to become today's Lean practices and ultimately served as inspiration for the Lean Startup approach.
However, what many do not know is that Design was born at that very same age, out of the same influences, struggles and technological advances brought on by the mechanization of humankind. As siblings sharing the same mother, they, of course, have their differences.
Both attitudes are needed to build a product so, in the end, it is not a matter of choice between Lean Startup and Design Thinking. There should be no science without empathy, and innovations are only useful if they leave the sketchpad.
That being said, there is no point in focusing on being fast if you are not also striving to build an emotional bond with the people you intend to serve. After all, you don't want to end up creating something pretty fast that no one will give a damn about.
Design Sprints carry Design Thinking at its core, and as such, they add three major superpowers to the mix when compared to standalone Lean Startup practices.
Techniques that give the team the opportunity to deep dive into the challenge before trying to solve it, resulting in less hip-shooting when brainstorming new ideas.
Tools that allow the team to co-create with the very same users they intend to serve. The chance users are already working to overcome their challenges is high. Worst case at least they have put a lot of thought into it.
Design Sprints use fast early prototyping techniques to help the team and users work together to test solutions, way before they commit resources to build them up.
These three key superpowers — Deep dive, Co-Design and Simulation — have the power to completely upend certainties, opening space for new quality discussions that will most likely create a positive impact in whatever it is that you are building.
I know what you are thinking, that's too old of an example. Well, you are right, but stick with me here and you may learn something new about this superhyped gadget.
The iPod is arguably one of the most iconic pieces of 21st-century innovation. Shortly after Apple managed to engineer a way to put a thousand songs into everyone's pocket, a question remained: How will people browse through all these songs?
I'm not sure they sprinted through this though. However, what I am sure about is that instead of obsessing over creating a new and super advanced browsing control, Apple's designers stepped back in time and found inspiration on the old radio dial.
Although the iPod was a unique and modern device, the choice to make use of such familiar control gave users the immediate impression of familiarity. The easiness to browse songs delivered the final blow to the super clunky MP3 players market back then.
The Design Thinking approach focuses on stepping back, absorbing the challenge's big picture, looking around, and getting inspired before moving forward into developing a solution. Its sibling, engineering thinking, takes a troubleshooting approach to solve problems, isolating variables and addressing issues as they present themselves.
As a designer and software engineer, I find myself having to switch modes pretty often. It is not comfortable, and usually, it costs me a full day of stupidity to switch from Gestalt (design) to troubleshooting (engineering) mode.
I tried to design screens thinking like an engineer, and code them feeling like a designer, trust me you don't want to do that. The first resulted in horrible functional crap; the later had me spinning around trying to find better ways to write code I should have pushed to Git many days before.
The Lean Startup approach preaches teams should be laser focused in finding a Minimum Viable Product; A minimalist solution that has had its viability verified, and then asks the team to test this minimal solution with real people to see how they feel about it.
My primary goal when founding the Design Sprint School was to cast a light on this discussion by, along with tools and methods, providing entrepreneurs and product managers with a solid intellectual discourse to be employed whenever trying to convince peers and their leaders about the value Design Thinking and Service Design can bring into the product development mix.
Lean Startup tests ON people.
Lean experiments are scientific experiments. Hypotheses are formulated by the project team "inside the lab", then tested on users. A classic scientific test is the A/B test, in which users are presented with different versions of the solution. Each user then gives feedback about what they've seen, and the winning version moves forward.
Sounds reductionistic, right? That is because it is.
By presenting two choices, scientists are literally trying to reduce the number of variables being tested which helps to determine variation from sample to sample more easily.
This is not to say A/B scientific tests are not useful, they are, but they usually shine after the idea generation stage is over and the goal is to uncover incremental change opportunities and errors in the proposed designs.
Design Thinking tests WITH people
It approaches testing sessions in a more collaborative way. When experimenting with users designers think of users as co-developers.
During a Design Sprint prototyping session, users will not only test but may also take the role of designers themselves. They are given the power to ideate fixes and improvements, and even to help the team think of new possible solutions. These tests go beyond the dilemma of A/B hypotheses, resulting in richer and often unexpected solutions.
Contrary to the Lean Startup approach, users in Design Thinking are not necessarily customers or "Earlyvangelists," people likely to buy early from you.
Design Thinking extends the term 'user' to represent any actor relevant to the challenge at hand. This is key when working with complex challenges like healthcare-related ones. When tackling healthcare challenges, friends and family members are as important as doctors and patients for the co-design and simulate phases.
The Lean philosophy was created during post-war times in Japan with the sole objective to find ways to fine tune the machine and increase production efficiency in factories.
The Lean Startup philosophy treats the original Lean's obsession with production-value, namely efficiency, as the same as end-users value, namely human emotions.
But these are completely different animals. Production value is about efficiency, sometimes at any cost. User-perceived value is driven by meaning and often goes against efficiency.
If humans were always bound to choose efficiency over meaning, all kitchens would look the same. They would be designed for maximum efficiency in meal preparation.
Needless to say, that is not the case.
I mean, there is a degree of efficiency you want in your kitchen, of course, but it stops when ugliness and discomfort start to show up in the model. Then you ditch the efficiency mindset in the pursuit of comfort, beauty, and other intangible, very hard to measure emotional values.
Like the cooking spaces you find in high-schools, prisons, and other high-efficiency driven facilities. Trust me most people don't want theirs to look like that.
Production value is not the same as the user-perceived value. As such, generating the first is not the same as having created the latter. The Lean Startup book makes this jump and fails to mention it. People was left talking about "creating value", without realizing there are two very different meanings to the term.
Focusing on viability first and then, only then, running experiments on people to determine if they like it, even if on a minimalistic level, is still wasteful.
Based on the scientific or lean startup approach this would mean executing the following steps:
1. Think about things you consider cool and that you can afford to buy.
2. Pick one of those things.
3. Try and see if they like it. If not, learn something and go back to step one.
Alternatively, if you use Design Sprints you would be doing the following:
1. Deep dive in the way this person live, work and relate to others.
2. Now, think about things that would be of good service to this person and that you can afford to buy.
3. Try and see if they like it. If not, learn something and go back to step one.
As you can see, it is smarter to anticipate what is valuable to users first, and this can be swiftly done with a Design Sprint.
As someone who has dedicated the last five years to educate product developers on how to Design Sprint, and that launched a book about it two years before Google Venture's released theirs, I confess I am biased, but here goes my truthful perspective:
As a movement, Design Sprint is already bigger than Design Thinking ever was, and this is only the beginning. It will become ubiquitous. The ability to Design Sprint a project will be as necessary for a product developer as the management skills required to get it off the ground. Learn it.
Don't have an account? Join Now
Create a Core77 Account
Already have an account? Sign In
Please enter your email and we will send an email to reset your password.
It is an interesting article. Despite of some minor differences, I believe that both methodologies are sharing a lot of commonalities. Before I read this article, I had thought that the Spring methodology is part of lean methodology and the latter is the basis for startup creation and growing.
Yeah, it makes sense to think like this cause we sometimes try to streamline things too much. Just the way we are all trained to think of things and solve problems. But I believe there is a lot of power in thinking lean and design as one engine constantly feeding each other in an ever-evolving experimental loop.