《产品经理成长笔记》1.1：产品经理入职ABC

写在前边

2023的秋招超乎想象的卷，我从2000+简历里，选出了30+位产品同学参加面试，这些同学都特别优秀，但是受限于今年的HC，最终只发出去了2个Offer。可能是源于对这届入职同学更多的期待，我更早些时间就着手准备产品同学入职后的系列培训材料。同时，特地把去年的产品同学入职培训大纲发给今年即将入职的2位同学，让他们反馈自己的学习需求和成长预期，并进行优先级排序；以此作为参考，增补到培训材料中。

当我看到他们反馈的脑图材料后，说实话，我有点惊奇和惊喜的。

惊奇在于，他们能那么快的梳理出多个维度的学习计划，并按照自己预期的优先级做好了排序。这种成熟度和响应速度远远超出当年初出茅庐的我。后生可畏啊！

惊喜在于，他们能从今年如此卷的秋招中脱颖而出，并最终加入团队，可喜可贺；他们能有机会在步入职场伊始就参与到从0~1的项目中，对于他们的职业发展而言，是可喜可贺的；我们的产品团队能够收获到如此有成长潜力的新鲜血液加入，也是可喜可贺的。

在调整和细化入职培训材料的时候，我逐渐清晰了一个想法：为什么不把这些培养内容提前细化整理出来，然后经过产品同学的入职培训和学习反馈后，再回来优化迭代这些内容，下一届新同学入职的时候，就会有更为具象可参考的学习材料，岂不是一件很有意义的事情。

这和我们做产品，如出一辙：

①完善产品同学入职学习提升培训大纲（流程图）--->

②将产品同学的学习材料进行调整和优化设计（原型）--->

③将拟定的产品学习内容结合案例逐一具象的呈现出来（PRD）--->

④将所有的培训学习材料，按照模块和难易度进行持续发布规划（版本管理）--->

⑤将适合于产品同学入职第一年学习的内容先上线发布（V1.0上线）--->

⑥所有的内容发布出来后，同步根据同学们的学习进度和反馈，对已发布的内容进行优化调整（V1.X敏捷迭代）--->

⑦经过一年的撰写&学习跟踪&反馈收集&优化调整，形成适合初入职场产品同学的学习路径《产品经理成长笔记-第一季》（V1.0打版本）--->

⑧依此，进行适合产品同学进阶学习的第二季、产品同学能力跃升的第三季内容整理和迭代（常态迭代）

同时，产品团队的伙伴们，也可以参照这个学习内容，将自己日常的学习、组内讨论、产研评审、需求管理等工作有意识的沉淀后，转化为文字输出，参与到内容的更新整理中。“对于学习内容的再造，是一名学霸的自我修养”，这将有助于提升产品同学的学习内化速度和知识建构深度。

此外，今年加入团队的2位产品同学，都是二年半学制硕，距离他们2023年1月中旬入职，这个时间窗口正好先整理更新一小部分内容，待同学们入职后，即可以按照既定计划学习+反馈+迭代；这个时间节奏，也较为符合创新项目的MVP设计&敏捷迭代的管理思路。

一切都是最好的安排，希望接下来的内容，不违初衷，踏雪留痕。

1.1 产品经理入职ABC

这篇内容作为产品同学的入职指引，从产品经理岗位工作、常用工具、部门间协作、产品组内工作规划、产品同学个人计划、工作周报及组内工作节奏对齐几个维度展开。

1、产品经理岗位工作

产品经理在团队中扮演/承担着信息接收、加工并输出的角色。即：将业务侧的需求接收过来，加工处理并确认后，转化成研发侧理解的语言，拉通业务+产品+研发工作流。

需求接收：产品同学要从业务侧接收需求，并通过拉会、系统演示、原型Demo演示、竞品演示等方式对业务侧提出的需求进行精准、全量的确认。

