Why your second path is quietly killing the first - A 30 minute interactive Q&A on why a second main path through your product is rarely free. Examples not tutorials. Places are limited to twenty.
shape :: Forming the problem before committing to a solution.
How talking about your solution makes people stop listening - A 30 minute interactive Q&A on staying in the pain longer than feels natural when you talk about your build. Examples not tutorials. Places are limited to twenty.
A different set of eyes makes all the difference - A single suggestion from a fresh perspective can change everything.
Multi-Sided Systems Blur Faster - The issue wasn’t that the user was vague. It was that there wasn’t just one.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.