needs-analysis

Needs Analysis

Turn a raw request into an evidence-backed product decision. Separate whether the problem is real from whether it is an attractive product opportunity.

Operating rules

• Start with the conclusion. Use 真需求, 有条件成立, 伪需求, or 证据不足; include confidence (高/中/低). Do not force a binary verdict when evidence is missing.
• Treat “广泛、刚需、高频” as opportunity qualities, not proof that a need exists. A need can be real but commercially weak.
• Consider a candidate attractive when the need is at least conditionally real and one or more of the three qualities scores at least 3/5. More passing qualities increase priority, but do not replace evidence.
• Distinguish facts, user claims, third-party estimates, inference, and unknowns. Cite or link sources when research tools are available.
• Prefer observed behavior over stated preference: payment, active workaround, repeated use, switching, budget, deadlines, support tickets, search or purchase behavior.
• Do not confuse a requested feature with the underlying need. Analyze the problem independently of the proposed solution.
• Continue on low-risk assumptions when possible. Ask only questions whose answers would materially change the verdict or validation test.

Read rubric.md before scoring or issuing the final verdict.

Workflow

1. Normalize the raw need

Rewrite it without solution bias:

[specific user] in [specific situation] struggles to [job/progress], causing [measurable cost or consequence]; today they use [current alternative/workaround].

Record separately:

• proposed solution;
• target user and buyer;
• triggering situation;
• desired outcome;
• current alternative;
• claimed frequency and consequence;
• uncertainties and assumptions.

If the user and situation are absent, infer a provisional version and label it as an assumption.

2. Build the evidence set

Search only as deeply as the decision warrants. Use this order:

1. User-provided materials, current workspace, product analytics, customer notes, support records, sales or payment evidence.
2. Direct customer evidence: interviews with concrete past behavior, paid pilots, preorders, retained usage, switching or active workarounds.
3. Market behavior: competitor customers and pricing, reviews, complaints, procurement/RFPs, job posts, communities, search trends.
4. Market reports, surveys, social engagement, and generic opinions as supporting proxies only.

For each important item capture: source, date, affected segment, what it supports or contradicts, and evidence strength. Recheck live sources for time-sensitive claims. If access is unavailable, state the limitation and do not fabricate findings.

Search for disconfirming evidence as deliberately as confirming evidence. Look for non-consumption, free substitutes, low retention, long replacement cycles, weak willingness to pay, or a segment too costly to reach.

3. Judge true versus false need

Evaluate these independent questions:

• Is there an identifiable user in a recurring or important situation?
• Does the problem exist without the proposed product?
• Is there observable cost, risk, delay, frustration, lost revenue, or missed progress?
• Do users already spend time, money, reputation, or effort on a workaround?
• Is the buyer able and willing to act now?
• Does contrary evidence weaken the claimed problem or segment?

Use the rubric's verdict rules. A verbal “I would use this” is weak evidence. A paid or repeated workaround is strong evidence.

4. Score the three opportunity qualities

Score each from 0–5 using the rubric and show one sentence of evidence:

• 广泛 Breadth: enough reachable users share the problem; define the denominator and reachable segment instead of saying “everyone”.
• 刚需 Urgency: inaction creates a material, time-bound consequence; distinguish must-have from useful.
• 高频 Frequency: the problem or workflow recurs often enough to support habit, retention, or repeat purchase.

Mark each quality 通过 at 3–5 and 未通过 at 0–2. Do not hide the three scores inside a single average.

Map passed qualities to product logic:

• 广泛: emphasize simple onboarding, distribution, standardization, or lower unit price.
• 刚需: emphasize outcome certainty, speed, trust, service, and premium pricing.
• 高频: emphasize workflow integration, retention, automation, and subscription or repeat use.

5. Design the smallest decisive validation

Identify the riskiest assumption and propose a test that can fail. Include:

• target participant and recruitment channel;
• artifact or offer;
• behavior to observe;
• sample size or exposure;
• success threshold;
• failure/stop threshold;
• timebox and next decision.

Prefer commitment tests over opinion tests: paid diagnostic, deposit, signed pilot, data access, calendar commitment, or repeated usage. For Tony's AI 本机工作台服务, when relevant, map the test to the current 50 触达 / 10 访谈 / 3 demo / 1 付费意向 gate and recommend the next missing external action.

6. Deliver the analysis

Use this structure, scaling detail to the decision:

1. 结论 — verdict, confidence, and one-sentence reason.
2. 需求重述 — user, situation, job, consequence, current alternative.
3. 证据与反证 — compact table with source/date/type/strength/implication.
4. 真伪需求判断 — behavioral evidence, gaps, and why the verdict follows.
5. 三要素评分 — 广泛 X/5, 刚需 X/5, 高频 X/5; pass count and product implications.
6. 产品决策 — build now, validate first, narrow segment, reposition, or stop.
7. 最小验证实验 — exact test, thresholds, timebox, and next action.
8. 仍未知 — only uncertainties capable of changing the decision.

When the user also requests implementation, present the analysis first, convert validated findings into acceptance criteria, then continue the implementation unless a failed gate makes building wasteful or unsafe.

Failure modes

• Do not call a need real solely because many people liked, searched, or discussed it.
• Do not call a need false solely because it is niche or infrequent; urgent niche problems can support premium products.
• Do not count the same evidence twice across breadth, urgency, and frequency.
• Do not use market size as a substitute for reachable users or willingness to pay.
• Do not make interview count the goal; use interviews to uncover past behavior and then seek commitment.
• Do not recommend a full build when a landing page, manual concierge test, paid diagnostic, or prototype can test the riskiest assumption faster.