“Embrace failure” is easy advice to give and hard to act on. No team sets out to fail, and no budget has a line for it. What the advice really means for a product team is narrower and more useful: arrange the work so that when an idea is wrong, you find out quickly, it costs little, and the team learns something it acts on.
That takes three habits. Make failures small by testing ideas as small, time-boxed bets. Decide in advance what failure looks like, so a weak result ends the bet instead of starting a debate. And when something does go wrong, study it without blame and turn what you learn into roadmap changes. This guide covers each habit, with templates you can use on your next release.
Why failure teaches product teams more than success
Failure teaches more than success because it shows you which of your assumptions were wrong, and every product is built on assumptions: who the user is, what problem they will pay to solve, how they will find the product, and what they will do in the first five minutes. A success rarely tells you which of those assumptions held. A failure, studied properly, usually points to the one that didn’t.
The catch is the word “properly”. A failure that is hidden, blamed on one person or explained away teaches nothing. The same failure, written down with its cause and the decision it led to, becomes one of the most valuable things a product team owns.
How do you make failure cheap?
You make failure cheap by testing the riskiest assumption first, with the smallest piece of work that can prove it wrong, before you spend on the full build. A wrong guess found in week two costs a few days. The same wrong guess found after launch costs the launch.
Practical ways to keep bets small:
- Test the riskiest assumption first. List what must be true for the product to work, and rank each assumption by how uncertain it is and how much depends on it. Start at the top of that list, even if it isn’t the most interesting part to build.
- Build the smallest thing that answers the question. A clickable prototype, a landing page with a sign-up form, a manual service run behind a simple interface, or a minimum viable product. Our guide on why build an MVP first covers how to scope one.
- Time-box every bet. Decide how long the test runs and when you will look at the result. An open-ended experiment drifts into a feature nobody decided to keep.
- Separate reversible from irreversible decisions. Amazon’s 2015 letter to shareholders described most decisions as two-way doors you can walk back through, and a few as one-way doors you can’t. Move fast on the first kind and slow down on the second, such as a pricing model, a data structure customers depend on or a public commitment.
- Release to a few users first. Feature flags and staged rollouts let you show a change to a small group, watch what happens and switch it off without a new release.
This is the thinking behind the build-measure-learn loop in Eric Ries’s The Lean Startup (2011): each cycle should end with something learned, not just something shipped.
Set kill criteria before you start
Kill criteria are the results that will make you stop or change a bet, written down before the bet starts. They matter because once work is under way, people become attached to it, and any result can be argued into a reason to keep going.
Good kill criteria are specific, measurable and tied to a date. An illustrative example for a new feature:
| Bet | We expect | We stop or rethink if | We check on |
|---|---|---|---|
| Saved searches will bring users back each week | A clear share of active users save a search in the first month, and those users return more often | Few users save a search after four weeks, or savers return no more often than others | Four weeks after release |
| A shorter sign-up will lift completed sign-ups | More visitors who start sign-up finish it | Completion is flat after two weeks of steady traffic | Two weeks after release |
Write the actual thresholds into your own version, using numbers from your analytics. The point is not precision. It is agreeing, while everyone is still neutral, what “this didn’t work” will look like.
Run a pre-mortem before big bets
A pre-mortem is a short meeting before a project starts, in which the team imagines that the project has already failed and writes down why. The psychologist Gary Klein described the method in Harvard Business Review in 2007. It works because it makes raising doubts the task, rather than a sign of disloyalty.
How to run one in 45 minutes:
- Describe the project and its goal in two minutes.
- Say: “It’s six months from now and this has failed. Write down every reason why.”
- Give everyone ten minutes to write on their own, so the loudest voice doesn’t set the list.
- Go round the room, one reason each, until the list is complete.
- Pick the three most likely or most damaging reasons, and decide what you will do now to prevent each one, or what early signal you will watch for.
The most common answers are rarely technical. They tend to be about users who don’t behave as assumed, a dependency on another team or vendor, or a launch date that left no time to learn.
How to run a blameless post-mortem
A blameless post-mortem is a written review of something that went wrong, focused on what happened and why the system allowed it, never on who to blame. Google’s book Site Reliability Engineering (2016) has a chapter on it, “Postmortem Culture: Learning from Failure”, and the practice works as well for a failed feature as for an outage.
The steps:
- Write the timeline first. What happened, in order, with dates. Facts before interpretation.
- Describe the impact. Who was affected, how, and for how long. For a product bet: what it cost in time and money, and what it didn’t deliver.
- Find the contributing causes. Ask why each step happened, and keep asking until you reach something the team can change: a missing check, an untested assumption, a handoff with no owner. There is rarely a single root cause.
- Agree the actions. Each action has an owner and a date. “Be more careful” is not an action; “add a usability test before every new onboarding flow” is.
- Share it. Put it where the whole team, and future team members, can find it.
The rule that makes it work: people describe what they did and what they knew at the time, and nobody is punished for an honest account. As soon as a post-mortem becomes a trial, people stop telling the full story, and the lessons go with it.
What to record about each failure
Record enough for someone who wasn’t there to understand the decision a year later. A one-page template is enough:
- The bet: what we tried and the assumption behind it.
- The kill criteria: what we said would count as failure, and when we’d check.
- What happened: the results, with the numbers.
- Why: the contributing causes from the post-mortem.
- What we learned: one to three sentences, each one a statement about users, the market or the product that the team now believes.
- What we changed: the roadmap, process or design decision that followed, with a link to it.
Keep these in one searchable place, such as a shared document folder or your project tool, tagged by product area. The library becomes useful once it has a dozen entries, when patterns start to show.
How lessons should change the roadmap
A lesson only counts once it changes a decision. After each post-mortem or ended bet, ask three questions:
- Does this change what we build next? Drop, reorder or reshape roadmap items that depended on the assumption that proved wrong.
- Does this change how we build? Add the missing check, test or review step to the process, so the same failure can’t recur silently.
- Does this change what we believe about users? Update the personas, journey maps or research notes the team uses, so new work starts from the corrected view.
Then close the loop: at the next planning session, list the lessons from the last cycle and show where each one changed the plan. That one habit tells the team that reporting a failure leads somewhere.
Building a team that reports its failures
A team learns from failure only when people feel safe saying something went wrong. Amy Edmondson’s research on team learning (Administrative Science Quarterly, 1999) called this psychological safety: a shared belief that the team won’t punish someone for raising a problem, a question or a mistake.
What leaders can do:
- Go first. Share your own wrong calls and what you learned from them.
- Reward early warnings. Thank the person who flags a problem in week two, even when the news is bad.
- Separate the decision from the outcome. A good decision made with the information available can still turn out badly; judge the decision, not the luck.
- Make ending a bet normal. Celebrate a clean stop against agreed kill criteria as a success of the process.
A sourced story: the Post-it Note
Many famous “failure to success” stories are retold so often that the details drift. The Post-it Note holds up, and 3M tells it in its own company history. In 1968 the 3M scientist Spencer Silver was trying to make a strong adhesive and made a weak one that stuck lightly and peeled off cleanly. For years nobody found a use for it. In 1974 his colleague Art Fry wanted a bookmark that would stay in his hymn book without damaging it, and remembered Silver’s adhesive. The product reached shops across the US in 1980.
The lesson for product teams is not “mistakes become hits”. It is that Silver kept sharing a result that had failed against its original goal, and that it took a second person, with a real problem, to see what it was for. A failure library and a habit of showing your misses to people outside the project do the same job deliberately.
How we’d approach it on a client product
On a new product, we’d start by listing the assumptions the product depends on and agreeing, with the founder or product owner, which one to test first and what result would change the plan. That shapes the first release: as small as it can be while still answering the riskiest question. Our MVP development page covers how a first version is scoped and built.
For a product that already exists, we’d begin with what the team has already learned: past releases that didn’t land, features nobody uses, and the decisions made since. That review is often where product consulting starts, before any new build is planned.
The short version
- Make failures small: test the riskiest assumption first, with the smallest build that can prove it wrong.
- Write kill criteria before each bet starts, with a date to check them.
- Run a pre-mortem before big bets and a blameless post-mortem after anything goes wrong.
- Record each failure on one page: the bet, the criteria, what happened, why, what you learned and what you changed.
- A lesson counts only once it changes the roadmap, the process or what the team believes about users.