The shift from projects to products is real — and it's not just a renaming exercise

Moving to a Product Centric Company

A senior leader stands in front of a slide titled Our Product Operating Model and describes, in fluent jargon, what is essentially a project plan with new vocabulary. Quarterly funding cycles renamed as "investment cadences." Project managers reissued as "product leads." Steering committees reconstituted as "value councils." The structure underneath is unchanged. The reporting is unchanged. The behaviour of the work and people is unchanged.

This is a common moment in large organisations right now. The intent is real. The vocabulary has moved. The system has not.

The shift from projects to products is one of the most consequential changes an enterprise can make to how it builds and runs software.

Done well, it changes how money is committed, how teams shape work, how value is measured (and realised), and how the business learns. Done as a rebrand and rename, it adds a layer of jargon to the same delivery machine — and burns the energy of the people who were hoping for something different.

What a project organisation optimises for

To understand why the shift from projects to products is hard, it helps to be honest about what a project organisation is good at. It is good at delivery against a mostly fixed scope, within a defined budget, by a known date. It is good at handover. It is good at closing things. It is good at dealing with small changes. It is good at producing the artefacts — Gantts, RAID logs, status decks — that allow leadership to feel oriented.

None of that is bad. In contexts where the problem is well understood and the solution is mostly known, project thinking is genuinely the right tool. Build a warehouse. Migrate a data centre. Roll out a payroll system. These are projects, and treating them as anything else would be malpractice.

The trouble is that new software products are not warehouses. The problem keeps moving. The market answers back. The assumptions at the start come undone. The technical implementation may be trickier (or easier) than expected. The thing being built needs to change shape as it gets built. The value is often realised over time, not at handover or shipping.

And the team's understanding of the work matures faster than any plan written at the start can keep up with.

Project structures applied to emerging product work do something subtly costly. They optimise the organisation for the things projects measure — on-time, on-scope, on-budget — and against the things products actually need: learning, adaptation, sustained ownership, and an honest relationship with value. The result is software shipped on time, on scope, on budget, and unused.

The real unit of decision changes

The shift from projects to products is, at its heart, a shift in what the organisation treats as the unit of decision.

In a project organisation, the unit of decision is the project. Funding is committed to it. Plans are written for it. Governance lives at its boundary. Risk is removed from the build through upfront analysis and detailed planning. When it ends, the organisation often moves on.

In a product organisation, the unit of decision is the product. Funding is committed to it as a continuing concern. Teams hold ownership over time. Governance is about whether the product is still earning its keep, not whether the project is on track. The product has a vision, a charter, a hopper of work, and a measurable relationship with the value it produces now and in the future.

This sounds like a small distinction. It is not. It changes how money is committed, how work is shaped (a continuous backlog, not a closed scope), how teams are formed (durable and stable, not assembled per project), and how value is judged (measured over time, not declared at launch).

The four kinds of value a product team chases

Most product organisations that get into trouble do so because they cannot say, clearly, what kind of value they are chasing. The work blurs. The investment justification blurs with it.

There are four kinds of value, and they should be clearly understood.

Financial value is external. It is what happens when someone outside the business pays for something worth paying for. It is the only kind of value that brings money in. Everything else is internal — and internal value is cost.

And it may be the case that the technology being built is for internal use – and those internal customers are the ones generating the value by using the technology. Still measurable.

Cost reduction is internal. It makes what the business already does cheaper, faster, more efficient, better. Useful, often necessary, but not direct revenue.

Enablement is internal. Compliance, regulation, infrastructure, licence to operate. The cost of being allowed to do the work in the first place.

Experiments are internal. Investments made primarily to learn what might create future value. They produce knowledge, not yet revenue.

Each is legitimate. Each is also different, and treating them as the same is one of the most expensive mistakes a company can make. A "CapEx for revenue" pound and a "CapEx for cost reduction" pound and an "OpEx for keeping the lights on" pound are not interchangeable, even when they sit in the same accounting code. They answer different questions, are governed by different logic, and produce different kinds of returns. Conflate them and the portfolio cannot tell which investments are working – and this is far more common than it should be.

Every piece of work is a problem and an opportunity

The other distinction skipped too quickly is the one between problem and opportunity. They are two sides of the same coin — you cannot pursue an opportunity without inheriting its problems, and you cannot solve a problem without opening new ones.

A useful discipline before any product investment starts: write it as a single statement.

We are addressing [problem] in order to open [opportunity], and we have considered [the operational, financial, and organisational consequences].

If the team cannot complete that sentence honestly, the work is not ready. If they can, the conversation about whether to fund it becomes much shorter and much more useful.

It's not uncommon for an organisation to spend considerably more money on building a technology solution than the value returned, and to boot, they then incur staggering operational costs for many years after the launch supporting and keeping it running. This is especially prevalent in technology functions building solutions for other parts of the same business.

Funding the team, not the project or product

One of the most under-appreciated parts of the projects-to-products shift is what it does to funding. Project funding is event-shaped: a business case, an approval, a budget, a close-down. Each cycle starts the politics again. Product funding is continuing: a stream of investment, governed by whether the product is still earning its place.

But there is a further move — and it is the one that separates organisations that have genuinely left project thinking from those that have only renamed it.

