比起每个需求都是重点，求每个重点都一次性做好；不如“快步小跑”，制作MVP产品，一步步迭代。

柠檬和柚子，两个委屈的产品经理：

“最小可行化迭代≠没做好！”

柠檬设计了公司的一个创业项目。她和几个技术加班加点，每天都是办公室最晚走的人，但她觉得委屈的是：领导和其他同事话里话外好像都嫌弃新做的功能不完善。

“一期的东西怎么能苛求完善！“柠檬心里在咆哮“这叫最小可行化产品好吗！MVP呀！连这都不知道！“

绝望……拒不标注优先级的庞大需求

柚子是个国企小产品，公司氛围一片和谐，但柚子觉得自己很可悲，因为组里每个人都不理解产品工作方式，他觉得心累。

比如今天，战略部出身的项目总监扔给他一个需求：开发一个供应商管理后台，密密麻麻的4页A4纸，总监讲了足足1小时，柚子昏昏沉沉听完：“您给标个优先级吧？咱们一期先做最核心的，一步步迭代。”

”这些都是最核心的呀，缺哪个都没法用！“

柚子感到绝望，最少半年能做完的后台，总监却坚持每个点都是核心功能，拒不接受分期实现。

一、不能妥协的原则：坚持小步快跑，不憋大招

《精益数据分析》是我看的第一本产品专业书，在这本书里知道了MVP-最小可行化产品这个概念。

在这种产品开发方式下，一次优秀的迭代比拼的不是完善——恰恰相反——比拼的是简单：功能点拆分得有多细，步子迈得有多碎，迭代频率有多高，对用户和时长响应时间有多快，这些是践行最小可行化迭代或者说精益开发原则的产品经理们追求的节奏。

简单说：就是步子小且快，而且在每一步校对方向。

我本人是这种开发方式的忠实拥泵。这种方式的好处已经得到无数论证，如果你想让你的产品迭代跟得上快速变化的市场，而且尽量避免做无用功，最小可行化是应该选择的方式。

爬上一个台阶再够另一个台阶，不管是产品经理还是技术团队都会觉得更轻松。但遗憾的是：别的岗位未必能理解这种好处。

假设一个电商的活动策划，当然希望有各种花样能玩，恨不得一次性做出个淘宝来才好。这时候你对他说，咱们刚上线一个月有很多事要做，要不先做个基础优惠券，只能打折没有任何玩法可以吗？

他必然是不高兴的。

你错了吗？没有，你选择的是最灵活最不容易让技术团队走弯路的工作方式。活动策划错了吗？也没有，他需要的是尽可能多的玩法好实现获客目标。

在这种时候，产品经理怎么争取其他岗位的理解呢？

我的办法是：如果是相对复杂的功能，不管一期能实现什么都要制定较长时间排期，并且把远景和近景都告诉需求方，让他清楚“不是砍需求，只是拆分需求分期实现，因为这样效率最高”。

具体分3步沟通：

1. 提需求时不要说“不”：让对方知道你是愿意配合的，把需求都记录下来，并且请对方定下优先级，至少3级。管住自己，尽量不说“做不了”，即使“APP图标和手机壳颜色保持一致”这样的需求，还有接下来的机会拒绝，这时候开放的态度比什么都重要。
2. 规划全景：把对方提出的完整需求进行规划。不合理的需求充分沟通后砍掉；合理但是优先级不高的需求放到一个较长的排期了，这样做的目的是让对方知道你真的有计划做。较长时间的排期不用担心被打乱，毕竟互联网公司，计划就是用来被打乱的……
3. 做完以上2点后，双方就能关注在合理且优先级高的需求上了。

二、小步快跑原则下，半年排期有意义吗？

答： 就我个人的经验，拒绝标注优先级的需求方，一般都是担心低优先级的需求被砍掉才会坚称每个细节都是核心功能。

没有一个人真的质疑“小步快跑”——实际上，不管什么岗位，每个人都认同重要的事优先做。

可问题是每个人都希望：即使自己最不重要的需求，也比别人最重要的需求优先级高。所以每个人都会刻意强调每个功能的重要性，资源紧张时尤甚。

所以这时候取得对方信任非常重要。虽然都知道排期到半年后≈不做，但这种态度会让对方安心：

“看，我已经写进计划里了，不会抵赖”。

本文由 @羊shuang 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于CC0协议。