Premortems are a marvelously powerful tool for teams trying to shift their product culture. They naturally move teams towards shipping smaller and more frequently, increase cross-departmental communication, and encourage good user research hygiene. Paired with retros, they become the foundation of how I help product development teams evolve.

I’ve used this meeting technique since 2018 to de-risk upcoming project launches and it is one of my favorite product management tools. It’s best for initiatives where there’s a lot of cross-functional work involved; if the feature release is minor and doesn’t require customer announcements or changes to sales processes then it probably isn’t going to be as helpful.

I hope you enjoy it as much as I do. If you have questions before running your next premortem, drop me a line.

---

What is a premortem?

A premortem is a technique you use prior to a product launch to help anticipate any major issues and plan around them. The term was originally developed by cognitive researcher Gary Klein and the concept was launched by his article in the ​Harvard Business Review​.

A premortem gets a bunch of people in a room together to hypothesize why a project, initiative, or launch might fail. They then prioritize the issues and create action plans to address the most critical ones.

To help you along with this, ​I’ve created a Figjam Template that you can use to host your own premortem​.

Why do premortems?

It’s a great way to build more ​cross-departmental collaboration​ into your ​product culture​.

Premortems create psychological safety, allowing everyone to express their concerns and worries in a safe environment. As Klein writes in his article:

Projects fail at a spectacular rate. One reason is that too many people are reluctant to speak up about their reservations during the all-important planning phase. By making it safe for dissenters who are knowledgeable about the undertaking and worried about its weaknesses to speak up, you can improve a project’s chances of success.

Launching products is hard and there are a lot of moving parts and dependencies. Premortems can help the team visualize and understand these dependencies, and increase empathy for the work that everyone across the company needs to do to make sure a product launch is successful.

Who should be involved in a premortem?

Premortems work best when there’s a diverse, but not too large, group in the room. I always set a goal of between 8-12 people across as many departments as possible. I make sure to bring in people who are divergent thinkers and worrywarts.

At a minimum, the group needs to include someone from each of the following departments:

• Product
• Design
• Engineering
• QA
• Sales
• Marketing
• Customer support
• Operations

If you have more than 12 people you want to involve, I suggest doing two sessions, each with a cross-functional group. Sometimes engineering teams will also run a ​technical premortem​ of their own.

One person needs to be the facilitator. This is most frequently someone from the core product team itself.

When should you do premortems?

The sweet spot for conducting premortems is after enough solutioning has been done that there’s a clear idea of what is being built, but not so late that it’s hard to make adjustments and changes to plans already in place. This means earlier for larger initiatives. No matter what, I would aim to do it no less than four weeks before target launch, and the sweet spot is probably more like eight weeks.

How do you run a premortem?

This assumes all the standard meeting preparation has happened; you have chosen your list of attendees, invited them at a specific time, sent out this explainer to them so they know what to expect, etc.

The meeting agenda should include links to any project plans, documentation, etc that define what the project is. Everyone coming into the room should already have a shared understanding of the initiative.

Optional: If you’d like to do a shorter meeting and your company has a culture of doing pre-work, ask everyone to do their brainstorming ahead of time and bring the list in. No matter what, invite people in the agenda to begin thinking about all the disaster scenarios.

Open the meeting

Set the ground rules –

1. More ideas are better than good ideas
2. We want you to be pessimistic about everything
3. We want you to think about unusual scenarios that might happen
4. Be supportive of your peers, no matter what

Remind everyone of the context of the project and what upcoming target dates and timeframes are. Make sure that everyone knows what the desired impact of the initiative is. Write that desired impact down.

Ideation

Invite everyone to write their ideas down (if they haven’t already). It should be one idea per post-it note. Use the following prompt:

Imagine a future in which things have gone terribly wrong. What was the reason?

If people feel stuck, use the following list to help them come up with more ideas

• Why did we miss the target timelines?
• Why did we not hit our metrics?
• Why did we not have the desired outcomes?
• Why are our customers unhappy with us?
• Why are our internal teams unhappy with us?
• What technical issues caused problems?
• What design issues caused problems?
• What did we build incorrectly?
• What did we misunderstand about our customer?
• Were there issues around communication?
• What surprised us that we weren’t expecting to happen?
• What external factors outside of our control influenced our failure?

Sharing

Have each person share the ideas they came up with. Each idea needs to only be shared once, so encourage everyone to discard ideas once they hear a colleague mention it. The explanation of each idea should be brief, just enough to get everyone to understand what’s on the post-it.

Categorization

As each idea gets shared, it should be placed on a ​2×2 matrix​.

• Likelihood: How likely is this scenario to happen? A data center being hit by an asteroid is low likelihood. A bug affecting a particular segment of users where it’s a complicated part of the codebase is probably high likelihood.
• Impact: How much of a problem would this be for the company if it happened? A typo in a marketing email is probably low impact; an issue causing a system-wide outage would be very high impact.

The whole group should try to agree on where within the 2×2 each of these ideas go. It doesn’t have to be precise; if everyone is debating whether this idea is more or less impactful than just that one other idea, just place them next to each other.

