需求验证这个问题，往往会牵扯到不同部门，比如产品和需求部门，又或者是在产品部门内部引发争论。所以，到底怎么做需求验证才更有效呢？这篇文章里，作者做了分享，不妨来看一下。

“Your most unhappy customers are your greatest source of learning.

最不满意的客户是你最宝贵的学习资源。”

——比尔·盖茨 Bill Gates

对于很多创业团队来说，需求验证的时候，就是最容易开撕的时候。

不光是产品和需求部门会撕，产品内部也会撕。

人脑子打成狗脑子，争的其实就是一个主题：

“你听我的，我说的对！”

一、定性和定量互相验证，会比较容易得到答案

↑我将以此图为大纲，帮助创业团队完善产品能力。

今天这一篇，开始针对看板图的最左上角的：

需求分析能力 -> 需求验证

在帮助创业团队做产品系列，关于创业团队的产品能力看板的需求分析能力这个分类，之前讲过了需求涌现，也讲过了需求分析。

关于需求验证的这篇，真就超级简单，也就一句话：

定性和定量可以交叉验证。

当然，对于大型的互联网团队来说，需求验证方法极其复杂，商业调查，用户体验报告、A/B测试、内测版本、灰度发布等等，不一而足。

但这些对于创业团队来说，成本实在太高了，而这种交叉验证的方法，非常简单粗暴。

所以今天就少讲理论，讲点儿例子就行。

1. 定性验证定性，最后往往就只能吵架

一个定性的假设从何而来？

按照之前的所述，可能来源于内部需求涌现时的讨论，可能通过用户访谈、可用性测试等方式得到的定性假设。

在内部无法达成一致的情况下，就需要进行验证。

举个简单的例子：

我们当时做民宿的时候，有用户就希望可以在搜索列表中，增加“可以做饭”的标签展示。

这个需求，很多用户会直接表达出来；同时运营人员也十分建议，因为他们会在一线接触到这些用户。

↑年代久远，就画个示意图吧

大家都知道民宿的特点，全家出游的几率比较大，而且又有很多人是长租。

所以民宿是否允许做饭，可以在列表中一览便知，这个需求对这类用户来说，就会无比的强烈。

但产品部门却表示反对，认为这属于小部分需求的无限制放大。

只是所谓“会叫的轮子先上油”而已。

那内部此刻就会陷入“用户有需求你们不做”和“这是个伪需求”的经典撕战中。

大家各自搬出定性的假设出来，互相对轰。

其实有经验的团队知道，这就是个可以通过定量分析来验证定性假设的时候。

在某版本中上线了功能并埋点后，最终发现：

1. 列表加入此元素，不能提升整体转化率；
2. 但对多人入住情况，会有些微转化提升。

最终的改进方案就是，并不在列表中展示这个标签，而是藏在了二级过滤中供用户使用。

↑ 同样，体会下这个示意图

这里可能有人会问了，如果任何一个定性假设都通过需要上线验证，那成本会不会非常的高。

是这样的，但同时我们也能做到：

1. 如上一篇的内容所说，调查问卷也可以起到类似的作用；
2. 需求多了自然也会排优先级，同时和运营部门的也会逐步优化磨合，大家会慢慢的有感觉，知道哪些才属于有效需求。

2. 定量验证到定量，最后往往就只能迷茫

一个定量的假设从何而来？

按照之前的所述，可能通过数据分析、调查问卷的方式得到了定量的假设。

如果说前者“定量分析来验证定性假设”会比较容易理解，那么这里就有点绕了。

还是举个例子比较简单。

之前在某垂直搜索引擎酒店事业部做产品的时候，曾经遇到过想要分析酒店列表页各元素重要性的议题。

目的是想让整个列表中的元素更简单干净一些。

↑ 再画个示意图吧~

用的就是纯粹的数据方法，把这上面的元素一个个都拿掉，逐步上线版本，然后观察转化率的变化。

结果出现了非常奇妙的情况。

1. 就是拿掉了酒店所在商圈的元素，发现用户的转化率没有显著变化；
2. 然后又拿掉了酒店星级的元素，发现用户的转化率也没有显著变化；
3. 甚至最后拿到了酒店的图片，发现用户的转化率依然没有显著变化。
4. ……

到最后拿不掉的就只剩酒店名称和价格了。

如果按照此时的数据结果的话，那么就会得到一个暴论：

酒店的搜索结果页，只需要有名称和价格就可以了……

这个当然不可以接受。

如我们所见，没有任何的酒店搜索平台敢于这么做。

背后当然是有原因的，就是NP≠P。

注意，这原本是一个数学概念，只是泛化到了产品应用概念上，后面有机会我会单开一篇来谈谈。

……即多个元素组合起来的作用，不等于单独元素加起来的作用，元素组合的过程中，会涌现出新的价值。

这样就不能用机械的定量方法来进行验证了，那最后也就会陷入迷茫。

此时通过定性验证就会明晰很多。

还是这个例子，假如我们通过某种定量方法：

某个元素（如商圈）去掉了对转化率没有影响，可以按照奥姆剃刀原则去掉。

那么就可以组织用户访谈或者可用性测试，来进一步验证这个定量假设。

1. 如果定性方法也同样能够证明，那就可以大胆的去掉。
2. 反之，如果用户认为某元素（如酒店图片）对自己帮助很大，那么即便定量数据上暂时认为没有影响，也需要非常谨慎。

这样就能做到优化酒店列表的任务目标。

二、定性和定量循环滚动验证，直到未来

好像上面讲的两个都是住宿行业列表的例子。

其实，这也是拿自己熟悉的经历来做举例。

对于整个住宿行业来说（乃至整个电商行业），搜索列表页是关键性页面，用户浸泡的时间也是占了大头。

那么，定性和定量循环验证，是什么意思呢？

比如住宿行业各大平台的搜索列表页，现在和十年前完全不一样，和十年后也一定会完全不一样。

但这种不一样，并非是脱胎换骨的不同。

就好像是“街上流行红裙子”，过了一段时间就会有反复。

这是因为竞争环境、用户消费习惯、用户信息检索能力、市场大环境等等始终都在动态变化。

各住宿平台都必须要契合当下而已。

还拿住宿搜索列表页来举例子，这里如有专职的产品经理：

1. 切入到某问题，如能否加上“可做饭”的标签，可以通过定量分析验证定性假设。
2. 在定量分析此问题的同时，数据中又会发现定量的假设，如用户好像青睐“可自助入住”的住宿，此时就可以继续安排用户访谈等定性分析方法，来验证这个定量假设。
3. 而在下一次定性分析中，通过用户访谈，肯定也会提出新的定性假设出来。
4. .……

这样就叫循环滚动验证。

对于此核心前端页面来说，这个产品经理就可以一直做下去，不断探究用户需求，且一直和同行保持竞争优势。

工作内容就这样打开了。

这对创业团队，更是重要。