Create first, research later
Leo Frishberg presents a new methodology to help minimise the risks involved with inventing new products
Here’s a problem: You’ve been working on a super-cool project for a couple of sprints, only to discover the end users don’t really need whatever it is. Or you’re part of a startup, focused 150 per cent on getting the technology stood up, but your friends and family don’t understand the reason for the thing you’re building. Or you’re the product owner on an agile team, buried deep in the enterprise. In spite of being trained in product ownership, you don’t have a good sense of the end user’s expectations — only the business group’s ‘requirements’. What do you do now?
Let’s be clear: inventing the future is hard. Really hard. The statistics bear it out — less than 10 per cent of startups are still in business two years later; less than 10 per cent of new ideas become profitable … ever. So given the likelihood of failure when embarking on something new or disruptive, how can you reduce that risk?
A new approach
One approach, the approach I’ve been using for over 20 years, rests on a simple notion: Fail fast, intelligently. You may be familiar with the ‘fail fast’ part — a viral meme of recent past — but that modifier (‘intelligently’) makes a huge difference.
My personal approach is called Presumptive Design (PrD) and with Charles Lambdin, I have written an entire book about it. It’s not that I invented the process — rather, we took the time to write it down. In a nutshell, PrD is a method to rapidly reduce the risks involved with inventing the future.
PrD is an agile-like method, meaning it embraces many of the same values promoted by agile culture. It is based on five principles, but these offer guidance to reducing risk rather than being hard-and-fast rules. You are free to figure out how to apply the principles in your own organisation as appropriate to your context. Let’s take a closer look at each of those five principles.
1 Design to fail
This is the key to PrD: You design an artefact you know will fail. Wait, I hear you protest, nobody in my organisation will let me design something we know will fail! That’s crazy! But the fact is, almost all organisations offer products, services and outcomes that fail. The problem is that, in the most extreme cases, they fail after spending millions of dollars.
Instead, we promote the notion of failing intelligently. ‘Design to fail’ means you start with the expectation your artefact will fail. You begin the process knowing you are intentionally designing something that will provoke critical reactions from users.
2 Create, discover, analyse
The typical approach to inventing the future starts with research. The research leads to deep analysis to find meaning behind the results, proceeds to conceptualising and ends up in a design. PrD turns this on its head: you begin by creating an artefact, then offer this artefact to your stakeholders during the discovery phase. Then you figure out what their reactions actually mean.
3 Make assumptions explicit
One of the biggest challenges to inventing the future is the assumptions we rely on; assumptions about who will be living in our imagined future, what they will value, feel and do. Sadly, most organisations fail miserably at surfacing any of those assumptions explicitly during the product definition phase, and products get imbued with all sorts of intentions that are not aligned with external stakeholder values.
This is the toughest principle to apply effectively. But consider the old maxim: Half the solution is in the statement of the problem. The purpose of PrD is to get key internal stakeholder assumptions out in the open, and get these assumptions rigorously tested out in the field without creating a bona fide solution.
We care deeply about the assumptions behind a design brief because if those assumptions are wrong, the entire downstream workflow is at risk. The most expensive way to discover you’re working on the wrong problem is to build the solution.
4 Iterate, iterate, iterate
You don’t know just how much you’ve failed, or in what ways, by working with a single stakeholder. You need to see a few folks before you can be confident of how wrong you were at the start. While there isn’t a hard-and-fast rule for how many people you need to see or how many times you need to repeat the process, we like to say you should do it until you run out of time, resources (people or money) or lessons learned (saturation).
5 The quicker you go, the sooner you know
Consider the first principle: Design to fail. You are going to fail. On purpose. You aren’t going to avoid it, no matter how much time you spend on the artefact. In fact, that misses the point. So why delay getting the artefact in front of your customers? The only reason for delay comes from calendars — it may take a week or two to get appointments with your stakeholders. If the stakeholders are available, you’re ready to go.
Putting it all together
Consider this case study that illustrates the principles of PrD in action. A small manufacturer of high-end network digital audio/video equipment (we’ll call it TrwoSound) was interested in expanding its products and services. To do this, it needed to move aggressively into software products.
In the PrD ‘creation session’ (a workshop in which internal team members align on their assumptions), key TrwoSound stakeholders brainstormed about potential software applications they believed their customers could use. These took the form of simple paper prototypes of various screens representing new functionality — new to both TrwoSound, and, they presumed, new to their customers (principle 1: Design to fail).
Over a period of a few weeks, the design team visited handfuls of TrwoSound customers, offering the artefacts in ‘engagement sessions’ — interview sessions with external stakeholders (principles 2–5). In most cases, customers didn’t understand the offerings, or more importantly, offered clear reasons why these putative solutions wouldn’t work in their context.
Superficially, it sounds like the process was a complete failure, but just the opposite is true! The results were a resounding success on a number of levels:
- The TrwoSound team quickly aligned on a set of assumptions, many of which they didn’t even know they had
- TrwoSound’s customers had the opportunity to critique those assumptions, not through a simple survey or interview, but by reacting to an artefact that embodied those assumptions
- TrwoSound inexpensively determined how far off their own assumptions were from their customers’ without building anything other than a provocative artefact
The bottom line
PrD is an agile way to reduce the risk of inventing the future. It enables internal teams to imagine a desired future within hours, quickly capture reactions to that imagined future from their intended audiences, and do so less expensively than any other research method I’ve ever used. In the end, PrD raises your confidence that you and your team are solving the right problem.
Leo is currently principal at product strategy consultancy Phase II, and has a strong experience-centred design philosophy
This article originally appeared in issue 283 of net magazine