The deeper shift is to fund the team that is aligned to a value stream or product theme. The team costs what the team costs — X per year, give or take — and the only live question becomes what work flows through it. The funding decision is settled the moment the team exists. From that point on, the leadership conversation is about prioritisation, not approval. Which products, which initiatives, which problems deserve this team's time and commitment? What is the most valuable thing we could be doing with people we are already paying for?

This relocates the decision upstream, where it belongs. In a project model, the decision is should we build X? In a fund-the-team model, the decision is what should this team work on next? — and that is a fundamentally healthier question. It assumes the capacity and capability. It puts value at the centre of the conversation. It stops the organisation from re-litigating the same funding case every twelve months for work it was always going to do anyway.

Most large enterprises stop short of this. They will move from funding projects to funding products — same team, but each tranche of work still wrapped in a solution-shaped business case. The team is stable on paper; the work is still chopped into approvable parcels. That is a real improvement, and worth getting to. But it is not the destination. It is the polite version of the move.

The full version is to fund the team or the value stream, and let prioritisation do the work that approval used to do. This is the territory of lean portfolio management — the principle that every pound of investment should be traceable down to the activity it funds and out to the value it produces. When that line of sight breaks, the organisation cannot tell whether any single investment is working. It can only tell whether the aggregate is on schedule.

The non-negotiable rule, in practice: one bucket of money, one portfolio initiative, one value type. CapEx for revenue, CapEx for cost reduction, and OpEx for run-the-business are not the same money. When they are blended under a single initiative, no one can tell which of them is delivering — and the reporting becomes watermelon: green on the outside, red inside, with the truth surfacing months too late.

Measuring whether the work is actually working

Project organisations are well-served by a small set of measures: time, cost, scope. Product organisations need more — and crucially, the measures need to be kept in distinct, never-blended categories.

Four lenses:

Financials — investment, value realised, run-rate cost, the honest relationship between spend and return.

Delivery — tracking against commitments, cycle time, shipping rhythm, dependencies.

Product — stability, usage, fit for purpose, customer-side performance.

People — wellbeing, engagement, growth, team spirit.

Each tells a different story. Together, they tell the truth about whether the product is moving from idea to value and whether the people in the organisation are thriving. When organisations blend these into a single dashboard, they produce data that few trust and few act on. When they keep them separate, the conversations become precise — and more accurate decisions become possible.

One more thing about measurement: shipping is not realising value. Shipping is the point at which value becomes testable. The value itself shows up later, in a usage curve, in a piece of feedback, in a cost line that quietly falls. Treating launch as the finish line is one of the great enterprise self-deceptions, and it is built into project thinking. Product thinking has to actively undo it.

The role of product, and the role of the team

The split is simple to describe and hard to live by. Product sets the vision, writes the charter, plans the work, and breaks it down. The team brings the technical and specialist craft to that breakdown, shapes the solutions, and turns ideas into something tangible. Neither side does the other's job.

The mistake project organisations carry into product is treating the team as a delivery resource. Tickets arrive at the top of the backlog, the team implements them, work is closed. In that model, the team's experience and judgement are sometimes wasted — and the cost of that waste is paid in attrition, rework, and quietly disengaged talented people.

A product team is involved in defining solutions, not just implementing them. They bring craft to the shaping. They are not order-takers.

A planning rhythm that doesn't pretend

The unit of planning in large companies moving to product tends to be the quarter. Not because quarters are sacred, but because they are long enough to commit honestly, short enough to be wrong about safely, and stable enough that the rest of the business can rely on them.

Plan in three horizons. The next quarter should be well defined — a clear commitment the team can stand behind, made up of shaped work the team has already broken down. The quarter after should be broadly clear — direction set, initiatives named, detail still to come. Further out is intent only — high-level outcomes, honest about the uncertainty.

And the quarterly review is not a reveal. By the time it arrives, there should be no surprises. It is a reflection on data the team has already been working with — a moment of alignment, not a deep dive. If the quarterly is the first time leadership sees the truth, the wiring is broken upstream.

What you can take from here

If you are a leader in the middle of this shift — or about to start one — the underlying question is not which methodology to adopt. The market is full of methodologies. The underlying question is whether you are willing to change what your organisation treats as the unit of decision, funding, and value. The methodologies follow. The vocabulary follows. If you change those without changing what sits underneath, you change nothing.

The playbook embedded on this page is a short guide to the operating picture for software product ownership at enterprise scale. It is the synthesis of the ideas in this article — the value types, the portfolio structure, the planning rhythm, the role split between product and team, the four measures. Read it, share it, hand it to a peer. It is free, downloadable, and intended to be used.

The Tech Portfolio Field Guide takes a wider view. The playbook is about a product; the Field Guide is about the portfolio — how multiple products and investments behave together as a system, how to govern that system without smothering it, and how to fund it in a way that lets value travel rather than just accumulate. The first half is free. The full version sits inside Studio, alongside the rest of the practitioner-grade reference layer.

The honest version

The shift from projects to products is, in the end, a shift in ongoing measurement of value. Product thinking forces the organisation to keep paying attention — to see whether the thing being built is actually changing the world it was meant to change.

The vocabulary is the easy part. The question is whether the system underneath has moved with it.