作为产品经理，如何验证我们的需求假设
需求是产品经理在日常工作中每天都在打交道的，我们每天总是在想用户可能需要这个，用户可能需要那个。
然而我们想的并不一定就是用户真正需要的，这就需要对我们提出的假设进行验证。
用户有各种各样的需求，有的需求是大众需求，例如：网上购物需求、线上打车需求。
有的需求是小众需求，例如：高达爱好者交流需求、老年人跳广场舞需求，虽然面向的人群有限，但用户的需求也足够强烈。
还有一部分就是伪需求了，大到一个产品方向、小到一个产品功能，你觉得用户需要这个，但真正做出来之后却发现用户根本不买账，比如共享经济比较火的时候出现的共享雨伞、共享篮球等等。
我们也许会问，既然是伪需求，那么为什么还有那么多的人要做这件事，特别像一些创业公司，花费了百万千万的投资，到头来却是竹篮打水一场空，最后不得不关门大吉。
首先我们必须承认一个事实，每个人的成长经历、眼界认知、行业经验等等都不同，而这些就导致了我们对需求的理解不同。
同样一个需求，可能是一个伪需求，但也有人觉得是用户的刚需。
我们经常容易犯的一个错误就是站在自己角度看问题，记得当年快手这个产品刚诞生不久，自己也下载过，打开里边的内容觉得这个整个产品看起来比较“low”，“有人玩才怪”，而如今快手的市值已经突破了1万亿港元。
周鸿祎也曾分享过一个他自己的案例，在滴滴很早期的时候，360是有机会投资滴滴的，但老周自己有司机接送，已经很多年没打过车了，便觉得现在打车的人应该没多少，市场不会太大，后来就没投，错过了入股滴滴的机会，又是一个几十甚至上百亿美金的教训。
我们常说说产品经理要站在用户角度思考问题，这句话没毛病，但说实话要做到这一点确实不容易。
就像让你去做一个广场舞产品，我们需要站在老年人角度去思考这个产品，二三十岁的我们从来没有跳过这个，对老年人的需求也不了解，就是想破脑袋也想不出来该怎么做。
因此还有一个做产品方法理念，就是多跟用户交流，不管是访谈聊天，还是看用户反馈等，据此了解用户真实的想法，加深我们对需求理解。
不论是换位思考、还是多接触用户、了解用户真实想法，我们总是会受限于个人对需求理解程度、样本数量的大小等因素，所以我们最终发掘的用户需求可能还会是我们的一厢情愿。
特别是现如今大部分需求都已经被满足的情况下，需求的真伪越来越难判断，要求我们对需求、对用户理解的更深刻，同时还要去验证是否和我们当初设想的一样。
这还不像互联网快速发展的时候，很多需求需求都是显而易见的，尽管快速迭代获取用户就是了，根本无需在验证需求上花费太多时间。
那么如何验证我们的需求是否跟我们的设想一致呢？
这里边还得分为两种情况：一是比较大的产品模式的验证，比如你有一个想法，想创业做一个产品，这种情况更多是验证你的想法；另外一种是产品版本迭代的验证，验证的更多的是产品里的功能模块。
01 产品模式验证
首先说产品模式的验证，我们常说大道至简，许多知识理论的本质都是一样的，只不过同一套知识理论应用在不同的场景而已。
我们先拿一个日常生活中事情举个例子，买房是我们人生中的一件大事，毕竟房子是高标的物，有时候还得掏空好几个钱包，看了好多个，最终决定在哪买的时候还是谨慎再谨慎，因为一旦买错了，造成的损失影响实在太大。
买房时要考虑位置、交通、学校、生活便利性等各方面因素，因为可能我们对这片区域不熟悉，所以这些因素可能只是了解一个表面。
可能你看房的时候是晚上，路上车比较少，所以房子内还算比较安静，可当你住进了才发现白天的噪音确实很大；可能中介跟你说周围有个大超市，可当你住进来时候却发现离你四五公里；更夸张的，之前在新闻上看到的用户买完房之后发现屋后就是墓地。
所以这里边会有很多潜藏的问题，一旦买错了，产生的成本还是比较高的。
但有的人会这样做，当决定要买这片房子时，会先在这个小区或者附近租个房子，住个七天半个月的，基本上对所有的情况都能有一个比较深入的了解，这个时候再决定买不买，潜藏的风险就小了很多。
这就是一个典型的验证我们假设的过程。
当你觉得这个房子的位置、学区、生活便利性等都很不错时，并不是直接签合同交钱，而是先通过租房形式验证你的假设是否正确，只有真正验证过后再做决定，验证这个的成本可能最多一两千块钱，可是她却能帮你减少了很多风险。
回到互联网领域，有一个产品理论叫MVP（最小可行性产品），看概念好像比较难懂，其实它的本质同我们举的买房的例子是一样的，并不是一上来就开始上手做这件事，而是先通过低成本的手段快速验证我们的假设。
我们经常看到有些创业公司，老板有一个“石破天惊”的想法，成功的“忽悠”了一帮投资人拿了几百万投资。
项目启动后，老板特别注重用户体验、特别追求完美，不等产品打磨好决不能推向市场。
当整个团队加班加点做了一年，老板觉得产品打磨的差不多，该放大招了，终于等到自己上场了，于将产品开放给用户，结果却发现使用者寥寥无几，满心欢喜变成泪眼汪汪，整个团队一整年的成果瞬间化为乌有。
MVP的理论核心其实就是低成本的快速试错。
02 低成本的快速试错
当你有了一个想法时，首先通过一个低成本的手段去验证你的想法。
假设你觉得男士化妆品很有前景，想做一个专卖男士化妆品的产品，并不是一上来就建网站、做App，可以先通过你的朋友圈（前提是好友里有你的目标群体）卖一段时间试试，看看大家的反响如何。
如果无人问津，那么可能目前市场还不成熟，大家对这个的需求不大；如果有许多人感兴趣，那么你可以在朋友圈跑通流程之后，逐渐增加公众号、小程序等新渠道。
其次就是要快，对于我们来说，时间是最大的隐形成本，时间就是金钱，时间就是机会，所以要快速的验证你的想法是否正确，如果验证正确，那么需要快速迭代占据市场。
如果错误，那么要及时止损，不花费过多时间，寻找其他的方向再次尝试。
以上跟大家分享了通过MVP形式验证我们的想法，接下来再跟大家聊聊如何验证我们产品功能模块。
03 产品迭代验证
作为产品经理，我们日常工作中最重要的一部分工作就是产品的迭代了，每一次迭代的功能模块如何设计、迭代后的效果如何，都需要我们进行验证，通常对于一个功能模块，有以下几种验证手段：
1. 改版数据
数据是最具有说服力的形式，当然前提是数据的埋点得正确、数据分析时对比的维度也要一致。
比如说这个版本做这个功能预期是提升产品的人均时长，那么我们可以在版本上线后查看新版本的人均时长数据，比较老版本提升了多少，如果没有提升，那么我们就要去想是哪个环节出了问题、还是当初太理想化了
2. 用户反馈
用户反馈是产品经理了解用户的常用手段之一，虽然说用户反馈也是验证功能迭代的一个手段，这个这个手段其实比较主观，并没有太大的说服意义。
像我们去年对产品做了一次升级，产品的页面变化较大，结果一批老用户就来吐槽，因为他们习惯了原有的产品样式，但对于我们来说，产品不可能一直停留在几年前的风格样式。
而且很多觉得改版好的用户他们也大概率不会发表意见，属于沉默用户，所以给人整体感觉上好像大家都在吐槽，但其实仔细一看，吐槽的只是占据所有用户中很小的一部分。
3. AB测试
有时候在设计产品的时候，可能有多个产品方案，每个人都说不准哪个方案更好，那么这个时候就可以使用AB测试这种形式。
AB测试是将我们的假设制作两个（A/B）或多个（A/B/n）版本，除了我们想要验证的假设之外，其他所有的条件都不变，在同一时间维度内目标人群随机访问这些版本，然后我们看每个版本的数据情况。
例如几年前做直播产品时，关于直播feed流是用单列大图、还是双列小图，大家都各执已见。
后来我们就把feed流内容样式分为AB两个版本，A版本用户使用的是单列大图、B版本用户使用的是双列小图，其他部分不变，AB版本随机分配50%的用户，最后看AB版本的数据效果。
当然如果公司没有现成的AB测试平台，得先需要搭建AB测试的环境，还有一定的开发量，另外在做AB测试时有些事项也需要注意：
首先是AB组一定要随机分配，绝对的随机几乎不太可能，只能尽可能的接近真随机；
其次在测试这块时间内，用户的行为是不变的，而且测试时间要长，因为有些新功能可能需要给老用户一定时间去适应。
另外AB测试毕竟还有一定的成本，并不是所有的改动都需要用AB测试，否则就是小题大作了。
4. 灰度测试
微信每次发布比较大的版本，我们会发现有些人已经用上了新版本，而自己去检查更新却提示已经是最新版了，这其实就是微信更新的灰度策略。
因为微信用户体量实在是太大，每天有10.9亿用户打开微信，3.3亿用户进行了视频通话，有7.8亿用户进入朋友圈，1.2亿用户发表朋友圈，如果功能更新一下全部推给所有用户，即使腾讯的测试再严格，也怕万一出点bug什么的，那影响的用户可太大了。
所以通过灰度测试的形式，先把新版本推给一部分用户，比如10%的用户，这些用户使用过程中没有什么问题之后，在逐渐扩大用户的比例，直到推给所有用户。
除了担心有潜在问题之外，通过灰度测试也可以看到用户对这个版本的反馈，比如用户如果对其中的一个功能比较反感，那么也可以及时调整策略。
灰度测试一般适用于体量较大的产品的迭代更新，特别是产品要推出全新的功能或者大的版本改动，那么验证我们的此次迭代，灰度测试是一个比较安全保险手段。
以上就是跟大家分享的验证产品需求的一些方法，这些其中的思维模式也并仅仅不局限于我们做互联网产品，在日常生活中我们也能找到很多相似的地方，希望能对大家有帮助。
#作者#
HQ，公众号：产品那些年。社交路上不断前行的创业产品汪。关注社交社区，打过工创过业，擅长产品规划与设计，纯干货，不掺假。
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
