Product operations: From zero to one

Product operations is a fairly new role for most companies. It certainly is for us.

Before creating a product ops function in our company, the product team at large had to absorb the responsibilities. Product leadership owned some duties while others fell to the Product managers.

For me, I liked being a product manager but I knew I wanted to work on more than a single product. I wanted to have a broader impact across my team. And thus, I felt the nudge towards product operations.

If you’re exploring the practice of product ops for the first time, read on to hear from someone who’s walked in your shoes. I’m not sure if the approach we take will work or not. We’re making bets and adjusting as we go. At the end of the day, it’s an experiment but it might be helpful for others who are struggling to get started.

In the spirit of building in public, I’m sharing what I’m doing and how I’m doing it as I go.

So let’s jump in…

Not all Product Ops roles are created equal

When I was looking around for roles I could grow into, product ops excited me. But it also confused me. There didn’t seem to be one single definition or description about what this role should look like.

Searching around for “product operations” job descriptions returned plenty of results. But there wasn’t any consistency.

Each result seemed to describe a slightly different version of the role, yet with the same title.

Some seemed to be a junior product manager role disguised as product ops — aimed at helping to schedule meetings, coordinate QA testing, and take other tasks off the plate of the product managers.

Others are more at the 20,000–30,000 ft. horizon. You’re expected to help leadership refine product development processes and play matchmaker between stakeholders of various departments.

Ultimately, I joined product ops slack channels, curated a list of Twitter follows, and generally tried to define our own version of what product ops would become.

Treat your product organization like a product

There are many variables such as company size, culture, team structure, industry, etc. that play very important parts in determining the success of your approach. What works for one company might not work for another.

Regardless of how you decide to define product ops in your organization, you need a view of the landscape within your company. You need to know where to dig in. As a new role, you’ll likely be under some scrutiny and you need to know where to find quick wins.

My solution to this problem was to rely on what I learned as a product manager. My strategy was to take a product management approach and define the points of friction. And from there, the right actions would begin to present themselves.

When I say “take a product management approach,” I’m referring to the concept of treating the product development process as the product to be managed.

The team of product managers, developers, and designers becomes your product features to optimize. They’re also the customers you serve. Your “customers” can also take the form of department heads, stakeholders, and executive leadership.

Marielle Velander sums this up nicely with her explanation of product ops:

In many ways, a product ops team functions as a miniature product team — the product process is my product, and the product team are my users. Therefore, my success in product ops hinges on my ability to understand the needs of my users, the product team, and align around shared goals for the improvement of my product — the product development process.

The intent is to focus time and energy on solving the right problems, which will yield the biggest impact.

This practice of tackling problems strategically based on data is beautifully explained in this tweet thread by Will Lawrence. From this point forward, I’ll use the same firefighting analogy Will uses in his thread (seriously, go read it and then come back).

Finding the most threatening fires

Coming into the role of product ops, I needed to gain a bird’s-eye-view of the landscape. This was critical to understand how many fires were burning, which fires are the most threatening, and which fires I could let burn while I work on the others. In other words, I needed to be strategic about how I planned to spend my time. I’m a team of one in Product Ops, so I didn’t have the luxury of anyone to hand down this context.

Approach

I sent out 3 different surveys:

• One to the Product Managers
• One to the developers & designers
• One to the department heads and key stakeholders from ancillary teams the product team interacts with elsewhere in the company

Each survey consisted of the following sections:

• Likert scale questions
• Open-ended questions

Likert scale questions

Here’s a breakdown of the Likert scale questions and who they were directed at:

Respondents scored the product team on a 1–5 scale. These scores were bucketed into the following:

• 0–2: Detractors
• 3: Passives
• 4–5: Promoters

The results were then calculated using the NPS method:

(Number of Promoters — Number of Detractors) / (Number of Respondents) x 100.

This allowed us to establish a baseline score from each cohort across each category. The result allows us to use the scores to quickly spot which categories need the most attention (depending on the cohort and overall).

