产品经理字节跳动收获总结：产品规划、PRD编辑、评审及复盘总结

1、编辑导读：年轻人为什么想去互联网大厂？除了薪资高之外，还有大厂完善的工作机制，以及各路大牛的亲自指导，能够帮助职场人快速成长。本文作者梳理总结了他在字节跳动的工作经验，与你分享。新公司实在太忙，现在才利用地铁时间完成第二篇复盘总结，希望对大家有所启发和帮助。本文总结了之前工作中，是如何完成需求方向确定， PRD编辑，需求评审，产研高效协作和复盘总结的，笔者希望看完这篇文章后，读者朋友都可以在当前团队试用这套产品管理方法，一些产品新人可以了解到如何做产品规划，如何写出一份结构完整的PRD,如何应用静默评审提升评审/会议效率，如何做复盘总结。因作者只在飞书产品线工作，受限于个人能力和视野局限，文中

2、内容既不能代表飞书更不能代表字节，仅是个人对过去一年多的复盘思考，不足之处欢迎评论区拍砖交流。笔者现在在贝壳金服，如果想要内推贝壳金服或贝壳的同学可以联系我哈，如果想要内推字节的同学也可以联系我，我去找朋友帮忙内推，祝好运任何方法都有适用场景，个人感觉飞书的需求管理更适合于 To C 的产品，而且一定程度上产品经理要有主导权，pm可以有效的控制节奏，如果是业务主导的随时插入需求的团队并不是很适用，如前文所说，产品的规划是按照双月纬度去推进的，虽然会有偶尔插入需求的情况，但是大多数需求都是在双月会上拉齐不同团队间的认知，协调好跨团队的资源，按照节奏进入产研流程中。前文中提到，我在飞书的时候，团队

3、是有年度规划复盘会和双月规划复盘会。当产品定位确定，年度目标和方向给出后，双月的规划会更多的是一个目标拆解的过程中的中间环节，它连接着年度目标和具体落地方案，即是年度目标的细化，也是对具体方案的抽象。一个完整功能的一页纸即可，以开发布会的视角去抽象和组织信息，以纯用户视角去编辑内容，需要体现产品的用户价值，one page prerelease1容上主要包含三个部分，标题， 2-4 个简短说明，一张示例图，如果需要可以补充一段注释。可以多看苹果和google的发布会，如何用一页PPT对一个产品的核心价值 做抽象，乔帮主的发布会值得反复学习，不堆砌硬件指标，用与用户相关的数据震撼观众，用一张图加

4、一段文字，甚至只是一张图，让观众为之疯狂。因为底层上来说，双月会上是争取团队资源做目标功能的评审会，需要大家认同当前做这个功能是有意义或价值的，所以在编辑内容过程中，需要对目标用户价值做出抽象，同时要符合产品定位和年度目标，当然所在领域的头部竞品和相关领域的头部产品都可以是思路来源，比如 gmail 的年度发布会说了什么，微软在企业知识图谱上即将上线哪些功能，在这个阶段需要pm 既要向外看，看市场的同类产品的规划方向，也要向内看，做功能抽象和用户价值提炼。其实任何职级的 PM 都可以考虑试用一下，对当前所负责的功能进行一页纸规划抽象，可以想象一下你正在发布会上介绍这个功能，如何做才有可能让用户

5、为其买单，有助于提升抽象能力，提升产品看问题的高度。上一篇文章对于PRD 模板用一张图做了简要介绍，本文详细叙述一下这套模板。模板可以看做是一套思维范式，可以统一团队看问题的视角和思考模式，一份结构合理而完整的 PRD 模板可以帮助创作者聚焦问题并发散思路，当团队中所有人用一套模板时，有利于评审时文档阅读者快速检索定位到自己的目标信息。相关人员。介绍清楚功能需求的相关方，包括产品 Owner,相关PM ,设 计师，UX,研发leader,研发同学，算法leader-,算法同学，前端，后端， SDK 等。如果存在跨业务线的情况需要把相关同学全部写明，方便后续沟通复 盘。评审记录。因为一个需求有可

