What I'd Protect First

Last time I said I'd choose product-led again, every time. Here's what I'd protect first if I were standing it up from scratch tomorrow.

These aren't the things the playbooks lead with. The playbooks lead with team structures and ceremonies. What I'd protect is further upstream. The choices that decide whether the rest of the model has anywhere to land.

Define what counts as a product

None of this works until you've decided what a product is. You have to decide it before the people, before the funding model, before anything else. Otherwise you're building structure around something that hasn't been named yet.

We took our business capabilities and split them as far as we could without too much bleed between them. Senior leaders made the cuts, with one Enterprise Architect supporting. Almost blind. The aim wasn't to get it perfect, the aim was 80%, and refine when new people come in to actually run the products. Wait for 100% and you never start.

The interesting part wasn't the business-facing products. Those were relatively obvious. The interesting part was Platforms and Foundations.

Platforms are the cross-IT technologies that other product teams consume from. M365. Azure data platform. Too big to belong to any one product team and too widely used to be owned end-to-end by one. So they become products in their own right, with the underlying technology as the product, and other product teams as their customers.

Foundations are different again. Service desk. Hardware. Laptops. Datacentres. The IT-of-IT layer that everyone in the organisation depends on. They're even further from a single business customer than Platforms are. They serve everyone, which in funding terms is the same as no obvious sponsor.

Three tiers. Business-facing products, Platforms, and Foundations. Same model, different shapes.

The Head of Product role

The next thing I'd protect is the Head of Product role itself. Specifically, who you put in it, where they come from, and what you make them accountable for.

The Head of Product should, in 95% of cases, be the people manager for everyone on the product team apart from the architect. That's a structural reality, not a philosophical one. You can't line-manage IT engineers from outside IT. So this is an IT role, 100%. Not a business role, not a hybrid role.

That's where I'd push back on a lot of the standard product-led literature, which assumes the Head of Product is or could be business-side. In an enterprise IT operating model where the Head of Product is also the people manager, that doesn't hold.

Where we sourced ours from is the other thing worth saying. We didn't default to "promote the existing product owners." We cast wide. Service delivery managers. Scrum masters. Product owners. Line managers. Adoption specialists. The reason we cast wide is that the new role owns both build and run. The previous Head of Product role only looked after new development, and often had no idea about the running solutions a service delivery manager could tell you everything about. That gap was exactly what the new role had to close.

The filter we used: must come from IT, must be mature enough, and must be open enough to land the mindset for their product area. The openness piece is doing real work. You can have all the experience in the world and still be too anchored to the previous shape of the role to hold the new one.

The architect counterweight

Here's a design choice that's easy to undo without realising what you're losing.

Product architects don't report into the Head of Product. They report to the Architectural Partner in the enablement layer. Which means the Head of Product doesn't line-manage their architect. They have to work with them as a counterpart.

This is deliberate. The Head of Product optimises for the product. The architect optimises for architectural coherence across the estate. Neither can override the other from inside their own line of reporting. Both have to make their case.

Without that separation, the architect becomes a function of whatever the Head of Product wants this quarter. Architecture coherence dies first, quietly, and you don't notice until three years later when nothing integrates and everyone wonders why.

The enablement layer, properly defined

Most product-led literature talks about "an enablement layer" as if it's one thing. We have four partner roles, each protecting the model from a different failure direction. Trying to collapse this into fewer roles is one of the easiest ways to hollow the model out.

Delivery Enablement Partner. Owns the people structure. The Head of Product reports up to them. They handle the things that would otherwise crush the Head of Product if they had to do them alone, like HR, team sizing, and where delivery leads sit in the line.

Architectural Partner. Owns architectural coherence across the estate. The product architects report here. This is the role that makes the counterweight above possible.

Value Partner. Owns whether the product is landing. Sits closer to the business unit than to IT. Tracks adoption, follows through on the outcome that justified the investment, and feeds the answer back. Adoption specialists report into them. Without this role, products ship and nobody checks whether the value actually landed.

Portfolio Partner. Owns whether the product is funded coherently. Sits closer to finance than to the business. Runs the funding process across all products in their portfolio, holds forecasting discipline, and sees the trade-offs across the estate that no individual product team is positioned to see. Without this role, money flows in unstructured ways and nobody holds the portfolio view.

People, architecture, value, money. Each one removes a category of work from the Head of Product's plate. Each one also protects the model from a specific way it tends to slip. Cut any of these and the failure mode they were protecting against shows up within a year.

