Category: Articles

Learn more about what’s happening on your product team via surveys

As a product operations consultant, I have to be able to quickly jump in to understand how a product team is functioning. Just like any product manager, I do my user research before I start making feature changes. I combine in-depth interviews, surveys, and document reviews to get a full picture. One technique I use that’s been the subject of a few product ops discussions recently has been the survey.

Surveys have some advantages:

• Easy to run (though hard to design)
• Can provide data over time to show progress
• Allow you to hear from a large group of people

I never run these surveys in a vacuum; just like with product research I use many methods to get as complete a picture as possible. The survey data gives me one set of data points that I always supplement with interview data.

At the end of an engagement, I run the survey again to show how I’ve been able to support a product team’s growth. It’s great to be able to demonstrate that I’ve had a positive impact on their goals.

Why it’s so hard to measure product operations

Within product ops, there are currently no agreed-upon methods to measure our impact. That’s because the outcome of product ops is a better product culture and culture is notoriously hard to measure. We can measure behavior. Behavior drives culture, but it provides an incomplete picture.

The HR world has been struggling to measure culture for many years. They’ve established a few limited ways to get a sense of company culture – surveys, interviews, behavior tracking, and following some metrics that can be gleaned from management systems (retention and referrals, for example). We have access to these same tools in product ops, and in this article, I’m going to dive into one method in particular – the survey.

A survey is going to be an imperfect measure. They aren’t great for giving the context behind answers, and subtleties get missed on multiple-choice questions. Despite its imperfections, it’s the best way to get a quantitative perspective on our qualitative work. We must take a product mindset to our work in product ops – which includes measuring our outcomes, just as we expect product managers to do. If we decline to try and measure our work at all, we run the risk of being categorized as ineffective or unnecessary.

In the rest of the article, we’ll cover best practices for running product ops surveys.

Survey design should focus on the target culture

It’s quite easy to end up with a survey that asks about every element of your product culture. While it is tempting to baseline everything, proceed carefully. A long survey will have lower response rates and many of the results will likely sit around unaddressed. That could create frustration for some people who feel they are not being listened to.

Focus your survey questions on the type of company culture you’re trying to build. Work with your leadership to define the key characteristics that your team values and measure for those. Don’t waste your time measuring things that you aren’t trying to change.

For instance, let’s say that your focus is on improving the product team’s use of product analytics. Focus your questions on how frequently they’re referencing the data, how easy it is to access, and what they’re doing to communicate findings. Since use of data will probably not correlate to release notes and documentation, don’t ask about those. On the other hand, use of data relates to how a product team prioritizes their roadmap, so you may want to ask about roadmapping.

Follow best practices around what good survey design looks like. Work with experts in survey design at your company – you likely have someone in UX who is trained in this. Test your survey questions by running the survey as an interview with 2-3 people to make sure questions are being interpreted appropriately. Ask someone else to edit your survey before it goes live.

How and when to run a product operations survey

Product operations doesn’t impact product management alone, but touches many other departments. Therefore, run the survey with all relevant colleagues – product development and go-to-market teams. Use question logic to show the applicable questions to the correct audience to keep the survey as short as possible for everyone.

To get strong engagement with the survey, think about how you will advertise it. Use techniques that will get you the highest engagement levels. I always ask my client, who is usually the head of product, to send out an email in advance of my sending the survey. The email lets everyone know to expect an email from me, a stranger. The announcement from leadership also encourages people to participate. In companies that have a strong Slack culture, I schedule a few posts directing folks to the survey so they get notified of it via multiple channels. I also mention in meetings that the survey is running and encourage everyone to do it. For best results, leave 5 minutes at the end of a meeting for everyone to take it then and there.

In terms of frequency, send the survey out on a regular cadence, changing as little as possible each time. This way you get valuable data to see where you’re improving. Send the survey to the same teams each time, making sure to add new hires and remove people who have changed roles. You want to keep elements constant.

To decide the optimal cadence, run the survey when you think you’ll see new information emerge. If you are rolling out a new roadmapping process, but only do roadmapping once a quarter, I would expect there to be useful feedback from the survey every 6 months or so – once the team has had a chance to try the new process out twice. If you are doing monthly roadmapping, you could start to see the effects of your work every quarter and so that would be a good cadence.

I don’t generally recommend doing a survey more frequently than quarterly. The feedback is less likely to have changed and you run the risk of creating survey fatigue by asking the same questions too frequently.

Questions to ask

Choose the questions that work best for what you’re trying to achieve and learn. I start each survey by collecting demographic data – where the employee works, their department, their tenure with the company, and whether they’re an individual contributor or a manager. I then dive into general sentiment about the product development process. 

After that, the survey splits depending on whether they’re part of the product development team or not. The product development team gets asked about whether they feel their ideas are valued, if they feel like they contribute to the team, and questions about communication patterns. 

The go-to-market teams get asked about what type of communication they receive, if they know what product is doing, and if they feel like they’re being listened to. You can find inspiration for the types of questions to ask in this article, where I go into detail about five of my favorite questions.

What gets asked beyond that depends on what is getting measured. It’s useful to use the pillars of product operations to make sure you’re covering all that you need. At the end of each section, I leave an open-ended option in case someone feels inspired to share more information.

Interpreting and using the survey data

In general, you want to look for places where there’s strong agreement or disagreement. That indicates topics where your survey is more likely to have actionable insights.