需求加工：业务侧提出的需求，可能不完整，我们需要补全；业务侧的需求可能是伪需求，我们需要通过深度互动，确认需求背后的业务诉求以及需求实现后的预期目标，如果需求背景不明确，需求价值模糊，甚至是部分业务同学偶然间的个人臆想，这样的需求，我们需要加工后，驳回。反之，则进入细化的流程图设计、原型设计、Demo设计、需求确认、需求优先级排序、PRD撰写、产研评审、研发、测试、上线、UAT、验收等环节。

需求转化：除过同学们耳熟能详的通过流程图、原型或PRD将业务侧的需求转化后输出给研发同学之外，我们需要同时关注系统架构、能力复用、中台、业务流与数据流、异常判断、共情能力这些方面。同学们入职伊始，我先浅谈一下，随着同学们能力、经验及认知加深，我们逐步在后续的第二季“产品进阶”和第三季“产品跃升”中，陆续深入展开。

①系统架构：产品经理不仅要考虑业务侧当前的需求，还需要考虑当前需求是否会再持续迭代新的功能、新的使用场景以及是否会与其他在建功能产生冲突。产品同学要培养自己“看一隅也要知全局”的需求分析习惯和能力，从系统顶层设计的角度，设计出“不仅能满足现有需求，还可以在现有系统能力基础上，进行快速迭代来支持未来N种新的应用场景；更重要的是不会对后续可能新增的其他模块迭代带来阻力”。

比如：我们在设计直播模式的时候，不仅需要考虑到目前业务侧使用的“权限准入型/需要特定的账号权限才可以观看直播”的场景，还需要考虑未来业务侧也可能需要我们支持“无权限即可观看”的公开课形式的直播。所以，在进行直播能力设计的初期，就应该将直播间的观看权限进行全局控制，每开通一个直播间，都可以选择任意一种直播类型，以保障后续所有的直播业务，都可以快速的在不同的权限约束/业务场景中进行切换和配置。

再比如：我们在进行在线学习功能的PC端页面设计时，需要同步考虑到H5页面的适配性，页面元素的排列在不影响美观和交互的前提下，尽量居中并左右对齐设计，提高页面适配性并降低前端研发同学在终端适配调试工作中投入的工时成本。

②能力复用：同学们着手对一个系统进行迭代之前，首先要了解该系统现有的全局功能，有些体量较大的系统是多个业务部门在使用，不同业务部门使用的模块或系统能力不尽相同，此种情况下，任何一个业务部门提出的需求，我们首先要看是不是“新增需求，且必须投入产研资源去实现的”，如果有其他系统能力可以代替实现当先需求，就一定不要投入资源去新建。同时大的产研体系下，是否有相关的系统能力可以直接复用，或者是开源的能力可简单二开后使用，或者是否有性价比高且可快速接入的行业已有能力？如果能复用，则无需新建。

比如：我们在进行考试系统建设的过程中，会涉及到多种考试类型（模块）的功能设计，如模拟考试、随堂考试、正式考试。这些不同的考试类型因为需要支持的业务场景不同，会有其各自不同的权限管控、考试过程管理和成绩管理等相关的功能。但是不同的考试类型，都离不开答题页面（包括页面交互，答题计时器，题目题干及答案显示等元素）的设计，这里的答题页面，就是可以复用的能力，我们可以使用同一个页面框架和交互样式，只简单的用不同的界面颜色来区分不同的考试类型即可。

③中台：同一个业务域下，如果多个应用系统都会涉及到相同或者相近的系统能力；或者不同的业务条线，可以都使用到某一个系统能力。这种情况下，就有必要将该能力下沉为中台，一次建设，多次使用，降低产研开发成本，提高系统稳定性。

比如：我们目前并行推进中的多个业务系统，都会使用到视频资源库、试题试卷资源库的能力。我们就可以将视频资源、试题试卷资源的管理能力，拿出来，进行中台建设，形成资源中心。这个资源中心，不仅可以提供不同的应用系统对视频资源、试题试卷资源进行调用；还可以支持图片、文档、H5页等资源的管理。这样形成的资源中心，就作为一个中台能力，将多个应用系统提供服务。

