Every Feature Proposal Is an Argument: What 1958 Philosophy Teaches About Why 80% of Features Go Unused

Originally published at vibeagentmaking.com

---

What 1958 philosophy teaches about why 80% of features go unused.

Every Monday morning, somewhere in a software company, a product manager stands at a whiteboard and writes four words: We should build SSO.

She has data. Sixty-two percent of enterprise prospects asked for it this quarter. Three lost deals cited it in their post-mortems. Six months later, SSO is live. Eight percent of enterprise customers have turned it on.

Pendo's 2019 Feature Adoption Report found that 80% of features in B2B software are rarely or never used, and 12% drive 80% of daily usage. In large-scale A/B programs, only about 1 in 8 tested ideas ships a material improvement.

This is not a prioritization-framework problem. It's an argumentation problem.

A Framework from the Courtroom

In 1958, S. Toulmin published The Uses of Argument. He decomposed practical argument into six components:

• A claim (the conclusion)
• Grounds (the data supporting it)
• A warrant (the usually-unstated principle that links grounds to claim)
• Backing (evidence that the warrant itself holds)
• A qualifier (the degree of confidence)
• A rebuttal (the conditions under which the claim would fail)

The first three are the minimum viable argument. The other three separate a strong argument from one that only sounds strong.

Over the decades, Toulmin's model became the dominant descriptive framework in rhetoric and legal reasoning. It quietly colonized pockets of software engineering -- Duke CS408 uses it for design decisions, security researchers use it to validate requirements. But product management never picked it up.

The Proposal, Decomposed

Return to Monday's whiteboard. "We should build SSO."

That is the claim. The grounds are the 62% request rate and lost deals. The warrant -- enterprise feature requests are a reliable signal of enterprise revenue potential -- is never stated. Never inspected. And might be wrong.

The rebuttal is absent. No sentence reads: "This feature will have failed if SSO adoption is below X percent within six months." Without that sentence, the feature ships, underperforms, and stays forever.

Where Arguments Die

Product management is a machine for producing hidden warrants:

• Customer requests predict usage. Pendo's 80% stat says otherwise.
• Competitor parity drives retention. More often, the competitor shipped it because their customers asked too, and nobody used it there either.
• Our biggest customer's feedback generalizes. The biggest customer is, by construction, an outlier.

Kohavi's 1/3 rule is the empirical rebuttal: when warrants are actually tested by controlled experiment, roughly one in three ideas is positive, one in three is flat, and one in three is negative.

Why RICE and ICE Aren't Enough

Every prioritization framework in popular use is a partial Toulmin structure:

• RICE scores Reach x Impact x Confidence / Effort. The warrant -- that this formula predicts actual outcome -- is assumed, never stated.
• MoSCoW skips grounds entirely. Pure classification.
• Kano classifies features by satisfaction mechanism. The classification IS the warrant -- and it's visible and testable. This is the rare framework that works.
• Opportunity Scoring makes the warrant explicit: underserved outcomes are where value lives.

Frameworks that make warrants visible (Kano, Opportunity Scoring) are discovery tools. Frameworks that hide warrants (RICE, ICE) are ranking tools. A culture that relies on RICE alone stacks ranked claims on unexamined warrants.

HiPPO Is a Warrant Dispute

The HiPPO rarely brings grounds. She brings a claim and a silent warrant: I have taste. The warrant is unchallengeable because it is never stated.

The fix is not to oppose the HiPPO. It is to require a warrant section in every proposal regardless of seniority. The HiPPO now has to write her reasoning down. She can still win -- but in a form where her reasoning can be cross-examined.

What Changes on Monday

A Toulmin-literate product team does four things differently:

1. Every proposal has a warrant section. One sentence: "These grounds support this claim because [causal theory]."
2. Every proposal has a rebuttal section. One sentence: "This feature will have failed if [condition] by [date]."
3. Reviewers attack the warrant, not the data.
4. Seniority is warrant-transparent. Same template for the HiPPO and the intern.

A small improvement in warrant quality compounds hard against Pendo's 80% baseline. You don't need most proposals to be right. You need fewer wrong proposals to survive contact with a named warrant and an explicit rebuttal.