The Product Model in Traditional IT

Marty Cagan and Chris Jones examine whether the product operating model, originally designed for product organizations building technology products, applies to traditional IT departments. They argue it can help when IT is building its own solutions and has real levers to influence outcomes, but is less suited when IT primarily buys third-party tools. They highlight structural obstacles in traditional IT, including project-based funding, staffing, and governance models built for predictability and a cost-center mindset. They also clarify nomenclature confusions such as innovation versus predictability, features/projects/initiatives versus products, and the role of project managers. The core test is whether a team truly has the levers to impact outcomes; if not, the product model is unlikely to fit.

01Key takeaways

• Apply the product model only where your organization actually builds solutions and can influence the outcomes it targets.
• Recognize that project-based funding and staffing structures tend to undermine outcome delivery even when they provide predictability.
• Clarify terminology across teams, since 'project' in IT often means what 'initiative' means in product organizations.
• Keep project management separate from product management so product managers can spend their time on discovery.
• Evaluate whether a team has the levers to impact value; if it lacks them, don't expect the product model to work.

02Key sections

Beyond Product Organizations

The authors clarify the product model was built for companies building technology products, and they are now fielding questions about applying it to other organization types, including traditional IT.

Build vs Buy

The product model fits best when an organization builds its own solutions; when it primarily buys third-party tools, its ability to influence outcomes is far more limited.

Outcomes vs Output

Traditional IT often operates as a cost center with project funding, project staffing, and predictability-focused governance, which undermine the outcome orientation the product model requires.

Common Confusions

Terms like innovation versus predictability, features/projects/initiatives, and project managers mean different things in IT than in product organizations, and misunderstanding them causes friction.

Is The Product Model Right For You?

Teams need real levers over value, such as ongoing engineering access and freedom from output or date mandates, before the product model can succeed; otherwise it is likely a poor fit.

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.