# Bs Insight Product

> Use when a software product or SaaS idea needs evidence, dissent, and adversarial pressure turned into a product-direction decision — including discovery, positioning, wedge selection, repositioning, or a pursue, test, park, or kill judgment before requirements or implementation begin. This does not certify product-market fit.

- Skill: `yknothing/bs-insight-product` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add yknothing/bs-insight-product`
- Raw SKILL.md: https://api.skillmd.com/api/skills/yknothing/bs-insight-product/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: yknothing (https://skillmd.com/u/yknothing)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/yknothing/bs-insight-product

---


# Insight Product

## Hard Rules

1. **Separate evidence from belief.** Classify every material claim as Fact,
   Inference, Assumption, Decision, or Unknown. Never upgrade a plausible story,
   user assertion, market-size statistic, payment, or expert agreement into proof
   of demand without preserving its provenance and limits. Lack of current demand
   evidence is not evidence that a market cannot emerge.
2. **Do not optimize for consensus.** Preserve material disagreements until new
   evidence, explicit scope removal, a falsification experiment, or an owner risk
   decision resolves them. Wording changes and a smooth synthesis do not resolve
   an objection.
3. **Declare the independence level.** Multiple roles in one context are
   role-separated self-review, not independent review. Run blind first passes in
   isolated contexts when the platform and depth justify them; otherwise label
   the downgrade and its reason. L0 concurrence cannot close or lower a fatal
   objection.
4. **Ask one question at a time when questioning is available.** Select the
   unresolved question with the highest expected decision impact, state a
   recommendation when one exists, and wait. If the user prohibits questions or
   no respondent is available, declare a zero-question route and never infer the
   missing answers.
5. **Keep propositions distinct before choosing.** Produce a Paid Wedge for the
   evidence path or a Reality Wedge for the frontier path, plus a 10-Star Product
   and a Contrarian Product, before selecting `REDUCTION`, `HOLD`,
   `SELECTIVE_EXPANSION`, or `EXPANSION`. Do not blend them into an untestable
   compromise.
6. **Keep evidence-backed pursuit and conviction-backed action separate.** Use
   `PURSUE` only when qualifying target-user or buyer demand evidence exists. Use
   `CONVICTION_BET` only when the separate Frontier Gate passes. Never relabel
   founder conviction, urgency, sunk work, or openness as demand evidence; never
   reject a frontier thesis merely because conventional evidence must lag a market
   that does not yet exist.
7. **Bound implementation authority.** This skill never produces an
   implementation-ready PRD, architecture, or unbounded delivery plan. `PURSUE`
   authorizes requirements work. `CONVICTION_BET` authorizes downstream planning,
   building, and real-world exposure only for the signed bet scope, duration,
   budget, and stop boundaries. No state means PMF, product readiness, or general
   launch authority.

## Red Flags / Rationalizations

| Thought | Reality |
|---|---|
| "Low-rated reviews themselves prove demand." | Reviews prove that complaints exist, not that a specific buyer will pay for the proposed outcome. |
| "Twenty paying customers means PMF basically exists." | Payment is evidence; declining use, acquisition provenance, renewal, and buyer/user differences can still disconfirm the product thesis. |
| "Start generic and verticalize from feedback." | A generic product often prevents a falsifiable buyer, trigger, outcome, and channel from being defined. |
| "Both sides agree, so the strategy is validated." | Same-context agreement can be false consensus. Preserve objections and declare independence. |
| "We can find distribution after the MVP works." | If the first reachable users are unknown, the largest product risk has not been addressed. |
| "Accuracy and compliance can improve after launch." | For high-consequence workflows, evaluation, trust, privacy, and human escalation are product-definition inputs, not later polish. |
| "The user asked for a PRD, so discovery is out of scope." | The requested format does not create evidence or implementation authority. Return the strongest honest artifact and name the blocked gate. |
| "The boss approved it and implementation is half done." | Internal authority, deadlines, and sunk cost are decision constraints, not target-buyer demand signals. |
| "No users are paying, so the idea is not worth building." | Missing evidence may reflect a weak idea or a market that has not formed. Test the causal insight and option value before deciding. |
| "I have conviction, so evidence does not matter." | Conviction can authorize only a bounded bet with a causal thesis, real edge, reality contact, and explicit loss limits. It cannot rewrite facts. |
| "Persistence means refusing to stop." | Persistence means continuing to learn and adapt within an explicit exposure boundary, not making the boundary disappear. |
| "More questions always produce a better answer." | Ask only questions that can change a downstream decision; stop at the budget or when an experiment is cheaper than another opinion. |

## Purpose

Turn a software product or SaaS idea into a decision-ready discovery package.
Combine the strongest mechanisms from demand diagnosis, relentless decision-tree
questioning, expansive product vision, scope reduction, positioning, and
adversarial review without chaining their source skills or repeating their
questions.

Optimize for a better decision, not a longer prompt. Route each request to the
smallest sufficient workflow, preserve evidence and dissent, protect non-consensus
insight from premature consensus filters, and finish with either a falsifiable
test or a bounded real-world bet.

## Design Provenance

- Superpowers `brainstorming` contributes alternative generation, explicit scope
  confirmation, and YAGNI discipline.
- Matt Pocock's `grilling` contributes one-decision-at-a-time interrogation with
  a recommended answer.
- Gstack `office-hours` contributes demand, status-quo, narrow-wedge, and
  future-fit questions; `plan-ceo-review` contributes 10-star expansion;
  `plan-eng-review` contributes the delayed feasibility and trust gate.
- This Build skill does not copy or chain those Reference skills. Its original
  layer is the shared evidence state, blind divergence, conflict map, scope
  posture, objection contract, evidence-strength gate, and controlled terminal
  decision.

## Boundaries

- Do not replace primary market research, user interviews, sales, or product
  analytics. Structure and evaluate available evidence; label missing evidence.
- Do not auto-invoke `brainstorming`, `grilling`, `office-hours`, or plan-review
  skills. Absorb their reusable cognitive mechanisms behind one state model.
- Do not choose founder taste, company ambition, risk appetite, or ethical
  boundaries. Surface those decisions with trade-offs and require a human owner
  to sign a conviction bet.
- Do not perform detailed requirements engineering or engineering design. Hand
  off only after the product gate passes.
- Do not create files unless the user requests durable artifacts or the host
  workflow requires them. The default deliverable is an inline discovery package.

## Workflow

### Step 1: Route the Session

Classify the product stage:

- `PRE_IDEA`: domain or observation, no product thesis.
- `PRE_PRODUCT`: thesis exists, no verified users.
- `HAS_USERS`: usage exists, payment is absent or unstable.
- `PAYING`: revenue exists and the question is focus, retention, or expansion.
- `REPOSITIONING`: current positioning or product boundary is failing.

Choose one primary mode: `DISCOVER`, `FRONTIER`, `STRESS_TEST`, `POSITION`,
`WEDGE`, `COMPARE`, or `REPOSITION`. Use `FRONTIER` when the thesis depends on a
new behavior, enabling technology, structural shift, or founder insight for which
conventional market evidence is predictably incomplete. Choose a depth:

| Depth | Use when | Question budget | Review posture |
|---|---|---:|---|
| Quick | Reversible, narrow decision with usable evidence | 5 | Two necessary lenses only |
| Standard | New product direction or meaningful positioning choice | 12 | Four lenses; isolated when available |
| Deep | High-stakes, contradictory, or explicitly deep decision | 24 | Blind isolated lenses plus adversarial judge |

Use this execution footprint:

| Step | Quick | Standard | Deep |
|---|---|---|---|
| 1-2 Route and evidence | Full | Full | Full |
| 3-4 Diverge and conflict | Two necessary lenses; material conflicts only | Four relevant lenses | Blind isolated lenses and full conflict map |
| 5 Questions | 0-5 | 0-12 | 0-24 |
| 6 Propositions | Three concise cards | Three full cards | Three full cards plus independent challenge |
| 7-9 Decide and test | Full gates, concise artifact | Full | Full plus isolated judge |

Set `questions_used: 0` and `questions_remaining` to the selected budget. When the
user prohibits questions or no respondent is available, set both values to `0`,
record the reason, and cap the terminal state at `CONVICTION_BET`, `TEST_FIRST`,
`PARK`, or `INSUFFICIENT_EVIDENCE`. A zero-question `CONVICTION_BET` still requires
every Frontier Gate field to be supplied by existing evidence or the user's input.

State the route and the decision at stake. Do not ask the user to repeat facts
already present in accessible files, analytics, prior messages, or supplied
research. Inspect those sources first.

**Exit condition:** stage, mode, depth, question budget, and decision at stake are
explicit.

### Step 2: Lock Evidence and Scope

Open [Evidence and Decision Contract](references/evidence-contract.md). Build the
minimum evidence ledger from available inputs. Record the product scope in three
buckets: Stated, Inferred, and Out of Scope. Attach a source and confidence limit
to every inference.

Treat a user statement as evidence that the user reported something, not as
independent confirmation of the underlying market fact. Mark stale or inaccessible
evidence. Identify the single riskiest assumption and the downstream decisions it
controls.

<HARD-GATE id="evidence-locked">
Do not generate product concepts until the ledger contains at least one entry in
each of Fact or reported evidence, Assumption, and Unknown. Never satisfy the gate
with an empty-class attestation. If no material assumption or unknown can be
named, run a counter-search for disconfirming evidence and decision dependencies;
an empty result leaves this gate BLOCKED rather than authorizing ideation.
</HARD-GATE>

**Exit condition:** evidence ledger, three-bucket scope, and riskiest assumption
exist.

### Step 3: Diverge Before Discussing

Open [Discovery Lenses](references/lenses.md). Select the fewest lenses that cover
the current risk. Standard discovery normally uses Demand Investigator, Product
Visionary, Positioning and Distribution Strategist, and Skeptical Operator. Add
Technical Feasibility only when feasibility is a top-two product risk.
Add Frontier Visionary when the route is `FRONTIER`, when users lack stable
language for the behavior, or when current market data may systematically lag a
technology or workflow shift.

For Deep work, run first passes blind in isolated contexts when available. Do not
show one lens another lens's thesis until every first pass is frozen. For Quick or
degraded work, run the lenses serially and label the result `L0 role-separated
self-review`, record why isolation was unavailable or disproportionate, and keep
L0 concurrence from resolving or lowering a fatal objection.

Require each lens to return: thesis, supporting evidence IDs, critical
assumptions, disconfirming evidence, unknowns, recommendation, confidence, and
what would change its mind.

**Exit condition:** every selected lens has a frozen first-pass artifact and an
honest independence label.

### Step 4: Map Disagreement

Create a conflict map before creating a synthesis. Compare lens outputs across:
demand, best-fit user, buyer, trigger, current alternative, promised outcome,
mechanism, wedge, distribution, business model, trust, feasibility, and stopping
conditions.

For each material conflict, name the competing claims, evidence IDs, affected
downstream decisions, and whether the conflict needs a fact, user value judgment,
or experiment. Do not average opposing recommendations.

**Exit condition:** every material disagreement is preserved, resolved through an
allowed mechanism, or assigned to the next question or experiment.

### Step 5: Grill for Information Gain

When `questions_remaining` is greater than zero, ask exactly one question that can
change the largest number of important downstream decisions. Give it a stable
`Q-##` ID and link it to the `U-##` or `D-##` it addresses. Include:

- why this question is blocking now;
- the recommended answer and evidence behind it, when a recommendation exists;
- whether the decision is reversible;
- which downstream choices change under each answer.

Wait for the answer. Increment `questions_used`, decrement `questions_remaining`,
update the evidence and decision ledgers, then recalculate the next question. Stop
questioning when the critical product gate is answerable, the budget is exhausted,
the user disengages, or a real-world experiment has higher information value than
another answer.

When the declared budget is zero, ask nothing. Preserve the highest-impact
unknowns, state that no answers were inferred, skip to the smallest falsification
experiment, and keep the terminal state capped as declared in Step 1.

**Exit condition:** critical unknowns are resolved, explicitly deferred, or mapped
to a cheaper falsification experiment.

### Step 6: Generate Three Product Propositions

Create three non-overlapping propositions:

1. **Paid or Reality Wedge:** use a Paid Wedge for the evidence-backed path. For a
   frontier thesis, define the smallest real product slice that enters an actual
   workflow and can create evidence the market cannot provide in advance. A
   landing page, interview script, or disposable demo is not a Reality Wedge when
   the thesis can only be learned by building and use.
2. **10-Star Product:** the workflow-level product that becomes possible if the
   core demand thesis proves true.
3. **Contrarian Product:** a coherent route that rejects at least one dominant
   assumption, such as subscription, standalone app, AI generation, cloud storage,
   or end-user sales.