As you can see from the example above, the lowest score was in Collaboration with other departments, Setting others up for success, and Data literacy. These are low-hanging fruit opportunities. I can dive in and get some quick wins if we’re able to move the needle in these areas.

We can also go deeper and compare the NPS scores for “Product Strategy” to determine how each cohort feels about our competency in that category.

I can conduct the same Likert scale survey at regular intervals (quarterly, bi-annually, etc.). This enables us to see if/where we’re making improvements based on the interventions Product Ops has been able to make.

Open-ended questions

I used the open-ended questions to further unpack areas of concern and organize them into themes (keep reading to learn more below). I also used them as jumping-off points for deeper exploration during one-on-one meetings.

Product Manager survey

I asked the following open-ended questions to our PMs:

• In general, how do you feel about collaboration with other teams at {Company_Name}?
• What do you think about the product team at {Company_Name}? What are the biggest opportunities for improvement?
• How do you feel about collaboration within the team? What works well? What needs to change?
• How do you feel about our current way of organizing our work within the product team?
• What do you enjoy about your job as a PM? What do you struggle with?
• How do you feel about making decisions in your role? What could make this process easier or faster?
• How do you feel about your ability to innovate? What could make it easier or make it happen more often?
• Thinking about the last 6 months, do you feel you’ve been able to create impact for {Company_Name}?
• Do you get to use all of your skills in your current role at {Company_Name}?
• Do you feel that you’re being acknowledged for your work? Do you feel you’re being rewarded for the right things?
• How satisfied are you with the mentorship and coaching available to you?
• How would you describe what the {Company_Name} offering will be a year from now?
• How do you feel about the current way of organizing our work within the Prod/Eng/Design ecosystem as a whole?

Developer/Designer survey

I asked the following open-ended questions to our Devs/Designers:

• When collaborating with the product team, what has worked well? What is the most frustrating?
• Which project phase of the product development lifecycle is the most frustrating for you? Why?
• Which project phase of the product development lifecycle is the most enjoyable for you? Why?
• Where do you see the biggest opportunity for improvement in how the product team works with you in your current role specifically?
• Where do you see the biggest opportunity for improvement in how the product team works with your team?

Ancillary teams survey

I asked the following open-ended questions to any ancillary teams the PMs interact with:

• When collaborating with the product team, what has worked well? What is the most frustrating?
• Where do you see the biggest opportunity for improvement in how the product team works with you in your current role specifically?
• Where do you see the biggest opportunity for improvement in how the product team works with your team?

Fighting the fires

The process of identifying the most threatening fires still isn’t done. While the survey responses bring the fires into focus, you still need to stack-rank them.

We use a tool called Productboard at our company to collect and organize insights from various sources into a central place. My next step was to treat each of the open-ended survey responses as “insights” and dump them into Productboard.

From there, I could triage each piece of feedback and group them into collections of similar themes. The themes are then further unpacked until you have obvious and tactical actions you can take.

The benefit of this approach is Productboard can easily display the themes in a stack-rank order. This quantifies the themes and actions top to bottom in order of most to least comments.

From here, we’re able to format each task into a roadmap for product ops in exactly the same way one of our PMs would create a roadmap for their swimlane. Productboard has a module specifically for various roadmap layouts, but you could easily use many other tools to achieve the same outcome.

Congratulations! This is your bird’s-eye-view of the most threatening fires. It’s organized into separate time buckets and is easily shareable. The next step is to simply start putting out the fires in this order.

Closing thoughts

Product ops can take many forms depending on your company, your team, and your challenges. You’ll have to develop the toolkit that works best for your situation.

A newly formed product ops function needs to demonstrate its value in order to gain momentum. The Likert scales and firefighting roadmap are two easy-to-use tools in your toolkit. They can help you communicate where you’re going and measure your impact on your journey from zero to one.

A tool like Productboard isn’t required for this method but it saves you some serious time and avoids spreadsheet gymnastics. Tools like this also typically have the “road mapping” feature pictured above. This allows you to actually plot out your firefighting plan in a timeline format that’s easily shareable.

Get Product Ops Certified👇