A field-guide taxonomy (Marcus Castenfors, SVPG) of ten predictable, repeatable traps that sink Product Model (vs. Roadmap Model) transformations — the claim being that the model itself rarely fails; organizations fall into the same handful of pits instead. Anti-patterns identified so far:
Every stakeholder audience in a transformation splits into Believers vs. Doubters (Transformation Stakeholder Split); the anti-patterns above are, in effect, the ways an organization fails to convert doubters into believers. Sourced from "10 anti-patterns when moving to the product model."
Cataloged in Marcus Castenfors' field guide "10 Anti-Patterns," which structures the ten recurring anti-patterns organizations hit when moving to the product operating model. His framing for why they happen: unsuccessful transformations are ones that treated the shift as an easy path, rather than taking it seriously as the hard organizational change it is.
Cagan names this the single biggest reason transformations fail: companies believe they already employ real product managers and product designers when, by the standards of the Product Model (vs. Roadmap Model), they typically don't — so the transformation stalls on missing competency rather than on process.
A common anti-pattern that persists even under an "agile" label: the PM writes a PRD, throws it to a designer, the designer produces comps, and those comps are dumped on engineers at Sprint planning. Cagan calls this, in his words, "literally waterfall" — relabeling the same handoff sequence with agile ceremonies doesn't change its structure. See Product Trio for why engineers need to be present during discovery instead.
A specific anti-pattern Cagan calls out by name: a PM writes a PRD, hands it to a designer who produces workflows and comps, and then both hand finished documentation to engineers at Sprint planning with an instruction to "build this." Cagan: "That is literally waterfall — that is literally what made waterfall bad." The tell is sequencing, not tooling or ceremony — a team can run Scrum ceremonies and still be doing this if engineers and designers are only ever consulted after the problem is already framed and the solution already chosen. See Cosplaying the Product Model for the broader phenomenon this instance belongs to, and Product Trio for the structure that's supposed to prevent it.
Julia Barham traces many team-scaling failures to a leadership gap rather than a team problem: leaders under-coach and under-invest in developing PMs. She attributes part of this to "half-baked" product-org transformations that inflated PM titles and scope without giving people genuine end-to-end exposure to the work those titles imply — leaving them under-equipped once they're expected to operate at the new level. See "Don't Scale Chaos" (Leader-as-Bottleneck Mistake).
Из тем: Transformation in Practice