Choose a Product Difference the Buyer Can Actually Use
Choose a Product Difference the Buyer Can Actually Use
The approval happened in April. In October, nobody can prove which version of the document was approved.
That is the opening of a deck I want to build, and everything downstream depends on whether I build it honestly. The scenario is invented: a fictional tool that retains every version of a submitted document, and two fictional buyers who face two different conditions. The invented capabilities are only as good as the reasoning I attach to them. Nothing here has been tested with a buyer, and no evidence about audience reaction exists.
One difference earns its place in a pitch when it changes a customer’s task under conditions you can name. For this fictional tool, assume the retained record links each approval to the exact submitted version. Retention alone would not supply that link; it is a separate capability the example depends on.
Start with the buyer task and a credible alternative
The first temptation is to start with the product. The better start is the work.
Draft opening, standard pitch:
Our approval-record tool keeps a complete version history of every submitted document. It eliminates errors, accelerates sign-off, and gives teams total confidence in their approvals.
Revision:
A two-person editorial team shares one file. Revisions arrive by email. When someone asks which version was approved, the current method gives them a filename, a mailbox and a guess. Our approval-record tool retains each submitted version and links its approval to that exact text.
The draft opening announces outcomes. The revision describes a task that a specific buyer would recognise. It also names the credible alternative: the shared file, not a competitor's product. Repeated in a deck, that alternative has to be presented fairly. A buyer using a single shared file may be making a reasonable choice.
This is where April Dunford's product positioning exercise is useful as a thinking frame rather than a proof. Her method separates a capability, the value it might enable, and the customers who care about that value. It asks which customers value the consequence, not whether everyone should. That distinction is the one I keep leaning on. It does not establish that my invented buyers behave as I imagine, and it is not evidence for any competing product claim.
The context in this scenario is illustrative. If I speak about an actual buyer, I have to say whether I observed them or invented them. Mixing the two is how decks quietly start lying.
Show the step between feature and benefit
The relevant capability combines retained submissions with approvals linked to those exact versions. The benefit claim has to follow that mechanism, not jump past it.
Here is the unsupported leap:
Automatic version retention makes teams more productive and reduces review time across the organisation.
Three separate things are being asserted. The tool retains versions—that is the capability. Review time shrinks—that is an outcome, unmeasured here. “Productive” and “across the organisation” are claims that no demonstration in this scenario supports. Each step asks the reader to accept something the deck has not shown.
A narrower version keeps the mechanism visible:
With two editors touching the same document, the approval-linked record lets one editor identify which text was approved at the time. Without that link, retained versions alone still leave the editor reconstructing which one an email or remembered approval referred to.
The action is specific: identify which version was approved. The comparison is specific too—with the capability, one editor matches an approval to a version; without it, that editor reconstructs from loose materials.
What the narrower claim does not say: how long reconstruction takes, whether editors avoid mistakes, or whether the tool improves the process overall. Those would be separate claims requiring separate evidence. If I want to make them, I need customer-task evidence, not a screenshot of the version list.
A useful check: read the benefit sentence and ask whether a reader could point at the exact action being changed. “More productive” cannot be pointed at. “Matches approval to a version” can.
State when the difference matters—and when it does not
The same feature is irrelevant to another buyer. Consider a sole author working on her own drafts. She only needs the latest. She opens the file, edits, saves. No approval record is meaningful to her because no second party must be identified. The version history is a longer list she will never consult.
This is not a weakness in the pitch. It defines who the pitch is for. The capability-to-condition match is the actual argument.
So the deck has to develop both buyers.
Condition A—shared responsibility and revision:
Two or more people touch the document. Approvals arrive separately from edits. Someone outside the immediate process later has to identify which version was approved.
Condition B—sole authorship and latest-state:
One author. Drafting in place. The latest version is the only working document.
Under Condition A, the approval-linked record answers a specific question: which retained text does this approval refer to? Under Condition B, that record adds nothing this fictional buyer needs, and her existing file works fine. Naming the boundary gives the matching buyer a reason to take the comparison seriously.
A tempting shortcut is to make Condition B sound reckless. “Sole authors can't be sure of anything.” That is false and the buyer would know it. Refusing to slander the alternative is what makes Condition A sound like an actual fit rather than a sales setup.
Match each part of the comparison to its evidence
A comparison is not one claim. It is at least four, and each has its own evidence requirement.
The capability claim needs current product-owner documentation or a live demonstration of both parts: retaining a submission and linking an approval to that exact version. “Eliminates review errors” requires different evidence; demonstrating the record does not establish an error rate.
The task claim—what the buyer does in their workflow—needs evidence of that workflow. In this invented scenario, the workflow is invented. In a real deck, the workflow would need observation, interviews, or the buyer's own account. My example cannot carry a real buyer's experience forward. It can only show the shape of the reasoning.
The comparison claim—what the alternative can and cannot do—needs at least the same specificity as the tool claim. If I say the shared-file method has no pinned approval, I should be able to explain why: the file has no record that attaches an approver's sign-off to a frozen version. That is a structural statement about the tool, not a verdict on the people using it.
The consequence claim—that a matching buyer gains something from the capability—is the hardest. It is a claim about one bounded function: identifying which retained version a recorded approval points to. Anything broader than the demonstrated function should be marked as a hypothesis. If the deck says “this reduces litigation risk,” the reader is entitled to ask where that was measured.
A comparison matrix can arrange these claims, but the matrix does not make them true. A proprietary label—“verified approval integrity”—is a name, not evidence. A screenshot showing many rows of versions proves the versions exist, not that anyone needed them.
The line I want in the deck: Follow the approval to the exact version it records. That bounded headline depends on both retention and the approval link. It doesn't claim to eliminate review errors, accelerate legal review, or improve team morale.
The consequence I keep wanting to add
There's a line I keep drafting and then cutting:
This will eliminate approval disputes entirely.
It sounds like the payoff of the whole argument. It is also unsupported in this scenario. Even an approval-linked record cannot stop two people from disputing whether a sign-off was intended or authorized. It gives them a specific record to examine; it does not settle every question about it.
Here is the honest replacement:
A matching buyer can identify which retained version the recorded approval points to. Whether that settles the dispute depends on circumstances the record does not control.
That second sentence is not a weakening. It tells the reader what the tool is responsible for and what belongs to the surrounding process. My expectation, untested, is that buyers respond better to decks that draw that line.
One difference, one task, one condition
The difference worth shipping is narrow. The fictional tool retains each submitted version and links the approval to it. The buyer task it changes is finding the exact text that was approved. The condition under which it matters is a shared document with more than one editor and a later need to identify which version the approval applies to.
Everything outside that condition is a different article, a different buyer, a different claim. A deck that keeps one difference and its condition visible is more useful than a deck that multiplies features and hopes the buyer does the arithmetic.
The invented scenario can only demonstrate reasoning, not proof. Every real capability, every real alternative and every real consequence needs its own current evidence, sitting beside the claim rather than in a footnote. Where the evidence is thin, the language should be thinner too. That is not caution. It is the only version of the claim a buyer can actually use.
Frequently asked questions
What makes a product difference worth putting in a pitch?
It changes a customer's task under conditions you can name. In the example, the tool retains each submitted version and links the approval to that exact version; the task changed is finding the exact text that was approved; the condition is a shared document with more than one editor and a later need to identify which version the approval applies to.
How should a benefit claim relate to the capability?
It should follow the mechanism instead of jumping past it. Retaining versions is a capability; saying teams become more productive or review time shrinks across the organization are separate outcome claims that need their own evidence. A narrower claim says the approval-linked record lets one editor identify which text was approved at the time.
Does the same feature matter to every buyer?
No. A sole author who only needs the latest version has no meaningful use for an approval record because no second party must be identified. Naming that boundary does not weaken the pitch; it defines the condition under which the difference matters. The alternative should not be made to sound reckless.
What evidence does each part of a comparison need?
The capability claim needs current product-owner documentation or a live demonstration of both retention and the approval link. The task claim needs evidence of the buyer's workflow. The comparison claim needs the same specificity as the tool claim. The consequence claim should stay bounded to the demonstrated function; anything broader is a hypothesis.
Can an approval-linked record eliminate approval disputes?
It cannot eliminate them entirely as stated. Even a record that links an approval to a version cannot stop two people from disputing whether a sign-off was intended or authorized. It gives them a specific record to examine; whether that settles the dispute depends on circumstances the record does not control.