2 min lesson
Anchor everything to one narrative
Take this situation: "A teammate sends you a launch video showing Cursor flawlessly refactoring a clean demo repo on the first try. What's your concern and what would you change?" Lead with your decision, then add the reason.
Step 1 of 2
Anchor everything to one narrativestory first, assets second
Write the one-sentence story before you write anything else. If the blog, the landing page, the demo and the video each tell a slightly different story, the launch reads as noise. When they all serve the same spine, the repetition compounds across channels into something a developer remembers.
- For whom
- The specific developer who feels this pain today - be concrete, not "all developers"
- The job
- The thing they're trying to get done that the feature now makes faster or possible
- The shift
- What changes in their workflow - the before-and-after a skeptic can verify
- The proof
- The demo or number that makes the claim survive a developer's BS detector
If you can't fill all four rows, the feature isn't ready to position. Fix that before you open the blog draft.
Staged demos are the fastest way to lose a developer audience. If your video shows Cursor one-shotting a flawless refactor on a toy repo, every engineer watching assumes you cherry-picked it - and they're usually right. Show it working on something real, including the moment you guide it. Authentic-but-imperfect beats polished-but-hollow with this audience every time.
“I'd write the one-sentence story first - who it's for, the job, the workflow shift, the proof - and make the blog, landing page, demo and video all serve that one spine. I write those assets myself; that's the role. And the demo is Cursor doing a real task on a real repo with me driving, not a staged clip, because this audience detects a cherry-picked demo instantly and it costs you more credibility than the feature buys.”
Learn more
Optional practice