我们应该评估这个需求的合理性，即做不做的问题

1. 这个需求做不做？
2. 这个需求什么时候做？

但是往往我们开会沟通的时候，会把这个问题纠结地去考虑，造成彼此的困扰。在这里我建议将这个问题分两步考虑，下面是我的一些经验：

首先，我们应该评估这个需求的合理性，即做不做的问题。做不做的问题完全取决于产品定义和产品形态，这个时候要放开时间的界限，把可能性都囊括进来。比如，在讨论语音搜索功能是否要做音量检测反馈的时候，我们的答案是肯定的，所以我们把这个需求记到需求列表里面。而常见的问题是，出现一个不和谐的声音“这个需求太边缘了，先不做了，赶不上要求的上线日期了”，这个时候往往就容易把这个需求打压掉，或者针对做不做的问题来纠结。其实仔细想，在讨论做不做的阶段，有些人往往在表达什么时候做的相关信息，这样就造成了信息沟通问题，造成了不必要的浪费。

第二步，我们要评估什么时候做的问题，这个问题即优先级的问题。讨论优先级的情况下，主要是看方案，而不要去怀疑这个需求的合理性。这个阶段的原则主要是MVP思想，把最核心的功能到最外围的梳理清楚，再去取舍。比如说领导预期上线的计划时间是2月底，我们在上一个环节合理性确认清楚的原则上，根据MVP的优先级原则，对需求进行分期、排期。这个阶段主要是由项目经理和产品经理对方案进行评估，能在最简洁、最合理的方案下，达到最合适的需求效果。

MVP（minimum viable product，最小化可行产品）概念最早由埃里克·莱斯提出，刊载于哈弗商业评论，并有出版物《精益创业》

和常规产品不同，MVP更侧重于对未知市场的勘测，用最小的代价来验证你的商业可行性。举个例子，如果你希望做一个图片分享网站，那么作为产品原型，MVP仅仅包含最基础的功能，形态或许就是一个提交图片的按钮以及图片的展示。借助MVP，经过一系列实践，产品的设计思路将被一次次整改，最终完成正式版的开发。

MVP的目的——更快的接触客户

按照常规的开发方式，从调研、到设计、到开发再到推向市场，会是一个漫长的过程，而且很难有人会保证成功率。但当换一种方式，以MVP进行小样调研，快速进入市场、接触客户并得到反馈。透过反馈不断修改原型，并进行不断地的迭代开发，极大减少了试错成本。

两种MVP——Validating MVP 和 Invalidating MVP

MVP的模型分为两种，Validating MVP 和 Invalidating MVP。

第一种是Validating MVP（可行的MVP，无对应中文，斗胆翻译），也是是较为常用的MVP：接近你的目标客户，把现有未完成的产品低价出售。如果他们乐意接受，则产品验证成功；反之，失败，但这并不影响项目的进程。