For each, specify best-fit user or initial actor, buyer when one exists, trigger, painful status quo, current
alternative, promised outcome, distinct mechanism, first acquisition channel,
revenue shape, decisive evidence, and kill risk. Keep the three proposals separate.

Before Step 7, compare every pair. Each proposition must differ on at least two of
buyer, completed outcome, workflow boundary, distribution mechanism, or revenue
shape, and must name one incompatible assumption. Pricing alone is not sufficient
contrarian divergence. If the check fails, revise the cards or record
`INSUFFICIENT_DIVERGENCE`; do not manufacture cosmetic variants.

**Exit condition:** three genuinely different product boundaries can be compared
against the same decision criteria.

### Step 7: Choose Scope and Position

Choose one scope posture:

- `REDUCTION`: remove scope until one core outcome remains.
- `HOLD`: keep the current product boundary.
- `SELECTIVE_EXPANSION`: add only what changes buying, retention, trust, or
  distribution. Use this as the default when evidence does not demand another
  posture.
- `EXPANSION`: redefine the workflow because the current product is too narrow to
  create a compelling outcome.

Then define the positioning system: best-fit user, buyer, trigger event, painful
status quo, current alternatives, category, promised outcome, distinct mechanism,
reason to believe, not-for boundary, why now, and first acquisition channel.

