The product model is an organizational approach in which product teams are handed hard problems to solve — outcomes customers love that also work for the business — rather than a pre-specified list of features to build and ship.
This is the alternative to the Roadmap (Feature/Project List) / project model, where teams execute a features-and-projects list handed down from above. Under the product model, a Product Strategy assigns problems, not solutions, and teams are trusted to discover the right one.
Apply: Hand a team a problem and an outcome to own, not a spec to build.
Palace Hotels (18 properties, ~15,000 employees, Mexico) ran a roughly two-year shift from a software factory delivery org to empowered, outcome-driven product teams, led by CPTO Anoir with coaching from Marty Cagan's SVPG and coach Gabby. The transformation is credited with raising booking-engine conversion from under 1% to over 5% over about 1.5 years of focused work on the guest booking experience — achieved not by building more (see the Discovery (Product Discovery Process) case study), but by teams owning problems/outcomes instead of feature lists. Notably, the business was already performing well (record post-COVID years) when the shift began — the motivation wasn't business failure but the recognition that technology work wasn't delivering value for the effort spent (see Transformation Theater).
Palace Hotels (18 properties, ~15,000 employees) is cited as a concrete before/after of adopting the product model over a roughly two-year transformation: the booking engine's conversion rate rose from below 1% to above 5%. The transformation replaced a waterfall Software Factory Delivery Model that had adopted agile ceremonies and titles without changing how "done" was defined — see Transformation Theater. Notably, the transformation ran without an army of outside consultants or a leader who was "born into" product management.
Under the Product Model (vs. Roadmap Model), the core trust conversation between leaders and teams changes: from 'did you hit the date' (project model) to 'how are you validating this' (product/discovery model). That's a different question to be held accountable to, and it's what actually has to change for a transformation to be real, not just installed (see Installation vs. Adoption).
On applicability: the model is claimed to work in big companies, regulated industries, and both B2B and B2C contexts — but only if leadership actually invests in developing product leaders and providing strategic context, not just relabeling roles.
Cagan used to describe the "product model" simply as "the difference between the best and the rest" — the term is a recent label for a distinction he'd tracked for decades, not a rebrand of something new. SVPG Service Model was founded specifically to teach the practices of "the best" product companies once the size of that gap became apparent.
He deliberately avoided naming it "product led company" or "product driven company" — both wrongly imply product management has taken over the company. "Product operating model" was picked up from a company that already used the phrase internally, then shortened by common usage to "product model"; Cagan prefers it because it signals a conceptual model rather than a mandated process (see Installation vs. Adoption).
Stripping away company-specific jargon — Spotify's tribes and squads (see Spotify Squad Model), Amazon's, Apple's, Netflix's own internal vocabularies — reveals the same underlying set of principles across the companies actually practicing it.
Cagan frames the product model as three nested layers of structure, not a single technique:
Three dimensions (see Three-Axis Transformation Diagnostic (Build / Solve / Decide)): how you build, how you solve problems, how you decide which problems to solve. Genuine transformation requires change across all three — implementing (real) agile alone only fixes the easiest dimension, how you build. Companies can still improve meaningfully doing only two of the three, but competing against companies like Amazon or Stripe requires excelling at all three.
Four competencies: product management (see Cagan's Definition of a Product Manager), product design (see Product Design: Whole-Experience Ownership), engineering (see Misconception: PM Owns the 'What', Engineering Just Executes the 'How'), and product leadership (see Context / Culture / Coaching Framework).
Five concepts: Product Strategy, Product Team (Five-Trait Definition), Discovery (Product Discovery Process), delivery (see Continuous Deployment Cadence), and Product Culture: Tolerance for Failure.
Cagan and partners spent roughly a year distilling decades of observation of "the best" vs. "the rest" into a formal structure: 3 dimensions (how you build/test/deploy, how you solve problems, how you decide which problems to solve — see Three-Axis Transformation Diagnostic (Build / Solve / Decide)), 4 competencies (product management, product design, engineering, product leadership), 5 concepts (strategy, team, discovery, delivery, culture — see Product Strategy, Product Team (Five-Trait Definition), Discovery (Product Discovery Process), Product Culture: Tolerance for Failure), and 20 product principles. Use this decomposition as a diagnostic checklist for whether an org's practices match the pattern across build process, problem-solving approach, and prioritization — not just its job titles.
In Transformed (2024), Cagan restates the model as not a process — "It is not a process." — but a consistent set of principles that different companies implement differently. He structures it as:
Transformed was written to answer the #1 objection to Inspired — "it's not possible to work this way at my company" — using case studies deliberately drawn from outside Silicon Valley: Saudi Arabia, CarMax, Trainline, The Guardian, Datasite, and Kaiser. See Operating Model as Starting Point, Not Rigid Blueprint, Output-to-Outcomes Shift Triad.
Cagan's own naming for the two poles of the model: feature teams (also called order takers) are staffed to build whatever stakeholders hand them, on a schedule; empowered product teams (problem solvers) are given a problem or outcome to own and choose the solution themselves, informed by Discovery (Product Discovery Process). The labels double as diagnostic language — describe a team as an "order taker" or a "problem solver" to name its current state without needing to explain the whole product-model framework.
Из тем: The Product Operating Model