foundation-build-risk-review

Name: foundation-build-risk-review
Author: product-on-purpose

486stars64forks

How to install foundation-build-risk-review?

product-on-purpose/pm-skills/foundation-build-risk-review

$npx -y skills add product-on-purpose/pm-skills --skill foundation-build-risk-review

Installs into the current project.

Summary

Runs a fast pre-build risk review on a product idea, feature request, or scope change, naming the single assumption most likely to make it fail and returning a clear verdict (build small, validate first, pivot first, or don't build yet) with a no-code validation step. Use before

Files · 1

View on GitHub

SKILL.md

1	<!-- PM-Skills \| https://github.com/product-on-purpose/pm-skills \| Apache 2.0 -->
2	<!-- Adapted from bin1874/before-you-build-skill (Apache-2.0), repositioned PM-neutral. -->
3	# Build Risk Review
4
5	Don't build it yet. First name the one assumption most likely to make it fail.
6
7	`foundation-build-risk-review` is a fast, pre-commitment gate for product decisions. Given an idea, a feature request, or a scope change, it returns a Build Risk Review: the single biggest risk, the evidence behind it, a verdict, and a concrete no-code validation step, then routes you to the skill that does the next piece of work. It is a foundation hub: its job is to triage and dispatch, not to duplicate the deeper skills.
8
9	## Hard gate
10
11	Do not write code, scaffold a project, recommend a stack, or design implementation. First answer three things: should this be built, what is most likely to make it fail, and what must be validated before committing.
12
13	If the user says the work is for learning, a portfolio, or internal practice, do not judge it by market standards; still flag scope and clarity risks.
14
15	## When to Use
16
17	- A product idea, MVP, or new bet is about to turn into build work.
18	- A feature request or scope change has arrived and you need to separate real demand from a polite ask, founder anxiety, or competitor-copying.
19	- Someone wants a fast "should we build this?" verdict before a PRD, roadmap row, or ticket exists.
20
21	## When NOT to Use
22
23	\| If the ask is \| Use instead \|
24	\|---\|---\|
25	\| A launched product's pivot-or-persevere call, weighing usage or market data \| `iterate-pivot-decision` \|
26	\| You have chosen the assumption and need to design the test \| `define-hypothesis` \|
27	\| Framing a confirmed problem for the team or leadership \| `define-problem-statement` \|
28	\| The full nine-block business model, not a single-risk read \| `foundation-lean-canvas` \|
29	\| Ranking many features or initiatives against each other \| `define-prioritization-framework` \|
30
31	The boundary that matters most: this skill is forward-looking and pre-commitment (low or no data); `iterate-pivot-decision` is retrospective and post-launch (it weighs market feedback on something already shipped).
32
33	## Modes (route first; state the mode at the top)
34
35	1. Pre-build - a new idea, product, or MVP not yet built. The usual primary risks: demand and distribution.
36	2. Feature-change - a feature request, scope expansion, requirement change, or competitor-copy on an in-progress product. The primary tool here is the demand hierarchy.
37
38	If the product is already launched and the question is whether to change direction, hand off to `iterate-pivot-decision`. If the request is too broad to review responsibly, ask exactly one clarifying question (complete the sentence: "this is for [who] in [situation] to solve [problem]"), then proceed. Never run a long questionnaire; at most two questions before a constrained review.
39
40	## The review (the contract)
41
42	Produce a Build Risk Review with these parts:
43
44	1. Biggest risk (`R1`). Exactly one primary risk, tagged from `references/risk-taxonomy.md`. Not a long inventory. Add at most three to five supporting risks (`R2`, `R3`, ...).
45	2. Demand level (feature-change mode). Place the request on the hierarchy: L0 founder anxiety or "competitors have it"; L1 one user asked; L2 repeated asks, no behavior proof; L3 workflow blocker; L4 revenue or retention blocker. Build-now is usually justified only at L3 or L4.
46	3. Evidence ledger. List the signal that exists and grade each entry on the strength ladder in `references/risk-taxonomy.md`. Likes, compliments, waitlists, and market-size numbers are NOT demand. Real files, booked calls, payment, repeated manual use, or switching from an existing alternative are.
47	4. Verdict (exactly one): Build small / Validate first / Pivot first / Don't build yet. Do not use "Kill".
48	5. Validation step. A specific, no-code or low-code next action (talk to the ten users who do X; manually deliver the result for three of them; collect a preorder, paid call, or deposit), never generic advice like "build an MVP" or "do user research".
49	6. Routing. Send the user to the skill that does the next piece of work (see below).
50
51	Be skeptical but

People who liked this also viewed

6 picks

Type

foundation-build-risk-review

486stars64forks

View on GitHub

How to install foundation-build-risk-review?

product-on-purpose/pm-skills/foundation-build-risk-review

$npx -y skills add product-on-purpose/pm-skills --skill foundation-build-risk-review

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	<!-- PM-Skills \| https://github.com/product-on-purpose/pm-skills \| Apache 2.0 -->
2	<!-- Adapted from bin1874/before-you-build-skill (Apache-2.0), repositioned PM-neutral. -->
3	# Build Risk Review
4
5	Don't build it yet. First name the one assumption most likely to make it fail.
6
7	`foundation-build-risk-review` is a fast, pre-commitment gate for product decisions. Given an idea, a feature request, or a scope change, it returns a Build Risk Review: the single biggest risk, the evidence behind it, a verdict, and a concrete no-code validation step, then routes you to the skill that does the next piece of work. It is a foundation hub: its job is to triage and dispatch, not to duplicate the deeper skills.
8
9	## Hard gate
10
11	Do not write code, scaffold a project, recommend a stack, or design implementation. First answer three things: should this be built, what is most likely to make it fail, and what must be validated before committing.
12
13	If the user says the work is for learning, a portfolio, or internal practice, do not judge it by market standards; still flag scope and clarity risks.
14
15	## When to Use
16
17	- A product idea, MVP, or new bet is about to turn into build work.
18	- A feature request or scope change has arrived and you need to separate real demand from a polite ask, founder anxiety, or competitor-copying.
19	- Someone wants a fast "should we build this?" verdict before a PRD, roadmap row, or ticket exists.
20
21	## When NOT to Use
22
23	\| If the ask is \| Use instead \|
24	\|---\|---\|
25	\| A launched product's pivot-or-persevere call, weighing usage or market data \| `iterate-pivot-decision` \|
26	\| You have chosen the assumption and need to design the test \| `define-hypothesis` \|
27	\| Framing a confirmed problem for the team or leadership \| `define-problem-statement` \|
28	\| The full nine-block business model, not a single-risk read \| `foundation-lean-canvas` \|
29	\| Ranking many features or initiatives against each other \| `define-prioritization-framework` \|
30
31	The boundary that matters most: this skill is forward-looking and pre-commitment (low or no data); `iterate-pivot-decision` is retrospective and post-launch (it weighs market feedback on something already shipped).
32
33	## Modes (route first; state the mode at the top)
34
35	1. Pre-build - a new idea, product, or MVP not yet built. The usual primary risks: demand and distribution.
36	2. Feature-change - a feature request, scope expansion, requirement change, or competitor-copy on an in-progress product. The primary tool here is the demand hierarchy.
37
38	If the product is already launched and the question is whether to change direction, hand off to `iterate-pivot-decision`. If the request is too broad to review responsibly, ask exactly one clarifying question (complete the sentence: "this is for [who] in [situation] to solve [problem]"), then proceed. Never run a long questionnaire; at most two questions before a constrained review.
39
40	## The review (the contract)
41
42	Produce a Build Risk Review with these parts:
43
44	1. Biggest risk (`R1`). Exactly one primary risk, tagged from `references/risk-taxonomy.md`. Not a long inventory. Add at most three to five supporting risks (`R2`, `R3`, ...).
45	2. Demand level (feature-change mode). Place the request on the hierarchy: L0 founder anxiety or "competitors have it"; L1 one user asked; L2 repeated asks, no behavior proof; L3 workflow blocker; L4 revenue or retention blocker. Build-now is usually justified only at L3 or L4.
46	3. Evidence ledger. List the signal that exists and grade each entry on the strength ladder in `references/risk-taxonomy.md`. Likes, compliments, waitlists, and market-size numbers are NOT demand. Real files, booked calls, payment, repeated manual use, or switching from an existing alternative are.
47	4. Verdict (exactly one): Build small / Validate first / Pivot first / Don't build yet. Do not use "Kill".
48	5. Validation step. A specific, no-code or low-code next action (talk to the ten users who do X; manually deliver the result for three of them; collect a preorder, paid call, or deposit), never generic advice like "build an MVP" or "do user research".
49	6. Routing. Send the user to the skill that does the next piece of work (see below).
50
51	Be skeptical but

People who liked this also viewed

6 picks

Type