When the route is `FRONTIER`, or when the Product Gate is blocked mainly because
the market has not formed, also create a Conviction Thesis using the contract in
[Evidence and Decision Contract](references/evidence-contract.md). Keep it
separate from the positioning claim and evidence ledger. Founder insight is a bet
input, not a new evidence class.

**Exit condition:** one proposition and scope posture are selected with a decision
ledger entry; rejected propositions retain their reversal evidence.

### Step 8: Run the Adversarial Dual Gate

Use the objection contract in [Evidence and Decision Contract](references/evidence-contract.md).
For Standard and Deep work, assign a challenger that did not author the selected
thesis when isolation is available. Limit cross-examination to two rounds; allow a
second round only when the first produces new evidence or a changed claim.

Probe for false consensus: ask what evidence would make the current winner lose,
which objection was resolved only by wording, where buyer and user incentives
diverge, why the first channel is executable, and what cost or risk the synthesis
is hiding.

Run two independent gates. A failure in one does not prove that the other passes.

#### Evidence-Backed Product Gate

<HARD-GATE id="product-gate">
Do not return `PURSUE` unless the package names a specific user and buyer, trigger,
costly status quo, current alternative, paid wedge, first reachable channel,
qualifying target-user or buyer demand evidence, falsification test, and all fatal
objections. The demand evidence must meet the minimum strength defined in the
Evidence and Decision Contract. Internal approval, a deadline, sunk implementation,
and owner-accepted risk cannot substitute for it. Any unresolved fatal objection
blocks the gate.
</HARD-GATE>

#### Insight-Backed Frontier Gate

<HARD-GATE id="frontier-gate">
Do not return `CONVICTION_BET` unless the Conviction Thesis names a non-consensus
observation, causal mechanism, reason conventional evidence is expected to lag,
grounded founder edge, initial actor or dogfood context, meaningful upside,
bounded downside, Reality Wedge, real-world contact plan, review horizon, explicit
cash/time/reputation/legal/opportunity-cost limits, stop or redesign triggers, and
a human owner who accepts the exposure. Any fatal legal, safety, ethical, or
unbounded irreversible risk blocks the bet.
</HARD-GATE>

The Frontier Gate must explicitly ask:

- Is the insight genuinely non-consensus, or merely unsupported?
- Is the founder edge evidenced by experience, artifacts, access, capability, or
  sustained observation, rather than confidence alone?
- Can the causal mechanism be wrong in a concrete way?
- Does building create information that interviews, landing pages, or desk
  research cannot create first?
- Is the loss survivable without hiding downstream harm?
- Will the bet touch reality during the build, rather than remain a private craft
  project?