At the end of this, you should have a board of ideas grouped into four categories:

• High impact/high likelihood: These are the items that you want to try and mitigate as much as possible ahead of time. Make sure you have a plan in place for each of them.
• High impact/low likelihood and Low impact/high likelihood: These are the items that you will need to decide on a case-by-case basis whether you do anything about it. If it’s easy to defend against now, it’s probably something you should do. If it’s hard to defend against now, you should probably make sure there’s at least monitoring in place to know if it does happen and the outline of a strategy around what to do if it does occur.
• Low impact/low likelihood: Ignore this category.

Work through the categories

High Impact/High Likelihood

For every item within the high impact/high likelihood there needs to be a plan of action. Bring up each concern with the group – there may be some where someone in the room knows that a mitigation measure has already been put in place or has already been queued up. For any where there isn’t already a plan in place to address the issue, assign an owner, a due date for a plan to be in place, and a due date for the mitigation to be completed.

For instance, if the concern was “we will have more traffic than anticipated and it will take down our application”, a good lead on the issue might be an engineer or QA lead. They would be asked to develop a plan for load testing by next Tuesday, and the load testing would need to be completed one week before target launch. Note that they might need data from other teams – they might work with marketing to figure out what the range for anticipated traffic could be – but that individual owns the issue.

If there are items in this category where prevention isn’t an option, then instead of a mitigation strategy the assignment will be to have a playbook ready. An example of this would be a concern such as “an influencer launches a negative campaign about this product on social media”. The playbook is in place so the relevant teams can respond quickly and in a well thought-out manner with talking points, as opposed to having to do a last minute scramble.

High Impact/Low Likelihood and Low Impact/High Likelihood

Go through each of these issues one-by-one. As a group, do a quick cost/benefit analysis to decide how much effort you want to invest in risk prevention around each item. Decide which of them needs mitigation, which need monitoring, and which the group is deciding to ignore. For any that need monitoring or mitigation, assign an owner, a due date for a plan to be in place, and a due date for the mitigation or monitoring to be set up/completed.

Low Impact/Low Likelihood

Agree as a group that this category will be ignored, as the investment in this category would not be worth the payoff.

What do you do after the premortem?

All of your notes from the meeting should be shared in an easy-to-find location, and the team should have a clear visualization of all the follow-ups from after the meeting. Whoever is filling the role of project manager on the team should be the one tracking all follow-up tasks and making sure they are completed. Beyond that, as Shreyas Doshi points out, the premortem shouldn’t be the only place where these problems are discussed.

It may be that a risk was identified during the meeting that is a total show-stopper. Use the outcome of the premortem to make sure everyone agrees that the timeline should or should not continue as before. Sometimes something is identified that makes the team realize the project should not proceed at all or should not proceed as planned. While never ideal, it is always better to identify those issues earlier rather than later, and shutting down an initiative is a sign that premortems are serving their purpose.

Amazon Prime Day was last week, netting Amazon a whopping $12.7 billion dollars in revenue. It’s their second-biggest sales event after the holiday season. While this top-line number is eye-watering, Prime Day has some incredible lessons for us to learn in the operations world and how to manage bottlenecks. Read the full article below.

It’s not random that Prime Day happens on a random pair of days in the middle of July. Historically, the middle of the summer is slower for shopping. For Amazon, a slow summer is a challenge. They want to have the staffing capacity to support Black Friday and the holiday. It’s better for them to be able to employ people year-round instead of hiring and training hordes of temps for the crunch period. But if they don’t have the revenue to support maintaining year-round operations, that’s a hard cost to justify.

Enter Prime Day. Generate demand in the middle of the slow season. This allows them to have more stable cash flow in their retail operations to support their fulfillment staff year-round.

More relevant for us, Prime Day serves as a holiday season “dress rehearsal”. It gives their teams the chance to practice running at the high capacity needed in December. It forces them to maintain their high-volume systems year-round. It means that everyone on the team is familiar with the procedures required to run things at peak. (It also helps them capture back-to-school and holiday shopping early, but that’s a topic for another day.)

“Leading up to Prime Day, we spend weeks and months preparing for this day, making sure that we have the appropriate staffing in place, schedule adjustments, transportation support in place to be able to ship items downstream to Amazon Air sites and sort centers.”

~Fred McPherson, general manager of the Pontiac Fulfillment Center

Product teams also have “peak seasons”. Whether it’s annual planning or performance management, there is seasonality to the work. And when that crunch time hits, our jobs get very busy. Unlike Amazon, it’s hard for product management leaders to hire contract workers to help staff during these periods. So instead, hours get longer and fuses get shorter.​​

Peak work creates bottlenecks

These peak seasons are expensive. It can lead to increased employee burnout. The day-to-day can fall off the radar to support these special functions. It can reduce the quality or slow down the velocity of what we’re shipping.

In other words, it creates operational bottlenecks on your team because more work is being added to the queue without increasing capacity.

So let’s learn a lesson from Prime Day and find ways to reduce the bottlenecks during spikes in work.

Smooth out the work

