百木园
回想我第一次面试产品经理职位时，被问到这个问题：
“你如何决定要开发什么功能？”
“如果不知道要开发什么功能的话，我会先了解客户的需求，针对使用者做简单的访谈，来决定接下来要开发什么功能。”
“嗯…你说的没错，但我们遇到的情况有点不同。我们每天从各种不同渠道，收到一堆来自客户、使用者的反馈，希望我们尽快开发各式各样的功能，同时客服、业务团队也对产品功能有很多具体的想法，面对这样的情况，你会怎么决定要先开发什么功能？”
面试当时，我过往的经验比较项目导向，因此听到这个问题时很直觉的反应就是「不知道要做什么？问客户、使用者、老板就对了！」秉持着来一个需求就做一个功能的心态，First In, First Out！
但在开发自有产品的团队内，事情却复杂许多，问题在于有太多的需求，在持续优化与产品迭代的过程中，资源有限欲望无穷时，排定优先级成为非常重要的决策能力。
一、什么是优先级
Prioritization，中文可以翻译为优先级、优先序、优先顺序，亦即先做什么、后做什么，在互联网产品领域中，即为决定先做A还是先做B、要优化现有功能还是开发新功能等等。
排定优先级背后隐含的意义，其实是「资源分配」与「机会成本」的概念，当我把时间与工程资源花在A功能上，就无法同时花在B功能上。
在瀑布式（waterfall）开发流程中，产品经理在早期就会跟相关部门讨论好完整的功能，若分不同版本交付，就需要决定每个版本分别要开发哪些功能，也就是说在一开始就会定好产品开发的优先顺序。
而在敏捷式（agile）开发流程中，核心价值是快速产出、测试/学习、迭代/修正，因此会更频繁与动态的调整优先级，产品经理要有根据实验与回馈的成果来随时调整优先级的心理准备，除此之外也难以避免紧急需求插入的产生，因此心里有一套排序优先级的方法与逻辑是很重要的。
二、先排序问题，再排序解法
使用者、客户、其他相关部门提出的反馈，以及用户研究分析出的洞见，常常乱到不知道如何整理！其内容可能包含现有功能优化、新功能开发、 Bug，或是一个很大的问题（如何帮助我们吸引会员回来电商网站购物）等等，也就是说有些是明确的功能、有些则是模糊的问题。
在一些非常成熟的行业当中，直接按照功能来分类需求、按照竞品的样子复制一个功能出去给使用者也许是没问题的。
但在变动快速的行业中，了解使用者提出这个功能背后的问题、需求与使用场景，才能帮助我们想出更多的解法、更好地去服务使用者。
在缺乏使用场景的情况下，产品团队很难满足每个使用者的需求、也无法判断该解决的核心问题是什么，因此多问使用者一个「为什么」总是不会错，也能够理清这是否一个值得解决的问题。
将使用者提出的功能反馈拆解成问题与需求后，可以先排定「问题」的优先级，专注于我们想要解决的问题、能带给公司的价值，而当开始定义问题、想解决方案后，产出一堆功能的想法时再来排定「解法」的优先级。排定优先级这件事情，会不断地在产品设计与开发的环节中发生。
三、三种常见的优先级评估标准
1. 问题规模
沟通对象：用户/客户、业务、客服、社群、用户研究员
对于「使用者中心」的产品设计团队，从使用者需求出发来考虑排序的优先级是常见的方法，问题规模可以包含：使用者针对该需求提出的数量与频率、该问题影响到使用者数量、该问题发生的频率/功能的使用频率来判断问题的规模有多大，以及是否值得优先被处理。
2. 商业价值
沟通对象：业务、BD、商业相关部门、各种利益关系人
在很多公司中，会先处理商业价值最大的问题，可能是可以立即赚钱的、或是可以帮助团队在未来打下更多市场的市场需求。
举例来说 B2B 产品团队接到与大型品牌客户的合作、B2C 产品团队与强大的第三方服务商合作，或是比竞品更早推出新功能而有机会可以抢到更多客户时，都有可能会将这类型的需求独立拉出来提高优先级。
商业价值也包含可以协助获取新用户、提高留存率、提高转换率、提高营收等指标，保持与公司的目标一致。
3. 资源考量
沟通对象：设计师、研发工程师、QA
资源考量常在排序解法时出现，与技术团队共同判断技术可行性、所需资源、与其他功能之间的相依性，来决定现阶段要用哪个解法来解决问题。
四、制定优先级的策略
1. 团队目标
在有规模与制度的公司内，每年、每季都会制定公司的目标与策略，例如营收成长、客户成长、会员数成长、新市场拓展等等，而产品团队也会因应公司目标而制定阶段性的产品目标，产品目标可以协助我做决策时定出不同的评估要点、权重并保持与商业目标的一致性。
2. 风险测试
在很早期的产品团队，或是产品本身发展潜力还很多元的时候，可以选择将不确定性最高（亦即报酬很大但失败性也可能最高）的功能推出去测试，先完成第一阶段的最小可行性产品（MVP）来看看成效，从中学习并快速迭代，来快速取舍接下来的发展方向。
另外一个思考方式，则是先处理风险低、信心程度高的问题，确保推出的解法是真正能够解决现有使用者的问题，创造影响力。
但其实撇开风险高低不说，早期花较少的资源透过小测试来快速得到反馈，每次收完反馈就重新调整优先级，将反应好的功能优化也是一个很好的开发策略，对于资源的安排也会更有弹性。
五、排定优先级的工作流程
在实际操作上并不会只参考一个方面，而是动态的考量不同因素来排定一个优先级。有时候这些方法其实是互相冲突的，举例来说商业价值最高的可能要花费的技术成本也最高，因此产品经理最困难的工作就是找出平衡点并跟团队一起讨论出大家都认同的产品路线图。
工作流程：
最后最重要的，是要跟内外部团队都充分讨论与告知目前的优先级，确保大家了解决策过程并且能够安排相对应的资源。以下分享两个思考决策与解决问题的小案例：
案例一：少数大客户 v.s. 多数小客户
以B2B产品为例，Key Accounts（KA）总是说话最大声的人，但当面对只有少数几个 KA 提出某个问题，而大部分的小型客户都没提过，这个问题是否就不重要而应该被排到比较低的优先级呢？
这个问题困扰我的地方在于，不确定「问题规模」的大小。有鉴于使用者除了常常不知道自己要什么，帮助他们理清问题就是产品团队的责任！
举例来说，其中一位电商卖家 KA 每周上新品的数量达 100 件，因此要求优化后台大量新增、上架商品的功能。此时除了确认 KA 本身的使用情境与需求外（包含老板、小帮手等不同使用者），也可以透过市场研究、竞品研究，并针对一般小型卖家发问卷、做访谈，了解他们目前的状况：
– 如何上架商品、谁负责上架
– 是否曾经有需要大量新增的需求、最大量是多少
– 上架商品过程中遇过哪些问题…等等
了解「未发声」的中小型卖家是否也遭遇类似的问题，或是他们未来成长变大的过程中会不会遇到相同问题，来初步判断这个问题是否值得优先被排期。
案例二：目标优先级、问题优先级、解法优先级
有时候跟使用者聊得太开心，收集到一堆反馈，就会直接落到「该功能/需求被提出的次数」这个最直觉的方法来决定要优先开发什么功能。
举例来说，若设立的团队目标是帮助卖家提升顾客来到电商网站的转化率，其中一个被放在高优先级的问题是「许多顾客将商品加入购物车，但没有完成结帐动作」，针对这个问题做使用者研究后，发现超多顾客提出的反馈是「我其实当时还没有要买，只是网站没有那种可以收集我的最爱商品的地方，所以想说先放在购物车里面之后慢慢挑」。
此时的团队目标是帮助卖家提升顾客来到电商网站的转化率。也许顾客此时提出的功能看似需求量很高，但他反映的可能只是产品体验的问题，比如通过收藏可以满足？我们要分析的是，用户从登录、浏览、进入详情页、加入购物车、下单、付款的整个漏斗中，哪个环节流失最大，做针对性的优化。
但同样这个问题对于负责产品体验的团队来说，可能就是优先级最高的事，因为你们的目标不同，要提升的核心指标不同。
六、综合量化的排序架构
在团队众多的产品公司里面，对于资源安排的方式更是斤斤计较，因此能够用更有架构的方式，甚至量化的数字来比较，会更有说服力。
分析一些我曾经使用过的方法：
- KANO：定义了三种不同层级的使用者需求 — — 基本型需求（Basic, Must-Be）、期望型需求（Performance）、兴奋型需求（Excitement）
- MoSCoW：定义了四种不同层级的使用者需求 — — 必须要有（Must Have）、应该要有（Should Have）、能做（Could Have）、不能做（Won’t Have）
- RICE：RICE score = (Reach*Impact*Confidence) / Effort
- ICE：ICE score = Impact * Confidence * Ease
七、写在最后
前面说了很多理想美好的排定优先及方式，但产品线上发生的 BUG 永远是第一优先要处理的，因此在面对线上功能出问题的情况，也可以制定出一套处理流程和标准。
以电商产品举例，与注册、登入、购物车结帐、钱高度相关的地方出问题绝对是 P0等级，需要马上被解决，这时候什么团队目标就放在一旁，先把最最核心的产品功能修好才是至关重要的。
1. 保持决策的一致性
优先级会不断的变动，高优需求插入也难免会产生，有一套一致的逻辑与决策方式来说服设计与工程团队内部、以及与外部业务部门沟通，可以帮助产品经理增进沟通效率。重点不只是方法，更是挑选这个排序方法背后的原因。
2. 从使用者反馈与测试中来调整优先级
如同前面风险测试提到的，将每次要验证的问题切小，快速迭代和收集反馈来重新调整优先级，对于资源的安排会更有弹性。
更重要的是，优先级的重点不只在于顺序，更在于资源的运用，如果能够因此用市场反馈说服老板直接「增加资源」，很多事情似乎就更好解决了！
作者：骆齐；来源公众号：产品经理骆齐（ID：pmjingying）
原文链接：https://mp.weixin.qq.com/s/2-fOVO0KtJmpIQdnGo0Gzw
本文由@产品经理骆齐 授权发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
来源：https://www.woshipm.com/pmd/5696877.html
本站部分图文来源于网络，如有侵权请联系删除。