好文分享～来自 Pinkoi PM 的分享！
有图好读 Medium 连结：http://pesc.pw/ND8GP
▍怎样是个合格的产品经理？
其实我没有完整的答案，如同成功的产品没有万灵丹、没有标准答案，合格产品经理 (Product Manager, PM) 的标准也很多元。每家公司面对独特的处境，对产品经理的期待也很独特，很少有完全相同的标准。
▍那你何必写这篇文章？
首先，我自己在应征 PM 工作，或代表公司面试应征者的时候，时常遇到这个痛点： 你我两个脑袋中的 PM ，是指同一个角色、同一份工作吗？正因为“合格产品经理的标准也很多元”，造成大家对 PM 的定义不尽相同，所以这篇文章希望带给大家一个“判断框架”，作为沟通媒介。
其次，我自己在 PM 的学习旅途上，虽然发现 PM 该学的东西无边无际，但还算有个“分类方法”。以前，当每次觉得自己快要合格的时候，又突然发现“因为还不懂这个，所以不够格”，然后觉得挫折。自从得知、整理出分类框架后，心态就变成“在这类工具箱中，又多了一把刀”的“蒐集感”，所以这篇文章希望带给大家这个分类框架，让我们都能像打游戏一样蒐集宝物、凑齐装备。
最后，我也想以现在任职的 Pinkoi 公司为案例，和大家分享我们如何设定产品经理的职责领域。
▍怎么看待 PM 的职责？
先厘清一件事： 这里的“产品经理”是指“运用电子硬件、数位软件、互联网等相关科技”来“打造产品”的“科技产品经理”，不是金融产业、快速消费品产业、零售产业的产品经理。
我用以下框架，判断一个产品经理的职责领域，也用同一个框架来区分产品经理的能力类别。这个框架可以叫做 PSS （Problem-Strategy-Solution），或叫做 DHD （Discovery-Hypothesis-Delivery）。PSS 用来判断“职责领域”，而 DHD 用来区分“能力类别”，互为表里、一体两面。
这个分类方法，对应了三个打造产品的核心活动：
- 问题探索 (Problem Discovery)： 探索市场与顾客的问题，聚焦在关键的需求
- 策略假设 (Strategy Hypothesis)： 面对尚未满足的需求，假设解决问题的路径，成为决策判断的依据
- 方案交付 (Solution Delivery)： 交付产品方案到顾客手中，推到市场上获取商业价值
在产品迭代周期中，这三个活动可能交错出现，也可能同时出现。产品经理在每个周期会偏重不同的活动，也许先偏重在问题探索与策略假设，然后偏重在方案交付。
如何探测一个团队，对产品经理的定位与期待？可以试着从“你们的产品经理，如何分配时间？”，或从“你们的产品经理，需具备哪些能力？”的角度切入，然后将获得的资讯套入这三大核心活动。举例来说：
- 某个硬件团队认为 PM 应该花绝大多数的时间在 Solution Delivery
- 某个软件新创团队认为三者的时间要尽量均衡
- 某个跨国浏览器公司认为要偏重 Problem Discovery 和 Strategy Hypothesis
- 另一个软硬整合的系统服务商则用三个人分别承担三类职责，但彼此略有重叠
对于产品经理自身来说，常见的学习路径是： 要先大致掌握 Solution Delivery ，再尽量掌握 Problem Discovery，最后再尽力掌握 Strategy Hypothesis。我也是这个学习路径，最近才刚摸到 Strategy Hypothesis 的边缘。那么，接下来就用常见的学习路径，依序大致介绍。
▍Solution Delivery 方案交付
产品经理基本的职责是： 要排除产品上市过程中，所有交付的障碍与困难。
方案交付需要许多技能，例如： 专案管理、开发时程安排、体验设计、品管与测试、在地化与国际化、上市发布计画、沟通协调，等等等。方案交付的过程必然仰赖很多角色的团队协作，产品经理不可能精通所有专业，但要根据团队现状来补位。例如，当团队没有 QA 品管与测试伙伴时，产品经理就得自己做。有些公司会额外安排一个角色，负责方案交付，这个人的职称可能是： 交付经理 (Delivery Manager)、发布经理 (Release Manager)、计画经理 (Program Manager)、或专案经理 (Project Manager)。
▍Problem Discovery 问题探索
产品经理的另一个职责是： 要降低产品开发到上市过程中，导致产品失败的关键风险。
有这四大关键风险：
1. 实行性风险 (Feasibility Risk)： 团队确知需求，但手边并没有解决问题的技术，或技术尚未成熟，就是“我们知道要做什么产品，但是做不出来”的状况
2. 易用性风险 (Usability Risk)： 顾客想用这个产品，但不知如何使用，或太少人克服使用门槛，就是“产品做出来了，但是好多顾客看不懂、不会用”的状况
3. 价值风险 (Value Risk)： 这个产品并没有解决顾客需求，为顾客带来价值，就是“产品做出来了，某些顾客也会用了，但后来都不继续用，因为没有满足需求”的状况
4. 商业可行性风险 (Business Viability Risk)： 这个产品对公司没有商业价值，或无法在市场竞争中存活，就是“产品做出来了，顾客也爱用，但是无法赚钱，或拿不到更多预算与资金，或无法赢过竞争者”的状况
当我自己觉得能大致掌握 Solution Delivery，也体验过产品推上市的过程后，发现“产品仍然很容易不成功”。不管交付的品质做多好、设计做多好、开发流程多完善，终究失败，原来是我们太晚认清以上风险。
问题探索需要的技能，例如： 用户访谈与研究、问卷调查、竞品与市场研究、线上随机实验（A/B testing）、易用性测试，等等等。如同方案交付，问题探索的过程也要仰赖很多角色的团队协作，但因为多数公司还不够认清这些风险的威力，所以这也是产品经理最常下海补位的工作。少数公司会搭配一些角色，和产品经理一起探索问题，例如：用户研究员 (User Researcher)、易用性工程师 (Usability Engineer)、产业分析师 (Industry Analyst)、资料分析师 (Data Analyst)，等等。
▍Strategy Hypothesis 策略假设
产品经理的最后一个职责是： 要避免团队失焦发散的状况，并降低团队自信过剩或信心殆尽的情形。
Strategy Space 是 Problem Space 和 Solution Space 取交集的结果，且要转成一个让大家“相信我们能够解决问题”的浓缩论述，但同时也是个假设 (Hypothesis)，以假设的心态让大家“有信心又战战兢兢”。这里的策略可以位于不同的公司/组织层级中，要看产品经理的职责范围，但对策略的思考框架基本上类似。
而一个完整的策略假设，需要包含以下三大核心元件：
1/ 问题诊断： 限缩过、解析过的问题描述，以及自己对这个问题的诊断，要能短时间内让人理解“这个问题为何重要、如何严重，有哪些背景成因”
2/ 指导原则： 根据现有资讯，我们假想“能让产品成功”的指导原则，能帮助我们在过程中做决策，并防止我们做出“跟问题本质相冲突”的决策，切此避免失焦
3/ 连贯的草案： 要能初步描述一个“可能的方案”，当作具体例子、初步讨论的基础，而且能扣紧指导原则与问题诊断，达成协调一致的聚焦效果，但也要和团队强调“这只是草案”，保留尝试空间
大部分人们广泛传播的策略，其实都可说是某种“指导原则”。举例来说，“低价抢市”（如亚马逊）和“补贴扩张”（如虾皮）被认为是两种有助于增加市占率的策略，但换个角度看，其实也是在“投资与花费”相关决策上的两种指导原则。低价抢市下的投资与花费追求“长期营运效率”的最大化，而补贴扩张则追求“短期扩张速度”的最大化，甚至愿意牺牲营运效率。必须把每个指导原则（人们口中的策略），放到问题情境里面，才好判断是否管用；只看“指导原则”而忽略“问题诊断”的策略思维，是盲目走向消亡的主因之一。
因为策略假设很抽象，因此需要以很多种表现方式来具体化，产品经理也要具备运用这些方式的技能，例如：
- 顾客用途： 用来表现问题诊断，或用来定义需求
- 优先序列： 是一种指导原则，可以是需求或功能的优先性排序，表示若我们按照这个优先性扩充产品、解决问题，就有机会成功，因此可作为决策依据，引导聚焦
- 目标层级： 也是一种指导原则，可以是一个或一组目标，表示若我们达成这些目标，就有机会成功，因此可作为决策依据
- 路线图： 用来表现连贯的草案，进一步把“优先序、目标、或方案主题”表现在“时间区间”上，引导时间分配，并协调彼此的行动
我们时常认为，策略假设是创办人、执行长、产品长、或最终管理层的职责，只在少数状况会交给产品经理。但其实，在产品经理的日常工作中，有很多机会锻炼我们在策略假设的能力，小至安排开发项目的优先序列，大至提出未来几季的产品路线图。
当我自己觉得能大致掌握 Problem Discovery 之后，接着遇到的痛点是“难以传播问题探索获得的学习”，因此难以在团队中落实。如此一来就没有降低风险的效果，团队也难以体会问题探索的价值。
产品经理必须取舍探索后的收获，浓缩成一段策略假设，以说故事的方式传播在团队中，并在各式决策点，重复取出具体化的指导原则，才能确保我们能落实彼此协调的解决方案。
▍有点抽象？来看 Pinkoi 如何做
以我目前任职的 Pinkoi 为例，来介绍产品经理的角色。Pinkoi.com 是亚洲领先的设计购物网站，贩售设计商品、数位创作、体验活动，并网罗海内外优质设计师群，坚持用好品味、客制化的独特设计，实现每个人对生活诠释的想像，也让每个送礼时刻更加独一无二。
在 Pinkoi 我们有 Product Design Team (PDT) 和 Engineering Team (Dev) ，产品经理属于 PDT，和产品设计师、视觉设计师、用户研究员、在地化语言专家 (L10n) 同部门。Pinkoi 目前没有根据产品切分常态存在的团队，而以动态编组队友的“专案团队”运作，每个专案有一位专案负责人 (Project Owner, PO)。通常根据专案特性，选派特定专业的队友兼任。举例来说，可能有这几类专案：
- 行销活动（线上、线下）： 可能由行销的队友担任 PO
- 外部合作伙伴、服务方案： 可能由商务发展、设计师关系的队友担任 PO
- 串接外部服务（金流、物流）： 可能由工程师队友担任 PO
- 电商平台的体验流程或基础建设改善： 可能由设计师队友、工程师队友、产品经理担任 PO
我们通常会属于二个专案团队，每个专案短的话 1–3 个月，中等的 4–9 个月，长的 10–18 个月但目前很少见。在这种状况下，PM 产品经理通常就是全职担任 PO，可能要担任二个专案的 PO。以我自己来说，在三类职责（Problem Discovery / Strategy Hypothesis / Solution Delivery）的时间分配，大概是 2 比 3 比 5。因为有用户研究员、产品设计师、资料科学家一起做问题探索，所以能花 20% 的时间做到一定程度。因为 PM 也兼任 PO，我们也没有 QA 测试队友，所以要花 50%
的时间维持专案运作的步调、做很多沟通协调、上线部署前的测试，但也因为队友都很主动积极、团队体质健康、沟通畅通，所以不用花超过 50% 的时间。
这样运作方式的优点，对公司来说可以弹性调度资源，对 PM 来说可以接触不同的问题与产品区块、很新鲜很有挑战。至于缺点，对公司来说是不利于“需长期发展”或“重要但不紧急”的目标，规模扩大时可能难以累积特定领域的知识，对 PM 来说，则是沟通和团队磨合上格外费心，因为人员时常重组。
对 Pinkoi PM 工作有兴趣的请到文章末：http://pesc.pw/ND8GP
就不在这边帮他们业配了～