{
  "schema": 1,
  "skill": "foundation-build-risk-review",
  "runs_per_query": 3,
  "trigger_threshold": 0.5,
  "queries": [
    {
      "q": "Before I start building this SaaS idea, tell me the one thing most likely to make it fail and whether it's worth doing at all",
      "expect": "trigger",
      "split": "train"
    },
    {
      "q": "A customer asked us to add SSO. Should we build it now, or is that premature?",
      "expect": "trigger",
      "split": "train",
      "notes": "Feature-change mode; demand-hierarchy call before committing"
    },
    {
      "q": "We're thinking of expanding our note-taking utility into a full platform; pour cold water on it before we commit",
      "expect": "trigger",
      "split": "train"
    },
    {
      "q": "Is this AI meeting-summarizer idea worth building, or should I validate demand first?",
      "expect": "trigger",
      "split": "train"
    },
    {
      "q": "Sales keeps asking for a bulk-export feature; sanity-check whether we should build it before I write it up",
      "expect": "trigger",
      "split": "train"
    },
    {
      "q": "Should we honor this feature request, or is it scope creep that hides a harder problem?",
      "expect": "trigger",
      "split": "train"
    },
    {
      "q": "I want to build a landing page and MVP for a freelancer-invoicing tool; what's the biggest risk and what should I validate first?",
      "expect": "trigger",
      "split": "validation"
    },
    {
      "q": "Competitors just shipped a Kanban view; should we copy it, or is that a trap?",
      "expect": "trigger",
      "split": "validation"
    },
    {
      "q": "Give me a build, validate, or cut verdict on adding a native mobile app to our web product",
      "expect": "trigger",
      "split": "validation"
    },
    {
      "q": "Before we put this on the roadmap, what assumption would kill it and how do I test that cheaply?",
      "expect": "trigger",
      "split": "validation"
    },
    {
      "q": "Write up the problem statement for our mobile checkout drop-off, with user impact and success criteria",
      "expect": "no-trigger",
      "split": "train",
      "near_miss_of": "define-problem-statement",
      "notes": "Framing a confirmed problem, not a build verdict"
    },
    {
      "q": "We launched six months ago, growth has stalled, and the data shows users churn after week two; document whether we should pivot or persevere",
      "expect": "no-trigger",
      "split": "train",
      "near_miss_of": "iterate-pivot-decision",
      "notes": "Post-launch pivot-or-persevere with usage data: the closest boundary"
    },
    {
      "q": "Build me a full lean canvas for this new product thesis across all nine blocks",
      "expect": "no-trigger",
      "split": "train",
      "near_miss_of": "foundation-lean-canvas",
      "notes": "Full business-model canvas, not a single-risk gate"
    },
    {
      "q": "Run RICE and MoSCoW over these twelve feature requests and show me where they disagree",
      "expect": "no-trigger",
      "split": "train",
      "near_miss_of": "define-prioritization-framework",
      "notes": "Ranking a list, not one build decision"
    },
    {
      "q": "We believe onboarding emails will lift activation; turn that into a testable hypothesis with success metrics",
      "expect": "no-trigger",
      "split": "train",
      "near_miss_of": "define-hypothesis",
      "notes": "Designing the test for a chosen assumption"
    },
    {
      "q": "Our paid product has flat retention and the market shifted under us; make the persevere-or-pivot call with the evidence",
      "expect": "no-trigger",
      "split": "train",
      "near_miss_of": "iterate-pivot-decision",
      "notes": "Second post-launch pivot near-miss (closest neighbor)"
    },
    {
      "q": "Reframe this drifted project around the original problem we set out to solve, for leadership",
      "expect": "no-trigger",
      "split": "validation",
      "near_miss_of": "define-problem-statement",
      "notes": "Re-anchoring a problem, not a build verdict"
    },
    {
      "q": "Stress-test our existing business model and compare two strategic options side by side",
      "expect": "no-trigger",
      "split": "validation",
      "near_miss_of": "foundation-lean-canvas",
      "notes": "Business-model stress-test across the canvas blocks"
    },
    {
      "q": "Debug this null pointer exception showing up in our checkout service logs",
      "expect": "no-trigger",
      "split": "validation",
      "notes": "Unrelated engineering ask"
    },
    {
      "q": "Find me a hotel near the Berlin conference center for next week",
      "expect": "no-trigger",
      "split": "validation",
      "notes": "Unrelated logistics ask"
    }
  ]
}

<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->
# Example: Build Risk Review (feature-change mode)

A worked case showing the full artifact. The scenario is a B2B ecommerce platform whose sales team is pushing to build single sign-on (SSO) after two enterprise prospects raised it. All merchant and deal specifics are `[fictional]`.

---

## Scenario

> The input the skill received.

"Two enterprise prospects asked about SSO in the last month, and Sales says we'll lose them without it. They want me to put SSO on next sprint. We're a 140-merchant B2B catalog platform; most of our paying accounts are mid-market. Should we build SSO now?"