Amazon does ask more of its workers on Prime Day. And it’s likely that your team will need to put in some longer hours to get through this crunch time. But how might you limit the extra work you’re asking from people as much as possible?

“We were supposed to go on mandatory overtime for two extra days. We had all hands on deck. It was no different than a Christmas holiday. Like on Black Friday, you’re on mandatory 12 hours.” ​

~ Nicole C

John Cutler came up with a great illustration of the value of smoothing out the extra work:

By spreading the work evenly throughout the year, you can reduce the total amount of work that needs to be done. It’s less disruptive to the system when it comes around. Sound familiar? This is a core tenet of agile development.

And remember how Prime Day becomes a dress rehearsal? The more frequently you do something, the better you get at it. If you only go through an exercise once a year, it’s always going to feel unfamiliar and awkward. Go through it once a month and it becomes routine.

Decision-Making Flowchart

I have a basic process I follow to prioritize different ways I can smooth the work on a team. After identifying those crunch periods I first look to see if we can apply basic agile principles to break it up into smaller chunks and spread it out.

If it can’t be broken down, I investigate if it can it be moved to a time that’s less chaotic. End-of-year planning often overlaps with holidays and sometimes sales and customer commitments. If the work can be moved to a slower time of year, that’s better than nothing.

If it can’t be broken down AND can’t be moved, I try to make a little more space for it to breathe. This can mean taking other tasks off the team’s plate or investing as much time as possible into simplifying the process. Alongside that, I try to find different ways to thank the team for working the extra-long shift.

Bye bye bottlenecks

While I used examples that happen only once or twice a year, such as major planning exercises and performance management, this can be used with any irregular work that creates stress on the team. A great example is how my team at SpotHero moved from monthly releases to biweekly. The same Prime Day principles applied, every two weeks.

Identifying the stress drivers is half the work. They often hide under the auspices of “we’ve always done it that way”, but they can be a major drag on your team. Identify those bottlenecks and do your best to remove them.

I talked in the last newsletter about identifying your shadow product operations organization. These are the people who are busy doing the work of product ops without it being a formal part of their job description. They’re trying to figure out how your product management team can work more effectively, make better decisions, and achieve more.

Having been a shadow product ops person myself, I can tell you it isn’t sustainable. I was trying to figure out ways to improve our roadmapping process and selling the other PMs on the new process. Meanwhile, I had the rest of my job to do: loop in stakeholders, build out my own roadmap, make sure my engineering partners had everything they needed, and manage my direct reports. The process work needed to happen, but it felt squeezed in and I was constantly teetering on the edge of burnout.

My own experience led to my conviction that we need to bring shadow product ops work into the light. We can’t continue to expect product managers and product leaders to make the work magically happen alongside their other responsibilities.

~Jenny

Shine a light

Once you’ve identified who is doing the work and what it is, it’s time to shine that light.

Shining a light starts with simply thanking your team members doing the work. From there, define this work as part of their job description or in a new role. And if you need to put ops work to the side for now, be explicit about it. These three actions will help you show that you care about improving your teams’ efficiency and effectiveness and are a worthwhile investment in your product culture.

Say thank you and acknowledge the impact

I asked a number of people how they like to be acknowledged for product ops work, and it’s amazing what a “thank you” can do. Everyone I spoke with brought up the impact that public acknowledgement had on them. It doesn’t just make them feel good, but also adds credibility to their work. This increases the likelihood that their initiative will succeed.

As Jessica Castro put it:

For me, the appreciation comes from thank you said either with words directly to me or indirectly when business, tech or product talks actively about how their life has improved or how business had good results due to a project I’ve helped deliver or a change in processes.

Make sure your thank you acknowledges:

1. Who did the work

2. What the work was

3. The impact it had

Make it part of the job

One challenge with shadow ops work is it happens alongside and on top of all the other product management responsibilities. Instead, make it part of the job.

This can happen in two basic ways: make it part of the explicit expectations for all product leaders in their job descriptions or formalize it with a new role. Either way, write down what the work is and make sure that if it’s getting added to someone’s list that something else is being taken away.

Attach the work to goals or OKRs

Once you’ve asked someone to do the work, make sure the work is actually being tracked. It doesn’t feel great to do work and then to be unsure if the work is actually helping you meet your company goals.

Tie your product ops work to your goal-tracking system so it’s clear that the work is valued. Connect the work to the impact on your journey to becoming more product-led.

Deliberately de-prioritize the work

If you aren’t able to do the above, then it’s probably a sign that the work needs to be explicitly de-prioritized. Be gracious about this, as someone has poured a lot of effort into investing in this area of your organization. Explain why it needs to be de-prioritized, and what the priorities are instead. Think through the risks of de-prioritization, and make sure you’re aligned on what the tradeoffs are going to be. If you decide to try and squeeze it in instead, you run the risk of neither intiative being done well.

What kind of culture do you want

I constantly advocate that product ops defines product culture. How you recognize and react to the work that your team is doing to change and improve your product culture adds another dimension to it.

