Explore
Community
Selected work

Product operating model

Giving benefits an owner

The product lifecycle tracked work until it shipped. What the work was meant to achieve was assumed, not checked. I redesigned the lifecycle so that every intended benefit has an owner and gets revisited.

The work in practice

Intended benefits are defined when work is proposed, owned by a named person and revisited after release. That evidence also feeds the portfolio’s persevere, pivot or stop decisions.

Delivery ended at launch

The business case justified starting the work, then disappeared. Delivery was tracked closely until release, and the benefit was assumed to follow. Nobody was asked afterwards whether it had.

Changing the lifecycle

I redesigned the lifecycle so that benefits run through it rather than sitting in front of it. Each piece of work now starts with a stated benefit hypothesis and a named owner. After release, the owner revisits the benefit at set points, and the evidence goes into the portfolio review, where it informs whether related investment should persevere, pivot or stop.

Connecting the measures

Each benefit traces from the product outcome to cost, revenue or risk, so the review knows what it is checking.

Changing what leaders aim for

A new lifecycle changes little if people are still rewarded for the old thing. Product goals had been written as outputs: features shipped, releases made. I replaced them with outcome goals, and that was the larger change.

A capability programme gave product managers the practice to work this way. Coaching helped senior product leaders write goals they could genuinely be held to.

What I learned

The process change was the quick part. Changing what leaders felt accountable for took far longer, and it was what made the process stick. Restructuring a lifecycle without moving accountability is the same mistake as installing a framework without changing decision rights.