After reviewing everything at a high level, I always slice the data by role. For instance, with one client I found out that everyone thought the product development process was sub-par except for engineering, which loved it. Other times I’ll find that GTM teams feel left out of the loop, but product development feels like things are headed in the right direction.

Other dimensions to use to interpret the results include by tenure at the company and by whether they’re a manager or IC. Finally, if the company is split across multiple locations I check if there are differences between those near HQ and elsewhere. For instance, with one client they had the majority of their engineering in India. The survey results indicated communication issues due to the time zones.

As soon as analysis is complete, create a quick report on it and record a video walkthrough. Send the video to everyone who was asked to take the survey. By sending out the results of the survey quickly, you promote a culture of transparency and indicate that the survey data is being used. This helps get a strong response rate for the follow-up surveys since everyone knows it won’t be a total black hole. If you make changes based on what you learned in a survey, be sure to communicate that out.

Don’t overcomplicate it

In terms of tools, whatever your company already uses for surveys should suffice. The most important feature is the ability to add skip logic so you’re asking the right people the right questions. For analysis, I usually import the data into a spreadsheet and pivot table so I can dissect the data in various ways.

To summarize:

• Focus your questions on the culture you’re trying to build
• Include colleagues from across the company
• Keep it as short as reasonable
• Run it on a regular cadence
• Market your survey strategically
• Use skip logic to keep it relevant
• Analyze it across multiple dimensions

If you want extra help in survey development or execution advice, drop me a line about coaching opportunities. If you’d like to run a larger baseline assessment and are looking for a neutral outside perspective, I can conduct a product operations assessment for you.

The sooner you start taking your baseline, the sooner you’ll be able to measure your progress. Keep it simple, use best practices, and get your survey out the door. You’ll be excited to see the results roll in.

Thank you for the quality feedback from Adam Kecskes, Michelle Harris, and Miriam Karlin.

Product management took 85 years to come into its own. How long will it take us?

When I first heard about product management, I knew it wasn’t for me. I had no technical background, didn’t want to work at a giant company, and wanted to practice human-centered design. 

This might sound confusing since product managers don’t need to be technical, do exist at companies big and small, and are supposed to constantly practice human-centered design. 

(puts on old-timey voice) Back in my day, there wasn’t this sort of consensus about what a product manager should be. Coming out of my MBA program, Google and Amazon were hiring the most PMs, they required engineering backgrounds, and were not talking about user research. 

There were tons of other companies at that time doing product management, but the role still felt niche. As a result, there were so many misconceptions. Fast forward to today and there’s clarity on what the role of a PM is, how to do it well, and what kind of person should be in the role.

What product management’s history can tell us about the future of product ops

I’ve been part of several private conversations recently where others have expressed concern about the lack of alignment in product ops. They have expressed a few concerns:

• If we practice product ops poorly, those organizations will not want it anymore and we’ll kill the discipline
• The people defining product ops incorrectly will end up leading the conversation, and the role will end up in a place we don’t like
• All this disagreement makes the product ops community look disorganized and will deter adoption

My advice: instead of worrying that some people are wrong on the internet and sending product ops down a path where it will be doomed for failure, accept the fact that we are early in this journey. 

Product ops today reminds me of product management back when I was starting out. We don’t have alignment on what the role is, what the work looks like, or who should do it. 

And that’s okay. We’re going to get there. 

There are some lessons from product management’s journey that I think can help preview the future of product ops. There will be a lot more disagreement before we get to alignment.

It took decades for any standardization to emerge

In the beginning, product management looked very different than today. It started as a marketing role and was about understanding the customer to craft the right message and shaping product direction. Due to the influence of the Toyota Production System and manufacturing, this eventually evolved into building what the customer wanted. (This is part of why delivery management has been considered part of the role in so many companies. Martin Erikson’s history is truly excellent if you want to dive deeper.)

It wasn’t until the Agile Manifesto that the core tenets of product management got well-articulated in one place. Even so, the Agile Manifesto doesn’t even use the word “product”. And until quite recently, as Aaksash Gupta puts it, “the ‘primary job’ of a product manager was considered to be writing product requirements documents (PRD).”

There was no “proper” product management role at the beginning and it took decades for standardization and specialization to become part of the role. Be patient. The product operations role is still evolving.

Spirited debates were critical to creating consensus

If you read any content on product management from the mid-aughts to the mid-teens, it was filled with debates about what product management actually is or should be. People debated if the PM is the CEO of the product, if PMs need to know how to code, if there should be dual track career paths, and the debate continues to this day on whether PMs are necessary at all.

The fact that there were enough people to participate in those debates and hold strong opinions was a sign that product management was coming into its own. If people were willing to argue, they really cared. These debates were critical in driving consensus. Many of the arguments have quieted down because people started coming to an agreement on an answer. 

We are going to have a lot of debates in product ops for a long time. Do we need it or not? What is it? Should you have a product management background? What does the career path look like? These debates are a good thing. Lean into them. It helps us learn. And eventually, by having lots of these debates, out in the open, we’ll become more and more aligned on the nature of product ops.

Companies created product management hiring programs at scale

Aakash’s history of product management highlights how the companies that created large-scale product management programs also made product management ubiquitous. Product management didn’t come into its own exclusively because people were talking about it; it took several respected, large companies to hire and train a lot of people into those roles.

The alumni from Intuit, Google, and HP went elsewhere after their first PM jobs and brought the discipline with them. As Aakash points out:

In addition, where it was practiced, it was not uniform. Companies like Microsoft built out their Program Management functions. These were product managers who were expected to do some technical program management. It was their own twist.