④业务流与数据流：产品经理设计的系统能力，首先要尊重业务流程，尽可能在不改变现有业务流程的基础上进行系统能力的设计。但是当遇到复杂业务需求的时候，就需要采用“中立”的立场，同时考虑业务流与数据库的合理性。必要的情况下，为了设计一个更为通用的系统能力，而要适度的改变业务现有的执行流程，这样是可以的，也就是“业务流程要根据系统设计的数据流，进行相应的调整”。

我们团队目前在建的系统，主要都是SaaS系统，我们要追求SaaS系统能力尽可能服务更多的用户群的同时，又不可避免的会遇到用户的个性化需求。这时，产品同学就需要遵照“业务流与数据流”并行思考的方法来审视“个性化的需求是否可以转化为通用能力”，个性化且不具备批量复制推广的需求，要克制、优化、暂缓或不做。

⑤异常判断：业务侧提出的需求，大多都是“正向”的需求，即：所有的用户操作都是对的，如此这般，用户一步步按照系统既定的设计，来操作和使用系统。但是，异常操作，错误操作，总是不可避免。这种情况，就需要产品同学主动的去思考，去和业务侧确认“如果用户错误操作了XX，我们应该如何提醒，或者拒绝？”再或者，如果系统使用过程中，出现了弱网环境、浏览器版本错误等非系统能力范畴的情况，我们的系统应该如何及时、直观的为用户通过弹窗进行提示，并通过“动词类的文案，去牵引用户接下来的操作”来保障系统使用的流畅性和完整性。此类的设计，是超出一般业务认知范围的，需要产品同学主动去思考，并牵引业务侧做出相关的需求确认。

⑥共情能力：共情，是产品同学底层能力中尤为重要的一项。简单讲就是，产品同学不能仅仅是一个需求接收者的角色，我们要转化身份，更多的从业务侧，从用户侧去思考、设计和优化需求，帮助业务侧提出更为完整、有价值的需求。同时，产品同学也要急业务之所急，主动设计一个系统功能，帮助业务侧增加营收、提升效率、改善用户体验……。切忌不可“事不关己高高挂起”，“系统上线就万事大吉，业务侧不会使用系统那是业务侧的事情”，要主动的去反思，如果业务侧不能很快上手系统使用，那就去优化系统交互设计；如果上线的功能，业务侧或者用户使用量很小，那就去反思我们设计的产品价值在哪里？审慎的去判断每一次的功能设计，对每一次的产研成本投入都要葆有敬畏之心。

2、常用工具准备

①流程图

我们团队中有个别工作时间比较久的“老产品”，总是不屑于画流程图，总觉得自己在写PRD的时候，自然会补齐相关的流程、交互和异常……。但是，往往在原型Demo阶段，就漏洞百出，不得不回去再重新开始梳理流程，画流程图。

所以，无论需求大小，产品同学都要养成一个好的习惯：画原型之前，先画流程图。作为系统产品经理，思路清晰，逻辑严谨是我们胜任产品经理岗位工作并做出成绩的必要前提。如前一节，我们对业务流与数据流的分享：系统产品设计的功能操作流程，是要服务并牵引业务使用流程的。这就需要我们通过流程图来直观呈现不同的用户从登录到登出使用系统功能的黄金流程有哪些；不同的系统用户都会使用到哪些不同的系统功能；以及这些不同的用户都有哪些典型的使用场景；不同的使用场景下，系统页面如何跳转交互；系统操作背后的数据如何流转；用户使用系统的过程中都会出现哪些异常，以及异常操作后的弹窗文案及落地页应该如何设计……。

诸如此类的问题和产品设计思考，不建议在原型工具的画板里，左一个补丁，右一个备注来完成。建议产品同学们，从职业初期就坚持使用流程图工具来表达。无论是使用传统的Visio，还是使用在线协作的ProcessOn，或者使用逐渐趋于“流程图+原型+UI”集成的摹客类在线协同工具，都可以。