The people doing this work are the people who want to change your product culture. They are trying to make it more customer-oriented, more data-driven, more collaborative. How you react to them makes a statement around where your priorities are in terms of your organization’s culture.

Making sure to publicly thank people who are putting in hard work that has an impact is another way to define your team culture. Your interpersonal style as a leader will rub off on others as well.

Set an example of the culture you want by shining a light on the work your team is doing to build a great culture. This will increase the likelihood your employees stick around and reduce the risk of burnout. In the process, you’ll be creating a community where everyone feels appreciated, and that’s always a good culture to build.

This article was originally posted on Mind the Product on June 23, 2023.

---

The best leaders approach product operatrions with a product mindset. And, as with a product, you need to understand what is in and out of scope to define your solutions. This four-part framework defines what is product operations. It helps me structure and assess how an organization is working together. I use this as a lens through which I conduct my user research, ideate, and experiment with solutions.

At the highest level, product operations, or product ops, are all the things that help product managers work more efficiently. As a result, product ops ends up defining product culture. Whether an organization’s product ops are run by a dedicated team or are one of the responsibilities of product management, great product ops enable a strong understanding of the product and allow teams to communicate that out.

I break product ops down into four key areas: using data; understanding users; team ownership; and cross-departmental communication. These areas are a variation on Melissa Perri’s framework from Escaping the Build Trap, which Marty Cagan summarizes excellently. I differ from them because I don’t believe tools and processes are a pillar of product ops. Instead, I see tools and processes as the way you improve the pillars of product ops.

Pillar 1: Using data

Analytics tools allow product managers to measure the success of their products and find opportunities for improvement. They also play a powerful role in helping teams speak the same language.

I once worked at a company whose product development team invested heavily into setting up a beautiful analytics suite. We had a tool that could tell us about conversion rates, we knew what actions users were taking in our apps, and it was fantastic. The only issue was that other departments used a different tool for their data and counted user visits slightly differently. So every time a product manager cited a conversion rate to a non-product person, they had to specify how that conversion was calculated. On top of that, each team defined steps in the conversion funnel independently. I spent my time pulling up data in each tool, comparing them, and trying to debug or explain the gaps. Eventually, we set up a small task force to try and reconcile the issues so we could all be on the same page.

Effective product ops increase trust in the data. It improves access to and use of analytics tools to drive quantitative insights. This might include making it easier for a PM to create a dashboard, creating clear company-wide definitions around certain metrics, or providing resources to introduce best practices around test design and measurement.

Pillar 2: Understanding users

Good product managers know they should talk to customers. But it’s hard. Connecting with users requires a lot of logistics and coordination just to set up the meeting, never mind document and share the findings. Great product ops automates away the busy work from customer interviews and improves how the team documents, categorizes, and shares learnings from these interviews.

A client of mine was struggling to create a shared understanding of their users. I did several things to assist them: first, I automated user recruiting through a chatbot and through an email automation tool. This means that PMs don’t need to recruit or schedule time with customers. Second, I worked with them to create an interview snapshot template that lives in their team wiki. This means that at the end of the interview they know exactly where to write down what they learned in an easily consumable format. Finally, I helped them create places where they can go to find all this information – recordings, snapshots, broader user research reports – so that everyone on the team can view these artifacts in the same place. Through these tools and processes, the team is slowly creating a shared understanding of their users’ needs and use cases. Over time they will develop shared language around how they talk about their customers.

This goes beyond just setting up interviews and repositories. The team should be thinking about different ways to get customer feedback from sales and customer support back to the product team. The data should be categorized and labeled so that as future projects emerge the PMs are well-equipped to search through past research for insights. The best product ops teams understand that creating this shared language isn’t just for the product development team. Stakeholders should have access to our user research and insights too. Democratizing user research across the entire company improves everyone’s work.

Pillar 3: Team ownership

Effective product ops also needs shared ownership across product management, engineering, and design. Gone are the days where product decides what to build, design figures out what it looks like, and engineering makes it. All three roles need to have a say in the direction of the product to have the best results. This takes more deliberate action than ever in today’s remote world.

I look for a few things to determine if there is strong team ownership. First, does everyone on the team feel invested in the problem that they’re trying to solve? The key is bringing the whole team into the entire product process. When thinking about product ops, find tools and processes to enhance that collaboration. Engage the team in finding solutions to challenges – everyone should care about improving how they work together, not just the operations people.

One of the moments where I knew that I had gotten this piece of the puzzle right as a product manager was when I shared a feature idea with my team. One of the QA engineers looked at me after I had talked it through. “That’s a cool-looking button and all, but you had said we were trying to solve a particular problem. This just moves that problem to a different screen.” We went back to the drawing board and worked together to come up with a more effective solution. All the small rituals we had developed as part of our product ops processes created a strong sense of ownership in every role.

Another way to measure team ownership is in terms of the amount of time a product manager spends managing work. Whether they’re working on PRDs, stories, tickets, or requirements, a product manager on a team with high levels of team ownership spends less time detailing every last element. They know that the rest of the group is listening and has a shared understanding of what they’re building and why. The team should be able to self-organize around targets, and the result is the PM does not need to be a micromanager or project manager.

