Reposition Around The Outcome

Shift an offer described by its features and deliverables into one named by the result the buyer is actually paying for.

Free moderate Offer Improvement Recipes

What it adds

Fixes the offer sold as a list of components, forcing buyers to translate features into benefit before they can judge whether it is worth the price. The AI builder extracts the end state hidden inside the current deliverables and objection notes, then rebuilds the headline, structure, and proof around that end state. The outcome is an offer buyers evaluate on result rather than on inventory.

What your builder is told to do

The actual instructions, in order.

1
Inspect the source files and run every deliverable through a so-that chain until it reaches a state the buyer would recognise as their own goal. Record the chain for each deliverable.
2
Identify the single end state most chains converge on and write it as one sentence in the buyer's language, avoiding internal terminology found in the delivery notes.
3
Define the before state with equal precision — where the buyer is today, in observable terms drawn from the objection list — because the offer's value is the distance between the two states.
4
Separate structural changes from copy changes: structural work is reordering the page so the outcome precedes the components, regrouping deliverables under the outcome they serve, and renaming the offer; copy work is the headline, the subheadline, and rewriting each deliverable as a contribution to the end state.
5
Rebuild the deliverable list so each item is stated as what it lets the buyer do, with the format named second rather than first.
6
Realign the proof section so any existing evidence in the source files supports the outcome claim rather than the feature claim, without adding new evidence.
7
Specify responsive behavior: on mobile, the outcome headline and before-state line occupy the first screen with components below the fold; on tablet, before and after states render as paired columns above the component list; on desktop, outcome, before state, and components appear in a single scanned view with the outcome typographically dominant.
8
Define tracking: measure time on the first screen, scroll depth past the outcome section, conversion rate, and the mix of pre-sale questions asking what-is-it versus what-will-it-do. Rollback rule — restore feature-forward structure if conversion falls and question volume shifts toward buyers not understanding what they receive.

Edge cases it handles

The things an agent skips when you only say "build a reposition around the outcome".

Do not promise an outcome the source files do not support; if the deliverables cannot produce the end state alone, state the buyer's required input alongside it.
Preserve every factual specification; components move down the page, they do not disappear.
Where buyers genuinely shop by specification, keep a complete component list accessible in one click rather than removing it.
If different buyer segments in the source files pursue different end states, pick one and note the others rather than blending them into a vague composite.
Avoid outcome language that implies a guarantee, a timeframe, or a result level not documented in the source files.

Definition of done

Your builder is required to check every one of these before reporting the work finished.

A so-that chain is recorded for every deliverable and the converging end state is written in one sentence.
The before state is defined in observable terms drawn from the source files.
Before and after page structures are documented, showing what moved and what was renamed.
The complete component list remains accessible within one interaction.
Mobile, tablet, and desktop layouts for the outcome-first structure are each specified.
Question-mix tracking and a rollback trigger tied to buyer confusion are defined before launch.
The builder reports which source files it used and flags any outcome claim it could not ground in those files.

Related offer files

Offer Improvement Recipes

Create An Order Bump

Insert a single low-friction add-on at checkout that completes the purchase without pulling attention off the main decision.

Offer Improvement Recipes

Split Into Tiers

Break a single take-it-or-leave-it offer into tiers that capture buyers at different budgets without gutting the core promise.

Offer Improvement Recipes

Repackage As A Bundle

Merge scattered standalone products into one coherent bundle solving a complete problem, priced below the sum of its parts.

How it works

1

Copy the link

Grab the Markdown blueprint URL for this offer type.
2

Give it to your builder

Paste it into Claude Code, Cursor, Codex, or whatever AI builder is already working in your app.
3

It maps, then builds

Your agent reads the blueprint first, then builds the offer into your app around the product, audience, and stack.

Works with your stack

These blueprints are written to adapt. They tell the agent to detect your framework, match your existing design system, and use your source files instead of guessing the offer.

Need it tighter than that? Customize the offer file and tell it exactly which source docs and stack to use.