The most common collapse is to merge Value and Portfolio into one role. It feels efficient until the year-end review, when one person is meant to be the business's advocate for outcome and the finance team's advocate for spend discipline at the same time. Those are different rooms, different counterparts, and different conversations.

Funding, with two clocks

Funding is where product-led most often gets hollowed out. The vocabulary stays. The mechanics revert. People still talk about products, but money still flows in project-shaped lumps.

Our funding works on two clocks. A frame-setting cycle and a continuous drawdown cycle, doing different jobs.

The frame-setting cycle runs twice a year. May, you submit initial numbers for the next fiscal year. June, IT gets feedback on its overall frame. November, refined and final numbers go in, saying what you actually intend to spend on what. Then the frame is set.

From May onwards, you can request funding from your frame at any time. Each request is specific. These are the measured outcomes and value we expect from this investment, and this is how it affects future IT running cost.

That last part is the bit most CAPEX/OPEX-split orgs miss. Every drawdown request explicitly answers what it does to your run cost going forward. Run cost gets incremented through the investment process, deliberately. There's no parallel pot that grows in silence.

The frame gives finance and IT predictability. The drawdown gives products responsiveness without waiting for an annual approval cycle. Both clocks get fed.

Platforms and Foundations carry the sharpest bar

Every product has approval layers. A business sponsor, normally the same person who sponsors the frame bucket the product draws from. Then the IT Director. Then, depending on size, the CIO and CFO.

That works cleanly for business-facing products. The business sponsor provides the first layer of scrutiny. They're the one whose budget is moving and whose outcome is on the line. They're also the one who pushes back first if a request doesn't make sense.

Platforms and Foundations don't have that. There's no business sponsor for the M365 platform team. There's no business sponsor for the service desk. The customer is internal, or the customer is everyone, which in funding terms is the same as no customer.

So the scrutiny has to come from somewhere else. In our case it comes from the IT Director, the CIO, and the CFO, harder than it would for a sponsored product. The substance of the pushback is direct: this is IT spending Arla's money on IT. The bar has to be the sharpest of all the requests.

This inverts what most people would assume. Platforms and Foundations are foundational, so you might expect them to get an easier ride. They don't. They get a harder one. And the design integrity of the model depends on that being true. If platforms got easier scrutiny, IT would over-invest in itself at the expense of the business outcomes the rest of the model is organised around.

The honest part: this is hard to live with on the platform side. The teams holding the sharpest bar are also the people learning the new model for the first time, and the people they'd normally turn to for advice are working from the easier version of the playbook.

What you have to actively protect during transition

Everything above is structural. There's another layer of protection that's about the live transition itself, and it's the bit nobody warns you about. Four things in the first six months I've had to actively protect.

Stop the Head of Product becoming the bottleneck. The role is broad. If you don't actively show people how to delegate to delivery leads, everything stacks on one person.

The transition bar. Mid-flight work doesn't fit cleanly into either the old or the new process. We didn't draw a central rule. We let the stakeholders of in-flight work decide for themselves whether to close out the old way or absorb into the new. The people closest to the work knew better than central transformation governance whether the work was actually done.

Identity transitions. People whose old role has become a new role have a real piece of work to do that nobody acknowledges. The old shape of ownership doesn't fit anymore, and the new shape isn't fully built yet. Protecting the people through that gap, and protecting the work they used to own, is its own job.

Information flow rate. Teams need information fast enough to operate, but not so much that they can't function. Too little and they freeze. Too much and they drown. Every week brings new questions. Protecting that rate is the kind of work that doesn't feel like work until it stops happening.

The model bends to the work

One last thing, and it's the through-line.

Foundations don't run with the full enablement layer the business-facing products do. Most Heads of Product in Foundations report directly to the IT Director, with a much thinner partner structure around them. The full layer would be heavier than the work warrants.

That's the principle. Business-facing gets the full structure. Platforms gets the full structure with a tougher funding bar. Foundations gets a thinner version reporting directly upward. Same principles, different shapes.

That's what I'd protect more than anything else. Not any specific role or process. The willingness to tailor.

Product-led isn't a uniform thing you apply. It's a uniform set of principles you apply with judgement to the actual shape of your organisation. The moment you start enforcing the same structure on every tier, the same enablement layer on every team, the same approval chain on every request, you've stopped doing product-led and started doing framework adherence.

More to come in this series. The next is about why all of this matters more, not less, as AI and agentic models land.