Stakeholders and the Product Model

Cagan and Jones argue that moving to a product operating model changes not just product teams but the business stakeholders who rely on them. The shift is from shipping feature roadmaps (output) to solving customer and business problems measured by results (outcomes). The piece offers practical guidance for stakeholders: share business context and constraints, frame requests as problems with success measures rather than prescribed features, and give product teams direct access to customers and data. It also describes how discovery (rapid prototyping and testing) and delivery run in parallel, and how to handle keep-the-lights-on work and high-integrity commitments. This matters because stakeholder behavior often determines whether product teams can actually deliver business results.

01Key takeaways

• Share the business constraints, from regulation to financials to partnerships, so product teams can find solutions that work for the whole business.
• Describe the problem, the people it affects, and how success will be measured, rather than prescribing a specific feature.
• Give product teams direct, governed access to customers and product data, since discovery depends on it.
• Expect to review clickable prototypes before anything is built, so feedback is cheap and early.
• Reserve high-integrity commitments for the few capabilities that truly need a trusted date, since they cost discovery effort.
• Route requests through product leaders, who juggle multiple stakeholders and can point you to the right product manager.

02Key sections

Why stakeholders are part of the product model

Anyone responsible for a key business aspect, or who depends on product teams for technology, is a stakeholder whose engagement shapes outcomes. The shift affects them as much as the product organization.

Foundation for effective collaboration

Three pillars are named: sharing business context, framing work as problems with success criteria, and granting unencumbered access to customers, users, and data.

Discovery and delivery in parallel

Instead of documents, teams rapidly build prototypes tested with customers, engineers, and the business before building production software, with instrumentation to measure outcomes once delivered.

Applying the model in practice

Routine maintenance work continues alongside larger problems, high-integrity commitments are used sparingly for dates that must be trusted, and stakeholders typically engage through product leaders.

03From the post

“By Chris Jones and Marty Cagan Moving to the product operating model is about moving from shipping roadmaps of features (output), to solving problems for your customers and your business, as measured by achieving business results (outcomes). But the changes required to do this reach beyond the product organization (the product teams and the product... The post Stakeholders and the…”

04Frameworks mentioned

Summary and takeaways written by PM Atlas; quotes are short excerpts. © the original author.