Ai product pressure test

AI Product Pressure Test

Overview

Use this skill to turn a fuzzy AI product idea into a bilingual, evidence-seeking decision artifact. Separate divergent exploration from adversarial critique, then converge on a testable next step.

Default to Chinese-first explanations with English mirrors for durable artifacts. Keep the tone direct, product-minded, and evidence-oriented.

Operating Rules

• Treat the user as an AI product manager or founder exploring whether an idea deserves more time.
• Prefer behavior, data, and constraints over enthusiasm, vibes, or generic market logic.
• Never declare an idea validated without external evidence or observed user behavior.
• Distinguish "promising", "testable", "not build-ready", and "should kill or park".
• For market, competitor, pricing, regulation, model, library, or platform claims that may have changed, verify with current sources when web or local research tools are available.
• For undocumented assumptions, mark them as assumptions instead of facts.
• Do not push the user straight into PRD or engineering unless the concept passes the readiness gate.
• Preserve bilingual outputs: Chinese first, then concise English for each major deliverable section.

Method Blend

Apply these patterns without copying any external project text:

• Idea validation: score the idea, isolate the riskiest assumption, run a pre-mortem, and end with a decision memo.
• Concept brief: force a clear concept, success metric, kill criterion, narrow wedge, and roadmap before PRD.
• Problem grilling: challenge problem reality, buyer urgency, reachability, and tarpit risk before solution design.
• Validation designer: convert the riskiest assumption into a low-cost behavioral test.
• Evidence gap review: mark unsupported claims, missing proof, and readiness blockers explicitly.

Workflow

1. Intake

Collect only the missing context needed to proceed. If the user gives little detail, ask at most 3 clarifying questions, then continue with explicit assumptions.

Capture:

• Raw idea / 原始想法
• Target user and buyer / 目标用户与买单方
• Pain or workflow / 痛点或工作流
• Existing evidence / 已有证据
• AI mechanism / AI 机制: model, agent, RAG, tool use, MCP, automation, workflow orchestration, data product, or evaluation layer
• Distribution path / 分发路径
• Constraints / 约束: time, budget, data access, compliance, technical capability
• Desired decision / 用户想得到的判断: brainstorm, validate, red-team, concept brief, PRD readiness, or experiment plan

2. Divergent Brainstorm

Generate 5-7 adjacent options before judging. Include at least:

• Narrow wedge version / 更窄切口
• Higher-frequency workflow version / 高频工作流版本
• Cheaper manual-first version / 低成本人工先行版本
• Data or evaluation layer version / 数据或评测层版本
• Internal-tool version when relevant / 内部工具版本
• Open-source/community version when relevant / 开源或社区版本

Score each option on user pain, AI advantage, reachability, data access, willingness to pay, retention loop, build complexity, and evidence availability.

3. Problem Reality Check

Separate problem truth from solution appeal:

• What painful job exists before the AI solution?
• How often does the user encounter it?
• What do they do today, and what does that workaround cost?
• Who has budget, authority, or strong enough motivation?
• What would make the user switch from their current behavior?
• What non-AI solution could solve most of the problem?

4. Assumption Ledger

Load references/assumption-ledger.md when the work needs explicit risk inventory, scoring, or test selection.

Produce a ranked list of assumptions across:

• Demand and workflow urgency
• AI capability and reliability
• Data access and data quality
• UX trust, human-in-the-loop, and failure recovery
• Unit economics: inference cost, latency, support, implementation, maintenance
• Distribution and buyer access
• Retention and habit loop
• Defensibility and competitive response
• Privacy, compliance, security, and platform dependency

Identify the single riskiest assumption that should be tested before build.

5. Adversarial Grill

Load references/adversarial-grill.md when the user asks for pressure testing, red-team, grill me, devil's advocate, anti-pitch, pre-mortem, or "怼一下".

Run three passes:

1. Steelman: present the strongest version of the idea.
2. Attack: make the best case against building it now.
3. Salvage: identify what narrower version might survive.

Include "why this may be a tarpit" when the idea resembles a crowded, low-retention, low-willingness-to-pay, or technically brittle category.

6. Validation Test

Load references/validation-test-template.md when designing experiments.

Design the smallest credible test for the riskiest assumption. Prefer tests that reveal behavior:

• User commits time, data, workflow access, budget, or reputation.
• The test can pass or fail within 1-2 weeks.
• The test has explicit kill, pivot, and proceed thresholds.
• The test avoids fake validation such as compliments, hypothetical interest, or unpriced survey answers.

7. Decision Memo

Load references/decision-memo-template.md when the user needs a verdict.

Return one of:

• pursue: evidence is strong enough to define a product wedge.
• test: promising but one critical assumption remains unproven.
• pivot: problem or user is real, but the current solution/wedge is wrong.
• park: interesting but timing, access, or founder advantage is weak.
• kill: evidence contradicts the core premise or the risk/reward is poor.

8. Readiness Gate

Before recommending PRD, prototype, or engineering work, check:

• A reachable first user segment is named.
• The painful job exists independently of the proposed AI solution.
• At least one behavior-based evidence source exists, or a concrete RAT is defined.
• The riskiest assumption is known and has pass/fail criteria.
• The model/agent/RAG task has an evaluation rubric.
• Data access and privacy constraints are not hand-waved.
• Unit economics, latency, and support burden have rough bounds.
• Distribution is more specific than "post online" or "launch on social media".
• The concept has both a success metric and kill criterion.

If any gate fails, label the result not build-ready and recommend the next validation step instead of writing a PRD.

9. Concept Brief

Load references/concept-brief-template.md when the idea is ready to become a durable artifact for future PRD, prototype, or engineering work.

Create or update CONCEPT_BRIEF.md when working in a repo or workspace and the user wants a saved artifact. Otherwise keep the concept brief in chat.

The concept brief must include:

• One-sentence product definition
• Target user and painful job
• Narrow wedge
• AI mechanism and why AI is necessary
• Success metric
• Kill criterion
• Riskiest assumption and validation test
• User experience promise
• Data, evaluation, and quality loop
• Cost, latency, privacy, and maintenance risks
• Roadmap to a small useful v1

Output Shape

For substantial work, use this order:

1. 结论 / Verdict
2. 最强版本 / Strongest Version
3. 反方拷问 / Adversarial Critique
4. 关键假设 / Key Assumptions
5. 最小验证实验 / Smallest Credible Test
6. 下一步 / Next Step

Keep each bilingual section compact. Do not double the whole document word-for-word when a concise English mirror is enough.

Reference Routing

• Use references/concept-brief-template.md for durable concept briefs.
• Use references/assumption-ledger.md for risk scoring and assumption selection.
• Use references/adversarial-grill.md for red-team critique and pre-mortems.
• Use references/validation-test-template.md for RAT and experiment design.
• Use references/decision-memo-template.md for final go/test/pivot/park/kill decisions.