## Prompt

"Run a build risk review on this SSO request before I commit a sprint."

---

# Build Risk Review: SSO for enterprise merchant accounts

**Mode:** Feature-change  |  **Date:** 2026-06-22

## Verdict

**Validate first.** SSO is a plausible enterprise requirement, but the current signal is two prospects raising it in calls, not a confirmed deal-blocker. Committing a sprint now would build on an L2 signal and pull capacity from the activation work that the data says actually moves retention.

## Biggest risk

- **R1 `feature-fit`:** the request is being read as an L4 deal-blocker when the evidence only supports L2 (repeated asks, no behavior proof). Neither prospect has put "no SSO = no deal" in writing, and no current paying merchant has churned over its absence. Building on that is the feature-treadmill trap: it feels urgent because Sales is loud, not because the data says it changes who pays.
- **R2 `distribution`:** even if built, SSO does not by itself reach more enterprise buyers; the constraint upstream is a thin enterprise pipeline `[fictional: 2 active prospects]`, which a feature does not fix.
- **R3 `trust`:** SSO is a trust-tier feature (identity, provisioning), so a thin first version that mishandles SCIM or de-provisioning would do more reputational harm than not having it, raising the real cost above the sprint estimate.

## Demand level

**L2 - repeated asks, no behavior proof.** Two prospects mentioned SSO in sales calls `[fictional]`. That is more than one ask (above L1) but neither has made it a contractual go/no-go, and zero of 140 paying merchants `[fictional]` have raised or churned over it. It is not yet an L3 workflow blocker (merchants complete the core catalog job today without SSO) or an L4 revenue blocker (no signed dependency).

## Evidence ledger

| Signal | Strength | What it does or does not prove |
|---|---|---|
| Two enterprise prospects raised SSO in calls `[fictional]` | medium | real interest from the target segment; not a commitment |
| Sales says "we'll lose them without it" | weak | a forecast, not a written requirement; Sales is incentivized to unblock deals with product |
| "Enterprise buyers expect SSO" (category articles) | weak | a category norm, not proof for these two deals |
| 0 of 140 paying merchants cite SSO `[fictional]` | counter-signal | no retention or activation pressure from the existing base |
| Activation A/B in flight shows onboarding checklist lifts week-2 retention `[fictional]` | strong (for the alternative) | the capacity SSO would consume has a measured return elsewhere |

## Validation plan

1. **Make the deal dependency real.** Ask both prospects to confirm in writing that SSO is a go/no-go requirement with a target date. Pass bar: at least one returns a signed contingency. If neither does, the L4 framing is false and this drops to Defer.
2. **Price the trust tier.** Time-box a half-day spike on the SCIM / de-provisioning surface to replace the sprint estimate with a real one; a trust-tier feature is rarely a one-sprint build.
3. **Hold the line on activation.** Do not pause the in-flight activation A/B; it has a measured retention return that the SSO request does not.

## Routing

-> `define-hypothesis` to frame "SSO unblocks >= $X enterprise ARR this quarter" as a testable claim with a metric and a date, then `define-prioritization-framework` to rank it against the activation work once the spike gives a real cost. If a signed contingency comes back, re-run this review; a confirmed L4 flips the verdict to Build small and routes to `define-problem-statement` -> `deliver-prd`.

## Sources

- All merchant counts, prospect details, and experiment results are `[fictional]` and illustrative.
- Demand-level and evidence-strength definitions: `references/risk-taxonomy.md`.

---

## Why not the other verdicts

> Included here for teaching; a real artifact does not need this section.

- **Build small** would be right at L3/L4 - if a prospect signs an SSO contingency, or a paying merchant churns over it. Today neither is true.
- **Don't build yet** would be too strong: the segment interest is real and SSO is a normal enterprise requirement, so the wedge is not wrong, only unproven.
- **Pivot first** does not apply: nothing here questions the product's direction, only the timing of one feature.

<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->
# Risk taxonomy, demand hierarchy, and evidence ladder

The three structures the review runs on. They are the skill's value: a generic prompt does not impose them.

## Risk types

Each type names where a build is most likely to fail, in the library's vocabulary, plus where to route for a deeper look. Tag `R1` (and supporting risks) with one of these.

| Tag | The failure mode | What it looks like | Routes to |
|---|---|---|---|
| `demand` | nobody wants it enough to change behavior | no repeated pull; no urgency over the current workaround | `discover-market-sizing` / `define-hypothesis` |
| `distribution` | you cannot reach the first users | no named channel; "we'll launch and they'll come" | `foundation-lean-canvas` (Channels block) |
| `positioning` | the wedge is too broad, crowded, or generic | "for everyone"; indistinct from incumbents | `discover-competitive-analysis` |
| `monetization` | the buyer or payment model does not fit | subscription for a low-frequency utility; buyer is not the user | `foundation-lean-canvas` (Revenue block) |
| `retention` | users do it once and do not return | a one-time utility framed as ongoing | `measure-experiment-design` |
| `trust` | users will not connect data, accounts, or money | privacy, security, or migration friction | `define-problem-statement` |
| `feature-fit` | the change does not move usage, payment, or retention | scope creep, feature treadmill, competitor-copy, one user asked | `define-prioritization-framework` |

