002.jpg
今天早上，运营很气愤的跑过来质问我：“你为什么又砍我的需求？”
本来想揍运营一顿，吐口口水到他脸上，再告诉他：“砍了就砍了，怎么滴了”。但是看了看运营200斤的体重和砂锅大的拳头，忍不住吞了一口口水，笑到：“兄弟，你别急，且听我慢慢说来”
我拉着运营坐下，顺便给他倒了杯水。和他慢慢说下，我们产品经理是怎么评估需求的。
- 产品价值主张
- 产品价值时钟
- Kano模型
- 技术可行性
产品价值主张
我告诉200斤的运营兄弟，我们产品经理评估需求大致分为四步，才扔进需求池的。
《大学》曰：知止而后能定。翻译下就是，知道了最终方向才能知道如何干活。价值主张就是最终方向，就是灯塔。[1]
我们的所有需求都必须是走向灯塔的，否则就是南辕北辙。
所以产品经理接到一个产品需求，第一步一定是考虑该需求是否符合我们产品的价值主张。如果符合价值主张，继续评估第二步；如果不符合，则直接砍掉。
举个例子：比如广汽传祺APP提了一个工业旅游的需求，我们第一步就是考虑这个需求是否符合广汽传祺APP的价值主张，我们认为是符合的才进行第二步的。
广汽传祺APP价值主张：我们的产品是一款APP，它专门为面临汽车生活烦恼现状的广汽传祺车主/潜在车主研发，不同于市面上现有的车主APP，我们将提供传祺品牌特有的数字化、智能化、社区化的汽车生活。[2]
传祺的工业旅游，明显符合产品的价值主张。
产品价值时钟
其次是一定要问下自己，该需求是否有产品价值。
你看下顶部的图，阿格把产品价值做了一个“产品价值时钟”。
怎么确定一个这个需求是否有产品价值呢？主要是根据2个维度：用户价值+商家价值，然后加一个时钟刻度[3]。
比如你最开始提的工业旅游需求，大致在5点种左右：有用户价值，但是商业价值是负的。我们一起商量后微调后，变成了2点点左右的需求：有用户价值，也有微小商家价值。
需求必须是调和用户价值和商家价值的。
只有商家价值，用户价值为负：你上了功能，也基本没人用的。
只有用户价值，没有商家价值：这种功能上了，做了是浪费资源
Kano模型[4]
确定价值后，我们需要敲定排期。
排期怎么敲定呢？主要是看该需求在kano模型中的什么位置。
科普下kano模型，有个日本教授将根据需求质量和满意度，画了一个曲线模型，如上图所示。
将需求分为5中类型：
- 兴奋型需求：没有它产品也没事，有了它可能会开心；
- 期望型需求：它的牛逼，产品就牛逼；它傻逼，产品就是傻逼；
- 无用型需求：一条横线，我都没画；
- 必备型需求：地产行业的七通一平，这个都没有房子还卖的掉[5]？
- 反向型需求：滚；
很明显，我们的工业旅游需求是兴奋性需求：有更好，没有也没事。
可以做，但是优先级不应该很高。
技术可行性
最后一条，是技术可行性。客观的说，我们做产品技术可行性，基本都是放在最后考虑的，满足用户才是第一优先级。
如果技术做不了，砍掉需求，不是应该的么。
如果流程图能走通，技术可行性基本没问题。
工业旅游功能在其他APP已经实现了，技术可行性肯定是通过的。
201斤的运营
听了我娓娓道来，200斤的运营同学，咕隆咕隆的一口喝干我给他倒的矿泉书。
然后，发出了201斤体重才有的声音：“原来你们做产品还有这些门道，一个小小的需求，还有走4道鬼门关才能进正式的需求池。”
201斤的运营：“阿格，我错怪你了，你不要介意呀”
看着201斤的运营，慢慢的松开他另一只砂锅大的拳头，阿格也悄悄的松了一口气，得意的翘起了二郎腿。
特别说明下：物有本末，事有先后；知先而后，则近道矣。这4步的顺序，一定是这样，而不是跳着来的。
以后我们约定个暗号，确认需求吧：比如2点种-必备型，就是P1优先级的需求。
以上全错
如果你做的是toB，则以上全错。
运营犹豫了下告诉我：“虽然我觉得你说的有点道理，但是你砍掉的某个需求是甲方大老板指定要做的，你还是想办法画下原型吧”
啪嚓，正在跷二郎腿的阿格摔倒地上了，果然得意不过3秒钟。
后记：深夜，画好原型的阿格，留着悔恨的泪水，写下这篇文章权当留恋。
阿格-微信号：ag490690
参考资料：
[1]大学，曾子，春秋战国
[2]《增长黑客》，范冰，2015.07
[3]《saas业务价值评估》，白鸦，2018.12
[4]《质量的保健因素和激励因素》，狩野纪昭，1979
[5]《SaaS产品经理课》，程功夫，2019.12
网友评论