产品经理成长之路:完成比完美更重要

产品老司机手把手教写文档,10天线上课程,零基础掌握产品经理必备7大文档撰写法。了解一下>

对B端产品经理来说,日常工作中的流程一般是什么呢?工作的时候又要注意哪些要点,避开哪些坑呢?笔者结合自己的实践经验为大家分享以上问题的答案。

写在前面

经过了几个月的产品实习,感慨万千,十分想将自己的经验,或者说是经历分享给大家,一来想和广大产品新人共同进步,二来也希望能够从产品前辈处得到一些批评指正。

我进行的是面向B端的中台产品实习生,所以需要在熟悉公司业务的基础上,考虑产品实现的逻辑,产品的用户也是公司内部人员。所以我的经验分享也主要是从B端产品的角度来进行,当然我相信和C端产品也会有共通之处,比如在沟通、紧急事件处理等方面,是属于在日后各类工作中可以进行复用的经历。

文章将按照产品经理进行工作的大致流程进行叙述,架构如下:

  • 一、需求挖掘与分析
  • 二、产品方案的思考与撰写
  • 三、产品方案评审
  • 四、跟进开发进度直至验收上线
  • 五、用户操作手册撰写
  • 六、数据指标分析
  • 七、复盘
  • 八、其他Tips

一、需求挖掘与分析

关键词:需求辨别

B端产品的需求大多数直接来自于业务方,少部分可能是产品经理自主挖掘,尤其涉及到整体逻辑的重构或是一个全新的项目开展,往往是产品提出的需求。C端产品的需求基本上都要产品经理自主去挖掘,借助问卷调查、用户评论、数据埋点分析、竞品分析等方法。但无论是C端还是B端产品在遇到各类需求时,都需要具备需求辨别能力。良好的需求辨别能力能够让你迅速分辨出哪些是该做的需求,哪些是没必要的需求;哪些需求优先级更高,必须尽快实现,哪些需求可以暂放,后续慢慢实现等等。

在拿到一个需求时,至少要进行如下几方面思考:

  1. 需求的场景,为什么提出这样的需求,解决什么问题?
  2. 有多少用户有这样的需求,是否值得实现?
  3. 实现后能带来的什么样的收益?比如用户使用次数增多、人效提高等,并不仅仅指金钱收益。
  4. 如何实现这一需求,如何既能满足需求又能简化实现方式与过程?
  5. 这一需求是否对其他模块造成影响,影响的评估?
  6. 这一需求的优先级,实现的紧迫性?

在整个需求分析过程中,我们都要多角度思考,既要站在用户角度看问题,也要站在研发角度看问题,更要站在产品角度看问题。

要学会跳出来看问题,不能被用户提出的需求受限,我们要考虑一个需求优化的外延性和其他可能性,要比用户考虑的更前一步,不能只看眼前优化的点,要考虑前后变动,不同业务、产品之间的关联,无论是系统和APP都要具有一定的灵活性与柔性,才能更好的支撑后续的优化与改进。

产品经理要摒弃一些想当然的想法,比如不能用户希望实现的功能就一定实现,必须考虑必要性(合理性)、可行性、收益;比如不能开发说不能实现就不去尝试,尤其对于不太懂技术的产品来说,千万不要抱有这样的想法,无论是否真的能实现,我们都要提出自己的看法,进行质疑与沟通,不要害怕说错话被嘲笑,永远不说不表达,永远也不会有成长。

另外我们还需要将所有的需求进行梳理,借助表格的形式,生成需求池,对需求进行分类、描述优化内容、优先级判断、目前的实现状态记录等等。

借助需求池,我们能大致知道一个产品在迭代过程中优化了哪些需求,还有哪些需求没有实现,哪些需要我们尽快实现。

关于优先级的确认:

B端的需求优先级不单单是由产品经理来决定的,而是要根据当前的项目饱和状态、具体使用时间等和业务方共同确认。

一般来说会影响当前使用、线上bug、时间紧急的需求必然优先级会高一些,而单纯的没有影响使用并且只涉及到少部分人的需求,优先级可能会低一些,但是还是要根据具体情况灵活判断。

如果有些需求临近使用,优先级是可以自动提升的,这个也是需要相关的产品经理自己注意这些时间节点,不能等到用户提醒才想起这些需求,然后导致紧急开发上线或是只能再次搁置。

我们也可以借助时间管理中的四象限法则:重要且紧急、重要不紧急、紧急不重要、不紧急不重要,来对需求进行大致的分类,并确定优先级。

关于竞品分析:

做竞品分析是属于需求挖掘的一种,通过与竞品的对比,优势继续发扬,短板进行补足,互相竞争才有长足发展。

相较而言,C端产品进行竞品分析会容易许多,因为可以直接获取到要分析的竞品产品,而B端产品往往很难接触到竞品公司的内部业务,所以较难分析。

