本文源自近期几次的产品评审会上的交流，有些人很容易得到排期，有些人却很难，思考下做以下总结：
从业务提出产品需求时，就得想清楚业务目标，然后一层层的影响到主管、产品、开发甚至是最终用户等不同人群。可能在这个过程中团队主管因了解你的业务能快速Get到需求对业务目标的贡献。而PD（产品经理）关键人物是连接业务和开发的重要桥梁，也要让PD能清晰了业务背后的思考，在产品设计的逻辑上才会更加流畅，用户交互也将更适于面向的对象，在评审会上，也能更快的与开发（前端、后端和测试）达到一致。其实随着业务环境变化，开发团队也越来越关注自身开发投入的价值，是否能产品化？是否能复用等。所以业务在对齐需求时也要将这些考虑到，讲清楚。
面对主管，要考虑到业务目标与需求的逻辑性。
业务规划时，一定是根据团队绩效目标的实现，主管认可后，才做产品需求的梳理，请注意一切都是为了绩效目标，而非满足少数用户的需求。产品需求先做团队内部的收集，尽可能的考虑到多方面的问题，甚至之前用户反馈进行综合评估梳理成产品需求。业务可以画成DEMO图，让产品需求可视化，也便于PD理解和优化。
1、团队要对齐业务目标与产品需求的逻辑性是什么？能实现业务目标吗？思考为什么要这样做而不那样做？
2、这样做能取得的结果是什么？用户习惯是什么样的？
3、主管对需求的业务逻辑是怎么想的？希望达到的绩效目标与你是否一致？
面对产品，要讲清楚业务需求与业务目标的关联性。
走出了第一步后，至少你获得了业务主管的支持，向下一步获取资源，让PD更轻易理顺需求，能让业务需求上线快人一步。
1、一定要注意，PD是做业务和技术转化的角色，将业务逻辑讲清楚，能帮你在用户体验上更上一层楼。
2、与PD的沟通不是说服，而是讲清楚聊透彻！有些业务可能还没想太清楚，好的PD好帮着一起理顺。前提一定是业务自己得把需求的背后原因告知清晰。
3、把简单留给别人，对PD也一样，你画了DEMO他可以优化，你不画DEMO一切重头来。请好好爱护对接的PD，因为业务需求很多，如何在众多需求中将你的排期靠前？需要强价值，又好配合的业务。
面对开发，评审会时让大家知道业务目标的重点性。
评审会上，开发从前端到后端，甚至测试因为绩效的问题，都会很关注产品需求的大小及价值，背后思考是什么？那么对于他们不将在是：用户反馈了问题？老板反馈了问题？这样简单的回答了。此时此刻是前面与主管对齐，与PD梳理逻辑，设计交互最重要的一环，一定要回答清楚以下的问题：
1、产品需求的业务目标是什么？首选提需求时，要想清楚背后的真实诉求和价值，别着急提需求，否则怎么要到资源并重视？
2、目前的问题是什么？讲清楚现状，最好要有数据，如果是解决的单一问题，开发一定会关心投入产出比是怎么样的？这个问题的大小影响的范围等？
3、建议的方法是什么？是否有现有方案可复用？提的方案为什么能实现业务目标？核心的产品思路是什么？业务与产品要将需求思路搞清楚，在需求评审会上，能让技术知已知彼。如果发现有些思路不清晰，还是要产品再理一理。
随着组织关系的变化，不同岗位的人都会关注生产力价值，要不大家辛苦一年没做出好产品来，图什么呢？也许这次的业务需求就是能让参与者更上一步的关键呢。
