Buying Failure Time
Updated: May 22, 2019
This diagram is wrong.
Well, not wrong. Incomplete.
The infographic should include a cycle within the cycle to represent multiple turns at Ideating through Testing. (It would be nice if it included a Victory Lap too before the cycle starts over again with Understanding, but I know that's asking too much.)
You might think what I'm referring to is multiple rounds of Testing; it's not.
The missing cycle is the part where you spend an inordinate amount of energy convincing the people who are paying for the project that you know what the hell you're doing even though you don't -- and aren't supposed to yet -- because you're still Testing.
I call this phase Failure Time: where the Real World overlaps with Infographic World. This is about how to commit to the idealized process while juggling the demands of the Real World calendar.
The truth is that Design Thinking can be a time-suck.
It’s not so much that each phase takes an enormous investment of time: the Empathize/Define/Ideate phases can be crunched into one afternoon of brainstorming or "kick-off" (if snacks are provided.)
But after the pizza has come and gone, executive teams generally like to set deadlines. They want to know that their is ROI on their snack investment.
So product managers frequently use the results of that brainstorming to acquire management buy-in for the project vision and objectives so they can keep working while the exec team isn't looking.
But then comes Prototyping where you produce some artifact — a set of wireframes, for instance — and Testing where you place the artifacts in front of eyeballs who aren’t part of the core team to get relatively unbiased feedback.
But what happens if the Testees hate it? I mean really hate it, as in "We Think You Should Start over."
Failure Time. If you don't allow for this, then you get stuck with some variation on your first prototype because management already set the deadline after falling in love with the Ideated version. Good job, product lead!
That's why Failure Time is what management really doesn’t like to give you…even when they say they do.
I know all about “Failing early and often.” Maybe Facebook still means it.
But in less progressive (and wealthy) companies, Failure Time is felt and judged as imprecise, resource-intensive, and expensive. You can Materialize and then Fail, of course, but that generally ends the whole exercise because you get fired.
If you’ve used your ideation phase to create management buy-in for your initial set of proposals, then they’re in: psychologically, they are already invested in Idea #1 and if you come back with negative Testing findings and a do-over scenario, then not only are you asking for more time, but you are, in effect, telling them that they also were wrong.
You may have increased empathy for your user but you’ve probably lost some from your management team.
So what can a product manager do to buy some Failure Time?
Build a fence around the sales team
Create a User Advisory Board
Create a sign-off ritual
1. The sales team
If a deadline has already been set, then it’s hard to find time for multiple cycles of prototyping and testing. In my line of business (media), if the sales team has already got a client excited about a concept, then the sales team will want to impose a deadline no matter what Testing reveals because that’s when they get paid.
So you must align the sales cycle to kick in after Testing so you get through some Failing before they say anything about anything to a client.
2. The User Advisory Board
For a company with an existing customer base, you can speed this up by creating a User/Customer Review Board that commits to making itself available for casual but frequent evaluation of prototypes.
For example, if I’m working on new templates, I can circulate wireframes or low-fidelity designs after Ideation and before showing them to management.
This group doesn’t necessarily have to be big; in fact, a big group will just produce noisy data. The ideal is to hand-select and recruit a handful of users that match key user personas and who understand upfront that their feedback won’t always be followed. These relationships must be cultivated over time and it’s important to recognize the effort with periodic appreciation events, the proverbial Free Lunch. To make sure customers don’t start to perceive their involvement as a quid pro quo, it’s a good idea to time-box the commitment in advance.
3. The Sign-Off Ritual
Frequently, you’re fighting to earmark resources for a project at the same time that you are Testing and Prototyping. It’s tempting to “sell” a management team on the Ideation so that they’ll allot sufficient resources. But if you get them too excited about Idea #1, then it’s defeating to come back and ask for Failure Time.
One way to avoid this is to explicitly designate Sign-off as its own phase in the Design Thinking process, coming between Testing and Implementation. To underscore that it’s different from previous discussions of untested ideas, it’s helpful to create some kind of ritual — formal signatures or a Go/No Go meeting or celebratory donuts — just so long as it’s an event that does not occur at any other point of the process.
This marks your management’s team commitment to Materializing.
(This won't prevent late-in-the-game interference, of course. I had a boss once who was famous for the “Swoop”, meaning feedback well into the materialization phase. She was usually right...but at the wrong time. I took to actually building the "Swoop" into the project calendar.)
To be realistic, hard deadlines are frequently unavoidable. That’s life, friend.
But even my modified version of this process still represents a real commitment to the Nielsen Norman ideal and promotes real culture change. So don’t get me wrong: I rely on and am still inspired by this diagram. It’s just tidier than real life.