产品发现（product discovery）是在动手做之前就决定什么值得做的那部分工作——跟用户聊、检验假设、把一个含糊的诉求变成一个有依据的赌注。它和「把功能需求照单全收、直接上线」正好相反。这页讲产品发现的流程、真正能推动事情的方法、值得问的问题、以及一份简单模板——然后是多数指南跳过的那部分：发现会产出一堆证据和假设，而从洞察 → 决策 → spec 的那条线，恰恰是它通常断掉的地方。
产品发现是团队降低「做错东西」风险的方式。它与交付并行——工程师在交付已定的东西时，团队在调查接下来该做什么：问题真不真、人们想不想要、我们能不能做、该不该做。它的产出不是一个功能，而是一个你拿得出手去辩护的决策，并附上证据。
经典的框架是「双轨」（dual-track）：发现与交付是连续、并行的两股流，而不是先后的阶段。发现要处理的风险通常归为四类：价值（会不会用）、易用（用不用得了）、可行（我们能不能做出来）、商业可行（对生意该不该做）。一个好的发现流程，无非是一套有纪律地在这些风险耗掉一个季度工程量之前就把它们消解掉的办法。
五种方法覆盖大多数真实发现。你不必每次都全做——挑那个能消解你当前最大风险的。
跟真实用户聊他们的实际问题，而不是兜售你的方案。单看杠杆最高的方法——要持续做，而不是做一次性研究。它的产出是在任何功能上桌之前，对问题的一份清醒认识。
Teresa Torres 的那张图：从一个期望结果，往下经由机会（未满足的需求）到候选方案。让你在理解机会空间之前别急着跳到功能——并把推理显式地摆出来。
列出一个想法要成立必须为真的东西，再按每个假设有多冒险、多未知来排序。先测最冒险、最不确定的。它阻止你去验证那些舒服的假设、却忽略那个真正承重的。
低保真原型、假门测试、人工 MVP——能证伪一个假设的最便宜实验。目标是在昂贵的「是」之前得到一个快速的「否」，而不是一个精致的 demo。
漏斗、留存队列、工单共性——访谈给不了你的那半定量。最好和定性搭配：数字告诉你去哪看，访谈告诉你为什么。
一份轻量的发现文档回答六件事：你在追的结果、机会（未满足的需求）、必须成立的假设、跑过的实验及其结果、达成的决策、留下的待解问题。整个模板就这些——价值在于诚实地填好决策和它的证据。
值得问的是那些让人不舒服的问题：要让这成为一个坏主意，什么得为真？这明确不是给谁的？以最便宜的方式很快发现自己错了，怎么做？如果我们对了，下游会有什么崩掉？只会印证既定计划的发现，不是发现。
发现真正的产出是一条链：一个观察成了洞察，洞察支撑了一个决策，决策塑造了一份 spec。在多数团队里这条链住在零散的文档和记忆里，于是当某个假设后来被证伪，没有任何东西沿链往前走到那份建立在它上面的 spec。Draftlize 把这条链显式化。
一条访谈观察、一个实验结果、一个假设——每个都是卡片。压在它们上面的决策连回证据，于是「我们当初为什么这么定」有了答案，而不是「某人记得三月有过一通电话」。
后来的一次测试证伪了发现所依赖的某个假设。引用它的那个决策——以及建立在该决策上的 spec——自动标记 stale。证据链是往前走的，不只是往回追，于是一个被证伪的假设，不会留下一份仍在悄悄压在它上面的「活」spec。
当 Claude Code 或 Cursor 经 MCP 起草 spec，它读到的是真实的决策和其背后的发现——于是被做出来的东西能追溯到当初支撑它的发现，而不是经由一份没人重开的文档做一次有损交接。
发现的产出不是一个功能——是一个附着证据的决策。弄丢那份附着，你就留下了结论、扔掉了理由。用你的方式做发现，让从观察到 spec 的那条链保持完整。
发现决定做什么、为什么；交付把它做出来。现代做法是「双轨」——两者连续并行，而非先后的阶段。发现消解「做错东西」的风险，交付在风险足够低之后执行。
持续的客户访谈、机会-方案树、假设映射、便宜的原型与实验（假门、人工 MVP），以及定量数据分析。你挑那个能消解当前最大风险的方法，而不是每次都全做一遍。
经典的「产品三人组」——产品经理、设计师、工程师——一起做发现，让价值、易用、可行被同时权衡。早早把工程师拉进来，正是阻止发现去提那些「做不出来或做不起」的东西的关键。
那些让人不舒服的：什么会让这成为坏主意、它明确不是给谁的、以最便宜的方式发现自己错了怎么做、如果我们对了下游什么会崩。只会印证既定计划的发现，并不算真正的发现。
用你喜欢的方式访谈、做原型、做分析。把发现和决策作为相连的卡片放进 Draftlize，这样当一个假设被证伪，所有压在它上面的决策和 spec 都标记 stale——而你的 agent 始终从证据、而不是一份过时摘要来构建。
$5 免费开始