#48 PM的三大核心职责

之前看过一篇文章（出处没找到），作者用了一个框架来判断一个产品经理的职责领域，也用同一个框架来区分产品经理的能力类别。这个框架叫做PSS （Problem-Strategy-Solution），或叫做DHD （Discovery-Hypothesis-Delivery）。PSS 用来判断「职责领域」，而DHD 用来区分「能力类别」，互为表里、一体两面。

这个分类方法挺有意思，因为对应了打造产品的三大核心过程：

问题探索(Problem Discovery)：探索市场与顾客的问题，聚焦在关键的需求；
策略假设(Strategy Hypothesis)：面对尚未满足的需求，假设解决问题的路径，成为决策判断的依据；
方案交付(Solution Delivery)：交付产品方案到顾客手中，推到市场上获取商业价值。

在产品迭代周期中，这三个活动可能交错出现，也可能同时出现。产品经理在每个周期会偏重不同的活动，也许先偏重在问题探索与策略假设，然后偏重在方案交付。

对于我自身的体会来说，这三大核心的学习路径是：要先掌握方案交付（Solution Delivery ），再尽量掌握问题探索（Problem Discovery），最后是尽力掌握策略假设（Strategy Hypothesis）。

Solution Delivery 方案交付

方案交付是产品经理的最最基本的职责，就是要排除产品上市过程中，所有与交付相关的障碍与困难。我始终记得二爷说过的一句话：对于产品经理而言，保证交付才能保住饭碗。

一款新产品的交付，涉及方方面面的内容。开发时间与质量矛盾的权衡，软件体验，配套的文档完善程度，与各个环节的顺畅沟通协调，等等。方案交付的过程仰赖很多角色的团队协作，产品经理不可能精通所有专业，但要根据团队现状来补位。

Problem Discovery 问题探索

产品经理的另一个职责是：要降低产品开发到上市过程中，导致产品失败的关键风险。

这里面有几大关键风险：

价值风险：「产品做出来了，某些顾客也会用了，但后来都不继续用，因为没有满足需求」，价值风险是最严重的问题。我在以前的文章中也说过几次，最大的问题点就是想当然以为产品可以成功。

实现风险：「我们都知道要做什么产品，但是做不出来」，团队确知需求，但手边并没有解决问题的技术或者相应的人，或技术尚未成熟，这时候该怎么办？

商业风险：「产品做出来了，也有顾客，但是无法赚钱，或拿不到更多预算与资金，或无法赢过竞争者」，这个对公司没有商业价值，无法在激烈的市场中存活。

易用性风险：「产品做出来了，但是好多用户看不懂、不会用」，这个的典型问题是产品使用门槛太高或者用户根本无法操作。

在我做产品的过程中，上述四个典型问题反复出现，做了很多事情，但仍然发现「产品很容易不成功」。昨天吃饭和同事讨论起前几年做了一款采样器，因为商业上没有成功，产品并没有条件经过太多的市场检验。此时产品的创新点、设计效果、开发品质，这些都没有意义了。

问题探索需要的技能，其实是我目前比较缺失的，也是做法最不正规的。因为这涉及到市场分析、用户需求探索、竞品分析等，而大部分开发人员的思维仍然停留在“自我想象和实现”的阶段。

Strategy Hypothesis 策略假设

产品经理的最后一个职责是：要避免团队策略失焦的状况。

昨天刚看了二爷的一篇文章，里面也提到这一点。在交付产品的过程中，产品负责人或者团队都很容易出现策略失焦，产品做着做着可能把最重要的问题忽略过去了。

所以作为团队负责人，遇到难题，需要让团队成员「相信我们能够解决问题」，但同时让大家认识到「有信心但路径并非易事」。

一个完整的策略假设，需要包含以下三大核心元件：

1/ 问题诊断：限缩过、解析过的问题描述，以及自己对这个问题的诊断，要能短时间内让人理解「这个问题为何重要、如何严重，有哪些背景成因」；

2/ 指导原则：根据现有资讯，我们假想「能让产品成功」的指导原则，能帮助我们在过程中做决策，并防止我们做出「跟问题本质相冲突」的决策，避免失焦；

3/ 连贯的草案：要能初步描述一个「可能的方案」，当作具体例子、初步讨论的基础，而且能扣紧指导原则与问题诊断，达成协调一致的聚焦效果，但也要和团队强调「这只是草案」，保留尝试空间。

以上就是我对PM三大核心职责的延展和想法，目前做得还远远不够，继续努力吧。