The IT Operating Model Revolution: From Projects to Products (30% Faster Delivery)

Your IT organization just completed a €1.2M "Customer Portal Redesign" project after 14 months. The project was declared "successful"—delivered on time (after 3 timeline extensions), on budget (after 2 budget increases), and met all requirements (from 18 months ago). The project team disbanded the day after launch.

Two weeks later, customers are complaining about missing features. The business wants urgent enhancements. But there's no team—they've moved to other projects. The project manager who knew everything is now working on an ERP upgrade. Knowledge is scattered. The business is told "submit an enhancement request, we'll prioritize it in Q3."

Meanwhile, your startup competitors ship new features weekly without "projects." They organize around products with persistent teams that continuously improve and evolve their software. They're faster, more responsive, and customers love their rapid innovation.

According to Gartner research, 64% of organizations report their project-centric IT operating model slows business agility. The median time from idea to production in project-based IT: 9-12 months. In product-based IT: 2-4 months. That's 3-4x faster delivery with the same resources.

I've led transformations in previous roles where we shifted from project-centric to product-centric IT. Delivery speed increased 30-40%, business satisfaction improved 45%, and employee engagement rose 35%. The shift wasn't about working harder—it was about organizing around outcomes, not outputs.

Traditional IT operating models organize around projects, creating waste and slowing delivery:

The Project-Centric IT Operating Model

How It Works:

Business Request → Project Approval → Project Team → Project Execution → Project Closure → Team Disbands

Example: "Mobile App Enhancement" Project

Month 1-2: Project Initiation

• Business submits enhancement request (3 new features)
• Business case created (projected value: €400K annual)
• Budget approval process (3 committee meetings)
• Project charter created
• Project manager assigned

Month 3: Team Assembly

• Resource requests to functional managers
• Negotiate for available developers (2-3 weeks)
• Assemble team: 1 PM, 2 developers, 1 designer, 1 QA
• Team members split: 50-70% allocated (working on multiple projects)

Month 4-8: Project Execution

• Requirements gathering and documentation
• Design and development
• Testing and bug fixes
• User acceptance testing
• Deployment preparation

Month 9: Deployment

• Deploy to production
• Project closeout documentation
• Team performance reviews
• Team disbanded and reallocated

Month 10+: The Problems Begin

• Users discover bugs or missing edge cases
• Business wants enhancements based on usage
• No team available—they're on other projects
• New requests queue up for "next project"
• Knowledge lost (team scattered across organization)

Timeline: 9 months from request to delivery

The Costs of Project-Centric IT:

1. Slow Delivery (3-4x slower)

• Project overhead: 20-30% of time spent on project management, not building
• Team formation: 2-4 weeks to assemble team
• Context switching: Teams work on 2-3 projects simultaneously (40% productivity loss)
• Knowledge ramp-up: New teams spend 2-3 weeks learning codebase

2. Misalignment with Business (Requirements 9-12 months old)

• Business needs change during project
• Built to original requirements (now outdated)
• No learning loop during development
• Launch disappoints because market moved

3. Wasted Work (15-25% of project work never used)

• Features built to specifications, not actual needs
• Edge cases not discovered until after launch
• No incremental validation with users
• "We built what you asked for" (not what you needed)

4. Knowledge Loss (Costs 10-15% productivity)

• Team disbanded after project
• Documentation incomplete or outdated
• Next enhancement team starts from scratch
• Bugs take longer to fix (nobody knows the code)

5. Poor Quality (Technical debt compounds)

• Pressure to "finish project" creates shortcuts
• No time to refactor (project is "done")
• Technical debt accumulates across projects
• System becomes unmaintainable

6. Employee Frustration (45% dissatisfaction)

• Constant context switching between projects
• Never see outcome of work (moved to next project)
• Lack of ownership (temporary assignment)
• Bureaucracy and overhead frustrating

I worked with a financial services company where IT operated on 100% project model:

• 87 active projects across 250-person IT organization
• Average project duration: 11 months
• Average time-to-production: 13 months (including queue time)
• Employee satisfaction: 5.2/10
• Business satisfaction with IT: 4.8/10
• Percentage of delivered features actually used: 62% (38% waste)

