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 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:
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.
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.
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
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).
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 …
Based on the previous story, here is a list of advice from my experience at ManoMano.
The first one is the most important to me: don’t wait, take the opportunity, people wait for it!
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)
Structure your work and act as if you were an actual team
You need to be a product manager to begin
You won’t change the world in your first day …
… and especially your own problems
Meet your customers
Listen, listen, listen and create links within the team
Not all your topics will work in the first place
Work hand in hand with product managers
Impact measurement .. still a dead angle to me
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).
Comments
Join the community
Sign up for free to share your thoughts