1.2.2 - What Does "Success" Actually Mean for the First Version You Ship?

The earlier files (user.md, problem.md, promise.md, positioning.md) describe the product: who it is for, what pain it solves, what it promises, how to explain it. success.md is the objective bar that tells you when version one is done. The earlier files frame what you are building; success.md is how you know when you have built enough to ship.

Version one success definition

Does version one success stay clear before users see it?

The call

Version one succeeds when one measurable user outcome is clear before scope expands. AI can produce fast drafts, but only you can decide what counts as enough.

Sharpen the version one success definition with AI

This is a Shape idea, so the AI move is to Sharpen the version one success definition: run your draft through the prompt below until two people would make the same decision from it. Build and Launch ideas have their own AI moves, building and running the code.

New here? Let your AI do this with you. Paste your problem into Guide me and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt.

Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see how to use vibe2value.

Or copy this prompt into AI chat, replace the bracketed lines with your real version one success definition and keep the instruction exactly as visible here. It helps you put your success.md together by refining your three lines until two people would make the same product decision from them.

There are six ways to work with AI across a build. This idea's AI moves are noted above. See Working with AI for all six and where each fits.

The same idea on a recipe card

Think of knowing when a cake is done. "Bake until ready" tells you nothing, so you either pull it out raw or leave it until it burns. "Golden on top and a skewer comes out clean" is a line anyone can check, so the cake comes out right every time.

Your success definition for version one is that skewer test. Name the one outcome that has to be true, how you will check it and the line that counts as done. Agree it before users taste anything, the same way the skewer test is settled before the cake goes in and not argued over once it is on the table.

The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See the recipe card.

What it really means

Version one success is not a mood. It is a concrete line that says what has to be true for this release to count as enough. Until you can name one outcome, one proof metric and one threshold that counts as success, the work is still too open. AI can help model options, but it cannot decide what enough means.

Make the version one success definition concrete

Compare the broad version with a version you can actually test.

• Too vague: Users find the AI search results useful and keep coming back.
• Concrete enough to test: A content creator completes three searches using their saved context, and at least two of those searches return results they act on within the same session.

The second version lets two people make the same go or no-go call from it.

Check the version one success definition

• Pass: You can say what has to happen, how it will be measured and what number or threshold counts as enough.
• Fail: If success still depends on words like traction, engagement or momentum without a threshold, it is not clear yet.

Do not move into roadmap, launch or growth work until this passes.

What you'll walk away with

You put this into practice with the prompt above. You'll come out with a success definition clear enough that every later decision flows from it. Scope cuts, what you leave out, when you ship and the prompts you write to AI all inherit that clarity.

You write the success definition before you start cutting scope, so you have one objective bar to make trade-offs against instead of "does this feel done?" The file is called success.md because that is what it is: the bar that version one has to clear. The post calls it a "version one success definition" because that is the role it plays at this stage, the moment you commit to what shipping actually means.

Write it down

Your success.md is a real file in your project. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. Write it down once instead of explaining it again.

knowledge-base/shape-build-launch/shape/success.md is just a suggested name and place for this information. The name and the location are just how we organise this type of documentation, not something you have to follow. Call the file and put it wherever suits your project. What matters is that it is written down in a format that is easily understood by both people and the AI.

The .md ending is markdown, a plain text format often used for documents kept in a code repository like GitHub. It is just the common way people store this kind of writing alongside their code.

Writing it down is how you keep good context for your AI. See Keep the signal, not the noise for why this matters across a whole build.

Risk and mitigation

• Risk: Treating activity as success, which hides whether users actually get value in version one.
• Mitigation: Define one measurable success signal first and reject changes that do not improve that signal.

Key takeaway

Do not move forward until you can say what has to happen, how it will be measured and what number or threshold counts as enough.

How to document your version one success definition

Write your version one success definition up in full so your AI has the whole picture: the answer, why you believe it, what you are optimising for, where you might be wrong and the standing instruction it should follow. Keep it in a file with your project like this.

# Version one success definition

## Answer
Outcome: [what has to happen]
Metric: [how it will be measured]
Threshold: [what number counts as enough]

## Evidence
Why you believe this. Conversations, examples, tickets, your own experience.

## Decision
What you are optimising for and what you are saying no to.

## Risk
Where you might be wrong and what would tell you.

## AI instruction
The standing note your AI reads on this project.

Here is one filled in so you can see what good looks like, grounded in the recipe card idea from earlier.

## Answer
Outcome: The cake comes out baked, not raw or burnt
Metric: A skewer pushed into the middle
Threshold: It comes out clean and the top is golden

## Evidence
The last bake looked done on top but was raw in the middle, so looks done is not enough to trust.

## Decision
Optimising for a reliable done test. Saying no to judging by colour alone or by the timer.

## Risk
A clean skewer near the edge can still miss a raw centre. Test the middle, not the side.

## AI instruction
Success for version one is a cake baked through, not raw or burnt. Judge it by a skewer in the centre coming out clean and a golden top, nothing fancier.

Common questions

1. What does success look like for a site rather than a product?
   Not traffic. A handful of the right people finding you without paying for it, joining a list you own and opening what you send. Those are small numbers early and they are the real ones. Your Ghost site is built to make them happen in that order.
2. And for an app on the Cloudflare Workers stack?
   One person completing the one path end to end, without you sitting next to them. Not signups. Not sessions. Completion, because that is the only number that proves the thing works. That is what Build your product aims the first version at.

What now?

Apply it. Guide me turns what you are building into a prompt that walks you through this idea.

Get all 27. The guide is a free coffee-length read with the whole method. Join free and it is yours to download.

Get a hand. Work with me and we will work out together what is worth doing. The first conversation is free.