Pillar 4: Cross-departmental communication

A product culture with strong communication allows stakeholders to feel more invested in the success of the product and smooths away conflict. It reduces status updates and busywork for the product managers. Reducing jargon allows everyone to be on the same page.

Effective cross-departmental communication doesn’t appear overnight. At one of my previous companies, we sought to improve our communication with an initial pilot. We assembled a cross-departmental team to plan and execute a feature that would require a complicated rollout. The team kept each other in the loop throughout, from reviewing customer quotes, to defining success metrics, to developing training materials for staff in the field. The team formed a shared language around the end-to-end process and goals. This led to a smoother go-to-market motion for the big launch and helped everyone feel less stress throughout the process.

Product managers hosting back-to-back meetings is not a sustainable or scalable communication method. Especially not on all-remote teams. Product ops can enhance asynchronous communication and make sure everyone understands the product development process. As communication improves, it becomes easier to align on a product roadmap, create an intake process for new ideas, and execute a go-to-market process with fewer surprises.

How does your organization measure against the pillars?

Use this four-part framework to score your organization in each key area. It will help you create a roadmap for your product ops investments. By conducting this type of assessment you’ll have a clear picture of which areas are holding your team back from making better decisions. You’ll be able to get the most value from everyone’s time.

As one area gets better, it will often drive improvements elsewhere. The best product ops leaders cycle through the change management process, finding small experiments to run, making incremental changes, and then iterating to the next.

Many thanks to Erica Ruiz for all her assistance in crafting this article.

Getting started with product operations at your company doesn’t mean you need to hire a product operations team. Start by taking a few steps to be more deliberate about where your team is investing today and acknowledging what the work would be worth to you. Simply shining a light on the shadow product operations work that’s happening in your organization is a great first step.

Talk soon,

Jenny

---

Who is doing your product operations work today?

Someone is doing product operations work at your company today. Your team has ways that they do things, whether by accident or design, and someone is helping move that work forward. A few examples of this work include:

• Scheduling customer interviews
• Helping clean up the events in your data analytics platform
• Running a roadmap review session
• Creating a project plan for a product launch

For a longer list of suggestions, I made a worksheet that you can use to try and identify who is doing what today. If nobody were doing any of this, your products would be at a standstill. Product ops has to happen at any company with a product.

Writing the names down next to these tasks should be illuminating: is most of the work being done by leadership? Individual contributors? Is the work spread across many people or is one person really taking lead? Answering these questions will help you understand what kind of operating model you’re using today (more on operating models later).

Is this the way you want this work to be happening?

As you look at who is doing what, you want to identify where you’re comfortable with how things are going and where you want to be.

First off, is the work that they’re doing the right match for the role? It might not make sense for product leadership to be validating data, but might make sense for them to be leading roadmapping processes.

You’ve identified the people doing the work. Now look at the expectations for their roles: do they actually have the capacity to be doing this work? Is it sustainable alongside their other responsibilities? What is falling to the side in order to make this happen? Did you mean for that work to be de-prioritized?

There is always more work to be done, which means that there is also product operations work getting less attention. Are the areas where people are investing their time the highest-priority ares for the organization? Are there priority areas that are not getting as much attention? You can make use of the four areas of product operations as a resource to help you think through it.

Which operating model makes sense for you?

Now that you have a good sense of your priorities, where you want to invest, and how you’re investing today, it’s time to figure out what operating model you want to use moving forward. Your operating model defines your philosophy around what type of value you deliver to your product team and how you plan to deliver it.

Map where you are today, consider the ways it is (or is not) working for you, and map out where you want to end up. As you think through this, consider the pros and cons of each operating model.

Finally, evaluate what sort of investment you’ll need to make in people and processes to power your new operating model. For instance, you may need to add product operations work to job descriptions, or increase staffing to better support your product managers’ success.

Acknowledge the tradeoffs

This exercise challenges you to prioritize product operations work alongside the rest of product management work. As with any prioritization exercise, there are going to be tradeoffs. It’s easy to say that you’re prioritizing in one way, but then not actually make the necessary changes to support that prioritization. Product ops is an investment in your organization, which means that you need to actually invest in order for it to succeed.

As you look through everyone who has been quietly doing this work already, make sure that you are recognizing it. It’s easy for product operations work to blend in with basic administrative work and disappear from everyone’s radar. Show that you value the work by thanking the people doing it and rewarding them for their efforts.

Finally, don’t let this exercise be a one-and-done. Routinely put time on the calendar to review it and iterate. See what you’ve learned, how the organization has changed, and set new priorities. The more you treat your product operations work as product work – with roadmaps, prioritization, and user research – the more successful it will be. So just like any product, once you’ve launched, measure and iterate.

Just as with any product, you need to understand the current state of your users before you try to change anything. That’s why it’s so important to get a full picture of your product operations function before you try to make any big changes. While it takes time to understand the entire picture around how the product team is functioning, there are a few questions I prioritize when establishing a baseline.

