Learnings from scaling Product Ops (0 to 1)
Being the first Product Operations hire in a product team implies bigger challenges than expected - and more fulfillment. One person takes care of the vision, the strategy, the execution and the evangelization of the role (hopefully with help). I don’t think there is any success recipe, but I have learned four valuable lessons from my own experience that would set me up for greater impact if I were to start over.
1) Avoid executing other people's plan: start by building my own plan and align priorities.
On day one, the only thing I knew was what I read in the job listing as “areas to impact”, but one week later they changed and I was given very specific tasks that needed to happen. Priorities seemed very clear, but they weren't: partly because there wasn't a clear definition of the role, partly because no one had effectively mapped out all problems for ProdOps (which seems obvious because it was no one's job).
I wanted to be productive - and liked, of course, I was new to the team -, so I just switched on my execution mode without questioning whether the huge list of tasks that I'd been handed over would really bring the highest impact. Soon enough I got to make loads of things happen, yet I felt they weren’t changing people’s life. At the end of the first quarter I stopped the wheel, reflected and switched to:
- Doing my own research to map out the opportunity space.
I didn't expect a full map of all the problems, but I did surely trip over the biggest stones by asking the right questions to the right people. - Designing my objectives and strategies, aligning expectations with management.
I learned it’s best to focus on one area at a time rather than trying to influence many areas at once. Rapid execution without focus and a plan may seem convenient in the short term but will hardly ever lead to success. - Building trust.
Building relationships and bridges with the people in the different teams help to reduce barriers to changing the status quo. Quicker wins may do the trick at the beginning instead of jumping straight into big projects, as well as genuinely caring about people and their individual experience in the system. - Educating about ProdOps to align expectations on the role.
This is a very important responsibility as a first and only ProdOps person in a team. I took for granted that everyone understood the role in the same way but I was wrong. This saves a lot of frustrations, noise and endless meetings.
2) Effective change adoption must be part of the "definition of done".
Since I was executing many things at the same time without a clear strategy, I wasn't really paying attention to the effective delivery of my initiatives. Reflecting on that, I realized that ProdOps is about changing people's behaviors: we arrange for either doing something new (whose value is not proven to the team yet), or doing something differently (something that used to work for the team). This requires different levels of change management strategies that I wasn't adding as part of the plan, so some changes were not very welcomed by all members of the team, and some others were not even adopted at all.
I began to learn more around this and learned that there are two important questions to reflect upon when expecting a change in behavior:
- Will people need to apply the change soon or won’t they need to adopt the new way for a while?
- What do I intend to change? Is it a particular procedure, a whole skill or a culturally embedded behavior?
The book Design for how people learn by Julie Dirksen (recommended by John Cutler) was really helpful for me. I understood that different answers to those questions need different communication strategies, so I’m experimenting now with this and putting more effort on designing delivery strategies that lead to increasing adoption rates.
Another thing that I found very helpful for change management is to involve the team in the solution (when possible). I’ve seen an increase in acceptance and adoption in several sensitive changes when at least some team members were involved. Some even became ambassadors of the changes and helped persuading the rest of the team to adopt them.
3) My scope is the Product Operating Model.
Understanding the context of the company is important, in my case it is a hyper-growth startup. The way product used to be developed needed to be adapted to the new company stage, the way product decisions were made needed to be transformed; silos had been generated, which led to miscommunications, inefficiencies and inconsistent product experiences as value streams were disconnected. Culturally, customers have always been at the core of our business, not only of our product practice: their experience, support, performance, satisfaction… This means that if I want to solve the main problems of the product team, break silos, connect value streams from end to end and have the maximum impact, the rest of the teams can't be left out of the picture (i.e. customer experience, marketing, engineering and sales).
We are all intertwined and I wasn’t taking into account their side of the story in discovering both problems and solutions which worked also for them. Local solutions, particularly when it comes to communication and collaboration with product team, don't work once deployed to the whole organization.
I learned that to be successful as a ProdOps in a customer-driven company, my scope is not only the product team’s system: it is the Product Operating Model of the company.
4) A common definition of success is critical to alignment and change management.
Finding and agreeing on a useful definition of success for ProdOps objectives and milestones is a whole topic in itself and I cover it in:
These learnings result from being the first hire of Product Ops in a product team, but also from this being my first experience in the role (previously, I was a product manager). I would, in fact, argue that they are applicable at any stage though more relevant when the ProdOps team is not mature enough.
