客户提什么，产品做什么？
经常有小伙伴抱怨，客户又改需求了；或者是客户说这个产品专业性不够，都没有把我说的整清楚。而真实的情况也许是这样的：
1、客户说：我看到这xxx上的功能不错，你给加上去；某PM本着客户就是上帝，客户第一的感受，说：可以，我立马改；然，客户又说：这个功能也不错，也加上去，PM说：好......经过反复的修改，最终客户把该加的东西都加完了，结果最终花费了几个月的功夫，终于把产品做完了，突然发觉这个产品与当初所想的完全不一样，整体就是一个四不象，最终只能委屈下我们的PM，给个🌟🌟、🌟🌟🌟咯，做个背锅侠。
2、客户说：我看到这xxx上的功能不错，你给加上去；某PM说：这个不好，不适用咱们这个功能，客户说：听我的，我就要这个功能，经过再三的沟通，某PM发觉无法说服客户，最终按照客户的要求来一点点的调整修改......
那在项目中，我们该如何体现出我们的专业性，让客户觉得是专业的呢？
全局观
作为一位优秀的PM，在拿到一款产品的时候，需要深入去挖掘，产品本身的架构组织、业务逻辑、用户群体、运营策略等等；
战场上有句话，叫知己知彼、百战不殆，每一款优秀的产品肯定是99%的准备+1%的灵感，我们每一次做一款产品都不光光只是把产品设计出来后就完成了的，我们做为产品经理，做每一次活动需求的时候，都不能仅仅考虑单次活动需求，而是应该让产品有足够的灵活性，可扩展，可复用，能满足将来类似活动可能的各种变化，在对接需求之前，都需要提前考虑到这个产品最终所能带来的利益与危害，要比其它任何一个岗位（运营、设计、开发）的同学考虑得更深，更全，不仅考虑到用户需求、业务需求，还能考虑到实现成本，能在用户需求与公司成本之间做出平衡，不仅能实现单次需求，还能提炼出某一类的共性需求。比如数据来源是什么？产品背后的业务逻辑是什么样的，用哪些字段做数据关联？如何跟其它系统、模块做好对接？在程序员客栈的原型评审就至关重要，并且在原型设计阶段之后也为大家增加了测试用例的环节。
测试人员在做测试用例的过程，是对产品每一个细节、正常流程、异常流程考虑得最全面的过程。优秀的产品经理写的需求文档与原型设计图几乎可以涵盖测试用例中每一种用例情况的说明。而如果不合格的产品设计，测试人员在做测试用例过程中会不停跟产品经理确认哪种情况该如何处理。
管理思维
优秀的产品经理在做设计的时候，会根据客户方的上线工期、项目团队设计合理的产品，让产品准时上线。而这里，如何保证正常的工期呢：
客栈的评估小组会根据每一位PM的1980文档进行评估合理的工期与预算，如果在原先的文档设计过程中，本身残缺不全，评估小组评估出的时间跟实际需求产品的时间就会有较大出入，最终导致项目开发过程中经常出现需求调整、工期延误等风险情况。
项目开发过程中的跟进也是优秀的PM必不可少的一部分工作，在项目中如果出现了设计上的不规范或者遗漏的流程，需要主动、及时的协调一切可利用资源，确保项目正常进行。在这过程中，PRD文档也是逐步完善，上线后的产品与PRD文档肯定是相一致的，这里整理了下优秀PM在PRD文档所经常会经历的几个阶段：
跟需求方充分沟通 就实现细节与技术充分沟通
结合产品原型写PRD初稿
修改评审后的PRD
交互定稿后，根据交互稿更新PRD
视觉定稿后，根据交互稿更新PRD
上线后，根据上线效果图更新PRD，包括定稿的每个文案。
所以，如果因为专业程度被客户打了差评的PM们，需要思考下自己是否专业！