The Financial Impact:

• €12M annual IT budget
• €4.5M wasted on unused features, rework, and overhead
• €8M in opportunity cost from slow delivery (features late to market)
• Total impact: €12.5M in waste + opportunity cost = 104% of IT budget

The problem wasn't the people—it was the operating model.

Why Project-Centric IT Made Sense (20 Years Ago)

Historical Context:

1990s-2000s IT:

• Software deployed once per year or quarter
• Changes were risky and expensive (manual deployment)
• Business requirements stable (market changed slowly)
• IT primarily built new systems (not evolving existing ones)
• Projects had clear start and end (ERP implementation, data center migration)

In that world, project model worked:

• Assemble team for big initiative
• Execute defined scope
• Deploy once
• Disband team
• Maintain in steady-state (separate team)

2025 IT Reality:

• Software deployed multiple times per day (continuous delivery)
• Changes are low-risk (automated CI/CD, feature flags)
• Business requirements evolve constantly (market changes weekly)
• IT primarily evolves existing products (not building new from scratch)
• Work is continuous improvement (no clear end)

In today's world, project model fails because digital products are never "done"—they continuously evolve.

The Product Operating Model

Product-centric IT organizes around persistent teams owning outcomes:

The Core Principle

Shift from temporary project teams → persistent product teams

Project Team:

• Temporary assignment (duration of project)
• Owns project deliverables (features)
• Success = deliver on time, budget, scope
• Disbanded when project "done"

Product Team:

• Permanent assignment (owns product long-term)
• Owns business outcomes (metrics)
• Success = achieve business results
• Continuous improvement (never "done")

The Product Operating Model Structure

Product = A solution that delivers ongoing business value

Examples:

• Customer Portal (not "Portal Redesign Project")
• Mobile Banking App (not "Mobile App Enhancement Project")
• Order Management System (not "OMS Upgrade Project")
• Data Analytics Platform (not "BI Dashboard Project")

Each Product Has:

• Dedicated Team: 5-9 people permanently assigned
• Product Manager: Owns business outcomes, prioritizes work
• Tech Lead: Owns technical quality, architecture
• Engineers: Build and maintain the product
• Designer: (Shared across 2-3 products if needed)
• QA: (Embedded or shared)

Product Team Responsibilities:

• Build new features (what used to be "projects")
• Fix bugs and technical debt
• Monitor and improve performance
• Respond to user feedback
• Continuously improve business metrics

Product Portfolio Structure

How to Organize IT Around Products:

Level 1: Product Portfolio (Executive View)

Example: E-Commerce Company

Product Portfolio (20 products, 15 product teams)
├─ Customer-Facing Products (8 teams)
│  ├─ E-commerce Website (1 team)
│  ├─ Mobile App (1 team)
│  ├─ Customer Service Portal (1 team)
│  └─ ...
├─ Internal Operations Products (5 teams)
│  ├─ Order Management System (1 team)
│  ├─ Warehouse Management System (1 team)
│  └─ ...
└─ Platform & Infrastructure (2 teams)
   ├─ Data Platform (1 team)
   ├─ Core Services Platform (APIs, Auth) (1 team)
   └─ ...

Level 2: Product Team Structure

Product: E-commerce Website

• Product Manager (1 person): Owns conversion rate, revenue per visitor
• Tech Lead (1 person): Owns architecture, code quality, technical debt
• Full-Stack Engineers (3-4 people): Build features, fix bugs
• UX Designer (0.5 person, shared): Design enhancements
• QA Engineer (0.5 person, shared): Test automation

Team Size: 6-7 FTE (full-time equivalent)

