Categories
Uncategorized

PRODUCT OPERATIONS MODELS

Starting in October, 2021, Marty Cagan at the Silicon Valley Product Group began writing about Product Operations and how he sees it relative to product development. He must have received a lot of (perhaps) negative feedback on the article, and he wrote a second blog post in November. That too seemed to land with a bit of a thud, and thankfully so. Because in December Cagan, along with SVPG partner Chris Jones, took a third run at Product Ops, and I think did a great job articulating this relatively nascent (if in name only) competency.

Cagan is adamant there’s nothing new being done under the moniker of Product Operations, but for most people that’s either fine or a moot point: plumbing’s existed since the Roman age, but who cares until you need one? That said, I think Cagan and Jones have done a great job synthesizing the roles and responsibilities of Product Operations in different organizations, and I’d like to summarize them here. As always, your mileage may vary, but ideally, you’ll see your current Product Operations set-up as well as aspirational model within the below.

The Reincarnated PMO Model

Cagan describes this as the claw back of the Program Management Office with its command-and-control mindset. He’s most wary of this model as a Trojan horse, even if some of the planning activities, coordinating and tracking, and standard operating procedures and governance are important and necessary.

The Two-in-a-Box PM Model

Cagan feels he’s seen this model for decades where companies struggling with too much work to do split the role into two—a Product Manager who owns the development of the product and a Product Operations Manager who handles the day-to-day tasks involved with development. Oddly, he recognizes that some medium- to large-sized companies have enough staff to break the work of the product manager into more manageable (and I’d offer, specialized, roles) though I understand his point that these should be subordinate to and offering advise and assistance to the Product Manager.

The Delegated Product Leader Model

Cagan believes it’s the role of Managers of product managers to enable their product managers to do good work through coaching and developing product strategy, and that product ops should not. I agree. But if you’re asking Product Operations to support Product Managers it’s a gray line as to what conversation or tool does or doesn’t coach a PM or assist in developing, designing, or communicating strategy. We can all be leaders to some degree, but I agree that a Product Operator is not at their core the manager of the product managers.

Production Operations Rebranding Model

I’m glad Cagan hit on this one, and I appreciate his clarification of “product operations” and “production operations”. In my review, this model—”ensuring the product is running properly in production”—is one of the two most common. The role is important, but in my view it aligns with Operations and not Product.

The Product Marketing Manager Rebranding Model

A model I’ve only just seen start to appear in job descriptions and postings is rebranding the Product Marketing Manager. Cagan notes this role covers “launch activities, customer discovery programs, beta programs, sales, services and marketing training; continuous product go-to-market testing; and then the customer feedback needs to be aggregated and analyzed by the various sales channels.” And we think Product Managers have a lot do, and then question why some might delegate work to product operations!

That said, I think this model is the most worrisome. Marketing and Product Marketing have existed for quite a long time, and need to exist, be well-fed and cared for. Simply giving up on “marketing” and calling it operations does a disservice to this competency.

The Force Multiplier Model

Finally, here we see Cagan imagine his ideal state for Prod Ops, through his reading of Melissa Perri’s great book—Escaping the Build Trap. Her three pillars are:

  • Quantitative Insights – help product teams make data-informed decisions
  • Qualitative Insights – coaching and enabling the product teams to do good research and learn first-hand
  • Tools and Best Practices Evangelism – constantly working to raise the bar on the skill level of the organization

This last pillar seems to cause Cagan the most consternation, because in his experience he’s seen good companies take principal product managers and ask them to raise the skills of the company’s product managers. That’s all good and well if the principal is given space, time, and the tools to do this. But in my experience many CPOs and VPs of Product feel like this takes a star player off the field in the hope that yelling from the sidelines achieves the same goal.

However if the principal is given the space, why not call them Product Operators and make this explicit? Cagan does suggest this, as well as a few other specialized planners well-suited for this role and moniker. Among the latter I’ve seen in many organizations where ProdOps is home for exceptionally strong people who track and coordinate the quarterly planning process as well as help organize cross-team planning, particularly with those not familiar with Agile development or Product processes.

**

At the end of his article, Cagan again warns of letting the process become the thing, and I can’t agree more. Very few like process for process-sake, and the goal of any process is not simply to exist but to solve a problem some human being is having.

Overall, I’m heartened that Cagan and Jones (and Perri as Cagan acknowledges) are spending time talking about Product Operations and helping to define a more standard model for companies and potential product operators to rally around.

Categories
Uncategorized

PRODUCT OPERATIONS AS COACH

A useful framework for many businesses is “People, Process, and Technology”: a triad of primary, non-monetary resources companies can bring to bear on a problem. This article is how to change a common misconception about product operations to increase its value in your organization.

Of the triad, technology is often ascribed to the engineers and solutions teams hard at work converting your big goals into working software. The people element is often left to functional managers (or ‘people managers’) or to HR. We often think of performance reviews, improvement plans, and compensation when we think about people. And the last, process, is the one most often considered when people think about Product Operations: not only how do teams accomplish their work but also the associated policies and procedures supporting those efforts.

But product operations can have a much broader view—particularly in the ‘people’ space if you consider the purpose of Prod Ops to include coaching and not simply about codifying how product teams work. Companies who look to Product Operations as coaches to their product teams unlock value from both the coach and the coached in ways that can significantly improve a company’s bottom line. Here are 3 tips to being a better coach that will ultimately help you and your organization achieve their goals.

Rather than being the one with the answers, be the one with powerful questions

These questions are meant to spur deep thinking—to help you, as coach, get out of the circumstances and into the person themselves. Your questions should be direct, blunt, provocative, and edgy. This isn’t to say they are mean-spirited or intended to put you in a messiah-like light, but good coaches know how to trigger ‘below-the-neck’ reactions in those being coached.

Coaching is not therapy

Being a good coach is not the same as therapist. People often seek therapy when they feel not-whole, but a coach assumes the coached person is whole and looking to excel from today in a forward-looking partnership. As a coach you are working to close the gap between where someone is and where they want to be. If you want to be a good coach, knowing these boundaries will help.

Practice empathy and being empathetic

While you may not agree with the person being coached, it’s still important to listen and respond with empathy. Letting someone know you understand what they are going through can be supportive as well as build trust with the person which may pay further dividends in the future. Many of the issues and roadblock teams face are not technical. They can be procedural, cultural, or personal, but these are all issues that can elicit emotional responses. An empathetic coach will be prepared for that.

In organizations where the product operations team is seen as a coach, their first responsibility is to the product team members themselves. By asking powerful questions, helping people excel, and practicing empathy, product operators can motivate the team to seek out problems and to help them solve them. In this way the product operations team becomes directly tied to the product the teams create, the speed at which they can release, and ultimately to the value those efforts bring to users and customers.