1.3.2 - What This Will Not Do (On Purpose) Is Half the Decision

promise.md already names one explicit boundary on what the product is deliberately not trying to do. scope.md is the broader inventory: every feature, edge case or workflow being kept out of version one, with the reason each cut protects the core path. promise.md was the headline boundary; scope.md is the detailed map.

Scope boundary

Is this on-purpose exclusion clear enough before you build?

The call

Say what this will not do before scope pressure makes the decision for you. AI will happily expand a product with no boundary.

Sharpen the scope boundary with AI

This is a Shape idea, so the AI move is to Sharpen the scope boundary: 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 scope boundary and keep the instruction exactly as visible here. It helps you put your scope.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 a host deciding what not to cook. "No starter and no homemade dessert tonight so the main course is genuinely good" is a deliberate cut that protects the meal. Try to cook five courses to impress and each one suffers, the kitchen overflows and you never actually sit down with your guests.

Your scope boundary is that list of what you are leaving off the menu on purpose. Say what is in, what is out and why each cut makes the main thing stronger. Decide it before the pressure to add "just one more dish" makes the choice for you, the way a good host commits to one course done well.

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

A scope boundary is not a vague future note. It is a deliberate statement of what stays out so the main path can stay strong. Until you can say what is in, what is out and why the cut makes the product stronger, the scope is still too loose. AI can help generate options, but it will happily expand a product with no boundary.

Make the scope boundary concrete

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

• Too vague: Version one will stay focused and not do too much.
• Concrete enough to test: Version one will help a content creator search using their saved context. It will not support multiple saved contexts per user yet because that would complicate the core search flow before it is proven.

The second version lets two people cut the same feature from it.

Check the scope boundary

• Pass: You can say what stays in, what stays out and why the cut protects the core path.
• Fail: If the boundary still depends on later, flexible or maybe, it is not a real boundary yet.

Do not move into feature, build or roadmap 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 scope boundary clear enough that every later decision flows from it. Estimates, priorities, what waits for version two and the prompts you write to AI all inherit that clarity.

You write the scope boundary before you accept any new request, so every "could we also..." gets compared against the cut that already exists. The file is called scope.md because that is what it is: the scope of version one, with the deliberate cuts named. The post calls it a "scope boundary" because the act here is drawing the line, not enumerating every possible feature.

Write it down

Your scope.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/scope.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: Weakening intentional exclusions after new requests arrive, which blurs purpose and slows decisions.
• Mitigation: Define one exclusion rule up front and require clear user-impact evidence before any exception is allowed.

Key takeaway

Do not move forward until you can say what stays in, what stays out and why the cut protects the core path.

How to document your scope boundary

Write your scope boundary 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.

# Scope boundary

## Answer
Keep in: [what stays in scope]
Leave out: [what stays out]
Why the cut helps: [why the cut protects the core path]

## 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
Keep in: The main course
Leave out: The starter and the homemade dessert
Why the cut helps: The main course is genuinely good instead of three rushed ones

## Evidence
The last time I attempted three courses the main came out rushed and lukewarm while I plated the dessert.

## Decision
Optimising for one genuinely good main course. Saying no to a starter and a homemade dessert this time.

## Risk
Guests might expect a full three courses. If that matters, buy a simple dessert rather than making one.

## AI instruction
The scope is the main course only, on purpose. Leave out the starter and the homemade dessert so the main is genuinely good.

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.