Value Proposition Builder
Build a value proposition and prove it survives having a competitor name pasted in.
Builds a primary value proposition and alternatives for one named segment, attaches the proof each claim requires, runs a competitor swap test to expose non-differentiating lines, and surfaces the strongest objection to it.
Ready-to-use prompt
The prompt
Copy it as-is, then swap the bracketed placeholders for your own details before running it.
Role: You are a positioning strategist writing a value proposition.
Context:
- Product: {{product}}
- Segment, described as a job title or situation not a demographic: {{segment}}
- The alternative they use today, including doing nothing: {{alternative}}
- What genuinely changes for them after adoption: {{change}}
- Evidence available: {{evidence}}
- Constraints, pricing model, category conventions: {{constraints}}
Task: Return:
1. One primary value proposition: headline, subhead of under 25 words, and three supporting points
2. For each supporting point, the proof it requires and whether the supplied evidence covers it
3. A swap test — replace your product name with the main competitor. Mark every line that still reads true, those lines are not differentiating
4. Three alternative propositions, each led by a different axis: speed, risk reduction, or capability the alternative lacks
5. The strongest objection to the primary proposition, stated as the buyer would say it
6. A one-sentence version usable as a meta description or ad line
Rules:
- Every claim must name what it replaces or improves on, never state value in the abstract.
- No adjectives that cannot be measured, ban seamless, powerful, innovative and best-in-class.
- If the evidence does not cover a claim, mark it UNPROVEN rather than softening the wording.
- Label supplied facts, inferences, and missing evidence separately.
- Apply the proof check to all three alternative propositions and the final two sentences.
- Scope competitor comparisons to the supplied tier, workflow, and source; label unknowns explicitly.
Finish with: the single sentence a customer would use to describe the product to a colleague.Estimated results
Editor's note
Why this prompt matters
A value proposition is easy to write and hard to defend. The usual output reads well, satisfies everyone in the room, and would read equally well on a competitor site — which means it is a description, not a proposition. This prompt puts that test in the middle of the process rather than leaving it to a sceptical colleague six weeks later. It also refuses to let evidence stay implied: every supporting point is checked against what you actually supplied, and anything unsupported is labelled rather than reworded into something safely vague.
Anatomy
Prompt engineering breakdown
Role
Context
Goal
Constraints
Output format
What you'll get
Expected output
Scenario and evidence boundary
This hypothetical example concerns a review workspace for agency operations leads who collect client sign-off through spreadsheets and email. Adoption puts each approval beside the draft it covers. The scenario assumes version-linked approvals are included in the proposed tier; client reviewers must access the workspace.
Assumed inputs: a walkthrough showing version-linked decisions, a sample approval export, and a comparison showing that a generic task board tracks owners and deadlines but does not bind approval to a draft version. These are illustrative inputs, not verified product facts. There is no evidence of faster delivery or fewer disputes.
Primary proposition
Headline: Replace spreadsheet approval tracking with sign-off tied to the exact draft.
Subhead: Instead of reconciling email replies with spreadsheet rows, agency operations leads can see which draft received client approval.
| Supporting point | Required proof | Coverage in this scenario | |---|---|---| | Replace a spreadsheet’s approval status with a decision attached to a specific draft version. | Walkthrough showing approval retained against its version after a revision. | Covered by the assumed walkthrough. | | Replace searching email threads for sign-off with an export containing reviewer, decision, and draft version. | Sample export containing all three fields. | Covered by the assumed export. | | Reduce approval-related disputes compared with spreadsheet and email tracking. | Comparable dispute records before and after adoption, with causes checked. | UNPROVEN; exclude from publication. |
Swap test
Against the task board described in the supplied comparison:
- Headline: Does not survive; version-linked sign-off is the distinguishing mechanism.
- Subhead: Does not survive for the same reason.
- Point one: Does not survive; the board records status, not version-specific decisions.
- Point two: Does not survive if its export lacks the draft-version link; confirm that limitation.
- Point three: Survives as an unsupported promise either product could make. Remove it.
This establishes a distinction from one substitute, not uniqueness across the category.
Three alternative propositions
- Speed: Find the approved draft faster than searching email threads. UNPROVEN: requires timed retrieval tasks.
- Risk reduction: Reduce wrong-version handoffs compared with spreadsheet tracking. UNPROVEN: requires observed handoff-error records.
- Capability: Attach sign-off to a draft version rather than a task-board status. Supported only within the assumed comparison’s scope.
Buyer objection
“Our clients already reply by email. Why would they adopt another approval step?”
Meta description or ad line
Replace spreadsheet approval tracking with client sign-off linked to the reviewed draft.
Customer-to-colleague sentence
“It shows which draft the client approved instead of making us reconstruct that from email.”
Under the hood
Why this prompt works
The swap test works because it converts a subjective argument into a mechanical one. Paste in the competitor name; if the sentence still reads true, that sentence is not differentiating, and no amount of wordsmithing changes that. Pairing it with the UNPROVEN label closes the other escape route — a model that cannot back a claim will otherwise soften it into an adjective, which feels like a fix and is not one. What survives both passes is short, specific and genuinely yours.
Model fit
Best AI models for this prompt
Claude
Best here. Most rigorous on the swap test and most willing to mark a claim UNPROVEN rather than dilute it.
ChatGPT
Fast and complete; restate the banned-adjective list near the end for best results.
Gemini
Good when you paste several competitor homepages as the comparison set.
When to use
- Before briefing a homepage rewrite, to separate defensible claims from evidence gaps.
- Before launching a tier, to check capability promises against packaging.
- After sales calls stall on differentiation, using actual objection transcripts.
- When entering a segment with a different incumbent workaround.
When not to use
- When no meaningful differentiation exists; investigate the product offer first.
- For internal mission statements rather than buyer-facing claims.
- When the current alternative is unknown; interview buyers first.
- When accuracy depends on competitor functionality; inspect current documentation or test the product.
- When regulated claims require qualified human approval.
Get more from it
Pro tips
- 1
Treat the swap test as a rejection filter: rewrite interchangeable lines around a documented mechanism, not a stronger adjective.
- 2
Choose one segment and one buying situation; separate agencies collecting client approval from teams handling internal review.
- 3
Remove UNPROVEN claims from publishable copy; assign each an evidence owner before testing again.
- 4
Rerun after pricing or packaging changes, checking that the named segment can still access every promised capability.
- 5
Describe doing nothing concretely: who maintains the workaround, and what triggers replacement?
- 6
For a second pass, supply the rejected lines, missing evidence, and buyer objection; request targeted revisions, not more variants.
Don't ship this
Common mistakes
✗ A proposition that reads true for every competitor.
Fix — Run the swap test and delete every surviving line.
✗ Stating value in the abstract.
Fix — Require each claim to name what it replaces or improves on.
✗ Softening an unproven claim instead of removing it.
Fix — Keep the UNPROVEN label; vagueness is not evidence.
People also ask
Frequently asked questions
Q.What is the swap test?
You replace your product name with your main competitor and reread the proposition. Every line that still reads true is describing the category, not differentiating you, so it gets rewritten or removed.
Q.Why write for only one segment?
Because a proposition covering three segments has to be abstract enough to fit all of them, and abstraction is what makes it forgettable. Run it separately per segment and use the strongest one where traffic concentrates.
Q.What should I do with claims marked UNPROVEN?
Either collect the evidence or remove the claim. Rewriting it into something vaguer feels like a fix but simply hides an unsupported statement behind an adjective, which is harder to spot later.