The Design Thinking and Lean Startup Models Are Broken. Here Is the Innovation Vortex!
Before I plant my feet firmly on some sensitive, long toes in the Design Thinking and Lean Startup communities, let me start on a positive note.
I love the ideas in Design Thinking and Lean Startup!
Getting out of the building, empathizing with users, developing prototypes, running experiments, and doing it all in rapid feedback cycles, it makes total sense to me. No problemo. Count me in! In fact, I teach and discuss all of that in my Shiftup workshops.
However, it is time for some improvements because the popular models are broken. There are three-and-a-half issues I’d like to fix.
My first issue is that feedback cycles, iterations, and increments are a fundamental aspect of Lean, Agile, and Design Thinking. So, why is it that the two best-known design thinking models always picture the process as a linear sequence of steps?
Every Design Thinking expert explains the need for an iterative, cyclical approach to design. So, why don’t they draw their models in an iterative, cyclical manner then? In a world where customers tend to implement design and development as waterfall approaches consisting of cascading stages, shouldn’t design thinkers be the first ones to realize that their visualization of the process needs a redesign?
Ironically, it’s the Lean Startup model that does a better job of emphasizing a feedback cycle, even though, paradoxically, it is the Lean Startup model that ignores the crucial parts that design thinkers are so good at (see my next rant).
On top of that, the idea that there are concrete steps or stages is misleading. This language suggests that your work can only be in one step/stage at a time. But design thinkers acknowledge that different people can sometimes be working on different things. While some team members are observing users, others could be evaluating test results.
Let’s agree that the popular visualizations are in need of an update. We should stop portraying Design Thinking as a couple of sequential boxes. Let’s not do that anymore. Boxes are só last century.
We should stop portraying Design Thinking as a couple of sequential boxes.
The first step in Design Thinking, according to the two best-known models, is about empathizing with users and customers. But which ones? How do you know which users to approach for interviews? How do you know which customers to observe? My second issue in this lengthy critique is that an important step has already been made before empathizing. It is the decision which people deserve our attention and which ones will have to wait for another time.
We cannot solve all problems in the known universe. So, what part of the world has our focus and what parts do we ignore? What is the context in which we seek to create solutions? If we must believe the popular models, design thinkers just jump in and start watching users and customers that seem to drop out of nowhere. Shouldn’t we draw some boundaries first of which people are in-scope versus out-of-scope? If you don’t include context as part of your model, nobody on your team might say to the others, “You know what? I think we’re looking at the wrong users.”
But don’t feel embarrassed, dear design thinkers, because the Lean Startup model is even worse! It says that we should Build, Measure and Learn in an endless cycle. That sounds great, but… Build what? Where do the ideas come from that we’re going build? Do they just drop from the sky? Do they emerge under the shower in the morning? Are they offered to us in a 200-page requirements study? (The answer is three times: No.)
Sure enough, the creators of Lean Startup go out of their way to say it’s vital to Get Out Of the Building, to understand the needs of customers, and to generate hypotheses for improvements that should be tested with lean experiments. But if that’s true (and it is) then why doesn’t the Lean Startup model show the explorations and hypotheses? Someone did a pretty lousy job summarizing the entire method. Perhaps this person wanted to get out of the building a bit too fast.
Why doesn’t the Lean Startup model show the explorations and hypotheses?
Design thinkers at least recognize that getting out of the building (which they call Empathize or Discover) needs to be included explicitly in the model. The same applies to synthesizing your learnings (which they call Define) and hypothesizing possible solutions (referred to as Ideate). Each of these responsibilities is mentioned by lean startuppers, but sadly omitted from their model.
While design thinkers do a better job with the early steps, lean startuppers are the ones who can claim a better ending. As anyone with a Lean-Agile mindset knows, continuous improvement is at the center of both Lean and Agile thinking. And it is often said that the retrospective is the heartbeat of an agile project. That’s why it pleases me to see an explicit step called Learn in the Lean Startup model. After measuring everything that is relevant about customers, users, and ourselves, it is worth taking a step back from our work to reflect and learn before the cycle starts all over again.
However, if I’m honest, I think that the Learn step in Lean Startup is not what it’s supposed to be. Most examples offered by lean startuppers are only about learning from customer feedback. They are rarely about learning about the value stream, working on process improvement, and addressing team performance. This is where Lean and Agile methods shine and I am in favor of elevating the Learn step to a level that would make systems thinkers proud. But let’s offer credits where credits are due: Lean Startup has a Learn step.
And what do we find in the Design Thinking models? Nothing of the kind. Well, to be honest, learning and reflection are certainly discussed in Design Thinking literature and it is perhaps implied as part of their final Test/Deliver step. But when these models already (unintentionally) look suspiciously like a waterfall approach, then it doesn’t help very much that the most fundamental of all steps, continuous improvement, gets a backseat that is out of sight and thus easily forgotten. Let’s conclude, which was my third issue in this post, that we must include continuous improvement in our models explicitly.
We must include continuous improvement in our models explicitly.
Good writers know that three is the magic number. So it pains me a bit to add a fourth issue to my list. But I feel it must be done. However, it is a small one, so maybe we can call it issue three-and-a-half.
Why is the method called Design Thinking? Is design more relevant than development? Is thinking more important than doing? I don’t think so. The models described in this article are as much about doing development as they are about thinking design (not to mention doing design and thinking development).
The name Lean Startup makes not much sense to me either. Is Lean more relevant than Agile here? Is the iterative model just for startups and not for scaleups? Again, I think this is not the case. An agile scaleup benefits just as much from continuous innovation as a lean startup (as well as agile startups and lean scaleups).
There, I just used the better term that Design Thinking and Lean Startup are all about: continuous innovation. Neither design nor development, thinking nor doing, lean nor agile, and startups nor scaleups are the goals here. These concepts are all means to an end. The real goal is for organizations to survive and thrive through iterative and incremental innovation.
The real goal is for organizations to survive and thrive through iterative and incremental innovation.
Without continuous innovation, organizations die; products disappear; people lose their jobs, investments go down the drain; and everyone involved feels a bit pissed. So, in a world that is always evolving, organizations shouldn’t just keep up with change, they should embrace it, fuel it, and drive it. That requires innovation. Continuously.
The Shiftup Innovation Vortex
I am not a great thinker or doer. My strongest talent seems to be stealing ideas from the best, tweaking them to my liking, and mixing them in such a way that the combined result is more attractive, and more digestible, than the individual parts. I call it the Mojito Method. I have done this successfully many times before. In this case, the ingredients were Design Thinking and Lean Startup, and the result is Continuous Innovation, visualized with the Shiftup Innovation Vortex.
First, the Innovation Vortex shows there are no separate, sequential steps in a continuous innovation approach. Instead, there are seven streams of activities that all swirl together in a dynamic-looking model that will hopefully blow its way through your organization soon. Yes, there is a logical order to the seven streams. But it is also true that different team members can do useful work in multiple streams, or even all streams, at the same time. The whole vortex is spinning like crazy!
Second, unlike the Design Thinking and Lean Startup models, the Innovation Vortex recognizes that there is a first stream, called Contextualize, which is about defining context, focusing and unfocusing, and it is as important as the other streams. The Empathizing stream makes no sense when you haven’t carefully considered which people to empathize with.
Third, the Innovation Vortex also recognizes that there is a final stream, called Systematize, which is about learning and improving the whole system, in ways that will be familiar to Lean-Agile practitioners and systems thinkers. It is an integral part of the model and not just something that should be taken for granted.
Third-and-a-half, the Innovation Vortex has a cooler name and a more impressive visual. Think whirlwinds, tornados, spinners, hot milk in your coffee, or getting sucked into alternate dimensions. It also has lovely colors. In a future update, it might even show a unicorn in the middle. Entrepreneurs and venture capitalists would crawl all over it, I’m sure.
Now, let the debate about this new and improved model begin. I hope that my fans will love it. I’m sure that the haters will hate it. But continuous improvement should also apply to the innovation models themselves.
Just don’t forget that, as I said at the start, I love the concepts offered in Design Thinking and Lean Startup. Everything makes total sense to me. But their visualization models are broken. When the actual goal is continuous innovation, it makes sense to describe all the work that teams need to do with a model that is itself a little bit more… innovative.
The Innovation Vortex is also featured: