Your product team still has a project scorecard

Give a team responsibility for improving checkout. Then judge its leader on whether every feature in last year’s business case shipped on time.

Which instruction do we think wins?

I was quoted in Pam Baker’s TechTarget article on why product operating models stall, published October 15. My point was about the scorecard:

“One of the easiest ways to kill a product model is to tell teams to optimize for outcomes and then reward leaders for utilization, project completion and staying inside a scope somebody defined twelve months earlier.”

That contradiction interests me more than the title on the org chart. People can understand the new model perfectly well and still make the old decisions. Their performance review is a fairly persuasive piece of documentation.

Let the checkout team change its mind

Consider a hypothetical commerce team funded to improve checkout completion. The approved plan includes a redesign, a new promotion component, and an account feature.

Once the team investigates, it finds a different problem: customers who encounter a payment failure cannot reliably resume their purchase. The proposed redesign might help. Recovering those baskets looks like the more immediate opportunity.

Can the team redirect effort toward recovery? Can it postpone the account feature? Who can approve the tradeoff, and does making it count as good judgment or missed scope?

If the answer requires rebuilding the entire business case, the team has responsibility for the result with very little room to pursue it.

Marty Cagan’s distinction between product teams and feature teams is useful here. A team assigned a problem needs room to discover a solution. A team assigned a feature list has a different job. Both require competent delivery. We should be honest about which job we funded.

I’ve written about the operational work behind taking an order. In this example, a better outcome could require changes across payments, checkout state, customer service, and order handling. Calling only the frontend group a product team does not give it authority over those dependencies.

Finance still needs something it can control

I would not ask a CFO to replace an approved project with an indefinitely funded team and a promise to learn things.

There needs to be a spending boundary, an accountable owner, evidence of progress, and a decision about what happens when the work does not justify continued investment. A product model should make those conversations more useful.

For the checkout example, I would want an agreed baseline, a bounded investment period, and measures that keep the team honest. Completion matters. So do payment failures, duplicate orders, support demand, and the cost of getting a valid order through the system. Improving one number by moving the problem into customer service is a poor result.

The review should ask what changed, what the team learned, what it costs to continue, and whether the original bet still holds. Attribution will be imperfect. Traffic mix, promotions, and payment-provider behavior can complicate the picture. Write those limits down rather than manufacturing certainty for a quarterly slide.

Roadmaps allocate capital. A product roadmap needs a way to reconsider that allocation when evidence changes. Otherwise discovery becomes something the team does after all the consequential decisions have already been made.

Utilization answers a different question

Utilization can tell a services business something useful about capacity and economics. Project completion can tell us whether a commitment was delivered. Neither automatically tells us whether the customer problem improved.

The mistake is making those measures the deciding reward while asking for different behavior.

A team that removes an unnecessary integration may deliver fewer features and reduce future work. A leader who stops a weak initiative may leave budget unspent. Those can be valuable decisions. They can also look terrible against a scorecard built to reward keeping everybody busy and finishing everything that was approved.

I want delivery measures too. DORA’s software delivery metrics help examine how a team delivers and recovers from changes. I would use that evidence alongside product results. Reliable delivery gives us a better way to test an idea; it does not establish that the idea was worth pursuing.

AI makes the mismatch more expensive

This is where the conversation connects to the bottleneck moving when AI writes the code.

If implementation gets faster while priorities remain fixed, a team can spend less time questioning the wrong feature and more time shipping it. That is a plausible failure mode, not a measured result I’m claiming for every organization.

The useful opportunity is shorter learning cycles: investigate the failure, make a bounded change, verify the behavior, and decide what to do next. That requires access to the system and permission to alter the plan. An AI assistant cannot grant either one.

This is also why the operating model belongs in the architecture conversation. The service boundaries may be sensible while the funding boundaries make every improvement a negotiation between departments.

Change one consequential decision

I would start with a product area small enough to understand and important enough that leadership will pay attention.

Name the owner. Agree on the problem and spending limit. Write down which decisions the team can make, which require escalation, and what evidence will inform the next funding review. Include the people who operate the thing after release.

Then watch the first uncomfortable tradeoff. A senior stakeholder wants a feature. The team has evidence that another change matters more. Somebody has to decide, and that decision has to survive the next meeting.

Afterward, look at the leader’s scorecard. Did we reward the decision we said we wanted?

That is where I would look for the transformation.