Those companies succeeded, and others started looking to emulate their practices. The product manager role finally found momentum.

We’re seeing companies start to build out product ops programs. But there are only a few companies that we can point to right now as “lighthouse” organizations (e.g. Uber and Pendo). We aren’t yet seeing a high volume of product ops people graduating from these companies and going elsewhere to start programs. As product ops sets deep roots in some high-profile companies, their graduates will start spreading the gospel (and the consistency of their training) elsewhere.

Training and education provided common language and framework

Training and education have played a massive part in creating consistency around product management. Marty Cagan’s seminal book Inspired came out in 2008 and was the first book exclusively about product management. Product Operations from Melissa Perri and Denise Tilles just came out a few weeks ago and is the first of its kind. It’s too early to tell if their book will become foundational like Marty’s.

Formal training in product management and communities were other ways that the role got codified. Product Tank (2010) and Mind the Product (2011) created the first formal path for product managers to share what they learned and feel like they were part of something bigger. Product School (2014) and Reforge (2016) created formal training programs that allowed people to both break into the discipline and level up their capabilities. Product ops has some communities forming, such as Product Led Alliance (added ProdOps in 2021) and ProductOps HQ (2022). Trainings are currently infrequent, smaller programs, and organizations like Reforge haven’t (yet) introduced product ops training.

A healthy training (and, for better and for worse, certification) ecosystem is critical to establishing product ops as a standard role. Right now, the trainings will have to talk about the disagreements around the role. Some trainings will be great, some will be mediocre. But they’ll move the use of common frameworks forward and add more legitimacy to the space.

How we get to agreement in product ops’ future

If we want product ops to establish itself, there are a few things we can do:

• Continue having open, healthy debate about what product ops is and should be, and welcome disagreement.
• Figure out what the specializations should be in the role and begin shaping those.
• Celebrate every new company that establishes a product ops function.
• Embrace more trainings and community-building opportunities.
• Remove normative language from how you talk about product ops. There aren’t “better” or “worse” ways to do it – we’re all experimenting together in it. Different circumstances will require different approaches. In the end, the results will speak for themselves.

It’s hard being in an emerging field. It takes the phrase “being comfortable with ambiguity” to a whole new level. But success will come from navigating that ambiguity as a community. Just as I had been exposed to a flavor of product management that no longer exists, many product ops roles today will be considered antiquated sometime in the future.

The first product managers started at P&G in 1931. It took about 85 years for product management to gain mainstream acceptance. Sales ops took about 40 years for mainstream acceptance. One of the first product ops roles started in 2011. It hopefully won’t take decades for product ops to hit mainstream. But it will take time. Until then, be proud that we are pioneers in the space and embrace the challenges that come with that.