Product Metrics (Team's OKRs):

• Conversion rate: 2.8% → 3.5% (target)
• Page load time: <2 seconds
• Checkout abandonment: 45% → 35% (target)
• Customer satisfaction: 8.2/10 → 8.8/10 (target)

How Work Gets Done:

Old Way (Project):

1. Business requests "Checkout optimization project"
2. Create project plan (2-3 months)
3. Assemble temporary team
4. Execute project
5. Deploy and disband

New Way (Product):

1. Business shares goal: "Reduce checkout abandonment 10%"
2. Product team analyzes problem (1 week)
3. Team proposes solutions (experiments, features)
4. Team builds, deploys, measures in 2-4 week sprints
5. Team iterates based on results
6. Team continues improving product continuously

Timeline: 2-4 weeks per improvement cycle (vs. 2-3 months per project)

The Four Pillars of Product Operating Model

Pillar 1: Persistent Teams

Principle: Keep teams together long-term (12-24+ months)

Benefits:

• No team formation overhead (save 2-4 weeks per project)
• Deep product knowledge (team knows codebase, users, domain)
• High trust and collaboration (team gelled, efficient communication)
• Ownership mentality ("our product" vs. "temporary assignment")

How to Structure:

• Teams of 5-9 people (optimal size for communication)
• Collocate team (same space or time zone)
• Dedicated 80-100% to one product (not split across 3 projects)
• Rotate team members only when necessary (career growth, backfill)

Pillar 2: Outcome-Based Objectives

Principle: Teams own business outcomes, not just outputs

Project Mindset (Output):

• Success = Deliver features on time
• Measured by: Project completion %
• Accountability ends: When project deployed

Product Mindset (Outcome):

• Success = Achieve business results
• Measured by: Business KPIs (revenue, engagement, efficiency)
• Accountability ongoing: Team owns metrics continuously

Example: "Shopping Cart Optimization"

Project Success Criteria:

• ✅ Delivered 5 features (guest checkout, saved cart, express checkout, cart reminders, upsell widget)
• ✅ On time (8 months)
• ✅ On budget (€450K)
• Result: Checkout abandonment unchanged (45%) → Project declared "success" but no business value

Product Success Criteria:

• Reduce checkout abandonment: 45% → 35%
• Increase average order value: €87 → €95
• Improve mobile checkout conversion: 1.8% → 2.5%
• Approach: Team experiments with A/B tests, ships incremental improvements, measures results, iterates
• Result: Checkout abandonment 45% → 38% after 3 months (€2.1M annual value) → Continues improving

Pillar 3: Continuous Delivery

Principle: Ship small changes frequently, not big releases infrequently

Project Delivery Pattern:

• Work 6-12 months
• Deploy everything at once (big-bang release)
• High risk (lots can go wrong)
• Slow feedback (learn after 6-12 months)

Product Delivery Pattern:

• Work in 2-week sprints
• Deploy every sprint (or daily with feature flags)
• Low risk (small changes, easy to rollback)
• Fast feedback (learn every 2 weeks)

Continuous Delivery Practices:

• CI/CD Pipelines: Automate build, test, deploy
• Feature Flags: Deploy code off, turn on gradually
• A/B Testing: Validate impact of changes
• Monitoring: Real-time visibility into product health
• Rollback: Quick recovery if issues detected

Pillar 4: Empowered Teams

Principle: Give teams authority to make decisions

Traditional IT (Command-and-Control):

• Team told what to build (detailed requirements)
• Team told how to build (technology choices made elsewhere)
• Team told when to deploy (change advisory board approval)
• Result: Team executes, doesn't think

Product Operating Model (Empowered):

• Team given outcomes to achieve (not features to build)
• Team decides how to achieve outcomes (architecture, technology)
• Team deploys when ready (within guardrails)
• Result: Team innovates, experiments, learns

Empowerment with Guardrails:

• Autonomy: Teams decide "how" (within standards)
• Accountability: Teams own outcomes (metrics)
• Alignment: Teams aligned to business strategy (clear priorities)
• Guardrails: Security, compliance, architecture principles

Implementing Product Operating Model

12-week transformation from project-centric to product-centric:

Phase 1: Foundation (Weeks 1-4)

Goal: Design product portfolio and prepare for transformation

Week 1-2: Product Portfolio Design

Step 1: Inventory Current State (Week 1)

• List all IT systems/applications
• Group by business capability (e.g., "Customer Engagement", "Order Fulfillment")
• Identify natural product boundaries

Step 2: Define Products (Week 2)

• Select 10-20 products (start small, expand later)
• For each product:
  • Product name
  • Business outcomes (metrics)
  • Target team size (5-9 people)
  • Current annual maintenance + project spend

Product Definition Criteria:

• Delivers specific business value
• Has identifiable users (internal or external)
• Has measurable business metrics
• Can be owned by one team (5-9 people)

Example: Defining Products for E-commerce Company

Don't Do This (Too Granular):

• Product: Shopping Cart Widget
• Product: Product Catalog Service
• Product: Checkout Form
  → Too small, would require coordination across 10+ teams

Do This (Right Level):

• Product: E-commerce Website (includes cart, catalog, checkout, product pages)
• Product: Mobile App
• Product: Customer Service Portal
  → Each product independently delivers business value

Week 3: Team Staffing Model

Current State Analysis:

• Map current IT staff to products
• Identify gaps (products without sufficient coverage)
• Identify overlaps (too many people per product)

Target State Design:

• Assign 5-9 people per product team
• Balance generalists vs. specialists
• Plan for shared resources (designers, QA)

Hiring/Reallocation:

• Identify open positions needed
• Plan for external hiring (if gaps)
• Communication plan for reorg

Week 4: Operating Model Documentation

Create:

• Product portfolio overview (1-pager)
• Product team structure guide
• Roles and responsibilities (Product Manager, Tech Lead, Engineers)
• Funding model (how products get budget)
• Governance model (decision authority, escalation)

Phase 2: Pilot Products (Weeks 5-8)

Goal: Launch 2-3 pilot product teams, prove the model

Week 5: Select Pilot Products

Selection Criteria:

• High business impact (visible success)
• Supportive stakeholders (willing to try new model)
• Sufficient team available (don't need hiring first)
• Manageable complexity (not most complex product)

Example Pilots:

• Product 1: Customer Portal (high visibility, supportive VP)
• Product 2: Mobile App (active development, frustrated by project model)
• Product 3: Order Management System (internal operations, clear metrics)

Week 6: Form Pilot Teams

For each pilot:

1. Assign Product Manager (business outcome owner)
2. Assign Tech Lead (technical quality owner)
3. Assign 3-5 engineers (full-time to product)
4. Assign shared resources (designer, QA)
5. Team kickoff meeting (introduce product operating model)

Team Kickoff Agenda:

• Product mission and vision
• Business outcomes (metrics to move)
• Current state assessment
• Roadmap planning (next 3 months)
• Ways of working (sprints, standups, retrospectives)

Week 7: Define Product Metrics

For each pilot product, define:

• North Star Metric: The one metric that best represents product success
• Supporting Metrics: 3-5 metrics that drive the north star
• Baseline: Current metric values
• Targets: 3-month and 6-month targets

Example: Customer Portal Product

North Star Metric: Customer self-service rate

• Baseline: 42% of inquiries resolved via portal
• 3-month target: 50%
• 6-month target: 60%

Supporting Metrics:

• Portal login rate: 35% → 45% → 55%
• Average time-to-resolution: 8 minutes → 6 minutes → 5 minutes
• Portal satisfaction score: 7.2/10 → 8.0/10 → 8.5/10
• Support ticket deflection: €180K/month → €220K/month → €280K/month

Week 8: Launch Pilots

Each team:

• Begins working in 2-week sprints
• Daily standups (15 minutes)
• Sprint planning (prioritize based on outcomes)
• Sprint review and retrospective
• Continuous deployment (ship every sprint)

Leadership:

• Weekly product review (30 minutes per product)
• Review metrics, progress, blockers
• Provide support and remove obstacles

Phase 3: Expand & Scale (Weeks 9-12)

Goal: Expand to all products, train organization

Week 9-10: Launch Remaining Product Teams

Wave 2:

• Launch 5-7 additional product teams
• Apply learnings from pilot teams
• Continue with remaining products (Wave 3, 4)

Week 11: Training & Enablement

Product Manager Training (2-day workshop):

• Product management fundamentals
• Outcome-based roadmaps
• Stakeholder management
• Metrics and measurement

Tech Lead Training (2-day workshop):

• Technical leadership
• Architecture decision-making
• Code quality and technical debt management
• Team coaching

Leadership Training (1-day workshop):

• Product operating model principles
• Managing in product org (outcomes vs. outputs)
• Funding and resource allocation
• Performance management in product model

Week 12: Operating Rhythm & Governance

Quarterly Business Review (QBR) Process:

• Each product team presents:
  • Metrics (actual vs. target)
  • Achievements (what shipped)
  • Learnings (experiments, failures)
  • Next quarter priorities
• Leadership provides feedback and alignment

Product Portfolio Governance:

• Monthly product portfolio review
• Review overall IT portfolio health
• Reallocate resources if needed
• Adjust product boundaries if necessary

Phase 4: Continuous Improvement (Ongoing)

Monthly Product Reviews:

• Product Manager presents metrics
• Demo of recent work
• Discuss obstacles and support needed

Quarterly Team Health Assessment:

• Team satisfaction survey
• Delivery metrics (velocity, cycle time)
• Quality metrics (defects, tech debt)
• Business outcomes achievement

Annual Product Portfolio Re-evaluation:

• Add new products (as business grows)
• Sunset legacy products (as systems retired)
• Rebalance team sizing (based on product needs)
• Adjust funding model (based on value delivered)

Real-World Product Operating Model Transformation

Case Study: Regional Insurance Company (800 IT Staff, 40 Product Teams)

Starting State (Project-Centric):

• IT organization: 800 people, 120 active projects
• Average project duration: 11 months
• Average time-to-production: 14 months (including queue time)
• Business satisfaction: 4.9/10
• Employee engagement: 52%
• Annual IT budget: €85M

Problems:

• Business frustrated by slow IT delivery
• IT team frustrated by constant context switching
• Quality issues due to rushed project closures
• Knowledge loss as teams disbanded
• Growing technical debt

12-Week Transformation (June-August):

Weeks 1-4: Foundation

• Identified 38 products across organization
• Designed product portfolio structure
• Created product team staffing model
• Planned reorg: 120 projects → 40 product teams

Product Portfolio (38 Products):

• Customer-Facing (8 products): Web portal, mobile app, customer service
• Distribution (6 products): Agent portal, broker systems, sales tools
• Core Insurance (12 products): Policy admin, claims, underwriting
• Enterprise Support (8 products): Finance, HR, facilities systems
• Platform & Data (4 products): Data platform, integration, infrastructure

Weeks 5-8: Pilot

• Launched 5 pilot product teams
• Products: Web Portal, Mobile App, Claims System, Agent Portal, Data Platform
• Teams trained on product operating model
• Began working in 2-week sprints

Weeks 9-12: Expansion

• Launched remaining 35 product teams (3 waves)
• Trained 40 Product Managers and Tech Leads
• Established quarterly business review process

6-Month Results:

• Delivery speed: 14 months → 8 weeks average time-to-production (7.5x faster)
• Business satisfaction: 4.9/10 → 7.4/10 (+51%)
• Employee engagement: 52% → 72% (+38%)
• Features delivered: 2.4x more features shipped (same resources)
• Feature usage: 62% → 84% features actively used (less waste)
• Technical debt: Decreased 18% (teams invest in quality)

12-Month Results:

• Delivery speed: 4 weeks average time-to-production (17x faster than baseline)
• Business value: €22M additional value delivered (measured)
• Cost savings: €8.5M reduced waste (10% of IT budget)
• Employee engagement: 78% (highest in company history)
• Business satisfaction: 8.1/10

Specific Product Team Success: Claims System

Team Structure:

• 1 Product Manager
• 1 Tech Lead
• 4 Engineers
• 0.5 UX Designer (shared)
• 0.5 QA Engineer (shared)

Product Metrics:

• Claims processing time: 18 days → 12 days (6-month goal: 8 days)
• Claims adjuster productivity: 14 claims/week → 19 claims/week
• Customer satisfaction: 6.8/10 → 8.2/10
• Manual work reduced: 40% automation achieved

What Changed:

• Before (Project Model):

  • 3 projects per year (4 months each)
  • Team assembled and disbanded 3x per year
  • Requirements gathered once per project
  • No ownership (team moved to other projects after delivery)

• After (Product Model):

  • Continuous delivery (deploy every 2 weeks)
  • Persistent team (same people 12+ months)
  • Continuous user research (talk to claims adjusters weekly)
  • Strong ownership (team proud of claims processing improvement)

Key Success Factors:

1. Executive commitment: COO and CIO championed transformation
2. Pilot first: Proved model with 5 products before full rollout
3. Training investment: 2-day workshops for all Product Managers and Tech Leads
4. Metrics transparency: Every product team dashboard visible to organization
5. Patience with transition: Allowed 3 months for teams to gel and find rhythm

2 Years Later:

• 42 product teams (added 2 new products)
• Product operating model standard practice
• Industry recognition (awards for IT innovation)
• Recruiting advantage (candidates want to work in product teams)

Action Plan: Product Operating Model Transformation

Quick Wins (This Week):

Step 1: Assess Current Operating Model (2 hours)

• Count active projects and average duration
• Calculate time-to-production (idea → production)
• Survey business satisfaction with IT delivery
• Identify pain points (delays, quality issues, knowledge loss)

Step 2: Sketch Product Portfolio (2 hours)

• List major IT systems/applications
• Group by business capability
• Identify 5-10 potential products
• Estimate team sizes needed

Step 3: Leadership Alignment (1 hour meeting)

• Present product operating model concept
• Share benchmarks (3-4x faster delivery)
• Discuss transformation timeline (12 weeks)
• Get commitment to pilot

Near-Term (Next 30-60 Days = Weeks 1-8):

Step 4: Design Product Portfolio (Weeks 1-2)

• Define 10-20 products (start small)
• For each: business outcomes, metrics, team size
• Staffing model (who goes to which product team)

Step 5: Launch Pilot Product Teams (Weeks 3-6)

• Select 2-3 pilot products
• Form teams (Product Manager, Tech Lead, Engineers)
• Team kickoff (product vision, metrics, ways of working)
• Begin 2-week sprints

Step 6: Monitor Pilot Success (Weeks 7-8)

• Weekly product reviews
• Track metrics (delivery speed, business outcomes)
• Gather feedback (team satisfaction)
• Document learnings

Strategic (Weeks 9-12+):

Step 7: Expand to All Products (Weeks 9-10)

• Launch remaining product teams in waves
• Apply learnings from pilots
• Communicate transformation progress

Step 8: Training & Enablement (Week 11)

• Product Manager training
• Tech Lead training
• Leadership training (managing product teams)

Step 9: Operating Rhythm (Week 12+)

• Monthly product reviews
• Quarterly business reviews
• Annual product portfolio review

Success Metrics (6-Month Goals):

• Time-to-production: 50% faster
• Business satisfaction: +30%
• Employee engagement: +20%
• Feature usage: +15% (less waste)

The Transformation: Projects to Products

Product operating model isn't just an organizational change—it's a mindset shift from outputs to outcomes:

Project Mindset:

• Deliver features → Product Mindset: Achieve business results
• Temporary teams → Product Mindset: Persistent teams
• Big releases → Product Mindset: Continuous delivery
• Executing requirements → Product Mindset: Solving problems

Organizations that adopt product operating model achieve:

• 3-4x faster delivery (weeks vs. months)
• 30-50% higher business satisfaction (IT delivering real value)
• 20-40% better employee engagement (ownership and purpose)
• 15-25% less waste (building what's needed, not what's specified)

Most importantly, product operating model aligns IT with business strategy. When teams own outcomes (not just deliverables), they think like business partners and innovate like startups.

If your IT organization is struggling with slow project delivery or misalignment with business, you're not alone. The product operating model provides the structure to transform delivery speed and effectiveness.

I help organizations transform from project-centric to product-centric IT. The typical engagement involves:

• Weeks 1-4: Product portfolio design, staffing model, transformation plan
• Weeks 5-8: Pilot product teams launch and success validation
• Weeks 9-12: Organization-wide rollout, training, operating rhythm establishment

→ Book a 30-minute product operating model consultation to discuss your IT operating model and create a transformation roadmap.

Download the Product Operating Model Toolkit (templates + playbooks) including product definition template, team kickoff agenda, and metrics framework: [Contact for toolkit]

Further Reading:

• "Inspired" by Marty Cagan (product management bible)
• "Empowered" by Marty Cagan and Chris Jones (product leadership)
• "Team Topologies" by Matthew Skelton and Manuel Pais (organizing teams)