The premortem for software development
There has been a fair amount of buzz around the premortem for large, cross-functional projects, but little writing on how to specifically apply this technique to an agile software development environment. For a product manager, the premortem can be one of the best tools in your arsenal for surfacing potential project pitfalls. This is even more true when you're asked to work on a 'pet project' that may not have gone through a complete discovery process. When these pet projects flow out of executives' brains, there is often the impression that pushback equates to lack of buy-in. The premortem turns those tables around, making enthusiastic description of how products will fail into the greatest form of team spirit.
What is a premortem? When big projects, software releases or initiatives fail, it has long been standard practice to hold a postmortem and evaluate where things went wrong. We often discover valuable things in those sessions, but the premortem seeks to find the same learnings before breaks occur. First, gather every stakeholder who touches a particular project and ask the group to individually imagine that they are six months post-launch and this project has failed. Have your stakeholders tell the stories of how the failure occurred. In organizations that tend to punish those, either directly or indirectly, who push back on new initiatives, the premortem creates space by saying, "the best way you can help drive this project to success is by telling us exactly how it could fail miserably". This environment removes the stigma that is attached to voicing concerns at the onset of a project, and usually extracts insight from those who were previously hesitant to share. Once you have spent 10-20 minutes in brainstorm mode, I find it best to use a typical dot-storming session in which everyone presents their ideas, writes them on sticky notes and places them on the wall. Give everyone in the group five dots and have them nominate the most concerning scenarios. The stickies (or groups of similar stickies) with the most dots are where you should focus your remediation plans.
Why is this particularly useful to a product manager? Even in the best, most product-centric organizations, product managers will face some degree of intervention from business leaders pushing their pet projects. Almost inevitably, you'll find yourself working on one of these projects and feel like you can't push back on the potential problems that said project might face without looking like a detractor from your CEO's favorite idea. Premortems allow you to create an environment in which pushback is expected. They also allow stakeholders to contribute doomsday scenarios without necessarily saying "I think this is going to happen", which again creates distance between the whistleblower and the whistle. In some cases, the premortem will construct such a mountain of failure scenarios that the champion of the project will reconsider its unassailable worth. In other cases, the scope or timing might be altered as you create specific remediation plans for the most draconian scenarios. At very least, you'll have everyone involved and able to view and acknowledge the risks of the project.
Software isn't the same as opening retail stores or building a new distribution center, and it has some unique considerations for a premortem. First off, you should neither ignore nor overly focus on the obvious. Your developers could die in a goat herding accident, your servers could melt or your new product could get sued out of existence because you forgot to check the app store before coding for 12 months. These are legitimate risks, and they can usually be boiled down to things like knowledge silos and legal hurdles. However, the real risks to your project probalby lie in the areas of complexity (this is taking us 4 years instead of the planned 3 months to build), competition (lots of competition and/or low barriers to entry), and adoption (the feature we built, despite our best product discovery efforts, is not being used). Of these three categories, the last two are more appropriate points of focus for a product manager. Misjudging complexity is an ever-present risk for software development, but remember that our perspective for this exercise is that we are six months out after launch and we're imagining the future in which we launched (with high hopes of success) and now we see that our product failed because ______. So, focus on why your users didn't want the software you built and how your competition took the wind out of your sails and you'll come away with a much more actionable remediation list for software development projects.
If you want to try this out for your next software product, here's a checklist to help you through the process:
- Gather every relevant stakeholder in person or as close to this as possible (email does not work).
- Explain the process and flatten the organization - if participants don't feel completely free to bring up failure scenarios, this will be a waste of time. To that end, if your are conducting this on someone's pet project, have that person emphasize their desire for real visions of how this project might fail.
- Play the hypnotist and take your audience to another place and time - the more vividly they can see and feel what the failed project looks like, the more likely their descriptions are to uncover risks.
- Have participants write down each failure scenario on a sticky note and group these notes into similar ideas.
- Ask each participant place a vote (I like to use dot stickers) on the five scenarios that they feel merit the greatest consideration.
- Among the top voted-upon scenarios, be sure to spend time as a group discussing remediation plans - this is often the point at which your stakeholders begin to realize the impact of ramming new products and features into the development pipeline.
- Don't get stuck debating technical details of how you're developing a piece of software - this isn't about technical discovery. Rather, focus on why your users didn't want what you built.
If you're interested in going deeper on the topic, Gary Klein is the preeminent expert on project premortems. In the future I'll be posting documentation of a premortem we conducted and how it impacted the product's final outcome, and please let me know if you try this at your organization and how it goes!