1.3.1 - The One Outcome That Makes This Build Worth Doing in the First Place

The earlier files describe the product (user.md, problem.md, promise.md, positioning.md) and what shipping version one means (success.md, risks.md). goal.md is the one outcome that makes the whole build worth doing in the first place: the change in the user's world you are chasing. success.md tells you when version one is done; goal.md tells you why version one was worth starting.

Main outcome

Is this outcome clear enough to guide every decision?

The call

Choose one outcome first. Otherwise AI generates options that pull the product in multiple directions at once.

Explainer

A main outcome is not a broad aspiration. It is the one result that justifies the work if it actually happens. Until you can point to one user outcome, one reason it matters and one signal that proves it happened, the work is still spread too wide. AI can help explore options, but it cannot choose what matters most.

Make the main outcome concrete

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

• Too vague: This creates more value for users of the AI search tool.
• Concrete enough to test: A content creator completes a search using their saved context and acts on at least one result in the same session, instead of leaving to search elsewhere.

The second version lets two people prioritise the same work from it.

Check the main outcome

• Pass: You can say what changes for the user, why that change matters and what signal will show it is real.
• Fail: If the outcome still sounds like value, impact or improvement without a concrete result, it is not clear enough yet.

Do not move into roadmap, feature or build work until this passes.

What you'll walk away with

In the members-only section below we put this into practice. You'll come out with a main outcome clear enough that every later decision flows from it. Scope, priorities, what you cut and the prompts you write to AI all inherit that clarity.

How it fits together

This is how the work is done in practice on the Cloudflare Workers stack with AI-assisted coding tools. The thoughts and ideas apply equally on any other platform.

The project is a monorepo so the main outcome (alongside the rest of the framework files) lives in one shared knowledge-base/ folder that every app, every package and every AI prompt reads from. The three products in the vibe2value build-in-public stack (subCancel, ghostMarketingFlow and flowRun) each carry this layout, so look at any of them to see the structure in practice.

You write the goal before you commit any scope, so every later trade-off is measured against the change you are actually trying to make in the user's world. The file is called goal.md (not outcome.md) because the runner already inserts an "Outcome" heading at the top of every framework post; one short noun keeps the two distinct. The post calls it a "main outcome" because that is the role the goal plays here: the one user-facing change that justifies the whole build.

If you sign up, this idea continues with how it all fits together, a worked example, how to use it with AI, how to evaluate it on a real change, the risks worth naming and how to mitigate them, the key takeaways and a copy-paste AI prompt you can drop straight into your next chat. Examples are shown on the Cloudflare Workers stack with AI-assisted coding tools; the ideas apply equally on any other platform.