想成为优秀的产品经理，这8个点需要落地

John 2023-07-26 19:04:33

周末和腾讯大佬聊天，除了上篇提到的《腾讯大佬教我的工作方法》，其中不约而同的提到一个优秀产品经理需要落地的八个点：

一、对产品所在阶段的判断：产品需求验证期、产品增长期等

我相信这个图大家都不会陌生。但是做为产品经理来说，在每个阶段重点去怎么做事需要很清晰的。这边John给的建议是：

1. 在启动阶段

产品经理一定要搭建种子用户群（C端）/搭建客户群（B端），引导用户去体验产品（真的很重要）。因为他们在体验的过程中一定有各种各样的问题点和需求，其中也会反馈出竞品相关的点（PS：谁家的产品的某个功能特别好）。

只要能按照规划能满足用户核心点，用户活跃度会非常高并且种子用户会更有参与感。相信你肯定听过腾讯“10/100/1000法则”，即：产品经理每个月必须做10个用户调查，关注100个用户博客，收集反馈1000个用户体验。

说句实话，现在要求产品经理有很强的用户感，一定要一边做自己产品的忠实用户，一边把自己的触角伸到其他用户当中，去感受他们真实的声音。只有这样才能脚踏实地做产品，你看微信就是被骂起来的（去看看微信早期用户吐槽）。

因为用户不会为你的梦想买单，只会为他们的需求买单。

2. 在成长阶段

在不断满足核心用户需求的过程中，第一步是如何实现用户增长？John通过一个简单的公式聊聊：（如下图所示）

赘述下用户画像常用的四个维度：（万能维度，但是所有的维度需要根据产品去定义）

基于用户的基本信息：性别、年龄段、地域、学历、来源渠道、注册行为等；
基于社会属性的环境信息：工作类型、职业标签、家庭身份（是否有小孩）、婚姻状态等；
用户行为数据：用户活跃度、活跃周期、每日活跃时段、使用偏好、价格偏好、参与互动数等；
用户的消费习惯及贡献度：单次贡献金额、累计贡献金额、最后一次消费时间、消费频次、投诉率等。

其他的可以在历史文章中查看：《用户增长策略三步走：产品策略、内容载体和产品增长》。

第二步再考虑商业化探索。产品商业化应该遵循两条路径：

从产品往外看，商业化的导向是业务数据、用户、流水；（变现）

从产品往里看，商业化要解决引流、获客、成交、复购等环节的连接和转化问题。（用户体验）

因为John只是笼统的来聊下商业化探索的几个方式（如下图所示）：

但是重点的是一定要平衡变现和用户体验之间的关系。（PS：就好像John公众号虽说发广告，但是一定在干货的前提下。请相信John）

3. 在成熟阶段

把用户拉进了鱼塘，就要能留住用户。所以在种子阶段的模块就要考虑好（如果留存非常差，就回头考虑产品内容的搭建和用户服务），留存做好了，有了增长，自然就达到了用户活跃度高。

其中想二次声明的是商业化是否成功很重要考量的数据是复购率。一次性购买的商业化注定是不长久的。再强调一点的是并不是到了成熟阶段，就意味着可以只想着挣钱的事情了。（PS：之前听某个大佬分享说能从用户的口袋里掏钱算本事，没有错。但是如何让用户心甘情愿的掏钱并且倍高兴才算真本事）

4. 在衰落阶段

产品一旦增长变缓、活跃度不够，变现的效率自然下降。这时候并不是一股脑强行变现（如果你这么做，结局肯定是死的）。是否寻找二次增长的策略呢？是否有其他业务模型可以探索呢？

这儿就举一个反例：美图秀秀。上周我进去看下了。这广告哎哟……真的有点多，并且基本上都不是我想要的。如果是我来做，探索拍照的场景，会做一些高级的工具做付费。（可能也是我想多了哈……就稍微的吐槽而已）

聊了这么多，想说明的是产品经理需要非常了解自己的产品后续的规划，以及针对这个产品如何迭代。那么你在做产品时就知道该如何处理了。

二、结合产品阶段判断，规划每个版本的重点，每个版本对核心指标有正向，版本之间可以互相支撑，最终搭建闭环

除了紧急Bug修复作为版本外，无论是每个版本迭代计划，都需要有一条主线。因为每次迭代版本都需要至少有一个点让用户更新APP。

针对于业务侧需求来说，迭代的模块能帮助用户做什么？比如做会员体系，那么区分会员和普通用户的点在哪儿？会员能赋予什么权益？（PS：大部分业务同事只会考虑达到会员目标，那么产品经理需要考虑成为会员的好处以及如何引导普通用户成为会员）

成为会员的好处：能更低价的购买商品？获得更多优惠券？解锁更多功能？……