## Demand hierarchy (feature-change mode)

Place a feature request on the ladder. Build-now is usually justified only at L3 or L4; below that, validate or defer.

- **L0 - founder anxiety.** "Competitors have it" or "it feels incomplete." No user signal.
- **L1 - one ask.** A single user requested it; no proof it affects usage, payment, or retention.
- **L2 - repeated asks.** Several target users ask, but there is no behavior proof yet.
- **L3 - workflow blocker.** Users cannot complete the core job without it.
- **L4 - revenue or retention blocker.** Users refuse to pay, churn, or fail activation because it is missing.

## Evidence strength ladder

Grade every entry in the evidence ledger. Do not let weak signal carry a verdict.

- **Weak (not demand):** likes, compliments, waitlist signups, survey "would use", market-size numbers.
- **Medium:** repeated unsolicited requests, competitor traction in the exact wedge, a manual workaround users maintain.
- **Strong:** real files or data handed over, booked calls, a preorder or deposit, repeated manual use, switching away from an existing paid alternative.

The verdict should track the strongest honest signal, not the most dramatic-sounding risk.

<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->
# Routing map

The Build Risk Review is a gate that dispatches into the rest of the library. Always name a routing target so the user knows the next move.

## By verdict

| Verdict | Means | Route to |
|---|---|---|
| **Build small** | worth a narrow first version | `define-problem-statement`, then `deliver-prd` / `deliver-user-stories` |
| **Validate first** | direction plausible; demand, payment, or distribution unproven | `define-hypothesis`, then `measure-experiment-design` |
| **Pivot first** | the area is plausible but the current wedge is too broad, crowded, or weak | `foundation-lean-canvas` (re-frame the model) |
| **Don't build yet** | too vague, no reachable user, or solved well enough already | stop; or `discover-competitive-analysis` / `discover-market-sizing` for an evidence check |

## By risk type

When a specific risk dominates and warrants a deeper look, route per the "Routes to" column in `references/risk-taxonomy.md` (e.g. a `monetization` risk routes to `foundation-lean-canvas` Revenue; a `demand` risk to `discover-market-sizing`).

## Several competing requests

If the input is not one build decision but a set of requests to rank, hand off to `define-prioritization-framework` (RICE / ICE / MoSCoW). This skill judges one decision's risk of failure; it does not rank a list.

## Boundaries (NOT this skill's job)

- A launched product's pivot-or-persevere call, weighing market feedback -> `iterate-pivot-decision`.
- Framing a confirmed problem for the team or leadership -> `define-problem-statement`.
- Designing the test for a chosen assumption -> `define-hypothesis`.
- The full nine-block business model -> `foundation-lean-canvas`.

<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->
# Build Risk Review: <one-line subject>

> Authoring notes are in blockquotes; delete them in the final artifact. Fill every non-optional section. Keep it short: a Build Risk Review is a gate, not a report.

**Mode:** <Pre-build | Feature-change>  |  **Date:** <YYYY-MM-DD>

## Verdict

> Exactly one: Build small / Validate first / Pivot first / Don't build yet. Then one sentence of rationale. Do not use "Kill".

**<Verdict>.** <One-line rationale.>

## Biggest risk

> Exactly one primary risk, `R1`, tagged from references/risk-taxonomy.md. Then at most three to five supporting risks. Do not produce a long inventory.

- **R1 <risk-type>:** <the single assumption most likely to make this fail, stated concretely.>
- R2 <risk-type>: <supporting risk.>
- R3 <risk-type>: <supporting risk.>

## Demand level

> Feature-change mode only. Place the request on L0 through L4 and say why. For pre-build mode write "n/a: new idea".

**L<0-4> - <label>.** <Why this level: founder anxiety, one ask, repeated asks, a workflow blocker, or a revenue/retention blocker?>

## Evidence ledger

> What signal actually exists, each graded on the strength ladder (references/risk-taxonomy.md). Be honest: likes, waitlists, and market-size are not demand. Mark counter-signal too.

| Signal | Strength | What it does or does not prove |
|---|---|---|
| <signal> | <weak / medium / strong> | <reading> |

## Validation plan

> Specific, no-code or low-code next actions with a concrete bar. Never "build an MVP" or "do user research".

1. <action with a pass/fail bar.>
2. <action.>

## Routing

> The next skill to run, from references/routing-map.md.

-> <skill> (<why>).

## Sources

> Real, cited facts only. Mark every invented number `[fictional]`.

---

**Output contract:** one artifact; one `R1`; exactly one verdict; one demand level in feature-change mode; a graded evidence ledger; a no-code next step; a named routing target; no code or implementation design.