Product Ops: Gaining Support while Setting Boundaries
What you’re not doing is just as important as what you are.
The title of this sounds a little strange, doesn’t it? Usually when we think about gaining support for something - investment in a team, a project, a tool, what have you - we think about telling people just how much we’ll do with that team or tool, or what the project will entail.
This post is inspired by a recent chat I had with someone who is about to embark on his Product Ops journey, building his team and practices, after much success in another ops seat. He’s got overall buy-in but this is a new role, and his concern is making sure he’s respectful as he kicks this all off.
One of the questions I am asked a lot is, “How do I make sure that the PMs and PM leadership see me as a partner, and not someone who is stepping on toes?” My answer to this, every time, is to ask start by asking your Head of Product a simple question: “What are we holding PMs accountable and responsible for?”. I have yet to see a Head of Product tell me they are holding PMs accountable for many things outside of identifying and solving customer pain, building innovative, revenue generating products with Engineering, and reducing churn and risk with the product by focusing on the overall experience.
Before I continue it’s important to note I do speak with Heads of Product who have already bought into the Product Ops role so this applies to many roles you’re worried you’re blurring lines with (Product Marketing & User Research come up a bit). Asking what that role is responsible and accountable for clears up confusion on where energy needs to go to hit those goals.
The thing with Product Management is that in addition to the items I mentioned PMs are held to, there comes the need for the system for them to do their best in so the customer gets that great outcome. As product teams grow, we need to find a happy path that helps us scale (and doesn’t force process that stifles innovation).
So, you need to be clear and say, “Great. I’m not accountable or responsible for those items, so odds are, my activities won’t be theirs. I’m here to make sure the PM can focus more energy with customers, engineers and our stakeholders.” In doing so, you’re making it clear what you will not be doing. It’s not your job as a Product Ops manager to do customer interviews, on-sites, etc. It’s not your job to partner with and inspire engineers to build or prioritize fixes with them. It’s not your job to present ideas to the Executives on what you believe is right to build next. The ‘what not’ helps clear up most worries when it comes to stepping on toes.
It’s your job to focus on the pain the PM has that prohibits or limits time spent as it relates to all of those activities. Whether it’s standing up the system for them to efficiently plan and communicate to stakeholders, or align with the sales and customer teams, or not handle an entire knowledge base, or manage an entire voice of customer program, or standardize data, or manage all tools and integrations, or something else, your work needs to strengthen the overall unit to drive better results.
Once that conversation goes well, the next thing you’ll get asked is, “So, what are you doing?”
In a prior post I mentioned one way to start in Product Ops is by identifying pain for the PMs and the broader organization as it relates to the Product Org. If you’re like me, or many of the people I’ve coached on doing this, you’re aware there are more pain points than you can count on two hands.
It becomes very easy to make a list and keep knocking items out to show progress and help get more support and buy in. This is why focusing on problems, and not just tasks off the bat is critical. What we need to be very conscious of is this: Jumping into task mode sets expectations that you will take on many (or any) things. Sometimes these things may not align to business goals. And before you know it, you’re managing a lot more than you intended, putting you further away from creating and maintaining that system I keep mentioning.
So, in your early days of Product Ops, it’s important to strike a healthy balance of knocking out the right low-hanging fruit (to gain trust and have a few quick wins), and breaking down complex problems (that will set the unit up for long-term success) while building your roadmap.
Odds are you’ve already surveyed the PMs and close partners and done ‘user interviews’ ahead of getting buy-in. If you have not, remember you are also building something new, and need to treat it like a product. So even before you go into your buy-in conversation, have your research done and a high level list of problems to solve in your role.
As you progress, work on very clear objectives with milestones. These are a great way to help your leadership see what you’re doing and where you’ll potentially need support. Make your problem-focused roadmap transparent and ensure your plan is clear to all relevant parties. Work with your leadership (I suggest quarterly, at least) on prioritization of your problems, and use this to reduce the one-off requests that may come in, as they always do with ops teams.
In doing so, you’re working on setting realistic expectations early. This is critical when it comes to setting boundaries on your work (and this is important for any role!). You can't be everything to everyone, and it's important to recognize your limits. Be clear about what you can realistically accomplish and communicate this to others. It's better to under-promise and over-deliver than the other way around.
Lastly, remember that this is a new role. We are in a space where we will be figuring it out for a while. Each company is different from the next that I’m speaking with, and each Product leader wants one of several flavors of Product Ops for the current state of their company. So the most important thing here is that communication is critical to clear up ambiguity and confusion. At the end of the day, the “behind the behind the scenes” will make an impact to the customer, so focus on healthy transparency to make sure you are driving that positive impact as a team.