shape
1.1.1 - If You Can't Name the User, You're Guessing What They Want - Name the user definition: say who the user is, what starts the need and what result they are trying to reach.
Shape it. Build it. Launch it.
A way of thinking for building with AI that survives change.
The framework is simple: work through the decisions that matter and write each one down. Those short notes become the documentation you and your AI build from. Pick the stage you are in below, or read all 27 ideas.
Three stages, each with nine decisions.
Three decisions in each stage. Pick the one you are actually facing.
Shape framework ideas
Shape is where you decide what the next change actually is, before anyone writes code. Skip it and you'll build the wrong thing fast.
shape
1.1.2 - Describe the Pain Without Mentioning the Solution - Describe the pain statement: say who is affected, what happens right before the pain appears and what it costs the user or the team.
shape
1.1.3 - The One-Line Promise That Keeps Your Build Honest Throughout - Write the one-line promise: say who it is for, what result it creates and what it is deliberately not trying to do.
shape
1.2.1 - Can You Explain This in 30 Seconds Without Mentioning the Tech? - Explain the 30-second explanation: explain who it is for, what problem it fixes and what useful result appears without adding a second paragraph.
shape
1.2.2 - What Does "Success" Actually Mean for the First Version You Ship? - Define the version one success definition: say what has to happen, how it will be measured and what number or threshold counts as enough.
shape
1.2.3 - The Risks You're Avoiding Naming Are the Ones That Bite You - Name the named risk: say what might fail, who or what it would affect and what action will reduce the damage.
shape
1.3.1 - The One Outcome That Makes This Build Worth Doing in the First Place - Choose the main outcome: say what changes for the user, why that change matters and what signal will show it is real.
shape
1.3.2 - What This Will Not Do (On Purpose) Is Half the Decision - Set the scope boundary: say what stays in, what stays out and why the cut protects the core path.
shape
1.3.3 - Describe One Main Path First, Then Ignore Everything Else - Describe the main path: describe the user, what starts the flow and the exact steps that lead to the outcome.
Build framework ideas
Build is where the change touches running code. The goal isn't to finish; it's to prove the change is real, safe and reversible.
build
2.1.1 - The Only Path Your Prototype Actually Needs to Walk - Define the prototype path: say what the prototype is meant to teach, which path will test it and what signal counts as proof.
build
2.1.2 - Where the User First Feels Value Is Where to Start Building - Find the first value moment: point to the moment the user first feels relief or progress and the step immediately before it.
build
2.1.3 - What This Build Is Meant to Teach You, Not Just to Ship - Name the learning goal: say what you believe, what the build needs to answer and what signal will prove or weaken that belief.
build
2.2.1 - The Routine Work Checklist Nobody Talks About - Define the routine work checklist: say what repeats, who owns it and what done looks like each time.
build
2.2.2 - Buy vs Build Is a Strategy Choice, Not an Engineering One - Make the buy versus build decision: say what the decision is about, why one side wins and which constraint makes the call.
build
2.2.3 - Understanding the Shape of the System Before You Change It - Map the system shape: say which part owns what, what each part depends on and where the important handoff happens.
build
2.3.1 - Where the Real Differentiation Actually Lives in Your Build - Name the real differentiation: point to the advantage, show where the user feels it and say what should remain standard.
build
2.3.2 - Why Cutting Features Is a Design Skill Most Builders Skip - Choose the feature cut: say what stays central, what gets removed and why the product becomes stronger because of that cut.
build
2.3.3 - The One Metric That Proves This Works for Real Users - Define the proof metric: say what the metric is, what user behavior creates it and what threshold counts as enough.
Launch framework ideas
Launch is when the change stops being yours and starts being theirs. Done well, it lasts.
launch
3.1.1 - Why Sharing Early Creates the Learning Your Build Needs - Plan the early sharing plan: say who will see it, what they will see and what question their reaction needs to answer.
launch
3.1.2 - Ask for Signals, Not Opinions, From the People You Trust - Choose the decision signal: point to the behavior or result you need to see and explain what decision it will change.
launch
3.1.3 - Decide in Advance What Would Change Your Mind - Set the decision threshold: say what evidence will trigger change, where it will come from and what action follows.
launch
3.2.1 - The Difference Between Learning and Being Stuck - Name the learning signal: say what question is being answered, what signal will answer it and what decision comes next.
launch
3.2.2 - Explain Your Decisions Before Asking for Review - Explain the review context: say what was decided, what trade-off it created and what question you want reviewers to answer.
launch
3.2.3 - Iteration Should Increase Value, Not Just Add Surface Area - Check the iteration value test: say what changed, what user outcome it is meant to improve and what signal will show that it did.
launch
3.3.1 - What "Ready" Actually Means Once Real Users Are Looking - Define the readiness rule: say what has to be true, how it will be checked and who owns any remaining risk.
launch
3.3.2 - Name the Risks Yourself Before Users Find Them in Production - Name the launch risk: say what might break, what would trigger it and what response reduces the damage.
launch
3.3.3 - Are You Comfortable Putting Your Name on This Build? - Set the ownership threshold: say what is still imperfect, what would happen if it failed and why shipping is still acceptable under those conditions.