6、能内部多轮评审，包括跟老板的评审，都会有一些重要的修改方向，通过评审记录完成关键意见和方向记录，因为通过静默评审答疑会在文档右侧的区域进行评论交流，所以评审记录更多是对每一次评审中重大改动意见的记录。产品方案：参考资料：当负责一些比较大型的项目，受限于当前技术能力或技术资源，需求需要拆分成多期落地实现时，微软的 PRD 模板比较好用，这是我在贝壳这边学到 的，同样分享给大家。Document Properties：Abstract。对功能的顶层抽象，抽象出系统或功能的主要价值，一般 3-5点。有点像是双月会上的产品用户价值，同时说明系统/功能对公司的价值，可以按照 1 分钟电梯演讲提炼和抽象内

7、容。User Scenario描述清楚用户场景，同上文中的用户场景Feature Requirements明确列出功能需求，并且给出评级，通过p0s0-p2s2定义产品功能重要程度，通过功能列表的定义，确定哪些功能当前重要紧急， 方便切分版本。Scope for this wave根据上面的评分，确定哪些功能在这一期的范围内， 哪些不在。Detailed Design。同上文的产品方案与字节 prd 模板有以下几点差异，对功能的优先级和重要程度界定，方便后续版本管理和规划。几个重点：不知道大家发现没有，每次我们准备跳槽面试的时候，我们往往会有一波感知明显的能力提升，因为我们需要对自己过去一段时

8、间的工作进行系统性的梳理，这个过程伴随着归纳总结，并且找到一些数据去佐证自己的价值，为谈薪获取筹码。笔者认为，产品的设计能力提升需要做定期的复盘，复盘包括几个方面：用户问题反馈，目标用户访谈和数据分析，因为飞书会有双月规划复盘会和年度规划复盘会，所以有一个机制帮助产品定期对自己所负责功能进行总结反 思。用户问题反馈。上线后会收到字节同学在bug或问题反馈群中提的意见，复盘中需要将这些问题梳理出来，确定是设计问题还是系统bug,并且与反馈问题的同学交流沟通，挖掘问题背后的诉求。目标用户访谈。除了做问题反馈用户的访谈外，还需要做目标用户的访谈，关于目标用户访谈的方法网上有不少，就不在这块赘述，在双

9、月会的汇报文档中可以将这部分内容放在相关文档出处，归纳提炼出来的一些意见可以放到正文中。数据分析。数据可以一定程度上真实反应用户的行为，所以所有功能上线前均需要做完善的埋点设计，方便分析用操作行为，辅助产品优化方案，监控问题，在复盘时可以作为量化的指标，防止大家凭感觉给反馈。准确的数据埋点是公司宝贵的数据资产，通常来说，在没有做基于数据模型驱动用户行为的设计时，往往前端用户埋点会非常混乱，导致即使有算法工程师介入，也只能服务端取业务数据，行为数据无法使用，还需要长时间的补埋点，积累数据后，才能获取到准确的数据，历史用户行为数据往往无法使用，这是一种极大的浪费，后面计划写一篇文章，总结一下我在这

10、块的思考总结，感兴趣的朋友可以提前关注哈。现在发现并不是所有的公司的产品方案都会有一个严格的内部评审机制，飞书的评审机制比较完整，分享给大家。过程中都会与对应的engineeheade中寺续交流，会不断打磨产品方案。个人 感觉上，这个过程是对产品来说压力最大也是提升最大的，后面换了新的产品老大，流程上做了一些调整，上了一套系统去管理需求，将产品上线相关的所有节点均包含在内，包括翻译，法务，数据等，因为后面的流程我没有走过，暂不做展开介绍。因为需求评审的过程中会有高级别的老板参与评审，这类评审可能不太关注具体细节的设计（也有可能非常非常非常关注字节），但是会关注对功能场景的抽象是否准确和深入，用

11、户需求场景的本质模型是什么？一些顶级竞品如微软的Team, Google G suite是如何做的，当前这个功能 是否与其他非直接竞品的底层逻辑一致，比如邮件服务是如何设计过滤器的，电商平台是如何做信息筛选的，如何实现的重要信息标记、提取和显示等。为了可以顺利评审过关， PM 需要做很多抽象工作，尝试回答现实场景中，用户需求的本质是什么，类似诉求下当前的解决方案有哪些，哪些我们可以借鉴，进而去设计我们自己解决方案，当然有可能抽象错了，也会在评审过程通过提问回答获得纠正。评审过程中先是小团队内部多人评审，使用静默评审的方式，对文档中疑惑点或者问题点进行划线提问，默读过程中，功能owner先用文字

