Product Operations - Where to Begin
Always operate with a Product Mindset when you’ve got big problems to solve.
This will be the first post in a series I’ll create around Product Operations. As the space grows, I find the same questions coming up from people who are getting their team off the ground, and new questions from those who have matured their orgs a bit. My goal with these posts is to memorialize what I’ve learned along the way and share more broadly as a way to give back to the Product Management Community. There’s no one size fits all model here, but I’ve learned that enough of us have come up against similar challenges, so it’s only right to find a way to support one another.
I hope it’s helpful to those starting out, or thinking about Product Ops.
About three years ago I embarked on a little journey where I started Product Operations, formally, at my current company. I say formally because truth be told, I have been doing Product Ops work since the day I became a Product Manager back in 2011. I’ll save the ‘How I fell into Product’ story for another post but let’s just say I accidentally, and happily fell into both Product Management and Product Ops thinking the same thing both times:
“It seems like there are a lot of problems to solve for my customer, and I’m up for the challenge.”
In short, Product Ops became my official job after years of understanding how a Product Team impacts a business, and not just the experience customers have with a software product. It became my role after my leadership and I realized we had lots of problems to solve for our organization at large, and not just the Product Team.
Over the last few years in Product Ops I’ve had the privilege of speaking with hundreds of product passionate, tech savvy, customer obsessed humans, and I’ve learned something important: No matter the age, size, growth trajectory, or industry, you have the opportunity in Product Ops to create a system that will impact both the internal and external customer experience, and not just that of your Product Manager.
So, now that someone has tasked you with this challenge, how do you start?
I mentioned when I fell into Product Ops, I felt the same way I did when I fell into Product Management. So, it’s only natural for me to recommend you start with discovery and problem identification as you would with an actual product.
Find the pain. In this role, you have an opportunity to make an impact in Product without putting things on a roadmap or launching a feature. Like a PM, I was hungry to figure out what work I needed to do to make a positive impact. All my years of understanding how tech companies work told me that I didn’t just need to start with the PM as my customer whose pain I needed to dig into. So in discovery mode, I also leaned into the relationships I built with my partners in Sales, Customer Success, and Marketing. I asked these partners what a successful partnership with Product would look like for them. Each of them had their own ideas that would clearly impact their goals, but they all centered around one common theme - transparency. Breaking that down further I learned that they were hungry for more from a Product Team that was already doing so much. But ‘more’ did not necessarily mean more features on a roadmap. It meant they wanted to know just enough for their individual roles - as a Salesperson, a Solutions Engineer, a Customer Success Manager, a Product Marketing Manager… I can go on - to be dangerous and successful. They felt excited about what the Product Team was doing, but not truly armed to speak as confidently as they wanted to about it.
In speaking with some who have tried the ‘find the pain’ route, I heard lots of the following:
My Sales team only cares about understanding what it takes to get a ‘valuable’ request on the product roadmap.
Sales doesn’t have time to learn everything but they need to know about everything.
Each CSM cares about what their customers care about the most.
Technical Success feels like they’re always escalating to product and turnaround time takes so long.
Product Marketing wants dates.
The common thread here is transparency. Whether it’s understanding how decisions are made, or when a new feature or capability is coming, or how to get education, a huge theme that arises in the beginning for many Ops teams is transparency.
At the same time, we dug into the pain of our Product Managers, knowing that standing up systems for scale was the first part theme of our journey. Put simply - that’s why operations teams exist - to stand up a system that an entire unit can use repeatedly to enable results. I also leaned in a bit to the pain I felt as a Product Manager, knowing what my time went to for so many years, wishing there was a better way.
We sent a simple survey asking our PMs questions. Some of these are below and I’ve included some that others have shared based on this recommendation while they started:
On average, how much time do you spend fighting fires?
How much time on average do you get a week to do discovery calls with customers?
How many sources of data are you looking at for feedback?
How painful is the quantitative data collection and analysis process?
How much time a month are we putting towards experimenting?
How much time on average do you get a week to brainstorm and plan with your engineers?
How often are different revenue team members asking you repeat questions about your roadmap?
How effective are your planning and roadmap sessions?
How often do you *repeatedly* change delivery dates?
And with each of these we used scales or ranges so we could later go back and measure the effectiveness of any of the processes or systems we would perhaps put in place to help combat the pain.
When you have a good understanding of all around pain, it becomes easier to identify quick wins that create trust and builds relationships. Like we do in Product, start small and test the effectiveness and value, then iterate based on results. As an example, in early days, a ProdOps manager would join a recurring Success team meeting to deliver updates on behalf of the PMs. This:
Gave the Success team information they needed for the next few weeks
Helped the Success team understand how to get training and education
Reduced the one-off questions to the PMs about their near-term roadmap and plans
VERY quickly we outgrew that model. To be honest, not everyone can do that these days with the way we’re set up to work across the globe or because their internal customer base is large. Within a few months, we moved to a recurring product update email that went out once a week. We noticed a drop in questions, but a rise in the need for more detail. This is what I call ‘a good problem to have’, and is something I’ll go into in the next post.
All of the above leads me to the first rule of Product Ops. Establish trust. We felt the trust being built with both customer sets through this first move. I can’t stress how critical this is for Product Ops. This is a highly cross-functional role where you are in the center of so much. Establishing trust is non-negotiable.
With one win in our pocket, we started to mature the system we created around it, and picked up the next problem… as a Product Manager naturally would. But that thing I mentioned about good problems - let’s dig into that next time…