1.1　策略产品经理的定义

笔者经常被问到一个问题：“策略产品经理是什么？”无论是共事的同事，还是部分HR，都对这个职位的具体定义缺乏明确的认识。比如一个研发工程师如果他会写后端代码，那么就可以称其为后端工程师；如果他会写前端代码，那么就可以称其为前端工程师；如果他会调模型，会写PHP，会前后端，又会运维服务器相关的代码，那么就可以称其为全栈工程师。具体是哪种研发工程师，要根据他所掌握的技能的种类来定义。

同理，运营经理和产品经理、产品经理和研发工程师、研发工程师和测试工程师之间也可以通过掌握的技能种类进行区分。人们根据该工种掌握了哪些特定的技能来划定彼此间的边界。换句话说，人们可以很清楚地描述不同的工种到底是做什么的。

但在产品经理的分类上，似乎不那么明晰。大多数人对产品经理的认识可能是画原型图的、理解用户需求的、业绩不好时担责任的、推动项目上线的，这是因为产品经理主要负责偏复合型的工作，在项目中充当桥梁的作用，往往缺乏特别专一的技能。所以，很多人开玩笑说：“如果你不会测试、不会写代码、不会做运营经理，那么你适合去做一个产品经理。”但果真如此吗？其实不然，在各大公司中，产品经理必须具有某种非常核心的竞争力才能够在职场中生存下来，没有任何一个CEO愿意为一个毫无价值的人支付薪水。

那这份“非常核心的竞争力”是什么呢？是项目沟通能力和对用户的深刻理解能力。

对于产品经理来说，这两项能力是不可或缺的，没有这两项能力就无法保证项目效果的顺利达成。无论是功能型产品经理，还是策略产品经理，都需要具备这两项核心竞争力。以笔者的观点看，策略产品经理与工程师打交道更多，也需要更强的技术能力，也就是说，策略产品经理是“懂算法的人中最懂用户、人性和商业逻辑，懂用户、人性的人中最懂技术”的中间型角色。

策略产品经理作为一个新兴职业，需要一个准确的定义，笔者给策略产品经理下的定义是：在限制条件内，通过推动项目、设定评估体系和全面评估项目收益三种手段，达到全局最优解的产品岗位。

在这个定义中，有三个关键词，分别是限制条件、手段、全局最优解，如图1-1所示。而这三个关键词是笔者对策略产品经理职位的三个关键认知。

关键词1：限制条件

“限制条件”是指在任何项目中都有一些限制条件，这个条件可能是上级领导、公司高层、政府机构等给出的“策略红线”。常见的限制条件如下。

●法律法规限制：如“禁止搬运有版权的内容”“禁止获取用户协议之外的用户信息”等。

●用户体验限制：如“对每个用户，每天最多推送5条内容”“禁止使用未经用户允许的批量关注行为”等。

●项目资源限制：如“项目只有两个后端开发工程师，无法在截止日期之前完成全部需求”等。

图1-1　三个关键词解读策略产品经理

●其他限制：如“当前硬件条件下，无法获取用户的心率数据”等。

策略产品经理做任何项目都无法摆脱这些限制，这些限制条件很像“运筹学”中的“约束条件”。当然，约束条件只是列举了一些常见的情况，在实际工作中不同约束条件的可操作性也是不一样的，需要具体情况具体分析。

关键词2：手段

“手段”是指在完成目标的过程中，策略产品经理经常使用的可行性方法。定义中提到了三类手段。

●推动项目：在负责的项目中，以负责人的角色，从最初的策略设计开始，逐步推动完成之后的需求评审、项目启动、项目开发、项目验收等工作，最后还要进行数据分享及筹划下一次的迭代，从而使项目流程形成一个完整的闭环。

●设定评估体系：在负责的项目上，设定客观指标体系和主观指标体系，厘清各项指标的换算关系。举个例子，在指标优先级排序上，要求点击率>互动率人均时长，点击率的权重是互动率的两倍，是人均时长的三倍，同时点击率和互动率指标允许的最大跌幅为1%，人均时长允许的最大跌幅为5%。这就将三个不同的客观指标进行了排序，同时设定了指标之间的权重关系，给出了底线阈值可接受的最大折损。任何一个项目的评估体系设置都需要与项目各参与方达成一致。

●全面评估项目收益：在“设定评估体系”的基础上，通过主观评估、数据分析和A/B测试实验数据评估方法，进行全面的项目收益评估，根据评估后的结果，决定策略是否上线。

关键词3：全局最优解

“全局最优解”是“数值分析”这门学科中提到的概念。选择用这个词来描述策略产品经理的原因是其代表着策略的最终理想态，一旦确定了“评估体系”并掌握了“评估项目收益”的方法论，每一次“推动项目”都只能完成一个项目闭环。这时候就像爬山，数据收益远没有达到理想态，需要不断地迭代项目，充分进行试错和验证才能找到全局意义上的“最优解”，将项目做到极致。

事实上，基于商业目的的考量，因为人力资源总是有限的而项目需求总是无限的，所以在大多数策略选择上难以做到绝对意义上的“全局最优”，往往选择的是带来妥协性质的“局部最优解”。策略产品经理会不断挑战自己，追求极致，从而让我们离“全局最优解”越来越近。