mcpField
C
continuous-discovery

continuous-discovery

github.com/refoundai设计与 UI1.5k385 次安装15 周前更新
代码仓库

关于 continuous-discovery

continuous-discovery 是面向产品团队的持续发现技能,帮助将客户研究融入日常产品决策。它涵盖直接接触用户、梳理机会及验证假设的方法。

主要功能

  1. 01评估团队与用户的直接接触
  2. 02建立定期发现活动
  3. 03梳理需求、痛点与愿望
  4. 04用原型验证假设
  5. 05将研究融入产品交付

适用场景

  1. 01安排定期客户访谈
  2. 02区分未满足需求与功能构想
  3. 03在全面开发前验证假设
  4. 04通过观察客户工作发现流程阻力

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/refoundai/lenny-skills --skill continuous-discovery

安装后在 Claude Code 中输入/continuous-discovery确认已加载。

附带文件references/artifacts.mdreferences/guest-insights.md

详细介绍

持续的产品发现

将客户反馈从周期性琐事转变为高频驱动产品决策的引擎。

借助 Lenny's Podcast 和 Newsletter 中 23 位嘉宾及文章分享的见解,帮助用户持续开展产品发现。

如何提供帮助

  1. 审视当前的接触距离 - 评估团队与用户直接互动的频率和质量,并找出现有的把关者。
  2. 制定发现惯例 - 帮助建立定期访谈、演示日和支持轮班机制,让整个产品三人组都参与其中。
  3. 梳理机会空间 - 指导将原始反馈转化为可视化图谱,呈现未满足的需求、痛点和愿望。
  4. 加快证据收集 - 建议采用轻量的方法,在投入完整开发之前,通过原型和行为映射来验证假设。

核心原则

区分需求与解决方案

Teresa Torres:“我可以告诉你,机会是未满足的需求、痛点或愿望,这很好。但我也可以告诉你,写下机会的人中有 98% 都把机会写成了解决方案。因此,我们往往真的很难区分问题空间和解决方案空间。”

真正的产品发现要求严格将每个机会定义为未满足的客户需求,而不是预先设想的功能创意。

消除开发者与用户之间的层级

Brian Tolkin:“每天都和客户交谈,比如一对一地引导客户完成入门流程、回复支持工单;没有集中的支持团队,也没有离客户更近的人,对吧?所以我认为,这种基础实际上能让他们真正理解什么推动了业务,并与客户保持紧密联系;而这也为他们进一步思考如何以更具规模化的技术方式开展实际开发奠定了很好的基础。”

通过消除集中式过滤环节,让产品团队直接参与客户引导和支持,才能建立深刻的同理心。

将产品发现融入执行

Itamar Gilad:“Google 是我所说的以证据为导向的公司。它非常重视关注客户、提出大量创意、查看数据,以及观察这些创意的实际成效。他们不避讳推出粗糙、不完整的 Beta 版本,并从中学习;随后,他们期望人们根据结果采取行动。”

推出粗糙、不完整的版本来收集真实场景中的数据,并据此决定是调整方向,还是继续推进工程任务。

优先关注高信号的非正式交流

Jeff Weinstein:“客户觉得有必要特意主动和你谈论某个问题,这本身就是一份难以置信的礼物。我会离开一场会议,只为回复他们一条消息。如果你能和 5 或 10 位这样的客户通过短信保持友好沟通,就能获得大量直接信号,而且这种影响会不断扩散。”

与积极主动的用户直接进行非正式交流,例如通过短信沟通,往往比结构化研究提供更高质量的信号。

让研究持续参与并协同

Judd Antin:“对我来说,解决方案很简单,但并不容易。我们需要重塑产品开发方式,让研究更充分地融入其中。这意味着建立持续稳定的合作关系,让研究人员、他们的工作以及他们提供的见解,从头到尾都成为流程的一部分。”

研究应贯穿整个开发流程并作为协同伙伴,而不是仅在流程开始时才被临时调用的服务。

通过直接观察发现阻碍

摘自《The unconventional Palantir principles that catalyzed a generation of startups》:“你必须成为用户,才能理解这个概念。我不是在精神层面上说要‘像用户一样思考’,而是说要真的用你的产品做他们的工作,作为团队中的一员,看看你能从中学到什么。”

与客户并肩完成他们的实际工作,从而发现仅靠访谈无法揭示的运营阻碍。

让技术人员进驻客户的工作场所

Nabeel S. Qureshi:“有一种不同类型的工程师,会被派到一线。你可能会从周一待到周四,真正走进客户工作的那栋楼,与他们并肩工作。你会真的在那里有一张办公桌,因此,这种工程师后来被称为前线部署工程师。”

要做好高价值的企业客户探索,最有效的方式是让工程师在客户办公室现场工作,找出具体的瓶颈。

模板与框架

  • Continuous Discovery vs. Project-Based Research(Teresa Torres)——重新思考探索如何融入产品工作:它不是交付前的一个阶段,而是与交付并行、持续进行的一种习惯
  • Opportunity Solution Tree Framework(The Best of Lenny’s Newsletter 2023)——Teresa Torres 提出的持续产品探索框架,将成果、机会、解决方案和实验串联起来。
  • Product Scrapbook (Notion Database)(Product manager is an unfair role. So work unfairly.)——一个轻量级 Notion 数据库,按战略泳道整理客户洞察、反馈和证据,以便更快地开展探索和规划。
  • Forward Deployed Engineering (FDE) Model(The unconventional Palantir principles that catalyzed a generation of startups)——一种客户探索和产品开发方法,工程师会长期(数月而非数小时)进驻客户环境,去
  • Exposure Hours(Guillermo Rauch)——Vercel 内部的一项运作原则,用于培养产品品味和同理心。
  • Product Trio Model(Teresa Torres)——一种协作工作模式,产品经理、设计师和软件工程师作为平等伙伴,共同进行探索并作出产品决策,而不是 th
  • Customer Support as Everyone's Job — Implementation Rhythm(What working at Figma taught me about customer obsession)——Figma 处理任何客户互动时采用的三步节奏,涵盖支持工单、销售电话和偶遇交流
  • Go to the Source Checklist(First-principles thinking)——五种获取一手信息的方法,而不是依赖二手假设

完整清单及详情请参见 references/artifacts.md。

帮助用户思考的问题

  • “上周,你们团队花了多少小时观察客户完成工作?”
  • “最近一次让你们决定放弃或调整某项功能的客户洞察是什么?”
  • “过去 14 天里,你们工程团队中有哪些成员直接与用户交流过?”
  • “你们是否将尚未满足的客户需求与功能请求列表分开跟踪?”
  • “目前有哪些内部把关人或集中式团队挡在开发人员与用户之间?”
  • “你们目前如何存储和整理客户证据,以便在规划时随时查阅?”

需要指出的常见错误

  • 把探索当成一个阶段 - 探索应当是一种并行且持续的习惯,而不是在开始交付前进行的一次性项目。
  • 听从用户明确表达的立场,而非关注其动机 - 用户常常会提出一套做法或要求,以掩盖驱动其实际行为的深层动机。
  • 在访谈中聚焦解决方案 - 早期探索应着重深入理解用户的根本需求,而不是推销具体的功能创意。
  • 为少数意见强烈的用户构建产品 - 过度重视最活跃用户的反馈,可能导致产品无法满足更广泛市场的需求。

深入了解

如需查看来自 23 位嘉宾的全部 27 条引用见解,请参阅 references/guest-insights.md

相关技能

  • 客户访谈
  • 创意验证
  • 产品实验
  • 定义 ICP

评论

支持 Markdown