一个正常的产品肯定首先要有一个非常清晰的产品定位和价值主张，有一个相对清晰的规划和路标。怎么来去制定这个定位和路标，这是一个战略规划的过程，战略规划完成之后还需要通过战略解码来实现上下对齐，战略可以得到很好的执行落地。
有了清晰的路线图之后，一个产品从小做到大，常用到的方法论是 MVP 。（Minimum Viable Product –最简化可实行产品）。MVP是一种产品理论，每次都迭代交付出一个最小功能集，这个集合的功能可以满足用户的基本需求，虽不完善但至少可用。然后逐次迭代做出满足客户预期的产品，直至最后完全满足客户需求。
这个也比较容易理解，就不展开讨论什么是 MVP 了。本文也不讨论战略规划和解码， 重点讨论下产品迭代过程中，怎么不停的去获取客户的反馈以及迭代产品需求的过程。这也是 PM 最核心的日常工作。PM 经常会接到客户的需求，到底做不做，什么时候做，这个其实非常依赖 PM 个人的判断。这偏文章我写一下比较通用的判断逻辑。
接到需求，首先要做到的不是着急下一个结论，去决定做还不做，反而是要去把需求本身要搞清楚。一般要先搞清楚客户场景是什么。
这点其实非常重要，因为客户提需求，文字或者口头表达的不一定是他真实业务中需要的，或者能完全描述得清楚，所以越早搞清楚客户的真实场景和诉求是非常必要的。搞清楚对 PM 能力上要求很高，是要 PM 能代入客户场景，问到关键的问题。举例子说明，客户说要 global database，非常有可能他只是需要一个容灾的能力。那做global database 的代价比容灾就大多了，如果一开始方向就错了，效果肯定是事倍功半。
实践过程中，其实客户会提很多并不是真实的业务场景，只是想解决一些想象中的问题，如果一个好的产品还是要最终解决客户真正的问题，带来本质的降本增效才有持续的意义。
另外搞清楚场景，对实现也是一个关键的因素，只有搞清楚了场景和价值，才能进一步思考，是否有更好的解决办法，以及是否一次性解决更通用的问题。
搞清楚了场景，觉得是否做，先看看在不在产品路标上
在产品路标上，那就没有什么好说的，全局排好优先级。
是否符合产品的价值主张和定位，比如 PaaS 层的产品是不是不要把 SaaS 的逻辑过多的夹杂在里面，比如产品是为了提示易用性的，就不能去把产品做复杂。
如果不在，就是一个复杂的 ROI 判断过程了。
怎么来判断一个需求的 ROI ?
首先要明白，决策肯定是一个复杂的取舍过程，要平衡长短期的问题。但通常来说，肯定要问以下几个问题。
给客户解决的问题程度? 解决了一个复杂问题，还是一个简单的问题？是不是可以解决同样一系列问题。
解决了之后能带给用户的 aha-moment 是什么？
是不是一个通用场景？估计有多少用户会用。什么类型的客户会需要。
自己的代价有多大，是不是一个很薄的切入点，还是要很费劲。如果非常费劲就是一个战略的考虑问题，要非常慎重。