Thank you to Kevin von Gillern (#openToWork), Anna Peterson, and Joshua McLaughlin for their marvelous edits and comments.

A book review of Product Operations

Product operations has finally made its way into product leadership conversations. This attention can partially be attributed to the launch of Melissa Perri and Denise Tilles’ new book, Product Operations: How successful companies build better products at scale – if Melissa Perri thinks something is worth writing a book about, the community listens.

The book’s argument implies one big question: what should product leaders and product managers actually be spending their time on? The authors’ answer: once you start scaling, not product operations. They recommend hiring a separate team to handle the challenges of a growing team.

In that sense, this book feels like a sequel to Melissa’s first book, Escaping the Build Trap: How Effective Product Management Creates Real Value. In that book, she explained how product management can deliver value. In Product Operations, they explain how to free up product management and leadership time so they can actually succeed.

Is product ops the best path forward?

As they explain, being such a new discipline means a lot of people don’t understand what product ops is or why it matters. Melissa and Denise promise to lift the veil of confusion by telling a fictional story, explaining what product ops is, and sharing case studies from companies like Fidelity, Amplitude, and Stripe. They want you to see the undeniable appeal of product operations: “Once product managers, product leaders, and the C-suite fully grasp the leverage product operations brings, everyone will want it – and should want it.”

They address the counter-argument to this right at the beginning: most successful companies have created product teams without hiring product ops professionals. 

Lots of product managers are, in fact, taking on many aspects of product operations. What’s the problem with that? 

Well… they’re burning out.

Product ops is one method to solve the problem of scaling product teams, but not the only strategy you can employ. Bringing on product ops has its own challenges. Yet all the alternative ways you can solve this problem have challenges too.

Explaining product ops

In terms of introducing the audience to the world of product ops, the authors do a wonderful job. Their three pillars are clear and comprehensive:

• Business data and insights: Collection and analysis of internal data for strategy creation and monitoring
• Customer and market insights: Facilitation and aggregation of external research
• Process and practices: Scaling product management value with consistent cross-functional practices and frameworks

I worry that that the “process and practices” naming makes it sound like product ops’ job is to deploy processes and define templates. While these are common methods used in product ops to achieve success, the goal of a great product ops team is never to implement a new process. The goal of the team should always be to encourage a particular behavior. The detailed write up covers this nuance, but the way the pillar is named runs the risk of people glossing over that critical information.

As for why product leaders would want product ops – they present the strategic value of product ops quite clearly. Their examples of product ops in practice showcase leaders who are driving the capacity of the organization forward. They touch on the ways in which product ops can also remove administrative burden from leadership, while making clear that those administrative tasks are only one aspect of the function. Product ops does not aim to be an assistant to a product leader or product manager.

In terms of their third promise – how to run a product ops team – it would be impossible to write a book that answers this question for every organization. Instead, they provide a variety of ideas on how to get started. These include convincing C-level executives of the value of this investment to deciding which problems to solve. They then sketch out what growth might look like, including some different topologies for product ops teams, and explain different ways to think about measuring product ops success.

Denise explained a key philosophy behind their writing:

I wanted to make sure we had something that was truly grounded in reality and had just so much actionable insights, positive case studies, case studies with lessons learned. And so I think that was sort of our guiding light, our product principle.

There will never be one guide to everything product ops

This book cannot be a step-by-step guide that tells you every detail of what to do. That’s because one cannot do product ops in a cookie-cutter manner. It needs to be customized for the organization it’s in and the culture it’s trying to build. Given those constraints, this book gets as close as most anyone can to providing tangible, clear steps towards launching a product ops function.

After the success of Melissa’s first book, eager anticipation surrounded this one. The authors managed to get a remarkable amount of information into an easy-to-read, concise format. It’s up to the reader to decide if product ops has undeniable appeal and is required for organizational scale. But there’s no question, after reading, that it has the potential to add value to many organizations.

Many thanks to my reviewers: Kedar Deshpande and Larry McKeogh. This post contains affiliate links.

Bonus: Roundtable discussion on the book

I was lucky enough to moderate a discussion with four people featured in the book: Clare Hawthorne, Gerisha Nadaraju, Adrian Leung, and Hugo Froes. We talked about how each of them got involved with the book, what they thought of it overall, and some lessons learned. Watch the whole thing:

Over the past few weeks I’ve been diving into what a strategic partner looks like and how to advance your strategic thinking. Today I wanted to take the conversation a bit more tactical to show how a strategy and a tactic interact. This type of case study is a bit different for me. I’d love to know if you want to see more content like this or not.

---

“When is the next release coming out?” 

“What’s in the next release?” 

“Was a change just shipped to my customers? What was it?” 

I’ve gotten these questions before. You probably have too. Whether these are coming from marketing, sales, customer support, or finance, everyone wants to know what’s shipping and when. 

Then there’s the most common question of them all: 

“What’s on the roadmap?” 

If I had a nickel for every time I was asked this question….I’d have a lot of nickels. And for many teams, especially on the go-to-market side, the roadmap question is actually asking about visibility into release plans. Turns out this is a remarkably common issue.

Communication strategies

I’ve talked to (and been on) so many teams that have struggled with communicating the right release information to all the right teams. Some want high-level summaries, others need detailed screenshots of every change. 

I interviewed two women whose product ops teams got it right. Alice Jin was part of the product ops team at Paper and Julia Bansemer was at Foodics. 

Alice highlighted that part of her strategy was increasing trust in the product team and product process. When you get communication strategy wrong, it erodes trust across product and the cross-departmental teams. They feel like product is setting them up to fail and struggle to find ways to work around it. Status update meetings abound. Product managers get constant messages and emails asking for status updates. Communication becomes a time sink for too many people. 

Julia described what it was like before the release calendar came out:

We had the feeling that product on this side and sales on the other side were talking two different languages, were two completely different worlds, and how do you bring them closer together?  

When you get this critical piece of communication right, you enable everyone to do their jobs better. Everyone moves a little faster. Julia’s shared with me the impact of a good release calendar: 

Colleagues from sales were so happy because they felt included and thought of. It also kind of dissolved the silo between product and all other teams. For us at least, [understanding releases] was the biggest clash between product and sales.  

There are a few things that these release calendars did so well: 

1. They went to where their customers were already hanging out 

2. They provided lightweight information with links to deep-dive as much as needed 

3. They were easy to administer and keep updated

Two companies, the same release calendar

The solution was dead simple: a shared Google calendar. Both Alice and Julia shared that the biggest motivator was going where the sales team already was. Every sales person started the day by looking at their calendar. So instead of another Slack bulletin or email newsletter (Julia tried both), a simple calendar event marking a release was unobtrusive but noticed. 

Alice included a few things in the calendar event itself: whether it was a beta or a general release, which customers were affected by the beta, and a link out to a Notion page with a one-pager and links to all the details. On Julia’s side, it was the name of the release, a link out to the Release Hub in Notion, a description of what was new, and a link to the Slack summary of the release. 

If a release changed, they could move the date. Alice set hers up as a shared calendar, which also gave coworkers the option to sign up for email notifications when events changed. Julia invited everyone to the event, and managed taking people on and off the invite as needed. 

For both teams, the product ops manager that worked most closely with the product area for that particular release kept the calendar and documentation updated.

Consistency and transparency build trust

As for advice for anyone looking to do this themselves, both Alice and Julia agreed that you should focus on consistency and transparency. 

It was very important that the calendar event was always up-to-date. Everyone had to trust this as the right information so they didn’t go asking anyone for the latest update. It had to be used for every release that met the criteria, with the same information every time. In other words: it had to be reliable. 

Because the solution was simple, it was easier to be consistent. The only real risk was forgetting to make the update when something changed. Because it linked out to the full documentation, it was easy to remain transparent and get everyone the depth of information they needed. 

And the more consistent and transparent the team was, the more everyone else learned to trust them and trust the process. This freed up product managers’ time to focus more on understanding their users and business value they could deliver.

Tactics emerging from strategy

I’m not advocating that everyone start doing all stakeholder communication (or even release calendars) via a shared calendar. But this story is important because it highlights that simple solutions using the tools you already have can be very effective. 

On top of that, it shows the connection between a strategic goal and a tactical solution. Both of them wanted strategically to improve coordination between sales and product. From a strategic standpoint, prioritizing this issue helped them because solving the coordination challenge also freed up product managers’ time. It slowed down the flood of messages each PM was getting around who was responsible for what release and requests for updates and more detail. Freeing up PM time from this task helped their entire product team become more effective. 

This is the power of product ops. A small investment, from one team member, is able to make two departments more effective. Operations is a space where one person’s actions can lead to exponential impact. In my upcoming cohort of the Product Ops Impact Accelerator, we’ll be talking about how you can think strategically to shape what you tackle on your roadmap. You’ll be able to ask your peers in the cohort how they tackled particular challenges so that you can get a variety of ideas on how to create meaningful change in your organization. I’d love to have you join us.

It’s there in your head – time to put it on paper

This article was originally posted on Christine Itwaru’s substack, The Product Heart on October 12, 2023. If you aren’t already a subscriber, you should definitely subscribe!

---

Chris Compston was part of a new product ops team that quickly identified some low-hanging fruit. There were 15 product teams and 18 product requirement document templates. Cleaning that up would be a great first win.

His team consolidated everyone to one template. I connected with him about this experience. He reflected:

“We were satisfying everyone while pleasing no one. It was a huge challenge and the effort and time it took was probably triple what we predicted. The teams did not suddenly become more efficient (what a surprise!) and certainly were no more effective than previously. Customers would have noticed no change in the value they were looking for, the business felt no change on the bottom line.”

They were hoping for fireworks and instead it fizzled. He realized that they weren’t strategic partners to their product team, but had just been reacting with small-scale tactical changes. The team shifted their approach when identifying the next opportunity. Their first step was asking better questions, like how to streamline documentation, improve collaboration, and get more value into the customers’ hands.

These questions and the solutions that emerged from them began to shift product culture. As he described it, they “forced strong discussion that moved us from a ‘throw it over the wall’ waterfall mentality, to truly collaborative product teams focused on customer outcomes and aligned to the business.” In other words, the product ops team became strategic partners to their leadership team. 

Become a value multiplier

Christine Itwaru shared on Lenny’s Podcast how product ops can add strategic value to the organization:

“You need to be able to articulate the value to somebody who’s heading up, essentially, businesses and saying, ‘Here’s what this role is going to drive for you at the end of the day.’ The very mature product ops orgs end up having people that are strategic advisors to a product leader. Once you can show that this is what you’ll also get as a result of me and this other person or me and this team doing [product ops], it ends up being an easier conversation.”

Back to Chris. He’s since become a product operations consultant and now approaches all his work with strategic partnership as the goal.

“My approach to any engagement is to communicate early the value this type of partnership can bring. That being the value to the customer and the business. What difference are you going to make to the organization, its customers and how can you impact the business on the bottom line?”

I recently wrote about how to tell if you’re a strategic partner. Now it’s time to talk about how to become one. The fastest way to get there is to build out a product ops strategy stack. Defining the five components of the stack for your organization and continuing to adjust and align them over time sets the foundation for a strong product ops function.

Build your product ops strategy stack

The elements of a strong product ops foundation are the same as in product management – I always refer to Ravi Metha’s product strategy stack when looking at these elements. They lay out five elements of product strategy to help explain the difference between mission, strategy, roadmaps, and goals. 

Ravi explains the connection between the five layers well:

“Importantly, each layer of the stack builds on the previous layer…. We cannot have a company strategy without knowing our company’s mission. We cannot have product goals without knowing our product strategy. Given this relationship between the layers, Product Strategy serves a critical role—it is the connective tissue between the objectives of the company and the product delivery work of the product team.”

By clearly defining your stack, you’re making the boundaries of what you will and will not do explicit. Looking back to the example above, having a framework to say “no” and focus in on value-add work instead would can help tremendously.

Below I break down the five layers of the product strategy stack with a product ops specific interpretation. While at the abstract level the stack remains the same as product strategy, each element can be interpreted specifically for product ops. 

Vision or mission

What is the product culture you’re trying to build? Work with product leadership to clearly define what great product management work should look like at your company. Look at your company strategy and figure out what product habits are most important to make that succeed. Perhaps you need a more execution-focused team, or a team that is absolutely amazing at discovery. Maybe you want a lot of consistency across every team, or are comfortable with each PM doing things their own way. Just don’t set out to be great at everything – a strong product ops mission should prioritize certain cultural elements over others.

Product strategy

What is the overall product strategy you’re supporting? Product ops strategy should be focused on prioritizing the capabilities that the product strategy needs in order to succeed. Make the product strategy explicit to drive alignment with the product ops strategy you develop. An example: if the product strategy focuses on optimization of current user flows, then the product ops strategy should include making sure that data quality and experimentation infrastructure are able to support that kind of work. 

Product ops strategy

As the heart of the product ops strategy stack, the core strategy itself is the largest and most difficult element to build out. It’s the layer most likely to change as the pieces around it shift, and most likely to force the other layers to adjust as it evolves. 

How will you turn your vision into a reality? Every strategy is a hypothesis about how the mission will be accomplished. Your product ops strategy should map out a high-level path that explains how and why you will take a particular approach to achieving that mission. Cycle back and forth between the organization strategy and the product ops strategy, because it is likely that as one becomes more clear, it will force the other to shift and vice-versa. 

How does the product ops function fit into the overall division of labor? There is no single right way to structure how your product ops team gets work done. For example, some product ops teams use a “staff augmentation” model, where the ops person embeds on the team to help supercharge individual PMs. Others will try to build more shared processes and tools to increase consistency. One quick way to start defining your organization strategy is to define your product ops operating model. This can be a shorthand way to explain how the company plans to deliver product ops value. 

Roadmap

What user problems do you need to solve to achieve that strategy? A roadmap focuses on the user problems that are standing between you and your vision. The strategy you’ve defined helps you set which problems you’re going to tackle first. Each problem you successfully solve then (in)validates your strategy, helping you know whether to stay the course or pivot.

Goals

How will you know that your strategy is working to achieve your vision? Your goals help you measure whether you’re making progress on your mission. They should confirm that the roadmap is advancing the strategy, and that the strategy is advancing the mission. A good guideline for product ops goals is that they should be focused on whether the product management organization is becoming more effective. If your goals are all around launching tools and getting adoption of tools and processes, you may need to lift your head up to look a little broader.

The most important part is to get started

Crafting your first product ops strategy stack is an investment in having a more focused future.  Chris and the Product Ops team realized, through this experience, that having a clearer documentation strategy would’ve been hugely beneficial. You will be able to focus more on what matters if you set up your strategy in advance as well.

Another reason to build it out sooner rather than later is that it should be a tool through which you learn and experiment. You may discover one part of your strategy that doesn’t contribute as much to your goals as you thought it would. The sooner you learn this, the sooner you can adjust.

This kind of adjusting is what Chris Butler, Group Product Manager at Google, calls aligning the product spine.

“I’ve often said that ‘strategy is now’. There isn’t a difference between tactical and strategic decision making in my mind. You ideally need to apply the high-level strategies to every decision. This is a key part of the product spine. There is a very important aspect that the strategy should be applied fractally down the levels of abstraction from very high level to middle level (like roadmaps, OKRs, etc.) and lowest level (backlog). If you can’t chain these things together, there is a break that will cause problems in the execution of the strategy.

As you go through this exercise, walk up and down the stack to ensure there’s alignment between each component. Every layer should connect to the other layers in a logical, cohesive fashion. If something doesn’t flow quite right, that’s a sign that the alignment is off and you will need to make adjustments. Eventually, the whole stack will click together, with each element supporting the others. 

The best strategies come via collaboration

The majority of my failures setting strategy have been in cases where I tried to do it alone. This has led to a lack of buy-in, nearsighted focus, illogical jumps in reasoning, and a general shortage of good ideas. The more I’ve collaborated on strategic exercises in the past, the better my results have been.Don’t try to do this alone. Collaborate with your product leadership, colleagues, and users. The more people you involve in your process, the better the outcomes will be. If you want an outside perspective on how to build out your stack, this will be a core component of the upcoming Product Ops Impact Accelerator and I’d love for you to join us to build out a great stack for 2024.

related articles

What is a strategic partner, anyway?

One common theme between every product ops manager I talk to is the desire to drive positive change in the organization. That’s why we got into this work in the first place – to be positive change agents.

And yet so many are frustrated that they aren’t achieving their goals. Which is why I’m launching the Product Ops Impact Accelerator. It’s a 7-week cohort program designed to help you become more effective in driving strategic change across the company.

Note the key words in there – strategic. Just like the best product decisions rest on a foundation of solid strategy, so do do the most effective product operations initiatives.

Over the next few articles I’ll dig in further to how you can make that transition to being a more strategic partner to your product leadership. I’ll provide a starting list of what you need to have in place to drive strategic impact and some of the benefits of stepping into that strategic space.

Check out the Accelerator

Product leadership: “I’m getting pulled in so many directions right now. I want to encourage more autonomy on my team to help free up some time.”

Product managers: “I want to do more strategy work in my role. It feels like I’m in execution mode all the time.”

I had been working with a client for several months on their use of data. The product managers understood what we were trying to achieve but felt stuck in the work they were doing. It felt too much like project management instead of product management.

The product leader and I were on the same page – we wanted to create true product managers, not project managers. So I proposed that we spend time strengthening the roadmapping process and skills on the team.

I proposed coaching for the product managers on building out their strategy and a process for translating that into roadmaps. This helps product managers take more control over what they’re working on and be better at communicating it out. It enables strategic thinking driven by metrics. It serves everyone’s goals.

Understanding the long-term needs of the organization, proposing ways to fulfill those needs, and executing on it forms the basis of what it means for product operations to be a strategic partner to product leadership.

We aren’t living up to our strategic potential

Product operations, done right, helps leadership achieve their goals through enabling the product management team to work at their highest level possible. A great strategic partner chooses very carefully how to make that happen. Yet when I talk to product operations professionals, they so rarely feel like they are fulfilling that potential.

The product operations manifesto includes as a prerequisite (emphasis theirs):

An understanding that Product Operations is a strategic discipline as well as an operational one.

What does it really mean to be a strategic partner, or a strategic discipline? Even if you know what it is, how do you get there? Over the next few weeks I’ll be diving into these questions. For now, I’m starting with what a strategic partner actually is.

Defining a strategic partner

A strategic partner invests their time in the activities that will have long-term benefits for the organization. They search for opportunities to be a force multiplier, where one hour of their investment results in multiple improved hours for their team. One article on human resources included an excellent illustration of what a strategic partner should do:

Strategic HR partners are not involved in the “weeds” of HR administration and execution. Instead, they focus on the big picture, collaborating with the HR d

epartment and consulting with the leadership team to make sure everyone is pulling in the same direction.

I constantly hear about prod ops fighting fires, getting bogged down in administering tools, and becoming a meeting scheduler. Instead, product operations can strategically create the right environment to drive product culture forward.

Antonia Landi talks about it on the Product Experience:

It is legitimately also a strategic role. I want to have these conversations with senior leadership about what kind of product organization we want to be in three years. Concretely, what does that mean needs to happen in the next six months? And then that is effectively my roadmap.

Strategic product ops partners think about the long-term outcomes of the activities they drive. They invest in their head of product’s goals and take action towards achieving those goals. They develop a strategy that helps make the overall product strategy more likely to succeed.

Are you a strategic partner?

Take a look at the list above. Unfortunately, most product ops managers are not strategic partners (yet). That’s because it’s hard. It takes time to figure out a strategy and to get the right buy-in. It’s no fun to say no all the time, but if you say yes to everything, it’s hard to stay strategic.

If you want to practice how to become a more strategic partner, I’m launching registration for the Product Ops Impact Accelerator soon. It will cover many of the key elements of strategic partnership, including how to build a product ops strategy and roadmap, put together OKRs or KPIs to track progress, and help you develop techniques to gain buy-in for your ideas. Sign up for the waitlist to be the first to access registration and get the early bird discount.

Thank you so much to my pre-readers for their thoughtful feedback: Brian Gibson, Adam Kecskes, Jeremy Finch

How one company structures their product operations to hit their goals

Drew had been waiting a long time for a pickup order at a new Thai restaurant in his neighborhood. The restaurant was swamped and still hadn’t gotten him his food an hour after it was supposed to be ready. A delivery driver in the same boat was waiting next to him and getting worried because his customer was going to be upset, but there wasn’t anything the driver could do to speed things up.

Luckily for this driver, Drew happened to be a product leader at the same food delivery company. His responsibilities included scaling and enabling customer support, trust & safety, and the overall delivery experience.

Drew pulled out his phone, looked up the customer whose food was late, and called to explain that he was with delivery support. He provided a full refund to the customer and gave the driver an extra tip. The next day, he kicked off an initiative for customer support to proactively help in situations like this.

I recently got the chance to talk to Drew about his experience and what the company has done to build a customer-obsessed culture. Due to company policy, he asked that I keep the company anonymous.

Becoming Customer-Obsessed Takes Work

This food delivery company prides itself on its customer-centric values. Drew’s company has ingrained this value into their product culture through a series of operational decisions. I wanted to learn more about how the company did it, so I sat down with Drew for a talk about product culture.

As he describes it:

I’ve really liked our “bias for action” culture. What that means, practically speaking, is if you have an idea and you have something you want to do for the customer and you feel strongly that it’s the right thing to do for the customer, it’s culturally encouraged to run through walls to get it done. We’d much rather you release something to five customers, speak to them directly for feedback, figure out if it’s working, and then build your case from there. 

Through our conversation, he highlighted five things that the company has done to make this possible:

1. Bring more cross-functional expertise onto the product team
2. Make it easy to get in touch with customers directly
3. Reward customer-first actions
4. Define the customer problem before building
5. Build in opportunities to generate empathy

Companies always say they’re user-centric, but not all make it easy to do. You need to integrate customer-centricity via multiple touchpoints to make customer obsession part of your culture.

5 strategies to encourage a user-centric product culture

Bring more cross-functional expertise into the product team

Most companies separate “technology” and “the business”, by having them report to separate executives and work on separate teams. At Drew’s company, an operations manager works on the core product team alongside design, analytics, engineering, and product management.

While the PM focuses on identifying customer pain points and opportunities, the operations manager’s responsibility is to leverage internal expertise to execute on a customer-centric go-to-market strategy. This means that the product and operations managers are both obsessing about customer pain points at different points in the journey and working together to solve them.

Although the ops manager is not part of a formal product operations team, this is another way for someone to be responsible for one of the product operations pillars. The operations manager embeds on the product team to lead the cross-functional communication pillar of product operations on a team, but reports to Operations.

Make it easy to get in touch with customers directly 

One easy-to-miss detail in Drew’s story is how he looks up the customer’s contact info. He was at a restaurant waiting to grab dinner, so didn’t have a laptop with him to dig through a bunch of different systems. His company invested in making these systems easy and accessible for all employees wherever they may be, on whatever device they may have.

As Drew points out, customers appreciate getting contacted by product managers:

Getting a call from the PM in charge of the entire area that didn’t quite work for the customer often times makes people feel, “Hey, they actually care, we were able to fix the issue.” So just don’t overthink it. The more guardrails you try to put up around talking to customers, the more likely you just don’t bother, and that creates a whole different issue. 

At Drew’s company, product managers can identify customers who have had particular issues, easily reach out to them, and not have to go through any red tape to do so. This simplifies bringing the customer voice into your product development process.

On top of that, the company runs “customer advocate groups”, which are roundtables of customers or people that frequently interact with customers. They can be a group of customer support agents, delivery drivers, or particularly vocal customers. The PM and operations team members set up customer advocate groups as needed, and the groups usually meet every week or two.

The key lesson: Make it easy to contact customers, build structures so the contact is frequent, and encourage everyone in the company to do user outreach to build this type of culture.

Reward customer-first actions

Drew spent company money that night to fix a customer problem. He did not receive any negative pushback from a manager, HR, or anyone else. On top of that, he reached out to the customer directly to provide help without needing to get permission from the customer support department or any other organization. When an employee reaches out directly to customers and spends company money to fix customer problems, they get praised for it. 

It sounds simple, but isn’t that common. Positive reinforcement for talking to customers, every single time, takes deliberate effort. It has to be celebrated frequently and publicly.

Define the customer problem before building

Product leadership at his company doesn’t let product teams start exploring solutions without a product brief. The product brief is a document intensely focused on the customer problem, why the problem matters, and the metrics that will indicate they have solved the problem.

What we find is really having a lot of focus on why is this problem painful for customers, why is this worth solving? It helps us to ultimately open the aperture on the different solutions and get to the right one faster.

The product manager drafts the product brief and makes sure the right people review it. The rest of the product development team gets involved in the editing and refinement process. Product leadership, like Drew, provide strategic guidance. This helps make sure the entire team has a sense of ownership over what they’re building. The team and relevant stakeholders iterate on the document together and evolve it until they’re aligned.

Build in opportunities to generate empathy

One of the coolest ways in which Drew’s company creates such a customer-centric culture is through their driver-for-a-day program. On a regular cadence, every employee at the company has to deliver at least one meal. This mandated dogfooding ensures that they connect with all their customers – drivers, restaurants, and diners – regularly.

As Drew’s Thai restaurant experience illustrates, first-hand experience can be powerful. Making sure every employee can do this kind of work regularly takes effort to set up, but the payoffs are huge. It makes customer empathy everyone’s responsibility, not just the product manager’s.

Customer obsession doesn’t happen by accident

Map out the various stages of your product development process. Decide what characteristics you want your culture to focus on the most. If customer centricity is a priority, make it explicit in your product development process. Is it clear how to include customer’s voice throughout? Are there any gaps where there’s a longer stretch without that voice of the customer? Are there any points where product managers on your team should be connecting with customers, but aren’t? Write it down and share it out.

This illustration of your product development process helps expose how you can bring that customer voice into the process, from discovery to launch and evaluation. And if you need more help to understand where you stand today, feel free to reach out for a product operations assessment.

Drew’s company has established processes to encourage a customer-obsessed product culture. They have thought about how to get customer-centricity into every step of the way.

---

Many thanks for the excellent feedback from ​Kedar Deshpande​, ​Ashleigh Zustra​, and ​Larry McKeogh​.

The product operations equivalent of the feature factory

My brand-new client was stumped. “We signed up for this roadmapping tool, but it just doesn’t seem to be doing us any good. Can you help us make the product managers on our team update their roadmaps more frequently?”

I asked them why they wanted me to be a temporary administrator of this particular tool.

“So users can tell us what they want us to build and so stakeholders stop complaining that they don’t know what we’re working on.” But that wasn’t how they wanted to build their product, and stakeholders didn’t want to be communicated with in that way.

I have seen this sort of thing more times than I can count. Bringing on a shiny new tool, expect it to make things better, and then be disappointed that you’re paying all this money and nobody is using it. Try to solve it by putting a person “in charge” of the tool.

The tool got in the way of the goal

This might be the most common product operations mistake I see. Someone’s job becomes managing or enforcing use of the tool instead of trying to achieve a certain goal. It’s the product operations equivalent of the feature factory.

I love talking to people who have just been hired into product operations roles. But frequently when I ask them what they’re doing, the answer is “implement a roadmapping/analytics/customer research tool”. They’re mixing up the HOW (the tool) with the WHAT (improving the product manager experience). 

Nobody takes a job because they get to be the “Jira/Productboard/Pendo/fill-in-the-blank Administrator”. People take jobs because they want to contribute to a greater purpose, achieve things that they can only do as a team, and have an impact on someone’s life. 

The purpose of product operations isn’t to automate things. The purpose of product operations is to improve how the product management team uses data and collaborates across the org.

The tool was out of the way of the process

If you look at my client’s request again, they wanted me to get more people to use it. This was the second major error I’ve seen. A company picks a tool, and expects everyone’s processes to shift to easily incorporate that tool.

But employees were working without the tool before. Their habits don’t include the tool. And colleagues in different departments aren’t even thinking about the tool.

This goes for tools and processes both. John Cutler wrote about how tactics and processes, like tool implementations will change, but the operational goal should be the same:

Start with principles, and you’ll discover the right approach for the current challenge. This isn’t meant to diminish process, just noting that principles establish a strong foundation.

To change culture and habits, the tool needs to easily fit into everyone’s workflows. If the tool isn’t getting used, it’s likely because it was introduced as an extra step in people’s workflows instead of replacing a current step.

Get the tool to support the goal

The best way to keep the tool from getting in the way of the goal is to invest in your product operations strategic foundation.

Just like a great product will always have a clear mission, vision, and strategy, a great product operations function will have a clear mission, vision, and strategy written down.

This document should answer:

• What kind of product culture you’re trying to build
• Why that’s the product culture you want
• What are the biggest problems product managers at your company currently face
• What order you want to address those challenges and why

When there’s a temptation to bring on a new tool, make sure it fits into the strategy first. Then make sure it fits into your current workflows. If it doesn’t, re-evaluate the solution you’ve come up with. Consider prototyping with a Google Sheet or running something manually.

Do your user research by talking to your coworkers, run experiments, prototype and test. The foundational work of product management belongs here too. And hopefully, at the end of this process, you’ll understand if you need a tool, and if so, how to implement it so everyone can use it.

Let’s draft your mission, vision, and strategy together

I’m thinking of doing a workshop or course to help people develop their product operations missions, visions, and strategy. If that’s something you’d be interested in, set up time to talk with me. I’ll happily walk through your thought process and provide feedback on a draft document.  

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.