For all its promises as a sure-fire route to successful innovation, ‘design thinking’ has fallen short of its potential of helping organisations design viable new services and businesses — ie ones that make money.
In response, we’ve seen a growing push toward what we call viability-led design. Business design has grown as a discipline within agencies, innovation labs are hiring for ‘viability leads’ and new agencies (such as ours) have been founded on these principles.
The common theme is that design thinking methodologies don’t actually scale well from designing physical and digital products into effectively designing viable new services and businesses.
Viability requires a business model — the combination of a proposition, a delivery model, and a commercial model — that can make money, and do so in a competitive market. Doing this requires a fundamental shift in practice. When you move from designing a product for a customer, to designing a business model that can win in the market, you can't just reapply the existing methods, structures and culture.
So here are the four ways to adapt design thinking methods to designing for viability.
1. Define the business model before designing the service
A business model is a system of value creation, delivery and capture. And the nature of any system is that they are interconnected and chain-linked. In short, you can't design one part without flow-on effects on other parts.
But too often in traditional design methods, we see the ‘product’ brought to a level of definition before we have considered the rest of the business model — the service model, the operating model, the distribution model, the profit model.
As an example, we were brought into an innovation project for a big retail bank recently to help with the ‘viability’ of their design (on an ongoing project alongside one of London’s best product studios).
The design agency had been wrestling with a key decision on the revenue model — whether the service would make money via acquisition onto bank products, subsidisation by partner advertising, or through standalone pricing (or a combination thereof).
This had a big impact on product design. If it needed to make money with standalone pricing, then the product needed to create considerable value to drive purchase, meaning it should be rich with features and highly relevant and should target a relatively narrow market ('thin and deep'). However, if this was just an acquisition channel for bank products, then it could be relatively light on features, solve a more generic problem, and target a wider audience ('shallow and wide').
In one innovation project product design had progressed for 8 weeks before fundamental decisions about revenue model had been resolved.
The revenue model defined the product direction. And this branching of the product design needed to happen at the very start of design, given it suggested fundamentally different product directions, and research focus. Yet product design had progressed for 8 weeks without addressing this.
This wasn't the only conflict. Channel choices drive business model choices. The design agency wanted to create a standalone brand. But building a viable acquisition model probably meant leveraging bank channels. The bank wouldn’t let the proposition into the channel unless it was bank-branded. But if it was bank-branded, the broader market would think that the service was for bank customers only, limiting total adoption and market potential.
Clearly, some of the design choices weren't 'feasible' together. And the choices of target market, the channels we could use, the appropriate revenue model, the product design and the viability were all interdependent. In this case, target market (and therefore product choice) was an outcome of brand choice, which was an outcome of channel choice, which was an outcome of customer acquisition cost and bank policy.
This is why you need to think about the design of the business model holistically and realise the parts are all fundamentally interconnected. There is no way to design a product or service then wrap the rest of the business model around it. Instead you need to diverge at the level of the business model overall, explore different paths and the seemingly-viable variants you have. Then you need to quickly invalidate them to narrow the solution space before you can really get into building out product/service design.
But in the end, the only true measure of ‘the best design’ in the will be viability, i.e. which design has the highest probability of generating the greatest returns.
2. Design backwards from viability
Design thinking teaches us to start with the customer, and focus on ‘desirability’ first. But the initial idea — that innovation should start with the customer (and not a spreadsheet or a technology solution) has been lost along the way. Somewhere along the way it came to mean ‘design for desirability, and then build the business case for it’.
The problem is, in business, economic profit is a boundary condition - a hurdle that must be met. Simply, if the economics don't work, nothing works.
To design for viability, we need to turn design methods on their head.
To design for viability, we need to turn design methods on their head. While we need to 'start with' finding something customers want at a high level (i.e. a problem to solve and a rough solution), from there we need to design backwards from viability. That is, starting with the hurdle economics and assumptions, and asking what needs to be true of the design to deliver this.
Reversing the perspective allows us to see the assumptions we are making, where the unknowns are, and what the constraints are to guide our design. It sets out the questions that need to be answered: how ‘desirable’ does this need to be? What does our service model need to look like? What cost structure can we absorb? What price point is required? It may mean making a service less desirable, and to less people, if it means the cost structure is better or there is less competition.
In essence, the entirety of the design process needs to solve for ‘what needs to be true for this to be profitable’. And all decisions made in service of this goal.
3. Addressing feasibility broadly
Design thinking teaches us that to be successful, something needs to be ‘technologically feasible’.
Certainly, technology is often a major constraint — especially in corporations with legacy systems. But feasibility is a much broader concept than the ‘technological’ focused on in most design-led processes. Really we're asking: 'can we deliver this?' and 'how much will it cost?'.
Really we're asking: 'can we deliver this?' and 'how much will it cost?'.
This can mean anything from "can we access these channels?", to "can we access these resources or investment?", to "will company service level agreements (or risk policies/architecture policies/regulation/culture) allow us to run this service model?".
If you've ever done innovation work you'll recognise all these battles, and know full well that any can be mortal threats to delivery. So feasibility needs to consider more broadly the constraints of the system you are designing in.
At the same time, 'feasibility' (like desirability) is often a spectrum. Many things are ‘feasible’ if you're willing to pay for them. A bank project we had been brought into had a business case reliant on assumptions about a digital-first service model. The only problem: the service levels proposed conflicted with bank service level agreements. Aligning them blew up the service model and the cost-to-serve assumptions, in turn blowing the economics overall.
To avoid ending up in an unprofitable dead-end, designing for viability means expanding the feasibility lens, asking "can we do this" broadly, and understanding the financial implications of these calls.
4. Designing for distribution
There are not one, but two, customer-facing aspects to a business model: The ‘offer’ (what you sell) and the 'distribution' (how you create and capture demand for it). These roughly map to the core drives of a business’s economics: Customer Lifetime Value (CLV), and Customer Acquisition Cost (CAC).
Traditional design methodologies often treat distribution as an afterthought. But to design for viability, we need to bring it front and centre.
As Peter Thiel puts it: “Poor distribution — not product — is the number one cause of failure.
Customer acquisition cost (CAC) is often the larger hurdle to overcome for any new venture. Getting access to customers at scale and converting enough them is incredibly expensive. Many leading VCs have made this point, including Peter Thiel: “Poor distribution — not product — is the number one cause of failure” and Marc Andreesen: “Many entrepreneurs who build great products simply don’t have a good distribution strategy… a16z is a sucker for people who have sales and marketing figured out.”
When I led the strategy team at a large Australian corporate, consultants would always come to us with stories about the threat of certain ‘disruptive’ startups in the industry. But often with nothing but a simple back-of-the-envelope calculation, we could see that they were never going to survive their CAC and could safely wait them out..
Second, as Brian Balfour explains here, products need to be designed for channels and not the other way around. Your channel choices will inform the product design, and because they are both fundamental contributors to viability, neither is more important. Despite the focus on building breakthrough products, many a business has been built off an undifferentiated product with a distribution advantage.
The good news is we can adopt very similar methods to designing a product or service to design a distribution model: starting with a deep understanding of buyer behaviour, to then frame, concept, prototype and validate different models.
But until you've got a handle on distribution, you're designing for viability in the dark.
In summary:
Simplifying complex practice into four simple lessons doesn't really do it justice, but these are the primary shifts we think are needed.
Put simply, the methods, structures, capabilities and cultures fit for designing something beautiful and useful for a user don’t necessarily translate to the design of a business, where you need to solve for the economics, the interconnection of parts, and the broader dynamics of competition, buyer behaviour and markets.
Doing this well requires a fundamental shift in the practice, methodology and culture of innovation labs and their design agencies and product studio partners. It’s also why my partners and I left Fjord, DigitasLBi, and EY-Seren to start Class35. To turn product/service design into business design, and adapt the practice to the problem, separate from legacy cultures, methods and capabilities. Or as we say, design for the bottom line.
Designing products | Designing businesses |
Feasibility means “can it be done technologically” | Take a broad lens to feasibility, considering everything that is required for the target design to be achievable |
Focus on product desirability | Design the distribution model in parallel, and in the same way you would product, starting with a deep understanding of buyer behaviour |
Define the service first, then wrap a business model around it | Start with the business model overall before bringing definition to the parts, allowing for iterative feedback between them |
Desirability above all else | Design backwards from viability, asking ‘what would need to be true’ and using it to set direction and constraints for the design of the elements |