但是有一点就是B端用户的用户其实也是C端,所以也可以借助相关C端产品的分析,但是关注的点可能会比较不一样,比如C端竞品会考虑功能结构、用户体验等等,但是B端产品在进行竞品分析时,要透过现象看本质,在体验相关的C端产品时要更多的去考虑这个产品背后公司的业务构成与逻辑。

二、产品方案的思考与撰写

关键词:全面、准确、无歧义、可读、不要拖延

在对当前需要做的需求有了大致的想法后,就可以开始撰写文档了,记住千万不要等全部都想好了才开始写,而是有思路就要动笔,后面再逐步的完善细节。

在deadline横行的时代,越来越多人选择在最后一刻完成任务,其实这样并不是最好的方式,并且很多情况下提交的东西也不会是我们自己特别满意的东西。

所以其实最好的做法是,从最开始就记录自己的想法,先将文档整体的框架搭出来,对于一些不能够确认的细节,或是暂时未发现的问题,再一步步的去解决优化,可以借助脑图的形式将考虑到的各种场景记录下来,然后逐步判断方案是否能够满足这些场景的需求。

不要妄想一口气吃个胖子,也不要妄想一次完美的解决掉所有的问题,扔掉完美主义与拖延,完成比完美更重要

一份文档大致包含的内容有相关的项目背景、存在的问题、项目的目标、相关的部门、产品方案的概述、具体的优化需求描述等等,可能根据不同项目的特点与阶段会结合进竞品分析、项目风险、埋点需求等等,有时关于竞品和数据分析的部分也会单独抽离出来。

文档书写的一些Tips:

  1. 文档描述要全面,写清楚哪些没有变动,变动部分的如何变动
  2. 文档描述要准确无歧义
  3. 灵活借助目录、图示、表格、文档修订记录等来使文档可读性更高
  4. 根据方案长短灵活添加产品方案概述,总结方案中优化的点
  5. 存在的问题与项目目标基本是相对的,分点进行阐述,对于每个点进行简单总结,再具体描述,尽可能使用数据指标来衡量
  6. 涉及较多界面与交互的方案,除了产品经理自己制作原型外,最好也与专门的交互和UI设计师合作
  7. 做原型时要尽可能保持风格一致,但不意味着交互必须完全相同,因为可能有些之前存在的交互方式就不是最优的,要灵活判断
  8. 涉及逻辑、校验较多的方案,一定要配上流程图,会比文字更清晰易懂
  9. 可以模仿公司其他产品前辈的文档书写模式,要多看,看得多了就知道原来这里这样描述更好。接触到的越好,成长的越快。这也是为什么大家都希望能够进大厂实习,榜样越强大,成长的越快。

三、产品方案评审

关键词: 多次沟通反馈机制 

其实方案的撰写与评审是交叉的关系,在不断的沟通中,方案也会根据实现的难度、时间等原因进行调整,直至最终确定并进入开发。(方案评审-修改-评审-修改-评审-确定-开发)

撰写一份严谨的PRD是产品经理的必备技能,但是能够清楚的向各方人员阐述自己的方案是更加重要的技能。

在进行方案评审时,一定要交代清楚这个方案涉及的项目背景、存在的问题,我们为什么要解决这样的问题,解决了能带来怎样的收益,我们如何解决,涉及哪些模块,进行了哪些改动,从什么改成什么等等。

在这一过程中,往往很容易出现各方人员对同一句话理解不一致的情况,这种时候最好的方式是能够说出具体的场景,进行举例。

我们要学会建立起一种多次沟通反馈机制,在每次方案评审后,要及时记录会议纪要并同步给相关人员,包含需要修改的部分、存疑的部分等等,将确认修改的部分同步在文档中,对于存疑的部分,在下次沟通时进行二次确认,因为有时一次评审可能研发老师还没能彻底理解我们的方案,可能需要一点时间理解相关的业务场景,判断代码上实现的可行性。通过多次的沟通反馈,保证相关人员都能够理解并确定下来最终方案。

四、跟进开发进度直至验收上线

关键词:提早介入、进度同步、仔细验收、持续监控、查明问题原因

在进行完方案评审并确定可以开发的情况下,首先需要前后端、测试人员给出具体排期、上线时间。根据排期时间,产品经理要不断地跟进和推动整个项目开发上线的进度。尤其对于比较大型、逻辑复杂的项目,更要提早介入开发与测试,定期询问状态,避免到最后验收阶段才爆发各种问题与风险。

有时产品经理可能会遇到项目进度推动难或是bug修复进展慢的情况,对于这类情况,首先要辨别一下原因,是由于相关人员手中工作量过于饱和、其他更高优先级项目抢占研发资源、项目实现起来比预期困难或是某方人员不够重视该项目导致的等等。

根据不同的情况,灵活的处理与报备。如果发现以你的身份层级已经推动得很艰难,一定要尽早借助leader的力量去推动,并且要及时同步相关人员目前的进度情况。

作为产品经理要连接前后端、测试多方人员,必须协调和同步好时间,要确保各方均已知晓,不然就会出现信息不对称,时间不统一的尴尬情况。