Each of these questions maps back to some of the key pillars of product operations: using data; understanding users; team ownership; and cross-departmental communication. The faster you can understand the way your team is working in each of these areas, the better you can diagnose the best course of action.

The goal is not to just ask these of the product managers, but of the entire product development organization and key stakeholders. The more you understand alignment around these key product concepts, the more you’ll be able to make suggestions that move the needle.

Five of my favorite questions to ask to quickly understand how well the product operations function is running

Do you know what is on the roadmap for the products you’re working on or work with?

This question focuses on communication, both on a team and across departments. If the engineers and designers don’t have roadmap clarity, they’re going to struggle to make great decisions about the product as invested owners. If stakeholders across the org lack understanding of what’s coming up, they’re going to struggle to make sure the product is promoted and supported appropriately.

Do you know how to find product and business performance data? When is the last time you accessed it?

I recently worked with a client where everyone had a strong sense of the business data. Everyone knew whether purchases and overall utilization were trending up or down. But they didn’t have a great sense of product performance, so were unsure about the leading indicators to that business performance data. This slowed down their velocity overall because it meant that to see the effects of changes they were shipping, they had to wait for that business performance data to shift.

I ask this of everyone because even if every person at the company doesn’t use this data frequently, everyone should be able to access it when needed.

Do you know which products are performing well and which are not?

This may seem similar to accessing the data, but it’s got some nuance. Just because someone can access the data doesn’t mean they are looking at it. And sometimes reports are sent out about product performance that don’t require you to actually access the data.

In addition, this helps indicate if everyone agrees on what good product performance looks like. Sometimes different people have different opinions on what the target is, which can indicate a lack of alignment or shared understanding across teams or departments.

How many times have you talked to a customer/user in the past 4 weeks?

For the product team, this question helps you understand the sophistication of their product discovery process. If everyone in the product trio isn’t talking to customers with some frequency, you’re leaving value on the table.

For stakeholders, this helps you understand company culture. Is this an organization that sees the value of talking to customers across the board? It can also indicate how much product is bringing stakeholders in early on work to build alignment.

How frequently do you hold retros? What was a change that came out of a recent one?

When a team has frequent, well-run retros and follows up on action items after, half of product operations work will be taken care of. Good retros identify areas that need improvement across data and communication, help the entire team feel ownership and responsibility over their work, and get everyone invested in team processes.

This is just the beginning

As with all user research, make sure to listen actively and ask good follow-up questions. Don’t just take the question verbatim and move on. Listen for what’s being left out of answers as much as you listen for what’s being included.

When I run a product operations assessment, I ask these questions and quite a few others. I then pair it with a survey and generate a pretty extensive report. But if you’re looking to just get started and target some critical areas to focus on at the beginning, these five questions will get you quite a bit of data and insight to work with.

This article on setting a team model was originally posted on the Product-Led Alliance under the title “Choose your own adventure: models of product operations” on March 21, 2023.

---

Here’s some harsh truth: most companies assume product operations (prod ops) work will just happen. They take a haphazard approach to this critical work, assuming things will just magically fall into place. But this approach leaves many teams feeling frustrated and overwhelmed by the amount of work they have to do. Instead of relying on volunteer time, take deliberate steps to improve your team’s effectiveness.

This guide is to help all product leaders – whether prodOps is a separate role or just another responsibility of product management leaders – figure out how to organize prodOps work in their company.

Before you can choose the right model for your organization, you need to understand two things: 

1. What the goals of your product operations function are.
2. Who is doing the work today (there are assessments that can help with this)

Unless you have a dedicated prodOps function, the people doing this “glue” work are probably not being recognized for their efforts. Defining your product operations organizational team model helps structure their efforts and improve the quality of their outputs.

Choosing a Model

I like to think about your model as a “choose your own adventure” team structure. For every spectrum below you can pick either the extreme or the middle of the range. If you have a complex org structure, you may have some sub-groups on one side of the spectrum and  some on the other.

The most important thing is to deliberately choose a model; don’t let the work continue to happen in the same haphazard way it has been. There is no wrong choice – depending on your team dynamics, strategy, and resources one direction might make more sense than another. 

Team hierarchy

The first decision is whether prod ops is going to be a separate team or not. Many successful companies have never had a separate prod ops role. Many successful teams love having people dedicated to prod ops. Some choose a hybrid approach, where certain team members spend a percentage of their time on operations work. 

Most independent prod ops teams still report through the CPO, though in some organizations they report to a general manager, CTO, COO, or program management. 

Team hierarchy
Unified with product management	Separate team
Good for… – Turnaround situations where product leadership is trying to shift product culture – When you want to make sure the people feeling the pain of weak operations are motivated to fix it – Small teams that can’t afford a separate role	Good for… – Complex organizations where prod ops involves a lot of time interacting with other departments – Where there’s a need for deep focus on prod ops challenges – When you want to make the resource allocation to prod ops explicit

Operating principle

Prod ops work can take three different shapes in terms of operating principle: 

• Enabling: Creating the infrastructure to help others do their jobs better
• Coaching: Teaching others the processes and procedures to do their work
• Execution: Doing the operational work for others to free up their time

