好文分享～来自 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 就不在这边帮他们业配了～ --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 126.149.115.160 (日本) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1574391614.A.6F5.html