Product Operating Model Marty Cagan

The Product Model and Org Design

When a company is transforming to the product model, one very common question we often get is whether they will need to reorganize as part of that transformation?  TL;DR: in most cases, a reorg is not necessary.

That said, the question itself often highlights underlying confusions about the purpose of organizational design, and the implications of the product model in general, and on how product teams are able to work in particular.

Just recently an excellent summary article was published highlighting the two major organizational design models, along with a very common hybrid model, and the pros and cons of each.  Most people will immediately recognize the two main models, referred to as the GM (general manager) Model, and the Functional Model.1

Note that in some companies the GM Model is referred to as the “BU” (business unit) model, or the “STL” (single threaded leader) model.

To be very clear, with the right people, skills and culture, you can create absolutely amazing products and services with either model:

Amazon leverages single threaded leaders in the GM model to optimize for spinning up a relatively large number of new products and new lines of business, where speed and true agility are critical.

Apple leverages the functional model to optimize for the holistic user experience across a relatively small number of very complex, deeply integrated, ecosystem products.  

Both are exceptionally successful businesses, but each has very different business strategies, product visions and product strategies, which is why they have different org designs.  Yet both use the principles of the product model to deliver world-class products and services to their customers.

It’s important to realize that every org design makes some things easier and some harder.  Experienced product leaders know the same is true for the team topology. 2 Every topology makes some things easier, and some things harder.  

For example, the functional org model is a very natural fit for the manager as coach.  In the GM model, sometimes, if they don’t have functional managers under the GM, the general manager is not able to provide the necessary coaching (because they have a different expertise), so in this case you would need to have someone that’s not the direct manager provide the critical coaching.

So back to the original question: does a transformation to the product model necessitate a reorg? 

The main drivers of the most appropriate org design are your business strategy, and the associated product vision and product strategy.

For example, if your business calls for a portfolio of loosely related products, each pursuing their own product vision and strategy, then it’s likely that the GM model will be the natural fit.  But if the business depends on a tightly integrated, holistic product experience, then the functional model is likely best suited.

The main reason the hybrid model is so popular is that many companies do have a portfolio of loosely related products, yet they need the leverage and efficiencies provided by a common platform.

Beyond these fairly straightforward heuristics, I often explain to company leaders that it’s tempting to think that a reorganization will fix their company’s issues, but in most cases, it’s simply rearranging the deck chairs on the Titanic.

The larger issue impacting the company’s ability to deliver the products and services they need is the quality of their product leaders, the skills of their product teams, and the product culture in the company.

This is not to say that we don’t have strong opinions on the best org model, but those opinions are not driven by the move to the product model; they are driven by the desire to best fit the company’s particular business strategy and product vision.

To be clear, everything described above could apply to either feature teams building projects and features (outputs), or empowered product teams solving problems (outcomes).  So whether or not the company embraces the product model is orthogonal to the org design they choose.

If that seems counter-intuitive to you, just review each of the three product model dimensions, the four product model competencies, the five product model concepts, and the twenty product model first principles.  When you consider each element of the product model, you can see how the org design might indirectly make some things a bit easier or harder, but certainly neither org design will prevent nor guarantee success with the product model.

To drive this point home, I believe strongly that with the right people with the right skills, a strong product team can succeed no matter the org design.  I’ve seen enough skunkworks teams over the years achieve the impossible, even in the most bureaucratic of organizations, that I will never again doubt what a motivated group of empowered and skilled cross-functional professionals can accomplish.  Strong product teams are all about overcoming obstacles, and it’s inevitable that the organizational design, whatever it is, will at some point be one of those obstacles.

  1.   This is purely anecdotal, but I’ve probably seen as many product organizations as anyone, and in my experience, these two major models plus the hybrid represent at least 95% of what’s out there.  Small companies skew heavily towards the functional model, and large ones, often the result of acquisitions, skew towards the GM model, or increasingly the hybrid model.
    ↩︎
  2.  Note that team topology is not an org structure.  The org structure shows where the individuals on the product teams report up into.  The team topology shows what each product team is responsible for, and how the individuals collaborate on cross-functional product teams to solve problems.  Reporting relationships can change without impacting the team topology, and vice-versa.
    ↩︎