产品经理会处理来自各个部门的各式问题。有些问题的解决就需要产品经理协助进行决策，比如多个功能的上线时间，或者对于插入需求的优先级和资源安排，或者需要使用哪种功能方案。
 

　　也许，产品经理在组织中，没有对应的权利去直接拍板。但是出于职业的要求，产品经理必须要冲到最前线去协助或推动解决问题。
 

　　1.理想中的决策流程
 

　　决策分为三个阶段：
 

　　自由讨论
 

　　清楚地决策
 

　　全力支持
 

　　在“自由讨论”阶段，大家畅所欲言，充分表达自己的观点。
 

　　在“清楚地决策”阶段，由于上一阶段的清晰讨论，在这个阶段就可以清楚的做出决策。在这时，产品经理必须要顶住压力，清晰明确的表达决策内容。因为，决策有时会带来争议。如果为了缓和争议，而使用含糊不清的表达，争议方会更加不满。导致问题将搅得更浑，问题越来越复杂。
 

　　比如，在跨部门制定需求排期时，每个部门都想争取到自己需求的开发资源，但是开发资源的有限，产品经理必须明确制定出排期安排。
 

　　在“全力支持”阶段，不管最终决策内容，所有参与者都要以公司的利益为重，坚决的执行决策。
 

　　当然，这只是理想中的决策流程，但是实际中会存在着阻碍。
 

　　2.实际决策中的阻碍
 

　　在实际的决策中，会有各种各样的情况，阻碍着决策流程的推动。
 

　　比如，真正遇到问题的人没有参与决策。安迪·格鲁夫倡导，决策由问题最近，而且了解问题的人来制定。B端产品经理在处理业务需求时，特别要关注提需求的同事是否是真正了解这个问题的人。也许，他只是组织和传达真正需求方意见的人。
 

　　其次是“同级群体综合征”。也就是说，在跨部门沟通中，一群人不熟悉的人被拉在一起，会出于人性中的自尊、恐惧、或者不安全感，而寻求与周围的一致。往往在实际沟通过程中，就会把时间拉得很长，议而不决。面对这种情况，产品经理可以拉一位职级比较高、但不要求一定具备专业知识的人参加讨论。
 

　　当然，请一个位高权重的人参加讨论，只能是最后的大杀器，而不是协助决策的日常武器。只有在问题十分紧迫，但决策过程又议而不决的时候，才能祭出这个大杀器。
 

　　决策过程的关键，还是需要产品经理引导参加决策的人，积极参与讨论。明确解决问题、制定决策的目标，而不管是谁提出的观点和言论，都只是过程。实现目标才最重要。这就是产品经理应该具备的目标/结果导向的思维。或者从决策的场景来说，就是对事不对人。
 

　　3.关注决策的6个问题
 

　　根据理想的决策流程，大家都通过热烈的讨论，并统一输出了决策，最后被管理层给否决了。这肯定是很郁闷的事情。
 

　　但是，如何避免这样的事情发生呢?在决策过程中，请谨记6个问题，并将答案了然于胸。
 

　　决策的内容。
 

　　决策的时限。
 

　　决策人。
 

　　在制定决策前应先向谁咨询。
 

　　谁对此决策一言九鼎，或是能全盘否定。
 

　　谁应该在决策制定后被告知。
 

　　以我日常举行的排期会议为例。
 

　　先介绍背景。我作为产品经理，每两周会举行一次制定下一阶段研发计划的会议。
 

　　1.决策的内容
 

　　我们有一张业务同事、技术同事初步评定好的需求列表，然后敲定哪些可以排入下一阶段的研发计划。
 

　　2.决策的时间
 

　　因为以两周作为一个开发周期，所以尽量要保证在一次会议中制定好下一阶段的开发计划。对于有争议的需求，允许另行开会议讨论，但必须要在下一阶段开发开始前得出结论。
 

　　3.决策人
 

　　我们采用站会的形式，业务同事、技术同事、产品经理共同参与讨论决策。
 

　　4.在制定决策前应先向谁咨询
 

　　在开会之前，会对需求经过一次初步筛选，会咨询实际做此业务的技术同事，给出是否加入此次讨论的需求列表。
 

　　5.谁对此决策一言九鼎，或是能全盘否定。
 

　　当对研发计划有争议时，优先请技术经理与业务同事沟通决策。如果无法有结论，可以会后，再上升一级进行沟通。
 

　　6.谁应该在决策制定后被告知。
 

　　研发计划制定好后，参加讨论的业务同事和技术同事，都是主要告知对象。为了防止遗漏，采用拉式沟通，将研发计划公布在项目管理看板上。
 

　　4.决策流程重于决策速度
 

　　建立决策的流程，需要投入一些精力和时间。但是，总比快速的决策，最终被推翻要好。
 

　　正如，安迪·格鲁夫讲过的一个故事，他的下属曾经因为受不了英特尔的决策流程而跳槽去了一家鼓励个人自行做决策的公司。4个月后，下属又回到了英特尔，他解释说，“如果我可以不询问别人的意见便作决定，别人同样可以起而效法。”
 

　　水平有限，希望对你有所帮助。