I recently wrote an article about the importance of taking care of all the components of a product environment. Through this article, I tried to expose how I viewed the world in which product managers evolve and how to make a team more impactful.
However, I didn’t address one of the important questions: Who is responsible for applying these principles and ensuring this work is done?
Product ops is a spirit, not a role
Product leaders are responsible for the health of their company’s product environment. Hence, they are the ones who should shape the organization and set the right set up so that the team operates efficiently. However they are often busy people with few time to dedicate to such tasks (set the discovery framework or a moment for product managers to share and discuss, …). This is where product ops come into play.
But what do we mean when we speak about product ops? Today there is a hype surrounding this role (I mean a dedicated role in product organization). However, product ops has always existed. I have always seen people stepping up, (sharing their experience, setting up a new tool or framework, …) just because they thought it was the right thing to do. It was just not as visible as today and took other forms that a dedicated role in product organization. This is a question of mindset.
Then (to me), you can find different ways to perform product ops:
- The product leader doing it him/herself → great start but somewhat very limited
- ‘Isolated’ contributor → Working part-time, he often has good seniority and energy to lead actions, but the lack of structure, time and recognition limit the role
- Objectified senior people → Product ops is part of their job. It can be a good deal, but as for the leadership, enablers' efforts often come last and can be very long.
- Community of volunteers → A structured approach that can lead to tremendous results if you have the support of your leadership
- Eventually, the product ops role or team → a full ‘professional role that can have more impact because more time is dedicated.
It is important to note that one way is not more credible than another; credibility will be found in the problems you solve and how you solve them. Also this is up to you to continuously adjust it to your team and make this evolve.
The story at ManoMano
I have been at ManoMano long enough to know that we have used at least three different methods for product ops.
When I arrived at the company, it was the same time as its biggest fundraising with many projects on the grill. Hence, many teams were created, and many people were hired in tech and product. So I landed in a big product team (around 60 people at its peak) with much heterogeneity (skills, experience, location, …) and a lot of complexity.
Isolated contributor already made great things
Many initiatives were already launched by senior product managers (AB testing and analytics framework for instance) and a Miro board gathering many product managers’ feedbacks. The seeds were there, but we were missing common direction, support and also organization. I felt like we needed to go further and build on these foundations.
Note that I have been hired as a regular senior product manager in the first place, not to take this position. However, I saw an opportunity to step up but also to use the product skills I had gathered during my almost 10 years of doing PM
But we needed more structure
As I didn’t want to repeat the same mistakes as before, I decided to bet on volunteers and launch the first product community of ManoMano. Let’s meet POPEIE (Product OPEratIons and Excellency).
A first round of calls for volunteers brought 6 people (10% of the team, including a head of) with whom we began to structure our community. Although frustrating as we didn’t deliver, this phase was critical as it allowed us to pitch our project to product leadership, who gave us full support. Then, a second round of calls for volunteers with an official presentation led us to 12 people (20% of the team)!
The illustrations above represent the making of our product community as well as its diverse realizations
We delivered, from buddy programs and welcome letters for newcomers to the mentoring program, BET framework, or knowledge centers. We had successes and failures, but we didn’t manage to tackle important topics and bring something consistent for the whole product team (given that it was volunteer and side work and a big team).
From a community to an actual role in the organization
At this point, we had proven the value and benefit of tackling product issues (create a true dynamism in the whole product team, support to product leadership) but it was not enough. This very fact has been the trigger to consider creating a specific role (ie a product ops person). It was a long discussion process I had with the product VP and Head of (as I led the product community), not to convince them about the role (the fact we had a community already made up its mind) but rather to build the scope, the mission properly, …
And eventually, I was there, one year and a half after entering as a senior product manager. The beginning of a new era! My very first steps entering this job were to define the operating system (how do I work, with which tools), evangelize it to all leaderships and especially set up the product barometer and measure the product team’s maturity to create my very first ops roadmap.
After about 1 year and a half, what a ride, working with different departments, delivering many topics (customer insight center, product crafternoon, hackathon, supporting orga changes, ….), experiencing more failures …
Advice for people or companies who would like to begin with product ops
Based on the previous story, here is a list of advice from my experience at ManoMano.
You begin product ops with Isolated contributor / Community of volunteers
The first one is the most important to me: don’t wait, take the opportunity, people wait for it!
- When I sent the first call for volunteers to launch the community, 10% of the product people answered. The VP product was also very supportive
Try to get as soon as possible the support of your leadership (even if you feel like you are not moving as fast as you would like to)
- This is the difference between isolated initiatives and a recognized group. At the beginning, we didn’t release this for two months but worked on our organization and our principles to get the approval and support of the product leadership
Structure your work and act as if you were an actual team
- This is very important, especially if you begin with a community of volunteers. Acting as a team will give you visibility and credibility. At ManoMano we had a name for our specific rituals (demo, roadmap). Of course, this is not as smooth as with a regular team (given people are volunteers) but at least you create pace.
You want to go further and are looking for a product ops position
You need to be a product manager to begin
- Although the first product ops of some companies is not a product manager, I tend to think it should be. The main reason is because you will work for product managers and you need to understand how they work, their pain points, having gone through what they go through.
You won’t change the world in your first day …
- Don’t begin your job thinking you will change everything quickly, change takes time and it is also easy to get lost. On the contrary, try to identify and win some easy and quick-win battles first to gain recognition, trust and credibility.
… and especially your own problems
- This job is not about fixing your issues but understanding the whole product environment and acting on what’s more important. When I entered it I was in that spirit : I have done many years as a product manager, my problems are the same as the other product managers and are important. I will fix them first. False, when listening to other product managers, I discover new problems or new priorities I had no clue were important , Be humble and listen to people!
Meet your customers
- Product Ops could be compared to a B2B SaaS company: you provide a tool (product environment) for professional users. Then your users are close to you and you can figure specific problems or pain points easily. That can be informal points, surveys, specific points (I used to have 30 min every Friday to meet one random product manager)
Listen, listen, listen and create links within the team
- At ManoMano we have three offices and many people working in remote. Hard to create a common team dynamic. This is where I discovered an important part of my job (not quantifiable though) : Product managers have things to say, and the feeling of being listened is highly valuable and also triggers the fact to belong to a greater team where things are done for you.
Not all your topics will work in the first place
- When I am asked what the most important quality for a product ops team was, I always answer Resilience. This is the master word here. As an enabler function, you bring new processes and ways of working to the teams. Even if at first people seem to like it or even ask for it, you will have to enforce them, accommodate change, evangelize, market … and sometimes it doesn’t work. That’s not a big deal; move on to the next topic!
Work hand in hand with product managers
- To complete the point above, it is important to collaborate with product managers on specific topics to ease adoption or to begin with specific teams. This can ease (not solve) the evangelization part. At ManoMano, every Head of department was involved in a specific topic, and I also relied on volunteers PMs to work on specific topics.
Impact measurement .. still a dead angle to me
- Something I still struggle with is impact measurement: I went through many directions. From using the results of the barometer (but 6 months) to apply OKR (but too granular), even usage was a bit complicated sometimes. Eventually I ended up looking at formal feedback …
In the end the road to master product ops and create an efficient product environment is not straight and similar to what you see in books or in other companies. It can have many shapes begin with small experiments and iterations. The most important thing is to create a mindset among your employees and begin to identify problems to solve and then correctly dimension this role (e.g if you are a startup with 5 PM, you may not need a dedicated role, on the contrary this is different if you are a scale up at a pivot moment after a massive fund raise).
