需求验证方法极其复杂

Papri000

当然，对于大型的互联网团队来说，，商业调查，用户体验报告、/测试、内测版本、灰度发布等等，不一而足。 但这些对于创业团队来说，成本实在太高了，而这种交叉验证的方法，非常简单粗暴。 所以今天就少讲理论，讲点儿例子就行。 定性验证定性，最后往往就只能吵架 一个定性的假设从何而来？ 按照之前的所述，可能来源于内部需求涌现时的讨论，可能通过用户访谈、可用性测试等方式得到的定性假设。 在内部无法达成一致的情况下，就需要进


行验证。 举个简单的例子： 我们当时做民宿的时候，有用户就 智利手机号码清单 希望可以在搜索列表中，增加“可以做饭”的标签展示。 这个需求，很多用户会直接表达出来；同时运营人员也十分建议，因为他们会在一线接触到这些用户。 ↑年代久远，就画个示意图吧 大家都知道民宿的特点，全家出游的几率比较大，而且又有很多人是长租。 所以民宿是否允许做饭，可以在列表中一览便知，这个需求对这类用户来说，就会无比的强烈。 但产品部门却表示反对，认为这属于小部





分需求的无限制放大。 只是所谓“会叫的轮子先上油”而已。 那内部此刻就会陷入“用户有需求你们不做”和“这是个伪需求”的经典撕战中。 大家各自搬出定性的假设出来，互相对轰。 其实有经验的团队知道，这就是个可以通过定量分析来验证定性假设的时候。 在某版本中上线了功能并埋点后，最终发现： 列表加入此元素，不能提升整体转化率； 但对多人入住情况，会有些微转化提升。 最终的改进方案就是，并不在列表中展示这个标签，而是藏在了二级过滤中供用户使用。