Builder Product Thinking

Core principle

Turn product opinions into falsifiable decisions. Start from a concrete user behavior and context, locate the largest uncertainty, then select only the framework that can reduce it. End with an executable test and a stop condition.

Workflow

1. Frame the decision. Restate the decision, time horizon, constraints, and irreversible cost. If these are absent, state the smallest assumptions needed to proceed.
2. Build an evidence ledger. Separate supplied facts, interpretations, assumptions, and unknowns. Never present a market claim as fact without evidence.
3. Reconstruct the user event. Identify the user, trigger, desired progress, current alternative, observable cost, and success signal. Read user-and-scene.md when demand or user understanding is uncertain.
   • If the user needs active overseas SaaS opportunity discovery rather than evaluation of a supplied idea, read saas-opportunity-discovery.md and collect traceable market evidence before making the call.
4. Find the binding uncertainty. Classify it as demand, value, usability, feasibility, consensus, distribution, viability, or truth. Analyze the problem before accepting the proposed solution.
5. Load one primary lens. Use the routing table below. Add a second lens only when it changes the decision.
6. Check the commercial loop when required. For payment, brand, growth, stakeholder, or business-model decisions, trace need → value → consensus → transaction/relationship → resource return → capability. Name the broken link.
7. Make the call. Choose proceed, narrow, test first, defer, or stop. State the reasoning and confidence.
8. Design the next test. Specify cohort, behavior, procedure, metric, time window, success threshold, guardrail, and stop condition. Prefer the smallest test that can reverse the current decision.

Lens routing

Observable decision	Read
User, demand, persona, scene	user-and-scene.md
Overseas SaaS demand discovery, Reddit/Product Hunt signals, tool-site or Micro-SaaS opportunity scan	saas-opportunity-discovery.md
Idea, market, opportunity, positioning	opportunity-and-strategy.md
Feature, workflow, trust, delivery	system-and-experience.md
Functional/emotional/asset value, category, brand	value-system.md
Perception, adoption, stakeholder resistance, messaging, relationship	consensus-system.md
Pricing, monetization, unit economics, resource allocation, durability	business-model.md
Conflicting narratives, weak evidence, major direction or retrospective	truth-and-first-principles.md

Output contract

Return these sections in order:

1. Decision — verdict, scope, and confidence.
2. Evidence ledger — facts / assumptions / unknowns.
3. User and problem — concrete event and current alternative.
4. Key analysis — one primary framework, with implications rather than terminology.
5. Commercial loop — include only for payment, brand, growth, stakeholder, or business-model decisions; identify the broken link and resource consequence.
6. Test plan — exact behavior, threshold, time window, and stop condition.
7. Next action — the smallest action the Builder can take now.

If the user asks for a reusable artifact, copy the closest template from assets/. For an overseas SaaS market scan, copy saas-opportunity-scan.md. For retrospective work, read learning-loop.md.

Skill handoffs

• Use dbs-good-question first when the object, goal, constraints, or feedback entry is too vague to bound the scan.
• Use dbs-benchmark after concrete profitable competitors appear and the decision becomes which business to model.
• Use dbs-diagnosis when an existing operating business needs business-model diagnosis rather than opportunity discovery.
• Keep the evidence ledger and final product decision in this Skill; do not duplicate them in the handoff Skill.

Quality checks

• Does every confident claim have evidence or an explicit assumption label?
• Did the analysis test the problem before optimizing the suggested feature?
• Is the user described by a real event rather than a broad persona?
• Would the proposed evidence distinguish success from polite interest?
• Can the Builder tell when to stop?
• Did each framework materially change the decision?

Common mistakes

Mistake	Correction
“需求真实”“市场很大” without evidence	Label as a hypothesis and define the evidence needed.
Generic advice to interview users or build an MVP	Define cohort, task, metric, threshold, and time window.
Treat AI or a feature as the opportunity	Compare the complete workflow with the current alternative.
Apply every named framework	Use the minimum lens that resolves the binding uncertainty.
Give only a go/no-go opinion	Include a reversible test and stop condition.
Treat praise, attention, or usage as payment evidence	Identify the payer, exchange, value received, and price test.
Treat advertising as a substitute for product value	Verify value and retention before scaling consensus or distribution.
Treat a logo or visual refresh as a brand upgrade	Identify the product promise, memory, proof, and delivery capability.