shape
problemuser
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+build+launch :: a simple way to think about complex work.
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
problempain
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
problempromise
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
organiseclarity
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
organisegoals
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
organiserisk
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
strategyoutcomes
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
strategyscope
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
strategyuser-journey
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
prototypefocus
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
prototypevalue
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
prototypelearning
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
assemblecommodity
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
assemblebuy-vs-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
assemblearchitecture
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
differentiatorvalue
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
differentiatorsimplicity
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
differentiatormetrics
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
communityfeedback
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
communityfeedback
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
communicationlearning
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
clarityassist
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
assistreview
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
assistiteration
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
managedreadiness
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
managedrisk
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
managedconfidence
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.