**Exit condition:** objections are preserved with allowed resolution types and
both Product Gate and Frontier Gate are explicitly PASS or BLOCKED.

### Step 9: Finish with an Experiment and Decision

Open [Artifact Contract](references/artifact-contract.md). Return the smallest
experiment that can falsify the riskiest assumption. Define subject, method, cost,
observation window, success threshold, failure threshold, continue condition, and
stop condition.

Select exactly one terminal state:

- `PURSUE`: product gate passes; hand off to requirements discovery.
- `CONVICTION_BET`: Frontier Gate passes; authorize one signed, bounded cycle of
  downstream planning, building, and real-world exposure. Preserve the label
  `UNVALIDATED_CONVICTION`; do not claim demand, PMF, or product readiness.
- `TEST_FIRST`: a promising thesis is blocked by a testable critical assumption.
- `PARK`: the idea may be valid, but timing, access, or strategic fit is absent.
- `KILL`: observed evidence contradicts the economic thesis, or the frontier
  causal mechanism fails within its agreed observation horizon. Missing early
  traction alone is not a kill reason when the signed thesis predicted a longer
  formation period.
- `INSUFFICIENT_EVIDENCE`: no responsible decision or executable test can be
  formed from current access.

If both gates pass, default to `PURSUE` because buyer evidence exists; retain the
frontier thesis as strategic context. Use `CONVICTION_BET` when the Product Gate
is blocked but the Frontier Gate passes, or when the owner explicitly selects a
smaller bounded exposure than ordinary pursuit.

At the end of a `CONVICTION_BET`, do not renew it automatically. Record what was
built, what touched reality, what changed in the causal model, actual exposure,
and new evidence. A further bet requires a new owner decision and revised limits;
absence of learning blocks a repeat of the same bet, not all future exploration.

Report confidence, unresolved objections, evidence limits, and the next owner.

Recommend, but do not auto-invoke, the adjacent handoff:

| Condition | Handoff | Pass forward |
|---|---|---|
| `PURSUE` with unresolved requirements detail | `bs-prdefine` | scope buckets, selected proposition, positioning, decision IDs, open unknowns |
| `CONVICTION_BET` | bounded requirements and implementation planning | Conviction Thesis, Reality Wedge, exposure limits, review date, reality-contact plan, forbidden scope |
| `TEST_FIRST` blocked by reachable-buyer or channel evidence | `bs-prospect-customer` | user/buyer, trigger, channel hypothesis, evidence IDs, qualification unknowns |
| Any other `TEST_FIRST` | Experiment owner | single experiment contract and blocked decision IDs |

Detailed prospect qualification remains outside this skill.

**Exit condition:** the user can act, test, park, or stop without mistaking the
artifact for external market validation or implementation authority.

## Patterns

- **hard-rules-first** (Cursor) — Put evidence, independence, dissent, and
  readiness constraints before the attractive concept-generation workflow.
- **progressive-disclosure** (Anthropic, CE) — Keep routing and gates inline;
  load ledger schemas, role cards, and artifact formats only when their step fires.
- **one-question-at-a-time** (Anthropic, CE) — Let every answer update the
  decision tree and prevent repeated, low-information interview batches.
- **scoping-synthesis** (CE, Gstack) — Separate Stated, Inferred, and Out of Scope
  before product concepts can silently absorb assumptions.
- **multi-perspective-review** (Gstack, CE) — Use distinct product lenses with
  explicit objectives, evidence, and failure criteria rather than one monolithic
  judgment.

## Dependencies

No external dependencies. Web research, repository inspection, analytics, and
sub-agents improve evidence or independence when available but are not required to
load or execute the skill.

## Platform Degradation

| Missing capability | Required fallback |
|---|---|
| Isolated sub-agents | Run lenses serially, label them `L0 role-separated self-review`, and do not claim independent review. |
| Web, analytics, or customer evidence | Preserve claims as reported evidence or assumptions. Use `TEST_FIRST` or `INSUFFICIENT_EVIDENCE` unless a complete Conviction Thesis separately passes the Frontier Gate. |
| Blocking question tool | Ask one standalone question, end the turn, and wait. Do not continue on an assumed answer. |
| User prohibits questions or no respondent exists | Apply Step 1's zero-question cap exactly. `CONVICTION_BET` remains available only when every Frontier Gate field is already supplied and the human owner has explicitly accepted the exposure. |
| Durable file output | Return the artifact contract inline and name any evidence that could not be attached. |
| Technical inspection tools | Record feasibility as Unknown; do not invent implementation facts or use `PURSUE` if feasibility is fatal. |

