Declare It. Price It. Own It.

Maintenance is not an engineering problem. It's a leadership decision that most product organizations never make.

Your roadmap hides the real cost. Your team absorbs the trust damage. Your delivery cadence degrades one zombie project at a time — and the old guards and gatekeepers let it linger because nobody wants to be the person who says "kill it." And the pattern repeats because nobody builds the missing layer between "ship it" and "keep it alive."

I call that missing layer Operational Ownership — pricing maintenance into how a product is conceived. Not after launch. Not when something breaks. At the moment you're deciding whether to build it at all.

The customer doesn't care how it was built. They care that it works tomorrow.

This isn't a process. It's three decisions product leaders need to make before anything moves toward production.

1. Declare It

Is this disposable or production-bound? Say it out loud.

The damage happens when nobody makes this call. Prototypes silently become products. A stakeholder demo becomes customer-facing infrastructure. A quick internal tool becomes a dependency for three departments. Nobody planned for that because nobody said what it was.

The operational move: Every initiative gets a declared status before it starts: Experiment, Pilot, or Production.

• Experiment — disposable. No maintenance commitment. Explicit expiration date. When the date hits, it dies or gets promoted. No quiet survival.
• Pilot — time-boxed with success criteria. If it meets criteria, it gets a maintenance plan and moves to Production. If it doesn't, it dies. No "let's just keep it running for now."
• Production — full maintenance commitment. Owner assigned. Maintenance cost estimated. Sunset criteria defined.

If you don't declare it, the organization will decide for you. And they'll decide wrong. This is true whether you're shipping software, launching a new service line at a financial services firm, or rolling out a workflow change at a government agency. The medium doesn't matter. The pattern is the same: undeclared things become permanent by default.

I watched this at a company where I was consulting. They had eleven internal tools in production. When I asked who owned them, the answer for seven was "I think engineering?" Four of those tools had zero active users. They were consuming maintenance time on software nobody was using because nobody had ever said "this is done."

We declared all eleven. Four were retired immediately. Three were promoted to Production with real owners. The rest got expiration dates. Engineering got 30% of their time back in a single quarter.

2. Price It

If it's production-bound, the maintenance cost goes into the business case. Not as a footnote. As a line item.

Most product bets are presented as build costs: engineering hours, design time, timeline to launch. That's the down payment. The mortgage — the two-to-five-year cost of keeping it alive — is nowhere in the pitch.

The operational move: Every production-bound initiative includes a Total Cost of Ownership estimate:

• Year 1 maintenance: engineering hours for monitoring, bug fixes, dependency updates, documentation
• On-call burden: who gets paged, how often, what's the response expectation
• Integration tax: what other systems depend on this, and what breaks when it changes
• Sunset criteria: under what conditions do we stop maintaining this

You don't need precision. You need visibility. A rough estimate that says "this will take one engineer at 15% for two years" changes the conversation completely. It forces the room to evaluate the real bet, not the fantasy version.

If you can't afford the maintenance, you can't afford the product.

3. Own It

Assign an operational owner before it ships. Not after. Not "we'll figure it out."

An operational owner isn't a scapegoat. It's the person accountable for the product's health — its uptime, its roadmap, its eventual retirement. They don't do all the work. They make sure the work gets done.

The operational move: Before launch, answer these questions in writing:

• Who is the operational owner? A named person, not a team.
• What is their maintenance budget? Hours per sprint, not "as needed."
• What triggers escalation? Define what "broken" means before it breaks.
• What triggers retirement? Under what conditions do we stop maintaining this? Usage thresholds, revenue thresholds, strategic relevance — pick your criteria and write them down.

A product without an owner is a product with an expiration date nobody set.

If you're a PM, not a VP: You can run Declare-Price-Own on the products YOU manage. You probably can't force the org to adopt this. But you can answer those four questions for your own products and bring the answers to your next 1:1. When your manager sees the maintenance cost written down — maybe for the first time ever — the conversation changes. You stop being an order taker absorbing invisible costs and start being the person who makes the tradeoffs visible.

What Changes When You Do This

I started applying Operational Ownership three years ago. The shift wasn't instant, but it was measurable.

The first thing that changed was the conversation. When I started requiring a maintenance estimate alongside every build estimate, half the "quick wins" people were pitching stopped looking quick. That's not a bug — that's the point. The bad bets filtered themselves.

The second thing: engineering trust. When engineers saw that maintenance was being priced at the strategic level — not dumped on them after the fact — the adversarial dynamic softened. They weren't fighting against speed anymore. They were partners in a total-cost conversation.

The third thing: capacity. Declaring products as Experiment, Pilot, or Production — and enforcing expiration dates on the first two — meant the portfolio stopped growing unchecked. We retired more in one year than the organization had retired in the previous five.

Declare it. Price it. Own it. That's how product leadership earns trust with engineering — not by arguing about tools, but by taking responsibility for what happens after the build.

Prompt

Pick one product your team owns. Answer these four questions: What is its declared status (Experiment, Pilot, or Production)? What is its annual maintenance cost in engineering hours? Who is its named operational owner? What would trigger its retirement? If you can't answer all four, that's your starting point.

Try it on one product this week. Reply with what you find — I'm collecting these across industries and the patterns are striking.

If someone on your team needs this framework, forward it. This is the kind of thing that changes a 1:1.

Landed here from a friend? Subscribe here.

This is what we build in my workshops — the muscle to price maintenance, retire dead weight, and close the gap between "ship it" and "own it." If your team is shipping without a maintenance strategy, let's talk.