Transformation as a Project

Marty Cagan argues that many companies undertaking a transformation to the product model make the ironic mistake of managing that transformation as a conventional big project, with program managers, Gantt-style plans, RACI charts, and success defined as completing the plan. This anti-pattern contradicts the product model itself, which emphasizes learning, outcomes, and admitting what you don't yet know. He recommends treating the transformation like a product: identify the biggest risks, build small, cheap pilot teams to test them, and scale only what proves to work. The approach surfaces real implications early, and he contends it is usually faster to reach the desired outcome than a large up-front rollout.

01Key takeaways

• Treat a transformation to the product model as a learning problem, not a delivery project with a fixed plan.
• Define success by achieved outcomes and new capabilities, not by completing a set of transformation tasks.
• Identify the biggest risks early and test them with small pilot teams before scaling.
• Pilot teams expose the real organizational implications of role changes that look simple on paper.
• Use pilots to find which leaders can succeed in new responsibilities and where capability gaps lie.
• Scale progressively, using what pilots taught you, which is usually faster to a working outcome than a big-bang rollout.

02Key sections

The project trap

Organizations often apply their familiar big-project playbook to the transformation itself, complete with sponsors, plans, and status reporting. Success gets measured by finishing the project rather than by changed results.

Transformation should behave like a product

Because the organization doesn't yet know how to make the change, the work is really a learning problem. Risks should be identified and tackled through small experiments rather than detailed up-front planning.

Pilot teams as low-cost prototypes

Pilot teams are fast, inexpensive, and safe ways to learn the product model and reveal its organizational implications. They also let the rest of the company observe the effects on their own areas.

Concrete changes reveal deep implications

Retitling product owners as product managers, or making engineers first-class team members, sounds simple but reshapes roles, idea sources, and leadership expectations. Only real practice shows which changes matter and who can succeed in new roles.

Speed comes from learning, not planning

Pilots reveal needed capability building, strategy and collaboration effects, and discovery or delivery techniques suited to the company's products. Though it may feel slower, this approach typically reaches a successful outcome faster.

03From the post

“A partnership dedicated to teaching best practices to product teams and product leaders”

04Frameworks mentioned

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