产品经理能力要求

帅气滴呼呼 2024-07-26 12:11:56

问题：对于产品经理来说做一个领域专家还是跨不同领域，简单说做垂类还是做横向？

个人建议以及咨询其他伙伴得出一个方向：先做垂类，提炼方法论后在做横向，每个领域建议在 2 年左右，因为做横行后发现每个领域都不专业最后发现那一个都不OK，但是方法论沉淀后绝大多数都是可以横行发展，因为底层逻辑基本不变。

基于一个领域垂类，功能性产品在不同阶段所需要的能力又是什么样的呢？

本文将从实际工作出发阐述初级-进阶-高级各个级别的核心能力讲解以及潜力如何具像化。

一、初级阶段：技能为主，更多表现为执行

这个阶段日常工作流程和内容大体是：需求分析-需求设计-需求管理-需求上线-需求调研

在这个阶段提几个工作流程中如何理解更深入，如何做的更好。

1. 需求分析：挖掘需求背后的核心本质

此模型帮助我们在分析需求后不能直接跳过用户目的，直接从用户需求到产品功能，多一个用户目的步骤帮助我们找到用户需求背后的本质。

该模型其实是也是融合了5W1H方法论进行支撑我们深度剖析问题。

如何使用该模型：

针对场景追问who，what，when，where，找到用户目的。
通过Why挖掘用户目标以及找到更多目标。
挖掘用户目标背后更深层的人性需求。

2. 需求设计

也是PRD产出，没有准确的标准，也许在产品知识学习上，公司内部都会对PRD有要求需要写哪些部分。但是实际并没有像模具一样一模一样，因为每个需求都不一样。

但是有一些大的原则需要呈现，

需求场景：描述需求发生的场景，越具体越好，目前是给协同人员比如研发培训组等伙伴，快速了解该需求在解决什么场景。

需求方案：可以是流程图，可以是截图，一句话，等，只要表达出让研发和QA看明白即可。

变动内容：往往一个需求有多次变动，此时就需要有变动版本，变动内容区别，让协调方知道我们变动了哪部分，可以是评论也可以是版本记录等形式都可以，内部约定好就行。

其余内容：比如数据埋点，需求追述，等需要看需求是否需要。

以上仅是说需求要素有哪些，具体呈现的形式是文档，图文，还是知识库根据各自公司要求即可。

在这个阶段沟通能力，往往是占据我们绝大多数时间，甚至会影响一天的节奏，经常听到产品和技术之间的相爱相杀，在沟通能力说一些自己的思考和理解。

沟通场景主要集中在内部和外部两个维度：

3. 内部产研侧沟通

经常听到技术反馈这个做不来，这个需求不完整，等等不做的理由。技术认为需求是我们瞎叭叭出来的，没必要因为一个点整那么复杂，写好多if else，测试还出一堆bug，烦躁。

在我看来核心原因是我们和技术站在了对立面，他们认为我们在加戏，那我通常怎么解决这个问题的呢？

1）多说场景少说功能：你看这个功能我们这么做，这个场景体验是不更丝滑，用户理解是不是更简单？如果我们偷懒些是不是对用户不太负责？（统一战线共同交付场景，我们是同一战壕的伙伴）

部分技术还是认为没关系，牺牲就牺牲呗～

2）追问他的卡点：到底是因为时间问题？还是难点问题？还是自己情绪问题？追问到后首先表示理解，确实有点复杂难为你了，要不在克服克服，等等。（分析卡点，解决卡点）

这时候还是不行，原因是叭叭叭一顿输出，，那就要上大招了～

3）多方拉齐：拉着他的老板抛出问题，首先确实他这里遇到卡点了，我们这个leval解决不了，大家对对齐下这个问题是目前能不能解决，风险是什么？什么时候解决，快速对齐做不做不重要，重要是有结论有节奏。（上升问题对齐问题）

4. 外部需求方沟通

外部更多是用户或者商家，这个时候需要注意核心的沟通点，需求和功能的区别，要能后快速识别出来他在说什么。（这点需要长时间刻意练习，最好是对外沟通后观察更高leval 是怎么沟通，问问他我刚刚沟通有什么问题）

比如：常说的，我想要一个马车，那这个是功能还是需求？

明显要的是一个马车，已经是一个具体的解决方案，他核心的问题还是需要一个更快的工具，马车仅仅是用户自己基于他的认知想到的解决方案。

注意：绝大多数沟通其实都是需求方提出自己理解的功能，这个时候就需要判断追问他的场景，确认他的核心问题是什么？

在外部沟通中一定要注意这点，如果跟着他的功能往下走大概率就是做的狭隘了，因为这个仅仅是一个点，而且和客户沟通也不会让客户或者用户感觉他的诉求被真正理解。

再比如说用户说我想喝水，假设他的真实诉求是口渴，你给了一杯水OK，但是你说基于你当下的场景分析说你口渴，但是我推荐有牛奶，冰水，等供你选择，我建议当下天气选择冰水是更好选择。

你觉得哪个更好呢，用户更相信哪个呢。

以上这些点做好，其实已经完成基本入门，至少在执行的维度是一个有思考的执行者，大厂俗称有思考的小头兵。

当然也要了解下产品经理的起源 https://www.woshipm.com/share/6085089.html

二、进阶阶段：一条业务线的负责，或者说负责一个或多个模块并对结果负责

1. 某个场景或者功能模块对应的洞察力

比如：B 端给查询会员给会员发券的功能。如果是初级阶段接到商户诉求做好需求并确认即可。

但对于进阶阶段来说：需要考虑更加全面，经常会通过几个问题来追问深挖。

问题所对应的场景是什么样的？

客户/用户使用这个功能最多的场景频率是什么？

客户/用户使用链路是什么？

客户/用户痛点是什么？

带着疑问回到商户真实使用推演来看：

比如商户更多使用是售后发券，那这个场景是如何发生的呢？对于餐饮行业用户用餐离开门店发现菜品不新鲜（为什么是离店，因为在店基本上线下和店员就已达成一致的处理方案），此时不想回到门店进行沟通，就会通过线上联系客服进行反馈，客服收到反馈需要需要查询会员查询订单查询发券记录目的是 chack 用户消费真实性以及是否存在薅羊毛，最终确认后，会给用户发一张券，甚至有的场景不是该客服操作可能是另一个部门操作，操作侧已经结束，但是后面还有财务的事情财务会清算：会计算A门店订单发券B门店核销，计算门店之间的优惠转账。

这就是对整个场景链路的闭环理解，此时在洞察我们最需要解决的场景核心问题是什么？这样的决策会让我们在遇到类似的问题都会有很强的体感去解决问题，当下该做什么是最重要的，基于当下的资源进行处理，后续节奏大致心里也有有数。