I’ll admit that I personally lean towards enabling, but that doesn’t mean it’s the best choice for all teams. At some companies, it may be that certain people fill an enabling role, certain fill a coaching role, and yet others do execution work.

Enabling work focuses on reducing friction for product managers to work more effectively. By creating tools and processes, one can reduce the amount of effort a product manager needs to move development forward. This is the most common model of product operations. 

Organizations that need more standardization lean towards the coaching model; Kroger, the large grocery chain in the US, has invested heavily in this direction. 

If the product manager could really use a partner to get more done, the execution model might make the most sense. In these organizations there can be a risk that the line between prodOps and product management begins to blur, and a prod ops function might start to look more like a business analyst role. An example of this work might be prod ops synthesizing user research or writing the go-to-market documentation. This resembles what the prod ops team members at Uber do. 

Operating Principle
Enabling	Coaching	Execution
Good for… – Creating broad impact with fewer people – Prioritizing process improvement	Good for… – Organizations that have hired more junior people – Having the most reach per person	Good for… – Complex organizations with overworked teams – Adding capacity to the team

Work allocation

As with many other roles within an organization, there’s the decision about whether to do a shared service or embedded function. As a shared service, the people responsible for product operations act as a pooled resource for the company. Embedded means that the individual is on the team for which they are doing the work. 

This can be done in a hybrid fashion. At Doordash, the Director of Product is responsible for product operations in their area. They are, in effect, an embedded function for their department. When they need company-wide consistency, the directors team up to act as a shared service.

Work allocation
Shared service	Embedded function
Good for… – Organizations with more teams than fewer people responsible for prodOps – Big system thinkers and wide-ranging ideas Quality output that’s consistent across teams – Improving the collaboration across departments	Good for… – Tight alignment with the product manager or strategy – Complex organizations with overworked teams – Improving the collaboration of the product development team

Degree of focus

Do you expect prod ops to be focused on one or a few areas of prod ops, or to be able to jump around as needed? Think about designers – in some companies, user researchers, content writers, and UX designers are separate specialties. In others, they hire product designers and expect them to be able to do all the roles at least to some degree. This same dichotomy applies to prod ops.

Prod ops can specialize in a variety of different ways – either focusing on customer type, such as at Pendo, a product pillar, or a particular outcome that you’re targeting. 

Degree of focus
Specialist	Generalist
Good for… – Larger teams to avoid duplicative work – Organizations striving towards very specific goals	Good for… – Smaller teams where people need to swarm on problems – Flexibility to chase after different problems as the landscape changes

Don’t Choose a Team Model alone

Figuring out the right model is challenging. As you work through structuring your team, remember the following: 

First, don’t try to figure it out by yourself. Work with your partners across the company to decide on goals and evaluate options. If you need further help, call in an expert to provide an outside perspective. Run a workshop to figure out where you are today, where you want to be, and why. 

Second, don’t expect your first model to be your final one. Organizations iterate and evolve over time, just like products. What works today will not work forever, and it’s important to be flexible. 

While product operations as a separate role is a relatively new discipline, prod ops has existed since the birth of product management. The only thing that has changed is that we have started talking about it explicitly. As a product leader, recognize who is doing the work today and make sure you are thinking deliberately about how you want it to be done in the future. The teams that don’t spend time thinking about prod ops are also frequently the teams that struggle to ship quality products.

Changing how I use my dishwasher reminded me of why I am an operations geek. Seriously, hear me out:

For the longest time I was in camp pre-rinse. If I didn’t, my dishes would always come out caked in dried up food and I was convinced that I just didn’t own one of those mythical dishwashers that cleans well. I was resigned to my fate of doing dishes for 20+ minutes a day.

I thought I was being environmental because I was only running my dishwasher when it was full to the brim. Meaning every 2-3 days. Me and my partner talked about our glorified drying rack of a dishwasher.

I then read an article which talked about water and energy usage of dishwashers. Turns out that a modern dishwasher uses very little energy and as little as 3 gallons of water per wash. And the article was very much in camp “don’t pre-rinse” because even washing one place setting can take something like 8 gallons of water.

So we decided to run an experiment. For one week we would switch over to no pre-rinse, but we would also run the dishwasher every night so food didn’t get dried on before the dishwasher ran.

This was a total game-changer. We have saved hours per week of chore time which means more time to relax (or write newsletter articles). But we’ve found other benefits too: we no longer run out of clean silverware; we enjoy having guests over more because it isn’t as much work; it’s one less thing in our relationship to cause friction.

This is a perfect analogy about the value of operations. Great operations have value that compounds:

• Doing something regularly makes it easier to not fall behind. Set cadences so teams don’t end up with a giant pile of work that will never get done.
• Free up time in people’s days. It isn’t about adding process, but streamlining. When done right, you are giving people more time to work on what matters.
• Make it easier to work together as a team. When people have more time and clarity of responsibilities, it’s easier for them to work together. Nobody wants to spend their time managing interpersonal conflict.

Have you had a dishwasher moment in your life or work? Tell me your story!