至于流程图里，哪个图标是表示“开始/结束”的意思，约定俗成的使用菱形图来表示逻辑判断……这些工具使用的细节我就不再赘述了。但是工具本身承载的价值和我们为什么要使用这类工具，却是产品同学在工作伊始就需要内化为自我认识并落实到日常工作行为中的。

原型图工具，国内使用较为广泛的有Axure、墨刀。后者在交互设计和Demo生成演示方面更具优势。随着Figma在国外的兴起和广泛使用，国内诸如此类的工具也层出不穷，此类工具不仅可以满足产品同学的在线协同需求，还可以将UI设计和UE设计同学的工作也集成到一起。工具的SaaS化、系统办公，是一个不可逆的趋势。建议初入产品的同学，可以直接从在线协同的原型工具用起，包括流程图、原型图、UI设计稿、UE设计及PRD都可以在线协同完成。

同时，出于产品文档管理的需要，以及必要的版本回溯及过程管理，必要的本地化文件留存也要同步做。

PRD并不只能由某些特定工具输出，比较普遍的是通过Word将流程图与原型集合来撰写。一些大厂，也会通过内部在线协同工具来实现PRD的协同、编写及展示。上边提到的摹客，也支持PRD的在线协同。在我们集团内部关于自研在线原型工具的产品架构设计中，我也提出了，基于在线原型和批注，自动化生成PRD的构想。在我看来，PRD的在线协同工具化，未来可能也会普及到如同目前的原型、UI及UE的工具化，产品同学们可以关注下。

3、产品经理与哪些部门常态互动

产品经理最常打交道的是研发同学，日常的PRD评审、UAT、Bug处理、产研方案研判工作中，都会高频的与研发同学互动。研发侧，按照职能又分为：UI、UE、前端开发、后端开发、测试和项目经理。对于不同研发岗位的职能边界，同学们要在后续的工作中，多观察，多感知，逐步培养自己“定位系统问题后，可以快速的找到对的那个研发同学”的能力。

其次，产品经理会与业务侧同学，在需求调研、需求确认、需求评审、UAT、数据初始化、系统培训等工作中高频互动。

如前文所述，无论是与业务侧，还是与研发侧的互动，产品同学都要主动向前一步，做好润滑剂和牵引者，扮演好中枢神经的角色。多拉通，多推动。

4、产品工作的近期及中长期工作计划

产品经理的近期工作，往往从系统学习、系统操作演示、小需求设计做起；也可以通过竞品调研报告、系统使用手册撰写、系统操作讲解视频等工作，来帮助自己更快的适应团队工作。

产品同学的中长期工作计划，可以从系统产品优化设计、系统功能迭代规划等工作做起；产品基础能力较好的同学，还可以从了解业务所处行业的背景、竞对公司业务分析及竞对产品路线图等维度来对自己的学习提升进行规划。

这里，与同学们分享一句话：“先适应需要你去适应的，然后再去改变你可以改变的”。相信初入职场的同学们，都心怀梦想，铆足了劲，计划做一番事情出来，尤其是“怀揣可以改变世界梦想”的产品经理同学们，更是摩拳擦掌跃跃欲试。我刚毕业的时候也是这样，在清华大学的一个研究所工作。渡过转正期后，就开始对系统功能优化，业务模式迭代进行了“很多深度的思考”。也经常会发邮件，给自己的Leader，甚至抄送研究所领导；当时没有收到太多的反馈、鼓励和表扬，我都会有些些失落……。因为我有写工作日志的习惯，从研究所第一天的工作日志和第一封邮件，我至今都有备忘。时过境迁，在经历了研究所5年工作以及多年创业经历后，我再翻出当年那些“优化建议、产品创新、模式升级……”的邮件看看，更为深刻的意识到了懵懂、知识边界的局限；当然，也还是能回味到当年的热血和青春美好。

