This article on setting a team model was originally posted on the Product-Led Alliance under the title “Choose your own adventure: models of product operations” on March 21, 2023.
Here’s some harsh truth: most companies assume product operations (prod ops) work will just happen. They take a haphazard approach to this critical work, assuming things will just magically fall into place. But this approach leaves many teams feeling frustrated and overwhelmed by the amount of work they have to do. Instead of relying on volunteer time, take deliberate steps to improve your team’s effectiveness.
This guide is to help all product leaders – whether prodOps is a separate role or just another responsibility of product management leaders – figure out how to organize prodOps work in their company.
Before you can choose the right model for your organization, you need to understand two things:
- What the goals of your product operations function are.
- Who is doing the work today (there are assessments that can help with this)
Unless you have a dedicated prodOps function, the people doing this “glue” work are probably not being recognized for their efforts. Defining your product operations organizational team model helps structure their efforts and improve the quality of their outputs.
Choosing a Model
I like to think about your model as a “choose your own adventure” team structure. For every spectrum below you can pick either the extreme or the middle of the range. If you have a complex org structure, you may have some sub-groups on one side of the spectrum and some on the other.
The most important thing is to deliberately choose a model; don’t let the work continue to happen in the same haphazard way it has been. There is no wrong choice – depending on your team dynamics, strategy, and resources one direction might make more sense than another.
The first decision is whether prod ops is going to be a separate team or not. Many successful companies have never had a separate prod ops role. Many successful teams love having people dedicated to prod ops. Some choose a hybrid approach, where certain team members spend a percentage of their time on operations work.
Most independent prod ops teams still report through the CPO, though in some organizations they report to a general manager, CTO, COO, or program management.
|Unified with product management||Separate team|
– Turnaround situations where product leadership is trying to shift product culture
– When you want to make sure the people feeling the pain of weak operations are motivated to fix it
– Small teams that can’t afford a separate role
– Complex organizations where prod ops involves a lot of time interacting with other departments
– Where there’s a need for deep focus on prod ops challenges
– When you want to make the resource allocation to prod ops explicit
Prod ops work can take three different shapes in terms of operating principle:
- Enabling: Creating the infrastructure to help others do their jobs better
- Coaching: Teaching others the processes and procedures to do their work
- Execution: Doing the operational work for others to free up their time
I’ll admit that I personally lean towards enabling, but that doesn’t mean it’s the best choice for all teams. At some companies, it may be that certain people fill an enabling role, certain fill a coaching role, and yet others do execution work.
Enabling work focuses on reducing friction for product managers to work more effectively. By creating tools and processes, one can reduce the amount of effort a product manager needs to move development forward. This is the most common model of product operations.
Organizations that need more standardization lean towards the coaching model; Kroger, the large grocery chain in the US, has invested heavily in this direction.
If the product manager could really use a partner to get more done, the execution model might make the most sense. In these organizations there can be a risk that the line between prodOps and product management begins to blur, and a prod ops function might start to look more like a business analyst role. An example of this work might be prod ops synthesizing user research or writing the go-to-market documentation. This resembles what the prod ops team members at Uber do.
– Creating broad impact with fewer people
– Prioritizing process improvement
– Organizations that have hired more junior people
– Having the most reach per person
– Complex organizations with overworked teams
– Adding capacity to the team
As with many other roles within an organization, there’s the decision about whether to do a shared service or embedded function. As a shared service, the people responsible for product operations act as a pooled resource for the company. Embedded means that the individual is on the team for which they are doing the work.
This can be done in a hybrid fashion. At Doordash, the Director of Product is responsible for product operations in their area. They are, in effect, an embedded function for their department. When they need company-wide consistency, the directors team up to act as a shared service.
|Shared service||Embedded function|
– Organizations with more teams than fewer people responsible for prodOps
– Big system thinkers and wide-ranging ideas Quality output that’s consistent across teams
– Improving the collaboration across departments
– Tight alignment with the product manager or strategy
– Complex organizations with overworked teams
– Improving the collaboration of the product development team
Degree of focus
Do you expect prod ops to be focused on one or a few areas of prod ops, or to be able to jump around as needed? Think about designers – in some companies, user researchers, content writers, and UX designers are separate specialties. In others, they hire product designers and expect them to be able to do all the roles at least to some degree. This same dichotomy applies to prod ops.
Prod ops can specialize in a variety of different ways – either focusing on customer type, such as at Pendo, a product pillar, or a particular outcome that you’re targeting.
|Degree of focus|
– Larger teams to avoid duplicative work
– Organizations striving towards very specific goals
– Smaller teams where people need to swarm on problems
– Flexibility to chase after different problems as the landscape changes
Don’t Choose a Team Model alone
Figuring out the right model is challenging. As you work through structuring your team, remember the following:
First, don’t try to figure it out by yourself. Work with your partners across the company to decide on goals and evaluate options. If you need further help, call in an expert to provide an outside perspective. Run a workshop to figure out where you are today, where you want to be, and why.
Second, don’t expect your first model to be your final one. Organizations iterate and evolve over time, just like products. What works today will not work forever, and it’s important to be flexible.
While product operations as a separate role is a relatively new discipline, prod ops has existed since the birth of product management. The only thing that has changed is that we have started talking about it explicitly. As a product leader, recognize who is doing the work today and make sure you are thinking deliberately about how you want it to be done in the future. The teams that don’t spend time thinking about prod ops are also frequently the teams that struggle to ship quality products.