Yet despite significant investment, many organisations discover that very little has actually changed.
Projects are still approved annually. Success is still measured by delivery against scope. Leaders still specify solutions. Teams are still rewarded for output rather than outcomes.
The result is an organisation that looks like a product organisation on paper but continues to operate using a project mindset.
This is one of the key messages within Marty Cagan's Product Model: moving to product is not a technology transformation. It is an organisational transformation.
The Common Misunderstanding
Many organisations approach product transformation as a technology initiative.
The thinking often looks like this:
- Create Product Manager roles
- Rename delivery teams as product teams
- Adopt Scrum or Kanban
- Change roadmaps
- Introduce product ownership
These changes can be helpful, but they do not, by themselves, create a product organisation.
A genuine move to product requires changes across:
- Leadership
- Governance
- Funding
- Finance
- Risk and compliance
- Performance management
- Planning and prioritisation
- Technology
- Product management
- Design
In other words, the entire organisation.
If only the technology department changes, the organisation remains constrained by project-based thinking.
Project Model versus Product Model
At its core, the difference comes down to accountability.
Project Model
Teams are accountable for:
- Delivering agreed scope
- Meeting deadlines
- Staying within budget
Success is measured by delivery.
The key question becomes:
Did we build what we said we would build?
Product Model
Teams are accountable for:
- Customer outcomes
- Business outcomes
- Measurable impact
Success is measured by value creation.
The key question becomes:
Did we solve the problem?
This sounds simple, but it fundamentally changes how decisions are made throughout the organisation.
Why Technology Teams Alone Cannot Make the Change
Consider a technology team that has been restructured into a product team.
They are encouraged to run experiments, conduct discovery, and focus on customer outcomes.
However:
- Finance still allocates annual project budgets.
- Governance boards still approve detailed solution designs.
- Senior leaders still demand feature commitments twelve months in advance.
- Performance measures still focus on delivery dates.
In this scenario, the team is expected to behave like a product team while being managed like a project team.
The inevitable result is frustration.
The team may possess product titles and product ceremonies, but it lacks product autonomy.
True product organisations align the entire operating model around outcomes.
An Example: Moving from Project to Product
Imagine a large insurance company that wants to improve its digital claims experience.
Phase 1: Project Thinking
A senior steering committee reviews customer feedback and decides:
We need a mobile claims app.
A project is approved.
Project Objective
Build a mobile claims application by September.
Measures of Success
- Delivered on time
- Delivered within budget
- All requirements completed
A project manager is assigned.
Requirements are gathered.
Designs are produced.
Developers build the application.
The application is launched successfully.
The project closes.
Six months later:
- Adoption is low
- Customer satisfaction has barely improved
- Call centre volumes remain unchanged
The project was successful.
The customer problem was not solved.
Phase 2: Product Thinking
The organisation restructures around customer outcomes rather than projects.
Instead of approving a solution, leadership defines a problem.
Product Outcome
Reduce friction in the claims journey and increase customer satisfaction.
A permanent cross-functional team is formed.
The team includes:
- Product Manager
- Product Designer
- Engineers
- Data specialists
- Customer service representatives
Notice that the team is not purely technical.
The customer service team becomes a critical source of insight because they hear customer frustrations every day.
The team begins discovery.
What They Learn
Customer interviews reveal several unexpected findings.
Customers are generally happy using the website.
Most customers submit claims infrequently and have little interest in downloading a dedicated app.
The biggest frustration is uncertainty.
Customers repeatedly ask:
- Has my claim been received?
- Who is handling it?
- What happens next?
- How long will it take?
The problem turns out not to be claim submission.
The problem is claim visibility.
Experiments
The team runs several experiments.
Experiment 1
Real-time claim status updates.
Result:
- Significant reduction in customer enquiries.
Experiment 2
Automated SMS and email updates.
Result:
- Improved customer confidence.
Experiment 3
Mobile app prototype.
Result:
- Very low customer interest.
The team decides not to build the mobile app.
Instead, they improve claim tracking and customer communication.
Outcomes
After six months:
- Customer satisfaction increases
- Call centre demand falls
- Processing transparency improves
- Development effort is significantly lower than originally estimated
Most importantly:
The original solution was rejected because the evidence showed it would not solve the problem.
This is a hallmark of an empowered product team.
Success came not from building the planned solution but from discovering a better one.
What Changes Across the Organisation?
The transition to product requires more than changing team structures.
| Area | Project Organisation | Product Organisation |
|---|---|---|
| Strategy | Annual initiatives | Continuous outcomes |
| Funding | Fund projects | Fund long-lived teams |
| Leadership | Direct solutions | Provide context and goals |
| Governance | Approve plans | Review outcomes |
| Finance | Capital tied to projects | Investment tied to value |
| HR | Reward delivery | Reward impact |
| Technology | Build requirements | Discover solutions |
| Success Measures | Time, scope, budget | Customer and business outcomes |
Notice that technology is only one row in the table.
The Product Model requires every function to evolve.
The Hardest Change Is Not Process
Many organisations invest heavily in agile frameworks, tooling, and delivery practices.
These changes are relatively easy.
The difficult part is changing how leaders think.
Leaders must move from:
"I know the solution. Build it."
to:
"I know the outcome we need. Discover the best solution."
That requires trust.
It also requires accepting that teams may discover that a stakeholder's proposed solution is not the right one.
For organisations with strong project traditions, this can feel uncomfortable.
However, it is where the greatest value is found.
Final Thought
The move from project to product is often described as a transformation of technology teams.
In reality, it is a transformation of the entire organisation.
A business does not become product-led because it hires Product Managers or adopts agile methods.
It becomes product-led when strategy, funding, governance, leadership, and delivery are all aligned around a single principle:
The purpose of the organisation is not to deliver features. The purpose of the organisation is to create outcomes for customers and value for the business.
When that shift happens, teams stop asking, "What should we build?"
and start asking,
"What problem are we trying to solve?"
That is the real journey from projects to products.
No comments:
Post a Comment