Who Should Rule the Product?

Recently the product sphere had boiled-over over Airbnb removing product managers from product teams and converting them into product marketing managers. The Airbnb transformation may be a one-of (essentially an attempt to adopt the centralist Steve Jobs / Apple model), but the story and the discussion that followed surfaced an age-old debate: who should rule the product? 

In a classic case of Miles’ law, where you stand depends on where you sit:  

  • Many managers simply assume it’s their job to decide what to build and when, partly because that’s how things were done in the past, and partly because they don’t trust reports to make good business/product decisions (ego may be a third option). 
  • Some business stakeholders feel that they are the voice of the market, hence they should decide which products and features to build. 
  • Some designers believe that product development is all about “solving user problems” hence Design should drive the decisions. 

What’s common to these divergent worldviews is that they overlook key realities of modern product development: 

  • Developing products is not a zero-sum game. In fact, if there’s one thing we learned it’s that successful products reflect the strategic and the tactical, the business and the technical. Handing over control to one discipline or one group (including product managers) invariably creates an unhealthy bias. 
  • In modern product development we face a lot of uncertainty and complexity. Therefore we have to guide our decisions by evidence rather than by the opinions of any one person or group. Evidence cuts through disciplinary debates and HiPPO control and allows us to decide in a transparent and objective way (this is the key theme of my book: Evidence-Guided)

Still, if the deciders are neither managers, business stakeholders, designers, nor PMs (alone), what’s the alternative? Democracy? Chaos?

There’s no one right answer to this question, but we do have a few tried-and-tested models. 

The Trio model 

When I worked at Google, every product team was led by a Triad, now more commonly known as a Trio (kudos to Teresa Torres for popularizing the name and the model) — a team of three leads: PM + Dev lead + UX designer. Each member of the trio has his/her area of responsibility, but decisions that affect the team, for example quarterly goals, or which ideas to test first, are made by the trio in consensus. 

While each team member has a disciplinary direct manager — engineering, PM, UX — the product team as a whole “reports” to a trio of director-level managers, who in turn reports to a VP-level trio that runs the product org. 

The trio leadership model helps include all points of view in decisions. The development lead brings in the technical perspective, the designer reflects on user experience, and the product manager brings market and business knowledge. Trios at all levels keep close connections with peers in other parts of the org: Marketing, Sales, Customer Support, PR, as well as with other product teams/groups/orgs. The trios conduct outside research and are the experts in their area of responsibility — product, users, market, technology. This empowers the trio to make product decisions (with overview from managers and input from stakeholders). 

I would love to tell you that this approach solves all disciplinary conflicts, but in reality success heavily depends on the attitude of managers. In good cases leaders’ actions exemplify the cross-disciplinary spirit. They defer to each other’s expertise, are willing to compromise for the greater good, and are working to remove barriers between the disciplines. In bad cases the managers push for a disciplinary agenda that pulls the trios apart. I’ve seen heads of design removing designers from product teams in order to institute a central  “design agency”, because that’s how they like to work. Similarly it’s not uncommon to see engineering managers pushing for multi-year replatforming or quality initiatives irrespective of business impact, while heads of product strive to launch more and more features with little regard for code health. These behaviors greatly reduce the effectiveness of the trio model. 

Join my newsletter to get articles like this 
plus exclusive eBooks and templates

Leading with Context

The bigger power struggle is typically between managers and reports. The tendency is to create feature factories that deliver on the ideas of managers or committees. The teams are left (at best) with control over implementation details. While this may work in early-stage startups or some other isolated cases, it’s generally a very unreliable way to create high-impact tech products, not to mention that smart people tire of always pursuing someone else’s ideas.  

Companies like Netflix take a different approach. They teach their managers to lead with context. Context is the information people and teams need to do their jobs properly and to make good decisions. At Netflix when an individual or a team makes a bad decision, the manager may ask herself “what context were they missing?”  

Company or business unit leaders should define and communicate down strategic context, which includes the vision, mission, top metrics, and strategy (which isn’t a plan of action) of the company. They should then translate those into clear and concise yearly company goals, for example in the form of OKRs (much like army generals translate the strategy into missions). Strategic context and goals help align and focus the organization on the most important things, and makes it possible for teams to make good tradeoffs without having to go and check with managers. 

Product teams communicate up tactical context, which includes the situation on the ground in their area of responsibility — state of the product, what was learned in the market, new technologies, challenges, and opportunities. This keeps mid-level and top-level managers informed, and helps them build an up-to-date picture of the world (much like army intelligence reports do for army commanders and generals). 

The teams should also communicate concrete work progress. I suggest structuring reports around the GIST model (Goals, Ideas, Steps, Tasks — covered in my book) :

  • Team-level goals + progress — the goals are  typically set quarterly (approved by managers) and progress is measured fortnightly
  • Ideas being evaluated against the goals
  • Evidence gained while testing the most promising ideas
  • Decisions made based on the evidence

Communicating this status up and across regularly and transparently helps build trust, a crucial ingredient for breaking the feature factory / delivery team model. 

How To Transition

The nice thing about both the Trio Model and Leading with Context, is that they can be implemented in the product organization first, without necessarily forcing the entire company to transform. The leaders of the product org — CPO, CTO, and Head of Product — should take an active role here. 

Here are some concrete steps that can help:

  • Merge separate Eng/PM/UX silos into one cohesive trio-space (as shown above). Individuals should still keep reporting to their disciplinary managers, but the teams should be dotted-lined to trios of managers. 
  • Abolish separate Eng, UX, and PM OKRs (if exist). Instead leadership trios should create combined OKRs, which may very well include quality, design, infrastructure as well as user/business goals. 
  • Define clear company-level vision, mission, and strategy. This requires the cooperation of the entire executive team, but often the product trio is in a good position to move things in the right direction, creating a useful and concrete version of these.  
  • Establish product teams with clear missions and areas of responsibility, and ensure they are led by capable, well-informed trios. 
  • Establish a cadence of context sharing up, down, and across, through reviews, email snapshots, all-hands, and other forms of comms.  

Trios and Leading with Context are not the only forms of cross-functional, cross-rank product management, but they are common and successful enough to warrant consideration. Reverting to a centrist mode of management may work for Airbnb, but for most companies will be a step in the wrong direction. The goal should be to decentralize decision-making, while allowing managers to steer the ship. Empowering product teams should not be disempowering for managers, and adopting the trio model should not weaken any of the disciplines. On the contrary it should make everyone much more powerful, and yet working with far less friction.  


In my courses we practice implementing evidence-guided development and empowered teams hands-on.

Secure your ticket for the next public workshop or contact me to organize an in-house workshop for your team. 


Share with a friend or colleague