怎么能成为产品经理，功能型产品经理

来源：头条浏览：0 2023-01-27 09:05:16

与产品经理不同，“产品功能经理”通常指的是新人。他们职位所做的一般是完成上级领导传达的职能指令，而不是独立负责模块。

什么是背景产品功能管理器？与大家理想的公关不同，刚入行的同学往往只是产品功能经理。你不会独立承担一个模块，大部分的需求都是直接从自己的leader那里传递过来，然后添加页面吗？改变对话吗？要添加字段吗？

这种模式适用于所有规模的企业。 PM从一个功能开始成长，通过脱离功能级别了解需求，可以迅速从功能转移到模块。

怎么能成为产品经理，功能型产品经理

和大家理想地引领调查市场、开创全新业务的工作略有不同，但如何成为职能经理还需要大家不断总结。接下来，从整个业务流程的简要概述开始，介绍如何从新人过渡到合格的公关。

另一方面，要理解需求的反向推脱，从用户的需求到用户的目标需求源，可能只是leader的一句话，也可能只是一封邮件，甚至只是qq消息。但是，话越少，要做的事情也就越多。

首先要明确需求和目标绝不是一回事。

要求的普通说明文是“需要添加/修改功能/页面；如：领导告诉你，王先生，请收拾我的桌子。

目标的说明文是：“我想得到某些好处；例：领导希望你，王先生，我能很快找到自己想要的文件。

区别在哪里？制造需求，把桌子上的东西摆整齐，把笔记本和文件摆好，擦一遍桌子就可以了。要达到目标，就要把每份文件分类，堆在稿纸边上，把合同一堆，把笔记本再堆一遍。

领导只有一句话，我怎么能知道目标？反过来推，从结论到原因，从现象到本质。一个功能一般只有一个目标，一个目标可以对应多个功能也是敏捷开发中强调的用户故事。

《用户体验要素》针对需求分为五个层，大多数人只在框架层和表现层考虑问题。考虑得到需求后该怎么设计交互，这个按钮放在哪里，那个表格应该怎么排列。越是表面的东西越应该最后考虑，提高自己的水平。思考用户为什么会有这样的需求，学会思考，很多人在生活中尝试着这样的逆向思维。为什么车站的饮食味道非常普通呢？为什么现在的大学生必须自学编程？透过现象看本质是你从功能经理到公关的第一步。

追溯需求，场景化功能在了解用户的真实使用目标后，还是要追溯到需求，从需求应用的场景出发，考虑如何设计完整的功能。

为什么需要落实到某个具体场景？最大的好处是带来用户的体验感。其次是遍历所有的可能性，避免设计方案泄露。

需求是用户目标的落地方案，一个目标一定能满足多种需求，如何选择最佳体验，选择资源有限下利润最高的功能是PM最核心的技能。

怎么场景化？

根据《交互设计精髓4》的介绍，应该是用户调查。从市场调研到波斯纳的设立，是场景化的前提。遗憾的是，大多数功能经理和产品经理很少有机会进行专业的用户调查。

那么，折中方案是自己使用产品，或者在产品还没有交付之前尝试原型。当然，人类很难避免带入主观，所以必须马上刹车，避免满足过度设计和不存在的需求。

市场上有比较成熟的方案，5W2H法有助于我们及时纠正。

场景化本身并不是很难，但许多产品往往会习惯性地忽略这一步。因此，我们的PRD一直在开发中受到挑战。

如果不能执行到用户的具体使用场景，则会发生设计遗漏。举个典型的例子，某导航系统APP的核心流程是帮助用户换乘地铁。 APP此时在界面上显示换乘地铁的终点站。只有把用户场景带进来才能知道。在匆忙换乘的过程中，你第一个看到的一定是下一站的几个大字。

如何尽快知道换乘地铁的方向？ Where？ When？两个主要指标可以快速带入用户场景。

二、方案设计不急于进行新产品页面设计最大的误区是以为产品职责是对话，为用户提供可用的界面。这种设计思路的弊端很多，基于这种思想的设计方案不够灵活，不能满足用户的真正目标，最终的结果往往会涌向传统。

重点介绍新人容易忽略的两点。

)1)优先组织流程

了解客户的需求后，第一步是组织业务流程，将整个方案形成闭环，并在整个流程中包括从trigger到action以及各种失败异常。

如果过程过于复杂，可以逐步细化，从用户目标出发，逐步分解为产品功能。请注意，从顶层到底层一定是一对多的关系。

整理过程时，需要根据实际需要选择流程图还是游泳地图。一般来说，如果整个交互过程是为多个用户角色设计的，则使用游泳地图更好，也更便于开发人员理解业务之间的耦合关系。