12、回答问题，阅读完成后开始以回答问题为主的评审，如果文字回答满意可以不用复述问题，如果需要调整，评论下面创建todo。因为参与到评审中的角色会比较多（组内产品和小组leader,相关功能pm, 数据同学，算法同学等） ，所以在上评审之前需要自己问清楚自己为什么这么设计。包括但不限于交互设计，信息结构，竞品设计，策略，埋点，指标等。上一篇文章中提到了整体操作流程，这次补上一些图示。好处：看到这里，你可能会推理出飞书的评审会非常多，一个功能的迭代有可能多轮评审，而团队中每个成员还需要参与到组内或组间其他人的需求评审，所以评审比较耗时。我的理解是飞书的产品设计过程通过这种评审会（ 30到 45分钟的评

13、审会），让想法充分交流，评审过程中的静默问答模式让产品对自己的方案更加负责，上线前长时间的内部灰度确保产品质量，所以这么多伦的评审也不是适用于所有组织和团队，但是这个过程中形成的压力会磨练 pm 做更深层的抽象，对每个细节都有充分的考量，长期训练下来，有助于形成产品体感。而且评审过程中会看到高级别的 pm 如何提问，能问出好的问题是非常非常重要的。爱因斯坦曾经说过： “提出一个问题比解决一个问题更重要 ” 。而静默评审是一个帮助低阶产品学习高阶产品如何看产品，如何提问题的非常好的学习场景。其实网上一直流传着产品和研发水火难容的故事，之前的公司中，与研发配合时感觉还好，都能很快跟开发打成一片，和

14、小自己 10 几年的研发同学称兄 道弟。在 58和字节的时候，都会有一个小圈子，也可以称为产品的智囊团。先有产品证明自己的专业性，同时找到想把事情做好的关键成员， PM 说要做什么功能给出方案，前后端研发，算法，设计会帮着看方案是否有可以优化的点，哪里有漏洞帮我想到，研发主动提出更好的技术实现方案，大家为了把事情做成做好而愉快配合。也会遇到不好沟通的研发，但总能找到突破口。但最近因为配合的产研团队都在其他城市，所以遇到了一些协作问题，这让我开始思考，为什么会有这种情况出现，是否有什么机制可以一定程度解决这个问题？感觉在58 的时候是运气比较好，遇到了靠谱的同学，而字节是有一套机制和文化让人变得

15、靠谱，文化的部分放到下一章，先来说一下机制。本质上来说，产品经理和研发，设计，算法等工作性质不太一样，也就是为啥 pm 刚出来就是 “经理” 的原因，因为我们输出文档和原型，具体实现都是研发，设计和算法来落地，我们的价值是通过合作方来实现的，而且一般情况下产品会对产出负责。就如同西游记中师徒四人，产研协作中，产品就如同唐僧，经常说的就是： “我要什么” ，具体都要看孙悟空们落地。而这个过程中往往是产品经理扛着老板的压力和业务的压力，要给孙悟空们压时间和提意见，工龄长了之后，其实研发容易从对事情负责变成对任务负责，产品给出要给出没有问题的需求，研发不出 bug 的实现，一旦看到有问题的方案就会开

16、怼。笔者认为最底层上来看，这是把事做成做好的压力没有传达到团队成员的原因，更像是其他人在帮产品实现功能。如果希望团队高效协作，需要保证团队内部的成员大家对做成一个事情负责，而不是只对自己所负责的工作负责。字节的解决方案时增加一个角色，项目级别团队都会有一个engineerleader,这个角色不单单只是协调研发测试资源，组织站会，为团队争取留时间 余量和汇报进度，这个角色需要同产品owner高度配合，这个角色需要在研发评审前，和产品就产品方案达成一致，过程中可以提各种问题，但是对齐后， 那么方案的设计和落地就是两人共担。研发的老大开会的时候不会找产品，直接找对应的engineer leader