引导普通用户成为会员：会员试用7天？邀请好友成为会员？……

接下来是不是还要思考会员是否有等级？等级的划分和晋升通道是怎样的？后续的模块哪些可以划分成会员专区？……

做一步考虑后续规划是非常重要的。如果你单纯的做了会员体系模块，没有后续的规划，可能在一段时间有一定的效果，可想而知未来的续费率……

闭环虽说不能一口气就完成，但是在开始的时候就规划清楚。否则后续一直在填坑的路上。老生常谈的产品矩阵账号互通这件事上……第三方账号和手机号后续互通时就知道有多麻烦了……

这里想说明的是产品规划类需求通过产品路线图一步步梳理出来，其中月度评估的业务类需求，配合用户类、优化类需求做好版本插入，才不会漫无目的迭代版本……产品的用户好评度才会提升。

下图为产品路线图：

三、需求池管理需求是做产品的基础

关于需求池的重要性就不言而喻了。它是产品路径中的基础。也是John文章中反复强调的。再赘述一遍。所有的需求全部沉淀到源需求池，每次版本迭代作为一个计划，从源需求池里面取需求出来作为目标需求池（按照月度整理）并做好同步。运营也可以相应的准备运营方案，同时回溯需求时就清晰的知道哪个版本迭代了什么？

源需求池模版如下图所示（也是John在团队中制定的标准）：

其中注意的是：需求目标是为了后续回溯这个月做了啥，是否达到了这样的效果。

月度需求模版如下图所示：

所以建议产品经理好好做好需求池沉淀。真的会收获很多。

四、产品需求文档流程图清晰无遗漏、页面UI重点突出交互顺畅、功能点描述清晰全面、文案易懂无歧义和数据埋点完整

文档可以用一些专业术语。但是要保障能让团队小伙伴能清晰的了解意图。这里其实有一个经常的遗失点——功能和页面逻辑梳理。

针对模块来说，首先要梳理用户路径流程图，整理出用户进入该模块的入口和在模块的流转过程以及对应的引导出口。（其中在模块的流转过程分成正向流程和异常流程）需要注意的一点是流程需要画清晰一点。

在梳理基础框架起码要梳理成这样：（如下图所示）

如果有些通用模块需要复用，就尽量梳理的更清晰一点。如下图所示：

你这样清晰的梳理了流程图，起码用户行进流程不会错。然后缺失的只是逻辑缺失点。主要是字段异常处理，字段因果逻辑、页面空状态和页面弱网状态。

把这些梳理清晰后，对着John之前梳理的产品自查表一步步梳理——《产品自查表》。

但是再次强调的是——首先流程图一定要整理清晰。否则其他的都是白搭……

五、与技术评审时可以讲明白需求背景、目标、逻辑和注意点

产品评审会的目的并不是对着版本把功能和页面说一下就可以了。而是需要在开篇就要让团队小伙伴明白这次版本迭代的目的是什么？为什么这么做？

我不知道有没有这样的情况，评审会上前面所有流程都非常清晰，直到某个点技术有疑问，就围绕这个点不断深挖，导致评审会花费2小时也没有产出结果。

为什么会这样？目的是大多数技术压根不知道这些版本迭代的目的和目标是什么？之前产品产生的历史数据怎样？这是产品经理需要同步的。

不要把技术同事变成实现产品的工具人，有时候技术很多建议能帮助产品提升用户体验。但是前提是让技术了解需求的前因后果。

六、重要配合事情，一定邮件周知

只要是涉及到团队配合相关的事情，一定要养成发邮件的习惯。其中有几个节点需要邮件确认：

业务需求澄清 —— 当和业务方敲定需求后，一定要邮件确认。否则会因为需求不对齐导致中途变更（这是非常吓人的！！）；
产品初审会 —— 产品第一次评审会（主要拉上业务方、技术负责人同步确认）之前一定要邮件分发给技术负责人和业务方同事，提前周知。确保在评审会上能跟得上节奏；（需要保证问题一定是提前思考过的）
产品评审会澄清 —— 第二次评审会确认后，所有涉及到的资料邮件周知确认，并CC上一级和领导层，让全体伙伴必须周知；
产品排期表澄清 —— 有了排期表后，第一次时间同步给业务、技术、上级和领导层，并且跟进项目；
产品迭代通知 —— 其中一定要写清楚的是更新的内容和下载地址，主要目的是让团队伙伴周知产品已更新。需要同步客户、种子用户体验等等；
产品数据反馈 —— 前两周更新表现的数据指标（距离目标的差距表现），作为版本复盘点。

以上6个邮件是产品经理必须要去做的。需求透明、开发进度透明、版本透明和数据透明，这四点不复杂，但是能坚持的就非常少了。