请注意流程图的制作标准。圆角矩形表示状态，圆角矩形表示动作，菱形表示判断，多边框矩形表示子进程。

如何画出完美的流程图？

首先，明确用户的输入和期望的输出，把中间的交互过程当作黑匣子，只关心用户的最初操作和最终结果。以注册这个功能为例，用户的第一个操作是要求注册，最终的结果有望是注册成功并获得账户。在流程图的这个阶段，表格中有哪些字段，对应的交互策略并不重要，现在你只需要假设你的表格有一定的完美交互形式就可以了。分割中间过程。此时，需要将流程细分为各个步骤。最理想的状态是，每个步骤都对应于后端的一个接口调用。还是以注册功能为例，提交表单只是一个步骤，使用注册帐户会有点模糊，因为在后台提交表单和生成User是两件事。补充子过程。这个时候是展示你产品功劳的时候，对异常事件的扫描是开发同学最好的帮助，网上有很多现成的功能检查表。当然，流程图不需要细化到交互的程度，只要总结主干和支线的流程就可以了。 )2)编写数据字典

为什么需要数据词典？这个问题其实和在网上讨论了很久的产品经理是否需要理解技术有很大的关联性。在我看来，产品经理一定需要了解技术。当然，你不需要写可以像开发同学那样实现的代码。但是，逻辑级的数据流PM必须理解。至少可以在同学设计数据库表的时候参加，从业务发展的角度给予一定的帮助。

为什么产品要事先制作数据词典？看起来和产品没什么关系，其实是我们宣传的核心能力。无论是优化现有功能还是添加新功能，都必须提前考虑背后的字段。

在业务层面理解数据词典。产品的各项功能并不是孤立的。在构建数据字典时，必须事先考虑功能之间的耦合关系，以便可以定义每个功能的输入和输出。产品不是表单设计的最终决定者，但必须是表单框架的直接影响者。以评论这个功能为例，我们在设计页面的时候所有的信息要素，评论者、评论时间、品论内容、评价分数……其实这些信息要素都是后台的数据字典。从接口的角度理解数据词典。例如，在注册功能表格中，您必须提前列出所有相关字段和添加的字段，并反复推敲哪些字段是必需的，哪些是可选的，哪些是作为选择填写的。产品的作用是简化过程。对于表单类产品，减少客户需要填写的表单。可以自动填写的东西没有必要由客户填写。 Suggestion可以提供的内容，一定要提示客户自动填写。那么，这些填写和补充的字段必须事先考虑好。

三、建立反馈1 .建立数据指标版本并上线并不意味着已经成功交付。产品方案设计完成后的第一件事是建立数据指标。新人产品往往有以下误解。

1 )数据不重要

大多数新产品刚进入工作时，对一个版本的迭代其实并没有太多的监控意识。 Review版本有很多错误回溯，可能不会积极看在线数据的好坏。

对所有的PM来说，无数据监控的重复令人眼花缭乱，疲劳的功能导致大多数功能都是客户无法使用的。因此，产品功能经理也需要有数据监视的意识。

2 )虚假繁荣指标

刚开始分析数据的时候容易找错路，做监测指标的时候往往只能看到自己想看的东西。例如，去看数据变化的效果时，经常会忽视其他因素的影响。这样的例子也非常多，例如基于广告推荐比特的数据上升不能反馈功能优化的结果，短期的上升不能告诉这种迭代是正确的。

3 )指标过多

有一定的入坑经验，我们往往会特别谨慎。监视一个功能的话，可以使用的数据都会被查出来。结果，忽升忽降，最终不知道该做什么。此时，必须记住，一个产品在不同阶段一定只有一个唯一重要的指标，所有迭代效果都基于这个指标。例如，查看注册功能，最终标准是转化率，表格填写比例是辅助指标，只有在分析具体原因时，才能分解观察更多指标。

2 .在线分析结合指标和功能，分析数据指标产生差异的原因。所有指标都可以量化。也就是说，迭代的效果一定是好是坏，没有其他情况。首先根据唯一指标明确此次迭代的最终效果，然后提出假设，并逐步分解指标对假设进行验证。

3 .迭代计划可以实现预期目标，总结产品经验并应用于其他功能。

未能达到预期目标，需要深入探究用户实际行为与预期行为产生差异的原因。为下一次迭代提供理论支撑。

最后，产品功能经理是我们成为真正的公关的第一步。现在，你可能还不是业务模块的负责人，但是做功能的宣传也值得深入挖掘。

这篇文章是@One原创的，每个人都是产品经理。未经许可禁止转载

标题来自Unsplash，基于CC0协议