在正式上线前,产品经理会进行验收,验收时切记不可马虎大意,要针对文档中相关优化的点进行一一验收,在测试环境无法完全验收或是在线上不方便进行验收的部分,正式上线后也要持续进行监控。

也就是说上线并不意味着结束,因为有时到了真实环境,大量的数据运行起来,可能会爆发测试、验收过程中没有发现的问题。

这种时候首先要判断这一问题的影响,是属于方案漏洞还是研发处理上的bug,目前能够采取什么应急方案先进行修补,并且要让开发、测试人员及时进行bug的修复,或是紧急完善相关的方案,提高当前项目优先级,协调开发、测试资源继续支持,迅速迭代。

这种时候其实最重要的是不能慌乱。对于发现的问题,一定要查明原因并记录下来,避免后续再出现同样的问题。对于采取应急措施解决但实际没能复现的bug,千万不能忽视,一定要让开发人员进行复盘,查明原因,避免留下隐患。

直到负责的项目稳定运行一段时间后,这一版的优化才算告一段落。而下一版优化的需求梳理、方案撰写等流程在这一版进入开发时,就已经可以开始准备了。

五、用户操作手册撰写

关键词:用户角度

在项目临近上线前,产品经理就可以开始撰写用户操作手册了,撰写的角度是从用户操作使用的角度,一般借助PPT的形式。如果是面向公司内部人员的产品,还要对相关用户进行使用培训。

六、数据指标分析

关键词:核心数据指标确定、透过数据看本质

一个项目完成的是否符合预期,是可以从数据层面来进行衡量的,也就是文档中衡量项目目标的数据指标部分,数据指标提升得好,也是对产品经理工作的肯定。

一方面我们可以在项目开始前,借助之前的数据,分析挖掘相关的需求,并以此衡量我们的项目目标,进行结果导向;另一方面在过程中也可以借助数据分析来查明一些问题的原因;在项目运行一段时间后,可以再次收集相关的数据进行分析,评判本次优化的效果。

产品经理要培养数据思维与数据感,确定核心数据指标,然后借助合理的工具与方法,进行数据采集与分析,并得出相关的结论,结论不应当仅仅是数据层面的占比,而是要透过数据看本质,分析导致数据表象的真实原因。

七、复盘

关键词:PDCA循环 

大大小小的项目都需要复盘,将做得好的部分整理成可以复用的经验,做得不好的部分分析原因,进行记录,避免再犯。

其实犯错误、出问题不可怕,可怕的是一直犯同样的错误、一直出同样的问题。在这里有一种方法可以借鉴,叫做PDCA循环法:P是计划,D是执行,C是检查,A是行动,在这里面最重要的是在每一轮循环中通过Check,采取一定的Action,好的进行“奖励”,坏的进行“惩罚”,再复用进下次PDCA循环中。

八、其他Tips

  1. 每句话都要说到位,谨言慎行,对自己所的每句话负责
  2. 对于不同身份职位的人以什么口吻、从什么角度去沟通是值得不断学习的事情
  3. 建立多次沟通反馈机制,避免出现“知识的诅咒”
  4. 所有变动和沟通及时记录在文档或是会议纪要中,不要用脑子,用文字
  5. 提升自己的思维运转,要保持质疑与思考
  6. 一定要熟悉你的业务、文档,这样出现问题时才能更快的定位
  7. 学会目标拆分,最基本最核心的目标、其他有优化余地的目标等等

写在最后

其实上面阐述的流程是基于已有项目的优化,因为实习生一般不太会直接负责一个新产品或是新项目的搭建。

如果一个项目是从0-1的话,要进行更多的工作,比如项目立项、更多层面的竞品分析、产品框架与边界确定、功能结构图等等。

作为产品新人,还有很多要学习的地方,也还有很大的成长空间。未来还有很多的“坑”需要我去踩,也希望我能分享出更多有价值的经验。

人人都是产品经理,但不是人人都能够理解产品经理。曾经有人对我说,产品经理就是传话的,但我想说如果没有产品经理在中间“传话”,那么工作将无法顺利进行。

 

本文由 @齐进取 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议。

给作者打赏,鼓励TA抓紧创作!
评论
欢迎留言讨论~!
  1. 谢谢分享!讲真,产品经理真的被人低估了吧,什么都要会,什么都得用,左原型右设计,进能写代码后能做运营。yysy,原型用墨刀,设计用sketch都还可以~ ;-)

    回复
    1. 其实我理解工具主要还是提升效率,无论用哪个,用的顺手的,画的能表达出意图,画得快画得好就可以了,但要是考虑到协作共享,可能就必须得用和公司一致的工具了

      回复
    2. 对哇,工具只是一个表达的方式 ,不是目的,顺手顺手就好~ ;-) 哈哈我觉得墨刀企业版的协作共享很好,那些划水的再也划不了了哈哈

      回复
  2. 受益匪浅

    回复
  3. 加了一些项目管理的机制

    回复
  4. 很完整的方法

    回复