产品探索：用证据决定做什么

产品探索要在花一个季度开发之前，先决定什么值得做。本文讲探索要检验的四类风险和对应方法，并用一个完整例子演示使用数据、访谈、回放和假门测试如何导向一个清楚的决定。

什么是产品探索

产品探索（Product Discovery，也叫产品发现）是产品团队在投入开发之前做的工作：弄清哪些问题值得解决、哪些方案行得通。它的产出不是功能，而是足以做出决定的证据。

它和交付（开发和上线）并列。只交付的团队会做出没人用的功能；只探索的团队永远上不了线。好的团队每周两样都做。

探索要检验的四类风险

每个想法都带着四类风险，探索就是用低成本把它们降下来：

1. 价值：客户会想要、会买吗？
2. 可用性：他们能弄明白怎么用吗？
3. 可行性：凭现有的时间、能力和技术，我们做得出来吗？
4. 商业可行性：对业务行得通吗？定价、法务、客服、销售有没有障碍？

方法和它们回答的问题

下表把常见方法和它们检验的风险、成本对应起来。数字和对话要搭配：数据说明在哪里、有多少，访谈说明为什么。见定性数据和定量数据。

每个重要问题，都搭配一个基于数字的方法和一个基于对话的方法。

一个完整的例子：从数据到决定

一个 B2B 分析产品的试用转化不理想，团队做了四周的探索（示例数字）：

1. 数据说明在哪里。 一个月的 1,200 个试用里，55% 从没连接数据源，而这是看到任何价值之前的一步。漏斗指向的是某一步，而不是整个产品。
2. 访谈说明为什么。 和卡住的试用用户通了 12 次电话：7 人找不到 API 密钥，3 人需要管理员来创建，2 人只是在评估。
3. 回放证实了这一点。 连接步骤的 25 段录像显示，大家打开设置、四处找、最后放弃，平均每人尝试 3 次。
4. 假门测试检验需求。 给 1,000 个试用访客展示一个「从 CSV 导入」按钮；74 人点了（7.4%），看到「即将上线，要不要抢先体验？」的提示。
5. 原型测试检验可用性。 5 个用户试用可点击的 CSV 导入原型；4 人不靠帮助完成，1 人在列映射上卡住。

决定： 做 CSV 导入，把列映射做得更清楚，并把 API 密钥的说明直接放进连接页面。每一步花的是几天，而不是一个季度。

让探索持续下去

• 每周和客户聊。 一两次简短访谈，就能让假设保持真实。
• 每周看数字。 一个漏斗、一个留存视图、几段回放。
• 维护一张机会清单。 记录有证据、有规模的问题，而不是功能愿望单。
• 检验假设，而不是检验想法。 写下一个想法要成立必须满足什么，先测风险最大的那一条。

常见误区

• 问客户该做什么。 问他们上一次实际怎么做的，而不是他们想要什么。
• 把探索当成一个阶段。 一次性的调研很快就过时了。
• 只做定性或只做定量。 12 次访谈量不出问题有多大；漏斗解释不了原因。
• 假门测试不说实话。 告诉用户功能即将上线，并给点回报。
• 把 MVP 和探索测试混为一谈。 MVP 是上线的产品；大多数探索测试要小得多。

在 TapCub 里做定量这一侧

在 全端分析 里用自己的事件建漏斗，找到用户停下的那一步。看那一步的会话回放，了解他们尝试了什么。把假门按钮记成一个事件，按分群或套餐比较点击率。上线后，看新路径有没有提高激活率，也就是用户初次看到价值的那个点。另见产品使用分析。

相关阅读

• 产品验证：先测需求，再动手做

另见：什么是机会解决方案树？结构、示例和常见错误。