I'm constantly being asked what product ops really is. I boil it down to four key areas: using data, understanding users, team ownership, and cross-departmental communication. As you think about different ways to improve the effectiveness of your product managers, categorize all your ideas into these buckets. If something doesn't fit, it might be worth considering if it's really in scope or not.

As a subscriber you get early access to my article on the subject before it's published elsewhere. It's a bit long, so you get two pillars today and two next newsletter. As always, I respond to every email I get from newsletter subscribers, so let me know what you think!

Enjoy,
Jenny

The best leaders approach product ops 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 product operations framework 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.

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 increases trust in the data. It improves access to access 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.

Understanding Users

Good PMs 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 provides templates and clear next steps for the rest.

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.

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.

... stay tuned for part 2!

🙏 Enormous thanks to Erika Ruiz for her contributions to writing this article!

​