17、这个角色就是研发中的那个对项目结果负责的人，扛着对应的压力，因为他是研发体系的人，在处理内部矛盾上比产品直接协调好很多，而且我发现，越是高阶的研发负责人，越是懂业务，很多研发老板同时负责产研团队，换个角度来看，这种角色是研发负责人的种子。这个话题前一篇文章也提到过，但是还是想拉出来说一下，之前和一个关系非常好朋友聊百度搜索广告面对客户需求，产品反应速度慢的问题（可能是有的产品哈）。因为字节也在做搜索广告，所以有些类似的场景，面对客户的一个需求，字节可能是对接人快速飞书建群，拉上相关产研同学，锁定问题，讨论方案，排期规划，有可能1-2 周内开发上线，效率非常高，百度有可能耗费更久的时间走流程，一

18、个需求从一线到研发会经历很多个角色，每个角色可能都有自己的考量。因为没在百度待过，但是当时在字节的时候也有百度跳过来的同学，感觉投入度超高，非常有Owner意识，闲聊时他们会说在百度并不是这个状态。从我对自己投入度复盘来看，字节让我投入度超高主要有以下几点原因：承诺一致。说服力和细节中提到了公开承诺的力量，因为人本能的会保持自己行为和承诺一致，可能是人类为了协作对抗危险，演化写进我们基因中的一套底层编码，还记得前文中提到年度，双月，内部评审会吗？因为字节在乎数据，所以大量功能都会提前做出数据目标承诺，在多轮需求沟通（公开承诺）后，沉没成本不多增加，你会感觉这个需求或功能就是你的，千万不能做砸了

19、，进而会给自己持续增压。文化和价值观改变行为-字节范儿。当年的BAT 三家巨头中，阿里最讲企业文化建设，组织中甚至有政委的角色，没在阿里待过，但是从一些花边新闻可以看出，阿里是一个非常重视价值观和公司价值一致的公司，腾讯和百度似乎没有这么明显，三家中阿里的强度和压力也是最大的。字节没有政委，但字节范儿就是字节的文化价值观统一的密码，每个公司都有自己的文化价值观，但是字节范的落地是我见到最NB 的，当前字节范包含六句话： “追求极致、务实敢为、开放谦逊、坦诚清晰、始终创业，多元兼容” ，如何让这么抽象的概念深入人心，进而影响行为呢？通过大量的重复出现（办公室墙上，会议室未接入屏幕，食堂电视， 3

20、60环评，卫生间宣传画），来说两个场景， 360环评和卫生间宣传画。卫生间宣传画。在 58 我看到的卫生间 “展示位 ”给了公司季度业绩，猜测目标是为了激励员工努力？回忆当时似乎没有太强烈的感觉，在贝壳，看到的卫生间海报是介绍哪些行为不对，主强调正确行为引导。但是字节的卫生间海报就是宣传公司核心价值观-字节范儿，用漫画的形式告诉这些抽象概念对应的是什么行为，我在的这一年中经历过一次海报替换，但最终换回了最初我入职的那一套，感觉这个真的能体现出字节范儿是什么，大家可以感受一下。至少我感觉通过漫画我能够快速将字节范儿的抽象概念快速的与日常工作联系在一起了。360环评。在字节，试用期需要邀请其他人3

21、60环评， 8 月（年中）和3 月（年终）会有360 环评决定绩效，环评中会需要对被测评人的字节范儿给出评分和描述，环评工具会举例可以如何去写，产品一般需要给20-50个合作方写环评，所以这个过程中自己持续的给别人打环评的过程中，变向的也是在告诉自己什么是公司鼓励的行为，也是讲抽象概念具象化到自己身边同学行为的一个过程。周围同事都很拼。前文中提到了，评审会和讨论会占用大量的白天时间，虽然每个半小时到 45 分钟，但是产品有整块的时间还是要到晚上，因为字节有一个补贴政策，就是公司附近租房子有每月补贴1500 元，所以很多同学都住得离公司特别近，而且字节的食堂，下午茶，晚上零食水果是真的香，所以基本上你会发现9 点后很多人都不会走，也不着急走，而且确实又很多白天接回来的活要干，所以就出现了大面积的加班。双月会汇报压力。在飞书经历了两个阶段，第一个阶段，飞书 PM 人数不多（ 60人左右），那