产品经理深夜食堂，满足所有刁钻的味蕾

点融黑帮·2016-10-13 21:34

从现象级APP的爆发式增长到消逝，到“海底捞你学不会”的经营法门，产品在实现过程中到底要考虑多少用户需求？

在《如何成为一头优秀的服（产）务（品）员（汪）》中，以餐厅点菜为切入点，讲解了产品经理对需求的来源管理，在充分了解需求本质——用户动机的情况下，接下来面临的问题便是，如何实（做）现（菜）？

需求的实现管理

我们已经了解到了客户的需求：客户想吃腐竹，带茄丁不带肉的宫保鸡丁，那么如何操作，先做哪个？

理论先行。

1、KANO模型分析法

需求的优先级首先应该根据需求对用户的价值来判断。

日本教授狩野纪昭在1984年提出构了KANO模型，用来对客户需求的满意度进行分类，一共分为五类影响因素（引自维基百科）：

有两个反向因素的例子，豆瓣把自己的消息系统的名字由豆邮改成私信，仅仅是改个名字，结果遭到豆瓣用户集体反对，不得不重新改回来。支付宝的六一运营活动，也是改名字，给大家的名字后面都加了个宝宝，不少在意安全的用户，也把矛头指向了产品经理。这些站在用户对面的反向需求，用户必然会不满意。

无差异因素则更加悲凉，这种需求很少出现，你费力做出个功能，结果用户一点感知都没有，某种意义上来说，比反向因素更加不值得浪费资源去做。

（需求进展和用户满意度的关系图，来源：维基百科）

可以看到其中的三条曲线basic needs（基本型需求），performance needs（期望型需求），Delighters（兴奋型需求）的实现过程。

做一份宫保鸡丁属于基本需求，想吃到腐竹是期望需求，而兴奋型需求，则是类似海底捞的做法，等待的过程中给你提供刷鞋，美甲等更多的服务，给用户带来惊喜。

实现优先级上，首先满足基本需求，其次是期望型需求，然后根据产品的生命周期和市场情况，调整兴奋型需求的优先级。

比如在产品成长期，可以恰当做些爆点需求，增加曝光度，来快速拉升产品注册人数。

MVP最小可行产品：

互联网迭代越来越快，爆发出来的很多需求需要快速验证，这个时候做一个快速的可行性产品是成本最低的试错方法。

一般来说，MVP产品可以从以下几个纬度确定功能范围：

用户纬度：MVP集中满足核心用户/种子用户的需求；
功能纬度：找出最核心、与痛点最相关、最小的功能组合。减少需求永远比增加需求更难。这里可以用反向分析法，如果去掉某个功能，会不会影响主体流程。某个需求如果上不了线，用户会不会流失，如果回答是会，则放入mvp中实现，如果不会大胆的放到后续的迭代中做；
产品原型：现在更多的产品会通过微信公众号的形式验证，比如知乎的付费问答值乎，最开始的mvp产品形态主要是知乎服务号的自定义菜单或者朋友圈的分享，如果一开始就放在App端，如果用户没有来得及更新，就错失了市场机会（同一时间，分答已经在市场上跑马圈地了）。

现在很多的硬件创业团队mvp做法则是设计好了方案，到众筹网站进行展示，收集产品反馈，获得早期用户，快速判断产品是否符合市场需要。

按照产品需求的优先级分段交付：

现在的互联网产品思维都要求快速迭代，并不像传统的软件产品，需要所有功能完备才能推向市场。

分段交付可以理解为后续每一个迭代都是一个mvp，只不过跟从0启动的产品mvp判断标准不同，按照需求优先级来定义每一次分段交付的内容。

分段交付的优点有很多，也是scrum开发模式推荐的做法：

评估产品优先级除了上面提到的用户价值模型还可以从一下几个方面评估：

需求价值：用户价值即上面KANO模型评估结果，基本需求优先做，期望型需求尽量做，兴奋型需求要有一两个，作为产品亮点和差异化竞争策略需要。商业价值，是否对公司有利；
需求主体：是哪一类用户的需求，是否是核心用户，新用户，还是留存用户。受众面是不是足够大；
需求成本：需求实现的需要投入的技术资源和时间资源，以及是否依赖内部外部的一些资源；
需求强度：用户对该需求有多强烈，需求的频率如何。

假设我们仍然接受了客户的需求，不考虑商业价值亏损的情况下，需要做一份加腐竹的宫保鸡丁，满足的只是个别用户的单次需求，而且实现成本又很高，所以这个需求从优先级上是非常低的。所以不如先上个凉拌腐竹，再做个宫保茄丁：