Twitter, now that we understand why the preventable problem paradox is so prevalent and pernicious, it’s time to talk about combating it.
So, as promised, here’s a thread on pre-mortems.
In this thread, we’ll look at the “what” and “how” of pre-mortems, along with a novel technique of using “Tigers”, “Paper Tigers”, and “Elephants” to run effective pre-mortems.
But first, ICYMI, check out the thread linked below.
While I knew that thread would resonate with some, it got way more popular than I had imagined.
It seemed to especially strike a chord with folks in security, sysadmin, privacy, and related areas.
With that, let’s talk about a specific technique to help you do what’s right for your customers, your company, your team, by foreshadowing and mitigating the most blatant would-be blunders.
That technique is pre-mortems.
It is one of 3-4 mitigations for the preventable problem paradox.
It is also the most practicable one.
You can literally implement this on Monday if you want.
Post-mortems, after action reviews (AARs), etc. are becoming a part of the “standard process” at many organizations.
(and I think that is great!)
So, what’s a pre-mortem?
Note: you can (and likely should) do a post-mortem anyway, even if the project went quite well.
But, moving along.
Unlike a post-mortem—where you discuss what went wrong (and what you can learn from it)—in a pre-mortem, you get together earlier in a project’s lifecycle and ask the team to assume that the project has failed.
And you prompt the team to come up with the reasons why.
This short and excellent HBR article by @KleInsight is required reading on this topic.
@KleInsight Here are the highlights of the standard pre-mortem process:
@KleInsight I’ll now share a modified pre-mortem script that has worked well on the teams I’ve worked with.
As background, at Stripe, the teams I’ve led have regularly run pre-mortems for our products, particularly major product launches (e.g. Stripe Connect, Stripe Terminal).
And while we haven’t been 100% mistake-free, pre-mortems have enabled “calm product launches” and enhanced team productivity & morale.
Why change the standard pre-mortem script?
In my experience, the standard pre-mortem meeting was very engaging *while* the team was in the room.
But how many times have you had an engaging meeting and then people leave the room and everybody forgets about it and reverts to old patterns?
That’s what I saw repeatedly when we employed the standard script.
So, I began looking for ways to change that.
I wanted the team to
A. be spotting major problems, and
B. surface those problems up to other team members
*throughout the lifecycle of the project*,
not just at that one pre-mortem meeting.
What was missing, I realized, was an evocative, convenient lexicon that allowed people to talk about these things in a psychologically safe manner.
Related: I learned quite late in my career the tremendous benefits of giving your team a context-specific lexicon. Don’t be me.
Enter the metaphors:
Tigers
Paper Tigers
Elephants
The way I like to run pre-mortems now is to ask them to list out their concerns about the project in 3 different categories:
Tiger
Paper Tiger
Why are you not worried about a Paper Tiger (even though others might be)?
Usually because you’re responsible for the said area and have strong conviction that the ostensible Tiger is fully under control.
You’ve got it!
Elephant
An Elephant might not be a threat per se, but it’s the thing you’re worried no one is talking about.
It’s the “elephant in the room”.
So, with this lexicon, here’s how I recommend running a pre-mortem meeting:
It’s 1 hour long and the flow looks like this:
During the context setting part, I introduce the pre-mortem concept (it’s always *someone’s* first pre-mortem) and ask everyone on the team to come up with:
2 Tigers (at least), and
any Paper Tigers and Elephants they can think of.
There is absolutely no talking during this time.
Quiet time!
It’s amazing how long & productive a 10 minute stretch of silence can be in a meeting, when no one is talking.
After that, there’s another 10 minutes of Quiet time.
During this time, people read everyone else’s Tigers, Paper Tigers, and Elephants.
And they get to +1 others’ Tigers, Paper Tigers, and Elephants. Each person can give up to five +1s. So you need to be quite selective.
Btw, this is all being done in a shared Google doc or a Dropbox Paper doc. One advantage of Paper being that you can easily see who wrote what.
And then, Quiet time is over.
You go around the room, and people share their observations (e.g. what Tiger resonated the most, what they found surprising, etc.)
And, as the facilitator, you wrap the meeting up by summarizing the top themes that have emerged from the pre-mortem and sharing what people can expect next.
So, what’s next?
It’s the most important part of the entire process.
The pre-mortem action plan.
As the facilitator, you prioritize the top N Tigers / Elephants that emerged from the pre-mortem exercise.
You create a document that summarizes the action plan and share it with the team for commentary.
Here’s a hypothetical example:
Note that your goal isn’t to list *every possible problem* in the action plan.
You must focus on the major problems (i.e. the deadliest Tigers), and be fine with living with the minor ones.
You cannot (and should not) fix all problems because you don’t want progress to grind to a halt.
But more importantly, I’ll observe that solving one problem often creates a different problem.
So you’ve got to have clarity on which problems you’re willing to live with and which ones you can’t live with.
(this is perhaps applicable outside of one's work life too)
Also note that it’s important to list the verbatim Tigers and Elephants (as in column 2), since it reassures team members that their *direct input* was useful.
Every item must have a single Directly Responsible Individual (DRI). (they can of course delegate, as appropriate)
And the last column lists the proposed mitigating actions,
in priority order,
that will *reduce the chances* of the problem occurring, OR
will *limit its negative impact* if it does occur.
Once you’ve reviewed the action plan with the team, make sure that you track progress against the action plan during the rest of the life of the project.
You can do it by merging the action plan with the overall project plan, so it becomes an integral part of “how we do things around here” vs. a one-off effort.
So that’s pretty much it.
How do these pre-mortems help the team?
Besides the obvious benefit of reducing the chances of major mistakes, I love it when team members wholly adopt the “Tiger", "Paper Tiger", "Elephant” metaphors.
It’s quite typical that, N days after the pre-mortem meeting, team members will say in a meeting/on Slack/email:
“I recently thought of a Tiger that’s been worrying me since”
“Remember, that’s the Elephant that Bob pointed out earlier. We still need to do work there.”,
etc.
Saying in a meeting “I’d like to talk about a Tiger” is lower pressure on the individual than dealing with the fear (rational or not) of coming across as “pessimistic” or a “naysayer” when expressing their concerns in normal English.
These metaphors can be quite powerful!
And by calling out the importance of spotting deadly Tigers and talking about the big Elephants, you create more psychological safety for team members to bring up their concerns.
After a well-run pre-mortem meeting, observe your team members as they exit the meeting. Odds are high that their faces will look more relieved, their gait more optimistic.
Why?
Because the problem that had been worrying thus far them is no longer just THEIR problem to carry.
This catharsis can by itself be priceless.
Last week, I ran a (highly unscientific) Twitter poll to assess how common the practice of pre-mortems is.
I hope more pre-mortems will mean:
fewer privacy gaffes
fewer security issues
reduced system downtime
fewer “should-have-succeeded-but-actually-failed” products
clearer policy change communications
better-run events
less user misunderstanding
and ultimately, happier customers.
This Tweetstorm is getting quite long (even by my standards), so I’ll stop here for now.
I have some more draft Tweets on this topic (including answers to a few FAQs).
As an experiment, I’ll ask you to post any questions you have by replying to this Tweet.
And I’ll commit to responding to the most relevant questions.
Lack of time is a perpetual source of stress in the product manager’s journey.
No matter how well you’ve prioritized, no matter what milestone your product has just reached, there is a near-infinite list of really important things you could be doing that you just cannot do.
There are many well-known resources & principles for managing time: systems such as GTD, “managing your energy, not your time”, prioritization formulas, Eisenhower Matrix, etc.
These are no doubt useful, but for product managers, these systems leave a lot to be desired.
Why do companies with major resources & distribution make products that are mediocre & often fail to reach their potential?
There are a handful of reasons, many of which you already know. But there is one under-discussed reason: Operators Optimizing for Optics
Thread:
To understand this, let’s start with a story.
START OF STORY
Acme Inc has brilliant, visionary founders (Alice & Bob), amazing culture, has built a well-loved product, and thereby created a business much larger than the early people (including the founders) had ever imagined.
With this growth, they’ve had to hire a bunch of Operators: leaders who are skilled in scaling process, teams, operations, and overall execution. So far so good. As the business & the customer-base grows, it is a no-brainer for Acme to tackle adjacent areas of opportunity.
Some reflections since turning on Twitter’s Super Follows two weeks ago.
800+ superfans have joined 🙌🏾
Biggest benefit:
I am tweeting a lot more freely because I know I am speaking to superfans who understand what I am about. More advanced & nuanced content. Fewer unsent drafts
Biggest surprise:
The community aspect of Super Follows has been A+ thus far.
While not a primary goal, it was 1 of my hypotheses for doing Super Follows. And it has vast exceeded everyone’s expectations. I polled folks yesterday for feedback, and community was mentioned by most
Many super followers mentioned that they are now using Twitter more frequently & are replying/sharing a lot more freely with the community than they might in public, because of shared alignment.
One super follower said it best: people writing without fear of being misunderstood
As they grow in size, teams within megacorps and startups tend to implicitly bias more towards Project Thinking and not enough Product Thinking.
Product Thinking is a mindset and a process that, once you see, you cannot unsee it.
Product Thinking, Project Thinking, a thread:
From my experience working in individual contributor & leadership roles over the past couple of decades, and from my advising work with a number of fast-growth startups, I have often seen myself and founders / CEOs / execs worry about these things:
And, having been in the trenches of product work for a large part of my career, and having managed / mentored / coached hundreds of PMs & PM Managers, I have often seen myself, and other ICs & managers worry about these things:
1) Be proactive 2) Begin with the end in mind 3) Put first things first 4) Think win-win 5) First understand, then seek to be understood 6) Teamwork & creative cooperation 7) Continuous improvement
Basically, the habits in the classic book.
I know that many Product Managers will ignore this because they want something more advanced.
They have already read Covey's book at age 23, so there's nothing more & nothing new to learn from it.
They want an edge over others, so they seek & love esoteric advice & tactics.
And yet, 9 out of 10 times when I am working with extremely smart & ambitious PMs who are struggling (not getting promoted, not getting the performance reviews they think they deserve, not executing well, etc.) it is because they have forgotten one (or more) of these 7 habits.