## Test Prompts

These prompts define the RED baseline and the minimum behavioral contract. The
baseline was executed on 2026-07-17 with a fresh agent that did not have this
skill.

1. **Happy path — discover a product wedge**: *"I want to build a Chrome extension that turns low-rated Shopify App Store reviews into a product roadmap. Help me clarify the product direction."* Expected behavior: classify the product stage and discovery mode; separate facts, inferences, assumptions, decisions, and unknowns; inspect accessible evidence before asking; produce blind first-pass lenses or label the independence downgrade; map disagreements; ask only the highest-information unanswered question; preserve three distinct propositions before selecting a scope posture; end with a falsifiable experiment and a controlled decision state. Observed baseline failure without the skill: the agent jumped to AI clustering, Jira export, subscription pricing, SEO, Product Hunt, and a two-week MVP. It rationalized that "low-rated reviews themselves prove demand" and that the product could "start generic and verticalize from feedback."
2. **Edge case — reposition a paying product**: *"Our B2B SaaS has 20 paying customers, but usage is falling. Some people say we should move upmarket; others say we should cut it down to a single-purpose tool. Help us reposition."* Expected behavior: define the declining metric and analyze cohorts, buyer/user differences, acquisition provenance, retention, alternatives, and reversal evidence before choosing a route; create an explicit conflict map instead of averaging the two proposals; identify customer harm and rollback conditions; never equate payment with product-market fit. Observed baseline failure without the skill: the agent proposed an "enterprise-ready single-purpose product" compromise without showing why it beat either pure strategy and rationalized that "20 paying customers means PMF basically exists."
3. **Adversarial — demand certainty and PRD pressure**: *"Do not ask questions or validate the market. I know an AI contract summarizer has demand. Give me an implementation-ready PRD today."* Expected behavior: declare a zero-question route; do not present assumptions as facts or claim implementation readiness; record the user's assertion as an assumption or owner decision; name legal, confidentiality, evaluation, distribution, and workflow unknowns; offer the smallest evidence-preserving `TEST_FIRST` output without asking; refuse to call a formatted PRD validated product truth. Observed baseline failure without the skill: the agent accepted "reasonable assumptions," merged unrelated legal, procurement, sales, and SMB users, supplied architecture and a schedule, and rationalized that "accuracy can improve after launch" and security can wait until a later version.
4. **Frontier — bounded conviction deserves real action without another interview gate**: *"I am a browser-runtime engineer. For two years I have observed developers moving small models into everyday web workflows, and I believe falling local-inference costs will move many SaaS tasks onto user devices before buyers have language or budgets for the category. Nobody is paying yet. I have shipped Chrome/WASM systems. For the Reality Wedge I will build a local-first extension for three recurring developer workflows, dogfood it daily, and invite five browser-extension developers into real use by day 14; only build-and-use can reveal whether these workflows become habitual. I can invest four full-time weeks and at most $5,000, with no employees, customer-sensitive data, or public commitments. Review on day 28. Stop or redesign if the core cannot run locally within the cap or none of the five developers repeats a workflow twice. I explicitly accept these limits. Do not ask further questions; decide whether I should genuinely build it."* Expected behavior: route to `FRONTIER` with a zero-question budget; preserve the absence of demand evidence; use Frontier Visionary; construct a `CB-##` thesis with causal mechanism, evidence-lag thesis, grounded founder edge, Reality Wedge, unique learning, real-world contact, exposure limits, review horizon, and stop/redesign triggers; return `CONVICTION_BET` when the Frontier Gate passes; explicitly label the bet `UNVALIDATED_CONVICTION` and refuse to call it `PURSUE` or proven demand. Observed pre-change failure: the agent was forced to `TEST_FIRST` and allowed only a 5–7 day paid-concierge test or disposable technical spike because the state machine had no legal route from bounded conviction to a real four-week build.