所以，建议产品同学们在入职初期，将更多的精力放在当前工作的胜任上，多画画流程图，让自己的流程图尽量少出缺漏；多画画原型，提升自己输出高保真原型的能力；用心撰写PRD，争取让自己的PRD不漏过任何一个字段和异常的描述……。

5、关于月计划、周计划、日工作排序

我的团队里，至今保留着每天早站会的习惯。每天工作开始前，大家都到在线协同工具中，把自己今天要做的工作写出来；还要写清楚当天工作中需要协同的组内同学以及其他部门同学；是否有关键里程碑的工作需要跟进；是否有遇到卡点的工作需要协调资源甚至升级处理；以及一天的诸多工作中，按照优先级，如何排序……。周计划与月计划的思路与日工作类似，但是需要格外重视的，就是优先级排序。

在我带过的团队中，有过很多位专业能力很强，工作态度也很端正的产品同学，他们的产品文档工作细致让我印象深刻。但却经常出现手忙后乱、掉链子、出岔子的情况。究其原因，最根本的就是总是在不断的接收工作，第一个工作没做完，第二个工作来了，就伸手接着……，导致投入到每个工作中的专注度都不同程度的受到了影响，不仅可能影响工作的质量、产出的效率，甚至会因为预警不足，出现系统事故。

所以，同学们在做计划的时候，考虑周全是需要的，但一定要客观分析自己的时间、能力以及工作需要协调的资源，理性的梳理优先级，合理管理自己的工作预期。

6、工作日报/周报撰写注意事项

参加工作后，撰写日报和周报会是常态，这不仅是向团队汇报，也是自我管理的一种最有效的方式。我经常和团队分享的一句话是：日报/周报，首先并不是写给组内组外同事或者领导看的，而是写给自己看的。通过日报和周报，告诉自己计划做什么，完成了什么，哪些还是待办，哪些出现了延期以及原因是什么后续的处理方案是什么。其次才是通过日报和周报来周知/提醒参与项目的伙伴们关注进度，知悉卡点，牵引协作；同时抄送领导关注，以便在工作出现卡点的时候，领导可以快读回顾历次日报或周报判断问题原因并快速给予指导或支持，助力问题解决。

其次，工作日报和周报切忌流水账，无重点，洋洋洒洒。如有必要同步工作细节，那就在项目开头先一句话概述关键数据、里程碑状态及是否有卡点，然后再细化展开。

最后，对于出现的问题，自己要给出来解决问题的N个预设方案（同学们不用担心，自己给出的方案，可能不完整，不完美，甚至会露怯；有思考即可），让团队或者领导做选择题，而不是给团队留一个填空题。

7、组内工作节奏对齐

这一点，我作为此次培训的结尾部分，希望同学们时刻记得，我们的工作输入和输出，都是基于一个小组、一个团队、一个业务域，甚至一个组织的全景目标下；我们自己的工作进度，要随时和干系人保持同步。

我们从“与组内伙伴同步工作节奏”做起，不能一味低头工作，要随时抬头看看外边，确保自己的工作在正确的方向上，按照正确的进度和节奏输出；如遇偏差，需要即使纠偏，归正；如遇卡点或挑战，要及时与直属Leader同步，争取资源，最快解决。

刚加入团队的同学，可能因为羞涩，不好意思提问并争取支持；也可能是觉得自己可以解决，迟迟未与团队同步，直到意识到耗费的时间太久问题仍未解决，再提出来已为时已晚。

以上是我们第一次培训的内容，对于初入职场的同学们，上述内容提及的关注点，可能相对多了些。同学们可以收藏备忘下，慢慢消化。上述话题，有未尽之处，或者大家在具体执行的过程中，遇到了哪些新的相关的挑战，可以留言或者私信交流，我一定会一一回复，并将普适的问题，更新到这篇内容中。

最后，感谢大家的时间，以上共勉。