The Product Pre-Mortem
Before you build or invest, take these steps to de-risk
Before you start developing a product, there are two steps you can take to increase the odds of success. First, craft a press release that reads as the desired outcome. Second, envision a pre-mortem that covers undesired outcomes. As you progress through launch, use these as a guiding light.
The Amazon Internal Press Release
One of Amazon’s celebrated product practices is to write an internal press release for a product launch — before creating the product. Write it for new/existing customers to read, and work backwards:
There is an approach called “working backwards” that is widely used at Amazon. We try to work backwards from the customer, rather than starting with an idea for a product and trying to bolt customers onto it. While working backwards can be applied to any specific product decision, using this approach is especially important when developing new products or features.
Ian McAllister shared the purpose, outline and considerations for an internal product press release. Here’s the outline:
- Heading — Name the product in a way the reader (i.e. your target customers) will understand.
- Sub-Heading — Describe who the market for the product is and what benefit they get. One sentence only underneath the title.
- Summary — Give a summary of the product and the benefit. Assume the reader will not read anything else so make this paragraph good.
- Problem — Describe the problem your product solves.
- Solution — Describe how your product elegantly solves the problem.
- Quote from You — A quote from a spokesperson in your company.
- How to Get Started — Describe how easy it is to get started.
- Customer Quote — Provide a quote from a hypothetical customer that describes how they experienced the benefit.
- Closing and Call to Action — Wrap it up and give pointers where the reader should go next.
The benefit of this exercise is focusing on the outcome and value proposition for the customer from the outset. In the form of a story. And using it as a touchstone as the project evolves, by checking reality against that story. It aids in the Continuous Alignment of Product Management.
But while the press release helps identify product and market risks, but that’s not enough to guide success.
Risk and Post-Mortem
Here on Medium there’s a whole genre of the Startup Post-Mortem. Stories of failure that others can learn from. Usually shared by the founding CEO of a single product company that struggled with product-market fit. There’s a wealth of lessons from these failures.
One practice in project management is a pre-mortem to identify and mitigate project risk. Product are more than projects, requiring a different approach.
When a VC evaluates a potential investment, they do so by weighting risk and reward. Such as the 11 risks VCs evaluate by Tomasz Tunguz: market timing, business model, market adoption, market size, execution, technology, capitalization structure, platform, venture management, financial and legal risk. Leo Polovets gives 9 risk spectrum examples and how to de-risk: product/market fit, product quality, team, recruiting, sales, market, funding, short-term competition and long-term competition risk.
My suggestion is to focus on 4 key risks: team, technology, product and market.
The Product Pre-Mortem
A Product Pre-Mortem is internal post-mortem written from the outset of developing a product to de-risk failure.
Write the looking backwards blog post as though you are 3 months after product launch. Unlike the Internal Press Release, your audience isn’t as focused as a customer. The Product Pre-Mortem is written in a past-tense voice where you are reflective, but sharing for others to learn from your successes and failures. You have to assume it may be read by your customers, team members and other stakeholders.
A Product Pre-Mortem should describe at least 4 key risks: team, technology, product and market. Don’t hold back from writing down risks you don’t fully understand. That’s the point.
A Product Internal Pre-Mortem Outline
Summary — Write this last. Write it like the first paragraph in a news story: Who, What, When, Where, and Why. The last sentence should summarize the lesson from failure.
Team risk — Does the product team have the needed skills and expertise? Are there dependencies with other stakeholders? Are there learning and development needs? Can we recruit new team members and source expertise? Is this a new team (if there is one new team member, it is), or one with proven experience collaborating? Does our culture fit the opportunity (a-la founder/market fit)?
Technology risk — Does development of the product depend on an R&D breakthrough? What is our platform dependency over time? How does our existing architecture inhibit development?
Product risk — Do we deeply understand the customer problem? Have we prioritized requirements? Is the customer outcome well-defined? Does the product have adequate financial and other resources, and with what dependencies? In managing development, are there constraints for resources, time (e.g. a launch deadline) and quality?
Market risk — Does distribution have direct, platform and channel dependencies? Is the market timing right? Do we have evidence of demand and is the market opportunity big enough for reward? Do we understand the competitive risks in the short and long-term?
Lesson from failure: In your conclusion, describe how you managed your dependencies and mitigated your risks — and hypothesize what was the big failure to do so. Write to your future self what you learned from this failure. If there is something you wish you had done differently, the great news is that you still can!
Considerations for Product Managers
This isn’t just an exercise for a startup founder. This is for Product Managers in big or small companies.
If the result of your pre-mortem reveals a ton of risk, great! So long as the rewards are great. In a product portfolio or venture portfolio, the product can knowingly venture into these risks consciously.
Just as with the Internal Press Release, continuously revisit the Product Pre-Mortem to check how risks and dependencies are mitigated. This is a cycle of learning, and a Product Pre-Mortem gives you a valuable feedback loop that starts with you taking the time up front to think it through.
Got a better idea on how to craft a pre-mortem, or an example to share? I’d love to hear it directly or in comments.
Thank you to Nils Davis for feedback on this post. Icon credit.
