A diagnostic framework (attributed to coach "Gabby" in the Palace Hotels case) for assessing a technology function before deciding where to intervene in a transformation. It separates the assessment into three independent axes rather than treating "the org is broken" as one problem:
The axes are graded separately because a function can be strong on one and weak on another — e.g., disciplined engineering delivering the wrong things, or good problem selection undermined by weak Discovery (Product Discovery Process). The practical use is sequencing: start the transformation on whichever axis you already have organizational credibility to change, rather than trying to fix all three at once. Related to Single Pilot Team as Transformation Proof of Concept as one tactic for building credibility on the axis chosen first.
Leah Hitman frames the Product Operating Model as resting on three dimensions: how you build software, how you discover the right solution, and choosing the right problem to solve. Of the three, choosing the problem is usually the biggest unlock for leaders — most organizations have already invested in delivery mechanics and, to a lesser extent, discovery process, but skip the harder strategic work of deciding which problem is worth solving in the first place. See Product Strategy and Placing Bets (Strategy-as-Bets Framing).
SVPG (via Leah Hitman) names this same three-dimension framework the Product Operating Model: how you build software (small, frequent releases), how you discover the right solution (experimentation against Valuable / Usable / Feasible / Viable), and how you choose the right problem to solve (strategic prioritization, see Strategy Jump Starts). When a leader asks what they're transforming to, lead with the third dimension — strategy and insight work is usually the biggest gap, not delivery cadence.
"If you only have time to build, you will never compete."
Cagan states the three dimensions directly as: (1) how you build/test/deploy, (2) how you solve problems, (3) how you decide which problems to solve. His point in naming them explicitly: genuine Product Model (vs. Roadmap Model) transformation requires change across all three — an agile rollout only touches dimension 1, so it doesn't count as full transformation on its own.
Cagan states the three-axis claim directly and rejects partial adoption: "It means all three of those things: changing how you build, changing how you solve problems, and changing how you decide which problems to solve." Adopting agile ceremonies (how you build) without also changing how problems get solved (discovery) and which problems get chosen (strategy) is, in his framing, not a transformation — see Transformation Theater and Cosplaying the Product Model for what that partial adoption looks like in practice.
Из тем: Transformation in Practice