用户研究方法论
回答：怎么和用户聊天才能聊出真东西，而不是自我验证的噪音？
发现方法论骨干——Teresa Torres 双卡构成完整闭环：†opportunity-solution-tree（Outcome→Opportunities→Solutions→Assumption Tests 四层树；核心警示"98% 的人把 opportunity 写成了 solution"）← 输入源 †story-based-customer-interviewing（收集故事而非收集答案："Tell me about the last time..."，沿时间线追问"then what happened"，好访谈应像"和朋友喝啤酒聊天"）。配套：discovery-delivery-parallel（回应"没时间做 discovery"的领导质疑）、small-data-decision-making、problem-vs-solution-discovery（Marty Cagan）、double-diamond-process-asana。
一线接触与组织习惯——多来源共识见文末：†talk-to-failing-users（Uri Levine：要和"下载但没注册、注册但没用、用了没回来"的失败用户交谈，Waze 案例——70% 用户看屏幕导航、20-30% 只听语音，两者互不知晓对方存在）、everyone-talks-to-users、call-ten-customers（Jag Duggal）、complaint-storms（Noah Weiss）、customer-support-as-everyones-job、observe-dont-ask-for-pain（Gustaf Alstromer）、listen-for-deep-needs-not-literal-requests（Evan Spiegel）、dollar-driven-discovery（Todd Jackson）、co-creation-with-early-users、dogfooding-playbook-for-creator-tools、reference-customer-discovery、user-centered-performance（Judd Antin）、user-observation-playbook、macro-middle-micro-research。
反馈系统化与信任：feedback-2x2-matrix、feedback-trust-insights（两者同源 Reddit 5 年经验）、customer-feedback-followup-loop、concerning-tweets-feedback-loop、advisory-council-playbook、evidence-guided-discovery-playbook（Itamar Gilad）。效率与工具：automating-customer-recruiting、automating-user-research、canva-community-feedback-benchmarks、startup-researcher-benchmark、user-research-logistics-insight。问题定义（discovery 前端）：problem-reframing-and-constraints、problem-statement-criteria、problem-statement-vs-scope-creep、three-step-problem-solving-framework。
机会解决方案树 OSTOpportunity Solution Tree
团队从"被告诉建什么功能"转向"从 outcome 出发自主决定建什么"时，面对的是一个无结构、高度开放、极难入手的问题。Opportunity Solution Tree（OST）为这个转变提供脚手架，给团队一个可视化结构来组织从 outcome 到解决方案的完整路径。
故事化用户访谈法Story Based Customer Interviewing
大多数团队在用户访谈中问的是脱离语境的直接问题（"你喜欢看什么？""你怎么决定看什么？"），得到的答案是受访者快速编造的，不反映真实行为，也丢失了上下文和细微差异。需要一套可操作的访谈方法来收集可靠的用户故事，并从中发现未被满足的需求。
流失用户访谈法Talk To Failing Users
产品团队只和成功用户交谈，导致无法发现产品真正的障碍，也无法理解与自身不同的用户行为。
发现与交付并行Discovery Delivery Parallel
当领导者说"没有时间做 discovery"时，PM 不知道如何回应；团队误以为 discovery 和 delivery 是串行的两个阶段，导致要么跳过 discovery 硬上线，要么要求暂停交付做研究——两者都不可持续。
小数据决策模型Small Data Decision Making
在大公司中，产品团队常被质疑"你只和几个人聊了就做决策，这可靠吗？"——团队缺乏回应这种质疑的逻辑框架，也无法解释为什么小样本在产品决策中是合理的。
问题与方案发现平衡法Problem Vs Solution Discovery
PM 常被教导"花大量时间验证问题是否存在"，导致在问题发现上过度投入，而真正决定产品成败的解决方案发现却时间不足。
双钻设计流程Double Diamond Process Asana
如何系统性地进行产品发现和开发，避免陷入纯主观意见驱动的决策。
全员对话用户机制Everyone Talks To Users
用户反馈仅停留在用研人员层面，研发和设计团队因听不到一线声音而缺乏对痛点的直观感受和行动力。
呼叫十客户反馈法Call Ten Customers
PM 获取客户真实反馈时，传统大规模问卷调研耗时长、经过多手转达导致失真的问题。
抱怨风暴Complaint Storms
随着团队长期在自家产品中工作，容易变成“超级用户”，失去对新手或下一波客户群体的同理心，难以发现产品中显而易见的摩擦点和痛点。
全员客服机制Customer Support As Everyones Job
团队如何尽早发现用户痛点并快速响应，避免研发团队脱离一线用户。
观察而非询问痛点Observe Dont Ask For Pain
如何真实评估用户痛点的强度，避免用户口头反馈的误导。
深层需求倾听法Listen For Deep Needs Not Literal Requests
如何正确进行用户调研：既要避免闭门造车，又要避免沦为用户的需求传声筒（“给他们想要的按钮”）。
金钱驱动发现法Dollar Driven Discovery
传统的客户访谈容易陷入“友好陷阱”（客户出于礼貌说感兴趣，但实际不会买单），如何通过提问验证客户的真实付费意愿和能力。
早期用户共创策略Co Creation With Early Users
如何确保新产品研发方向正确，且发布即满足高标准需求，避免闭门造车。
创作者工具吃狗食指南Dogfooding Playbook For Creator Tools
产品团队容易脱离用户真实痛点，仅凭数据和访谈无法真正理解创作者在使用工具时的心理障碍和情感旅程。
标杆客户发现法Reference Customer Discovery
如何用一种方法同时完成"验证问题是否值得解决"和"验证解决方案是否对"两件事，并直接产出可用的市场口碑？
用户至上绩效诊断User Centered Performance
诊断产品团队为何在做大量“无用功”的研究，揭示伪“用户至上”现象，帮助团队建立真正以求知和证伪为目的的研究文化。
用户观察实操手册User Observation Playbook
PM 经常只看用户研究报告数据，而缺乏对用户真实反应的第一手体感，难以发现细微的用户需求。
宏中微观研究框架Macro Middle Micro Research
帮助团队识别并减少低价值、低影响力的研究工作，将研究资源聚焦于能真正驱动业务结果和产品改进的领域。
反馈二乘二矩阵Feedback 2x2 Matrix
面对庞杂且声量不一的用户反馈，产品团队如何客观评估并决定优先级，避免被声量大但影响小的需求裹挟。
反馈信任与洞察Feedback Trust Insights
打破产品团队处理用户反馈时的认知盲区，明确哪些反馈该听、哪些该忽略，以及错误处理反馈的代价。
客户反馈跟进闭环Customer Feedback Followup Loop
团队收集了大量客户反馈，但缺乏闭环机制，导致客户不知道自己的意见是否被听见，降低了反馈积极性与产品信任度。
零散反馈处理闭环Concerning Tweets Feedback Loop
极度关注客户的 CEO 经常将零散的客户反馈（如 Twitter 截图）扔进大群，导致团队兵荒马乱、盲目响应，如何系统化处理这类强反馈。
用户顾问团手册Advisory Council Playbook
如何在公共广场（如论坛、评论区）之外，与高参与度用户进行理性、深入的产品探讨，避免公共讨论中为了"赢"而无视产品细节的无效拉扯。
证据导向发现指南Evidence Guided Discovery Playbook
团队认为验证想法必须构建复杂的 MVP，导致验证成本高、速度慢，或在未验证前就全量开发。
客户招募自动化系统Automating Customer Recruiting
产品团队想每周访谈客户，但招募受访者需要大量协调工作，导致访谈不可持续。需要一套系统让访谈像周会一样自动出现在日历上，产品团队只需出席。
自动化用户研究法Automating User Research
PM 需要持续直接接触用户，但缺乏时间手动寻找和安排用户访谈。
Canva 社区反馈基准Canva Community Feedback Benchmarks
缺乏对超大规模SaaS产品处理用户反馈量级与闭环效率的基准参考。
初创用研人员配置基准Startup Researcher Benchmark
为初创公司及早期团队在“何时招聘第一名用研、需要多少用研”的资源配置问题上提供基准参考。
用研后勤工具洞察User Research Logistics Insight
误以为用户研究工具栈的核心只是问卷和数据分析工具，忽视了其他环节的真实工具需求。
问题重构与约束条件Problem Reframing And Constraints
PM 往往在尚未真正理解问题时就急于寻找解决方案，导致方案低效或团队在众多可能方案中犹豫不决。
问题陈述评估标准Problem Statement Criteria
团队在定义问题时容易写得太空泛、预设解决方案或缺乏焦点，导致无法落地执行。
问题陈述防范范围蔓延Problem Statement Vs Scope Creep
项目在执行过程中随着范围和复杂度的增加，容易出现 Scope Creep（范围蔓延），偏离最初目标。
问题解决三步框架Three Step Problem Solving Framework
团队在开发新产品或功能时，往往因为误解了要解决的问题而导致项目失败。该框架用于在进入设计或开发前，正确定义、对齐并坚守问题陈述。