Specific Promise, Vague Delivery
- Difficulty
- Easy
- Time to result
- ~weeks to results
- Steps
- 6
- Confidence
- —
The most common trap Jay Clouse sees in membership builders is getting granular about delivery on the sales page. Listing weekly calls, daily co-working and monthly workshops turns the offer into a rigid contract you must fulfil for as long as people are subscribed, even after you learn that half of it does not work. His rule is to separate the promise from the delivery: make the outcome promise so compelling, and back it so thoroughly with member success stories, that you retain the freedom to redesign the programming over time. Members should not arrive with a preconceived notion of how they will get the result, only confidence that you will help them get it.
Origin
Extracted from Deep Dive with Ali Abdaal
How to run it
- 1
Write the promise as an outcome
State the transformation in one line a member can repeat. 'Peloton for productivity' works because it makes the outcome and the mechanism-feel obvious without specifying any session.
Pro tip Test the promise by asking whether a member could say 'yes, I did this' twelve months later.
- 2
Describe delivery in categories, not schedules
Say you have facilitated sessions and facilitators who help with goal planning and accountability. Do not say there is a two-hour session every morning.
Pro tip Every noun on the sales page should survive you changing the calendar entirely.
Watch out A named frequency on a sales page becomes a promise you will feel unable to walk back, even if nobody would complain.
- 3
Fill the page with success stories instead of features
The sales page is essentially a promise plus proof. Testimonials with specific outcomes from people the reader identifies with are more persuasive than any feature stack.
Pro tip Unscripted video testimonials read as honest in a way written copy no longer can.
- 4
Keep the real programming plan private
Maintain an internal roadmap of what you will actually run. Share it with members inside the community rather than with prospects on the sales page.
Pro tip Frame the community itself as a lab so members expect the programming to evolve.
- 5
Right-size the programming once it is live
After a few months, cut sessions nobody attends, move weekly things to monthly, and double down on what drives attendance. This is only possible if you never sold the schedule.
Watch out Cutting something you did promise on an annual membership creates a refund and trust problem, not just an operational one.
- 6
Communicate changes as experiments
Tell members you take feedback on board and will change things as you go, so adjustments strengthen the brand promise instead of undermining it.
Pro tip Optically it is far better to expand offerings over time than to contract them.
In the wild
Ali described selling annual memberships to the YouTuber Accelerator at $5,000 with the specific deliverables written on the sales page. Three months in, the team realised one of the promised components was not actually the thing members needed, but it had been publicly promised to people who had bought an annual membership, so they had to keep delivering it. That experience was a large part of why he felt pressure to get the productivity lab right from day one.
→ Months of delivering a component the team knew was not working, purely because it was listed on the page.
Ali arrived with a detailed delivery plan: facilitated weekly reviews, monthly planning sessions, quarterly goal-setting and daily Zoom co-working with RSVPs. Jay's advice was to keep the peloton-for-productivity promise on the page and describe only that there are facilitated sessions and facilitators who help with goal planning and accountability, leaving the actual cadence free to change.
→ A sellable offer that preserves the freedom to redesign the calendar after launch.
Common mistakes
Selling the calendar
Publishing exact session frequencies converts an experiment into a contract. Fourteen months in you may not want to lead that weekly session, but members bought it.
Confusing a feature stack with a value proposition
Granular delivery detail feels like value but it primes members to judge you on logistics rather than on the transformation they actually wanted.
Being vague about the promise too
Vagueness belongs in the delivery, not the outcome. Without a specific, tangible promise there is nothing for testimonials to confirm.
From the transcript
“the better thing to do is to make the promise and the offer so good that you can figure out the right delivery over time”
“the less you specifically promise from a delivery standpoint in terms of like the actual programming the more flexibility you have to rightsize the programming…”
“everybody has a plan until you get punched in the mouth”
From the episode
How To Build An Online Community - Jay Clouse
Jay Clouse