Originally published in “.NET” magazine, Issue 283, Summer 2016. (That version can be viewed on Medium)
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. What do you do now?
You’re part of a startup, focused 150% on getting the technology stood up (and a smoke and mirrors demo ready for the next investor pitch) but your friends and family don’t understand the reason for the thing you’re building. What do you do now?
You’re the Product Owner on an agile team, buried deep in the enterprise. In spite of being trained on Product Ownership, you don’t have a good sense of the end-user 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: < 10% of startups are still in business 2 years later; <10% of new ideas become profitable…ever.
So given the likelihood of failure when embarking on something new, disruptive or innovative, what can you do to reduce that risk?
< 10% of startups are still in business 2 years later; <10% of new ideas become profitable…ever.
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 “fail fast” – a viral meme of recent past – but that key modifier, failing intelligently*, makes a huge difference.
I call the approach “presumptive design,” and with my co-author, Charles Lambdin, have written an entire book about it. It’s not that I invented the process, (it’s used by many different people and firms and has lots of different names) rather, we took the time to write it down.
Tweet this: Presumptive Design (PrD) rapidly improves the odds of your success in inventing the future.
PrD is an “agile-like” method, meaning, it embraces many of the same values promoted by agile culture. For example, PrD is based on five principles, but because it is agile-like, the principles are not hard and fast. They offer guidance to reducing risk, but the principles are not specific recipes. You are free to figure out how to apply the principles in your own organization as appropriate to your context. (In the book we provide a lot of examples of how to apply the principles.)
Principle 1: Design to Fail
This is the key to PrD: you design an artifact you know will fail. Wait, I hear you protesting, nobody in my organization will let me something that we know will fail! That’s crazy! But the fact is, almost all organizations offer products, services and outcomes that fail. The problem is, 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 artifact will fail. You begin the process knowing you are intentionally designing something that will provoke critical reactions from users.
Principle 2: Create, Discover, Analyze
The typical approach to inventing the future starts with research (diagram on left). In the best processes, the research leads to deep analysis to find meaning behind the results, proceeds to conceptualizing and ends up in a design.
PrD turns this on its head: it begins by creating an artifact, offering that artifact to your stakeholders during the discovery phase and then figuring out what their reactions actually mean (diagram on right).
Principle 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 think will be important, what they will value, feel and do.
This is the toughest principle to apply effectively. It’s the one we spend a lot of time in our workshops to help people internalize. But consider the old maxim: half the solution is in the statement of the problem. We care deeply about the assumptions behind a design brief because if those assumptions are wrong, the entire downstream work flow is at risk. Tweet this: the most expensive way to discover you’re working on the wrong problem is build the solution.
Principle 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. It’s possible the first individual you work with is way off base! But if you hear similar reactions to your assumptions from several people, you can be more certain where you didn’t get it right.
There isn’t a hard and fast rule for how many people you need to see, or how many iterations you need to go through. After a handful of iterations, you will likely hear similar reactions. We like to say you do it until you run out of time, resources (people or money) or learning (saturation). Armed with this new information (reactions to your assumptions) you can reconsider your original problem, possibly finding a more profitable problem to address.
Principle 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 artifact. In fact, that misses the point. Failing is built into PrD. Why delay getting the artifact 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. But from PrD’s perspective, there’s no reason to wait– if the stakeholders are available, you’re ready to go.
Putting it all together
Consider this case study that illustrates the principles in action.
A small manufacturer (we’ll call them WdGits) is interested in expanding its products and services beyond its long-standing premier offerings. They have excelled in crafting highly reliable, high performing digital components and have excellent relationships with their customers.
But WdGits faces a problem. It needs to move aggressively into software products to expand their brand. In the PrD “Creation Session” (a workshop in which internal team members align on their assumptions), key WdGits’ 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 WdGits, and they presumed, new to their customers (Principle 1: Design to Fail).
Over a period of a few weeks, we visited handfuls of Wdgits customers, offering the artifacts in “Engagement Sessions” (the 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 WdGits team quickly aligned on a set of assumptions, many of which they didn’t even know they had
WdGits’ customers had the opportunity to critique those assumptions, not through a simple survey or interview, but by reacting to an artifact that embodied those assumptions
WdGits inexpensively determined how far off their own assumptions were from their customers’ without building anything other than a provocative artifact.
The Bottom Line
PrD is an agile way to reduce the risk of inventing the future. It enables internal teams to:
quickly imagine a desired future (within hours),
quickly capture reactions from their intended audiences to that imagined future (within hours or days), and
do so less expensively than any other research method I’ve ever used.
In the end, Presumptive Design raises your confidence that you and your team are solving the right problem.
A version of this article is published in NetMag (which may not be visible to you without subscription)
* Intelligent Failures, a term introduced by Sim Sitkin in his 1992 article Learning Through Failure: The Strategy of Small Losses, have several important criteria, including: they are planned, have uncertain outcomes, are modest in scale and can be executed quickly.