It takes deliberate effort to create an environment where a new product manager can hit the ground running. Their onboarding experience in the first few weeks helps set the tone for their whole tenure at the company. Given that your product culture is shaped by your product operations, the new hire experience will also be influenced by how you’ve set up their first few weeks.

To set the tone, I like to include something I call “one small change” on their 30-60-90 template to get them up to speed on the company’s product processes. Creating an environment where the new hire can succeed at “one small change” means investing in documentation and infrastructure that will benefit the entire product team.

“One small change” is exactly that – take one minor improvement all the way from idea to execution. Identify a point of customer friction, work with the team to create a solution, and get it deployed, all within their first 45 days at the company.

The onboarding experience

Looking at a product with fresh eyes, it’s easy to see all sorts of major issues that need to be fixed, but there’s often a complicated reason those issues haven’t been addressed. That’s why I focus on helping new hires get to know the teams and processes at their company.

I had a “one small change” experience when I onboarded as a new product manager at SpotHero. They had set up a customer feedback Slack channel, giving me an immediate stream of data. I noticed a pattern — 1-2 times per week someone would ask for help deleting a credit card from their account. The current flow required a swipe to delete and people had trouble finding it.

I approached our design team about fixing it. They quickly came up with an easy fix based on common patterns. Engineers were happy to add it in the next sprint and still get a bunch of other things done.

The impact was apparent as soon as we shipped. The requests to delete cards stopped. It gave me a chance to learn about how the team worked and develop trust, and I had my first fingerprint on the product within my first 45 days on the job. 

I came to them with a idea backed by data. I let everyone bring their expertise to solving the problem. I learned a few things about our development processes that served me well as I started looking at those big, hairy issues. We all got an easy win.

Operationalize the experience

Looking back, I realize that product leadership had set up a number of systems and processes to make this accomplishment possible. As a result, when I’m onboarding new product managers, I now take the following steps:

• Create an easy way for your product manager to access customer feedback. The Slack channel hookup meant that from day 1 I was getting quantitative customer feedback.
• Make your product development lifecycle explicit. I knew exactly who to approach first in order to get the design process started.
• Express leadership support. I call it out as an expectation on the new hire’s onboarding plan.
• Celebrate the accomplishment. Highlight the new hire’s success by inviting them to demo their first win. Give them the support to make it go smoothly. This also opens up the door for the broader company to meet them.

The bonus is that this helps the entire product team. Everyone can take advantage of the customer data, having a clear product development lifecycle makes it easier for everyone on the team to move in sync, and celebrating the small wins reinforces the value of quick, small releases and continuous delivery. It’s a small technique to push people towards a cultural change.

After having been at a company for a while, it’s hard to remember how much a new hire has to learn. The “one small win” provides a structure for them to focus on people and processes, while allowing for the subject matter expertise to be gained along the way.

It’s December, which means that it’s time for predictions about what’s going to happen in the new year. Product-Led Alliance shared a number of product operations leaders’ predictions for 2023, including things like more companies adding product ops as a separate function, consolidation of the definition of product ops, and increased resources to product operations.

I have been thrilled to see prodOps getting substantial attention. And while I think that we will see more companies investing in it over time, you hear a very different story when you talk to product leaders generally versus people who are already in product operations roles. Here’s the honest truth: the majority of companies don’t have formal product operations roles right now, and won’t be adding them in 2023 either.

No product operations? You’re not alone

Product operations is a new specialization, taking responsibilities that have traditionally belonged to product management leadership and formalizing them in the org structure. That means that product operations is relevant to every product organization, because every company has product operations, whether they know it or not.

Whether that company is any good at prodOps is a different question. Nonetheless, since every company is doing product operations, many don’t see the need to separate out and invest in specialized staff. And especially for smaller teams, if a product leader has to choose between adding another full-stack PM or a prodOps professional, they’ll almost always choose the PM.

The rise of frameworks and training

Even though most teams won’t add a formal ProdOps role, we are going to be seeing more and more teams thinking about ProdOps as a discipline that deserves its own frameworks and approaches. Product management leaders will bring these frameworks into their own day-to-day work, taking advantage of the thought leadership coming out of the companies that have invested in separate product operations teams.

With that, we’ll see material designed to train product leaders in how to improve product operations within their own companies. Whether online courses, videos, books, or articles, 2023 will be the year we see hockey-stick growth in the volume of material.

Fractional support and consulting

More companies will decide to invest in product operations as a result. They’ll test the waters by bringing on short-term support. We will see an increase in fractional product operations teams or product operations consultants available to support product leaders for less than a full-time hire as the leaders think about how they want to improve their teams’ efficiency. They will choose one of a few paths: getting an outside product operations assessment, coaching, attending trainings, or bringing someone in-house for a few months.

What are your predictions?

With tech companies trying to go leaner in 2023, every product management team will be trying to accomplish more with a smaller group of people. This creates a perfect opportunity for product operations to gain a deeper foothold in these organizations, as it helps teams do more with less.

I’d love to hear your thoughts on where these trends will take us! Shoot me a message and share your 2023 product operations predictions.