The Four-Pillar Product Operating Model

Core principles

• 01A development methodology is one piece of the puzzle, not the whole operating model.
• 02Process is not the enemy — a 4,000-team org genuinely needs roadmap tooling and transparency to see what it is building.
• 03Value connection is the missing link: every team's work should trace back to a company goal.
• 04If your incentive is shipping volume, you will get shipping volume, not outcomes.
• 05Leaders cannot outsource their own job to a framework map.

How to run it

1. 1

   Name what your current framework actually covers

   Audit whatever you have adopted (Scrum, SAFe, LeSS, Scrum@Scale) and classify it honestly as a development operating model. Ask what it does NOT tell you: how you pick what to build, how you do discovery, how you go to market, how leaders above the team do their job.

   Pro tip Perri's litmus: SAFe is great at release trains and big-room planning, and silent on discovery, go-to-market and the VP/director role.

   Watch out Executives buy SAFe precisely because it is the only vendor that draws a full map — the map's completeness is a marketing artifact, not evidence of coverage.

2. 2

   Pillar 1 — Product strategy

   Establish whether you have a real product strategy: what the company goal is (e.g. geographic expansion), and what products in the portfolio actually deliver it. Most large organizations have no strategy that a team can trace its work back to.

   Pro tip Test it by asking a random team what company goal their current sprint advances. If nobody can answer, the strategy does not exist operationally.

3. 3

   Pillar 2 — Organizational design

   Look at how you are organized around products, not components. Check coverage (is there a skilled product person per product line?) and skill (are they actually able to do discovery?), up and down the org, including director/VP/CPO levels.

   Pro tip Component-based agile teams are the classic failure mode — people invent work for their component so nobody gets fired.

   Watch out Reorganizing by component rather than product guarantees make-work backlogs.

4. 4

   Pillar 3 — Product operations

   Build the infrastructure that makes good product work physically possible: access to data for decisions, a sanctioned path to talk to customers, user research, feedback mechanisms, roadmap transparency across teams.

   Pro tip When PMs say 'I don't have time to talk to customers', the real cause is usually that no mechanism exists for them to do it. Fix the mechanism before blaming the person.

5. 5

   Pillar 4 — Culture and incentives

   Inspect what you reward. If success is measured as volume shipped into the release train, teams optimize for stuffing backlogs. Re-point incentives at 'is this valuable, and does it move a business goal?'

   Watch out This is the pillar leaders skip, because it implicates them rather than the teams.

6. 6

   Only now choose (or keep) a delivery process

   With the four pillars designed, pick the lightest way of working that gets things to customers and lets you inspect and adapt. Keep the parts of any framework that serve you; delete the rest without guilt.

   Pro tip Every person Perri knows who found success with SAFe ended up ripping it up and turning it into something else — so plan to modify from day one.

   Watch out Taking a rigid process too far actively destroys value: a Dutch water utility that adopted SAFe got so consumed by process that it couldn't ship invoicing and payment collection, and went bankrupt.

In the wild

Common mistakes

Is it for you?

From the transcript