产品认知与推动力

Renners

已于 2022-06-29 17:35:28 修改

阅读量157

点赞数

文章标签：产品运营

于 2022-03-03 21:30:00 首次发布

本文链接：https://blog.csdn.net/renners/article/details/123259123

版权

副标题：产品的术与道
在很长的一段时间内，我都在解决需求方的痛点，随着需求越做越多，对业务也有了一定的了解，慢慢也开始做系统功能的自主迭代优化，当然优化效果也是显著的，但随着时间的推移，我发现自己的产品驱动力越来越固化，虽然自主优化和创新的东西很多，但总是感觉差点东西。直到最近在部门会议上交流的时候，听到了一位前辈的分享：“无论是你们画的原型图，流程图还是今天说的PRD规范…，都是属于术的范围，这些东西很重要，但是如果你仅仅是会这些技能，是干不好产品经理的。产品经理不仅要懂术，还需要掌握道，所谓的道就是企业的经营逻辑，因为如果你不懂业务场景，不懂业务场景背后对应的经营逻辑，你无论多么精通技术，干多少年你都只是一个工具人，我们常常说产品的驱动力和主动性差，驱动力从何而来，不就是这些背后的经营逻辑吗？”。听到这里我开始反思我的产品价值观，我为什么做产品？是为了解决用户痛点，还是为企业创造价值？或是仅仅因为竞品有这个东西我就要做？想通这些问题，产品经理实际工作中常遇到的问题便有了一个比较清晰的思路。

从我对企业背景经营逻辑的理解，我将产品关于“道”的认知阶段划分为五个阶段
** 阶段一**：业务痛点驱动；并不了解企业背后的经营逻辑，所有需求都是由业务方进行驱动，产品配合
** 阶段二**：结果导向驱动；对业务熟悉，能针对现有业务流程提出优化与改进，产品认知停留在功能改进和流程优化层面
阶段三：认知价值驱动；对系统熟悉，能根据原有系统设计反推部分经营逻辑，对系统整体清晰，根据产品自身认知范围内的企业经营逻辑对系统功能进行布局规划
阶段四：战略价值驱动；了解企业经营逻辑，围绕公司战略决策与经营理念做产品的规划和设计，所作功能可以解决实际问题并创造价值
阶段五：前瞻性驱动；了解整个行业发展趋势，对企业决策提供指导性意见，并设计规划可落地的解决方案

认知层在“业务痛点驱动”和“结果导向驱动”的产品经理往往只是在做功能，认知层在“认知价值驱动”的产品经理在做系统，认知层在“战略价值驱动”的产品经理才算是真的产品经理。说一个三年产品经验的人和一个十年产品经验的人差距在哪里？技能吗？非也，差距就在其认知范围，随着技术和知识的不断更新，十年产品经验的人会的东西不一定比三年产品经验的人多，但十年产品经验人的产品认知一定比三年产品经验人的认知要深，我们大部分产品经理的认知范围都在阶段一和阶段三之间反复横跳，都只是在做功能或做系统。一个产品经理如果认知能到第三层就已经超过了60%的产品，少部分产品经理的认知达到了“战略价值驱动”，很多人甚至干了多年产品都意识不到做一款产品的价值，也不会意识到企业战略价值驱动的意义，我当前的认知也仅仅处在“结果导向驱动”和“认知价值驱动”之间，如果不是这位前辈的分享，我可能都还需要很长一段时间才能悟到“战略价值驱动”和“前瞻性驱动”。

阶段	产品认知与推动力	产生结果
业务痛点驱动	业务方提出什么问题解决什么问题，系统功能在不停的修修补补	产品和开发都很忙，并没有创造新的价值，仅保障了系统的稳定性和功能的成熟度
结果导向驱动	随着对业务的熟悉，在业务方提出痛点的时候主动挖掘业务场景深层次的需求，与业务方共同确认要做什么东西，业务流程和功能易用性得以优化	系统功能随着业务方与产品的共同推进开始了迭代优化，业务方效率得以真正提升，产品的方向由产品经理和业务方共同确定
优点：
产品经理和业务方沟通紧密，真正提升了业务方办公效率，业务方对所开发出的功能认可度高

缺点：
1、所开发的功能可能仅解决了少部分人的痛点，功能做出来有意义，但并没有解决部门或企业层的痛点，如企业本季度打算盈利1.2亿，优化网站推广渠道有助于达成企业盈利目标，然而屁股决定脑袋，提需求的业务方本身就是做基层执行工作的，此时业务方关注点就仅仅是达成本季度盈利目标自己所负责的版块要做那些优化，也许这个版块本身就是一个很边缘的功能，产品经理由于并不知道营销部门的目标，很容易被业务方带着走，导致好的开发资源没有用到刀刃上

2、在明确了业务场景和需求结果之后（知道要做什么），产品经理很容易陷入业务中，看到功能有缺失就要想方设法进行弥补，看到交互有问题就要马上进行优化，陷入了为产品优化而优化的循环中，并没有考虑那些需求要优先处理，那些需求可以暂时不处理；当然这里并没有说系统的持续性迭代有问题，而是要根据紧急程度和重要程度来决定 |
| 认知价值驱动 | 主动识别需求价值，提前规避风险，紧急需求和重要需求优先，以解决问题和价值为导向 | 需求方痛点与部门重点需求得以优先处理，避免了高价值需求流程阻塞，产品和开发还是很忙，但有了一定的节奏
优点：
以结果为导向，集中资源干重要的事，开发资源的倾斜能真正为业务方创造价值

缺点：
高价值需求永远优先处理，迭代优化类需求进度缓慢，很多人不能识别需求重要程度和紧急程度，容易造成信息不对称的理解偏差，理解偏差有如下几种情况：
1、业务方理解偏差：不理解需求重要程度和紧急程度，以自己关注的需求为中心，如需求处理时效慢，就会单方面质疑开发团队效率和产品经理对其的重视态度

总结
1、产品不仅要懂术，也要懂道。术是指一个产品经理本身的精通的技能，如原型图，流程图，需求调研，竞品分析等这些都是属于术的范围；道指的则是产品经理对业务的理解和业务背后的经营逻辑。
仅精通技术，再努力也只是一个工具人，仅懂道，看的再远方案也无法落地。

2、将产品认知提高，把自己放在上帝视角看问题，避免人为因素影响决策，以产品价值和企业战略策略决定需求优先级

3、甄别那些需求可以不做，那些需求必须要做

4、饭得一口一口吃，路得一步一步走