Unowned Doesn't Mean Undecided

Two teams agreed on every feature. The disagreement was in the limits attached to those features — and nobody owned the decision.

Days before launch, both teams were running pre-release testing on a payment management product. Marketing opened the near-final build and found capabilities sitting in the starter tier that their pricing model had placed higher.

Nothing had gone wrong in the way these stories usually go wrong. Marketing owned the pricing tiers and had built them from market research. Product and I owned the tier-wise feature allocation and had built that from the PRD. Both artifacts existed, both were documented, and both teams could defend every line in them.

We had also validated the solution together before development started. Marketing had agreed the target market. Marketing had agreed the feature set. There was a meeting, there was a document, and everyone in the room signed off on it.

The document had a column for the capability. It had no column for the limit.

What we actually disagreed about

The useful thing to notice is how narrow the disagreement turned out to be once we listed it out.

Nobody disputed that the product should include analytics. Nobody disputed that clients should be able to onboard customers, or that each tier should permit some number of products and services. Every disputed item was a number attached to a capability that both teams had already agreed existed: product or service counts per tier, customer onboarding caps, and analytics visibility by tier.

That pattern follows from what the two functions are for. Marketing’s job is to make the lower tier upgrade. Product’s job is to make every tier usable. Those goals are compatible across most of the product and collide at the limits. There is no argument from first principles that automatically settles where the line goes.

Counts, caps and visibility thresholds. Not one of the disputed items was a question about whether a capability should exist, which is why every conversation about the feature set came back clean.

Why the validation session couldn't catch it

The review we ran was a good review. The failure was structural rather than sloppy.

Pre-development validation checks the feature list. You can look at a list of capabilities and confirm that everyone wants the same ones. But a limit is not a feature. It is a property of a feature, and the moment you write features as rows without writing limits as a column, you have created a document that can show agreement while concealing disagreement.

Both teams looked at the list and saw their own model reflected back. The list confirmed we agreed, and we did agree, on precisely the part it described.

There is a timing property here too. Two documents can describe incompatible systems for months without colliding because they are read one at a time. A build has one value in every field, so the contradiction becomes unavoidable the moment somebody opens it holding the other document in their head.

The honest lesson is not “we should have caught it in review.” Review would not have caught it. Only a comparison would have, and no artifact in our process asked for one.

Nothing raised it earlier. There was no meeting where somebody asked about tier caps and got told we would handle them later, no parked question, and no ignored flag. The limits did not come up until both teams were testing the working build.

Limits are a third artifact

Packaging is a third artifact, and it belongs to neither of the functions that produce its inputs. Product decides what exists. Marketing decides what it costs. The tier structure — which capabilities appear at which price, and with what ceilings — sits downstream of both.

Because it had no natural owner, both functions decided it privately, each reasonably assuming it fell inside their remit, and neither knew the other had done the same.

Unowned artifacts do not go undecided. That is the part I had wrong before this project. I used to think ownership gaps were things that fell through and ended up blank. This one was not blank. It was decided twice, thoroughly, in two documents, by two teams with defensible methods.

The generalization I now carry is simple: any artifact that sits downstream of two functions will be specified twice unless somebody is named to own it. Tier limits are one version. Data-retention rules between engineering and legal or service-level thresholds between delivery and sales can have the same shape.

What it cost, and how it ended

It took a week to reorganize the tiers, and the launch slipped a week.

Two internally valid positions cannot be settled by authority, and more internal research can make the argument worse because each side returns with stronger support for the conclusion it already reached. What ended this one was benchmarking competitor packaging and rebuilding the tiers against an external referent, weighted for competitive advantage and ease of use.

The value was not that competitors were right. The value was that the referent was external: neither marketing nor product owned it, so the argument could turn into a shared research task.

What I check now

Does the artifact everyone signs have a column for the number? If it lists capabilities without limits, thresholds, caps or gates, agreement on the document is agreement about the rows only. Anything living in an unwritten column is being assumed independently by every reader.

Which decisions sit downstream of two functions? That is the shortlist for explicit ownership. Both sides may need the number to do their own work, which makes duplicate specification more likely, not less.

Naming an owner takes a minute. What matters is that the number stops being everybody’s reasonable assumption and becomes somebody’s written decision.

The uncomfortable version

Every artifact in that project was competent. The PRD was thorough. The pricing model was researched. The validation session was properly run and genuinely attended. If you showed me that document set cold, I am not confident I would find the conflict.

That is why I stopped looking only for weak documents and started looking for the seams between strong ones. The failures I keep meeting are often not inside any single artifact. They are in the space between two good ones that were never read against each other.

This article was published in Analyst's Corner on Medium. Read the original on Medium →