The Solution To Design Thinking
And why making is fact, and everything else is opinion
A little over a week ago I posted The Problem With Design Thinking and I wanted to follow up with a piece that explains a bit more about the full-stack approach I described at a high level, as we practice it here at Made by Many.
The response I received from the first piece was really helpful and lots of fun — it’s a reminder of the rewards of blogging, and why it is sometimes helpful to put something a bit half-baked out there and see what happens.
I discovered, for example, that Faris Yakob and Camilla Grey have already used the full-stack label and idea in relation to strategy, and that Daniel Harvey is already using the term ‘full-stack design thinking’. More about that in a bit, because what I want to unpack is the concept of ‘a stack’, and what a ‘full stack’ can mean in relation to product innovation.
This post comes in two parts:
- The first will quickly provide clarifications about what I was trying to say and why.
- The second part digs into the cross-disciplinary approach that we use at Made by Many to tackle product innovation. This is where I want to dig into the ‘full stack’ we use.
Thinking About Design On Brainstorm Island
Firstly, please let me make clear that I am not trying to coin a new label or advocating the adoption of a bullshit new term. I’ll quickly say that again: I am not suggesting we replace Design Thinking with Full-Stack Design Thinking as some seemed to think. Steven Chabot commented:
The solution to a buzz word that isn’t working? Just splice on another one right up front. Good as new.
Nailed it Steven. But I’m not doing that.
I used the prefix ‘full-stack’ to convey a cross-disciplinary approach to innovation which is broader, I think, than that which classical Design Thinking provides. It’s not surprising: Design Thinking came into business use nearly 30 years ago (and its roots go back decades earlier to academe). That’s like a couple of hundred years in Internet time. It’s an approach that’s had a pretty good run for its money, but it’s built on a pre-digital-technology view of the world — a world many orders of magnitude less complex that the one we live in today.
I also take exception to the way Design Thinking calls out — and privileges — design over other disciplines. I know this is often explained away by saying it refers to ‘Big D’ Design. I get that, but I still don’t buy it. In practice it disempowers other disciplines, especially in the eyes of clients and senior stakeholders who may not get the nuance of Big D/little d. It feels like we should just use a different word: maybe we can accept that the world is too complex today to define this using a single discipline at all.
Some people were horrified that I had dared criticise the sacred cow of ‘Design Thinking’ at all, but I’m pretty sure that even IDEO’s Tim Brown would agree. He says pretty much the same thing in his recent blog post about IDEO joining the Kyu collective, ‘The Next Big Thing In Design’:
We need to bust out of siloed design practices.
We need to develop ever-broader capacities, taking an interdisciplinary, deeply collaborative approach.
It remains to be seen how IDEO’s design vocabulary will evolve as all those siloes start getting… busted out of… but it’s clear that the vastly expanded complexity of the world has eclipsed the woolly, feel-good simplicity of ‘Design Thinking’, even for IDEO. This is something brilliant that they gave to the world a long time ago in a spirit of humanity and generosity. It changed the way business (and everyone else) thinks about design and being human. Forever. But it’s run its course.
It’s yesterday’s answer to a different problem.
Secondly, I also got carried away with the Brainstorm Island analogy (hands up — it makes me laugh, and we probably need more humour in such a self-regarding domain as ‘the business we’re in’).
I know Design Thinking is much more than a workshop technique, although I do believe that this is how many people are implementing it. Having given the world Design Thinking it must make Tim Brown cry inside to see the way many practitioners have turned it into a day trip to Brainstorm Island. Yet for all of its awesome strengths, and even allowing for the widespread degradation of the term in practice, Design Thinking is still not enough on its own to create breakthrough innovation and full-stack business models.
Enter ‘The Full Stack’
The Full Stack is a fairly ambiguous engineering term that refers to all the component parts of a single system. It’s a neat concept for describing complexity and is being applied to more and more things: software, people and businesses.
In software it describe all the parts of a system: front-end, back-end, data-stores, server, network and hosting environment, business logic and so on.
In terms of people it describes previously disparate or siloed roles that are becoming more consolidated. For example, in order to build a complete software product you need either multiple developers, or a unicorn-like Jack-of-all-trades sometimes called a ‘full-stack’ developer. I say unicorn-like because there is much debate about whether the full-stack developer really exists, and definitions vary wildly — I’ve even seen the term ‘full-stack designer’ to describe an interaction designer who can code. But for our purposes it doesn’t really matter.
In business, the full-stack metaphor has been appropriated by technology commentators and VCs to define an emerging pattern of start-up business: the ones that are totally bypassing incumbent competition and building entire end-to-end products and services. Examples would include Lyft, Uber, Buzzfeed, Nest, Tesla and Warby Parker. What these companies have in common is that they have redesigned how a market works, or created a new one.
They are not trying to make an existing model work better, they’re reinventing it from scratch using new software.
Chris Dixon at VC firm Andreessen Horowitz coined the phrase, and he describes the breadth of capability required to pull it off:
Full-stack founders care about every aspect of their product/service, so they need to get good at many different things besides software — hardware, design, consumer marketing, supply chain management, sales, partnerships, regulation, etc.
I think these are probably the ‘broader capabilities’ that Tim Brown is talking about. It’s also the reason that IBM recently created its own version of design thinking called — guess what? — IBM Design Thinking. And it’s why consulting firms are buying experience design, innovation and technology shops like there’s no tomorrow.
This, after all, is the really big opportunity in a world transitioning rapidly from business using technology to one that is 100% software-driven. Chris Dixon points to future where big corporates will start doing the same thing as these successful startup innovators:
We’ll start to see many more industries that have mostly resisted technology finally stop resisting now that startups have figured out the right approach to take here.
The big, obvious industries include: education, healthcare, food, transportation, and financial services. All the areas of the economy where prices have outpaced inflation due to lack of technology.
The Full-Stack Approach At Made by Many
At Made by Many we work with startups and big global corporate clients to implement this approach in a product-centric way, through consulting and making. The approach draws on many, many methodologies that we’ve chucked into a big cauldron over the years — including Design Thinking, Agile software development, Lean start-up thinking, service design and systems thinking.
This pot has been bubbling away for nine years. I mean, it hasn’t been a totally smooth process — we’ve made all the rookie errors there are to make, not least the really stupid one that involves repeatedly fetishizing one methodology after another. We win at failing — we did it often and spectacularly. But we’ve ended up with a potent brew that brings design, technology and strategy to bear on a problem/opportunity space all at once.
Product is front and centre, and making is critical: we start with a slice through the full stack of the problem, and we make a solution iteratively and progressively through cycles of:
- Learning: about the business, capabilities, constraints and market opportunities; and also about the end-customer and their needs and behaviours.
- Making: progressively more complete and higher fidelity prototypes.
- Testing: validating both with real customers and people within our client business, including the operational teams who will manage the product, create the content, manage customer service etc.
Making Drives A Bias For Action
We are obsessively ‘making-oriented’ for a good reason: making forces you to commit and creates something testable that you can learn from. In fact, you learn much more from making than you can any other way. Making is a means of discovery as well as being exploratory and generative. We don’t seek to understand everything upfront, and we make something very early: it could be a sketch, a paper or code prototype. It could be a simulated experience or a landing page. It could be that we’re making in order to develop and test the strategy — it’s certainly not always the case that we are making a ‘thing’. Designing complex systems made of people and software often means making an experience — and we have developed a big toolbox of experience prototyping tools. There is no magic. We use whatever works and we’re constantly trying new tools and approaches out.
Making Is Fact. Everything Else Is Opinion
Making is the moment the talking stops and shit gets real. Before that moment everything is just an opinion.
Smart people are the best at talking about things for far too long.
Often when we start working with a client we find that they’ve been talking about making something for two years or even more. The best help we can give them is to break that paralysis by making something very quickly — like within days — that we can interrogate and learn from objectively.
It’s for this reason, in my opinion, that nearly everything we work on actually makes it market. How unusual is that? We don’t spend months creating castles in the sky, design fiction, big decks of sumptuous ideas than can never be realised, or will only come off the rails much later on. Instead, we make stuff that gets progressively more ‘real’, that moves forward quickly and reveals technology, organisational and operational issues, content questions, commercial constraints — the whole problem stack — as early as humanly possible so that we can design around them.
We move through the whole stack, all at once, very fast, through making.
Cross-Functional Workflow. Multi-Disciplinary Teams
To work through the whole business stack at high velocity and not explode, you need a cross-functional workflow delivered through truly multi-disciplinary teams.
Our ‘atomic unit’ of team at Made by Many brings three core disciplines together in a single cohort that works on a problem for a client at every stage of the engagement.
And yes, they sit together but — as we all know — that’s not a true measure of integration. I mean, it’s better than sitting in a different building, or continent, but in our teams no single practice area leads: it’s a force multiplier and it’s our superpower.
We’ve created a machine that renders insights and ideas into code in almost-real-time on a continuous and self-correcting basis.
Each practice area extends the capabilities of the others. They learn together, and they share responsibilities for the client, the idea and the project. Teams are drawn from three overlapping practices:
- Strategy: strategy is called Product Management and encompasses business and product strategy, Agile/SCRUM and human insights.
- Design: we call it Product Design and it’s a blend of interaction design and service design with a systems design bent.
- Technology: we call this Product Engineering and it spans tech strategy, front- and back-end development, DevOps and QA.
Product Thinking is the new Design Thinking
Our full-stack approach contains liberal helpings of Design Thinking but, rather than trying to define the approach through the lens of one discipline à la Design Thinking, or even Full-Stack Strategy) it acknowledges that a broader and more deeply integrated capability-set are required to solve really complex problems and build adaptive, emergent systems and businesses.
It’s a shame we have to use words — but we kind of do — and they’re important, but by continuing to call it Design Thinking we are in danger of allowing ourselves to pretend that it’s easier than it really is. Product Thinking is probably a better term to describe this more expansive approach to innovation — taking a full-stack approach to product innovation, because a successful product means the whole business stack working together: the people, workflow, experience layer, technology and model.
And in the end, let’s not forget, it’s all about impact.
