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

田宇洲 2023-07-28 03:41:42

一、前言

新公司实在太忙，现在才利用地铁时间完成第二篇复盘总结，希望对大家有所启发和帮助。

本文总结了之前工作中，是如何完成需求方向确定，PRD编辑，需求评审，产研高效协作和复盘总结的，笔者希望看完这篇文章后，读者朋友都可以在当前团队试用这套产品管理方法，一些产品新人可以了解到如何做产品规划，如何写出一份结构完整的PRD，如何应用静默评审提升评审/会议效率，如何做复盘总结。

因作者只在飞书产品线工作，受限于个人能力和视野局限，文中内容既不能代表飞书更不能代表字节，仅是个人对过去一年多的复盘思考，不足之处欢迎评论区拍砖交流。

笔者现在在贝壳金服，如果想要内推贝壳金服或贝壳的同学可以联系我哈，如果想要内推字节的同学也可以联系我，我去找朋友帮忙内推，祝好运~

二、产品规划、落地和复盘

任何方法都有适用场景，个人感觉飞书的需求管理更适合于To C的产品，而且一定程度上产品经理要有主导权，pm可以有效的控制节奏，如果是业务主导的随时插入需求的团队并不是很适用，如前文所说，产品的规划是按照双月纬度去推进的，虽然会有偶尔插入需求的情况，但是大多数需求都是在双月会上拉齐不同团队间的认知，协调好跨团队的资源，按照节奏进入产研流程中。

2.1 产品规划-one page prerelease

前文中提到，我在飞书的时候，团队是有年度规划复盘会和双月规划复盘会。当产品定位确定，年度目标和方向给出后，双月的规划会更多的是一个目标拆解的过程中的中间环节，它连接着年度目标和具体落地方案，即是年度目标的细化，也是对具体方案的抽象。

一个完整功能的一页纸即可，以开发布会的视角去抽象和组织信息，以纯用户视角去编辑内容，需要体现产品的用户价值，one page prerelease内容上主要包含三个部分，标题，2-4个简短说明，一张示例图，如果需要可以补充一段注释。

标题。一句话说明功能提供给用户的最主要价值是什么。
说明。简要介绍这个功能是什么，如何帮助用户提升哪方面的效率，如果有数据可以写上预计对核心指标的影响。
示例图。可以是低保真示意图，也可以是高保真效果图，还可以是竞品或相关产品的拼接图，核心是体现出这个功能未来可能是什么样子的，价值是什么。

可以多看苹果和google的发布会，如何用一页PPT对一个产品的核心价值做抽象，乔帮主的发布会值得反复学习，不堆砌硬件指标，用与用户相关的数据震撼观众，用一张图加一段文字，甚至只是一张图，让观众为之疯狂。

因为底层上来说，双月会上是争取团队资源做目标功能的评审会，需要大家认同当前做这个功能是有意义或价值的，所以在编辑内容过程中，需要对目标用户价值做出抽象，同时要符合产品定位和年度目标，当然所在领域的头部竞品和相关领域的头部产品都可以是思路来源，比如gmail的年度发布会说了什么，微软在企业知识图谱上即将上线哪些功能，在这个阶段需要pm既要向外看，看市场的同类产品的规划方向，也要向内看，做功能抽象和用户价值提炼。

其实任何职级的PM都可以考虑试用一下，对当前所负责的功能进行一页纸规划抽象，可以想象一下你正在发布会上介绍这个功能，如何做才有可能让用户为其买单，有助于提升抽象能力，提升产品看问题的高度。

2.2 产品方案落地-PRD

上一篇文章对于PRD模板用一张图做了简要介绍，本文详细叙述一下这套模板。模板可以看做是一套思维范式，可以统一团队看问题的视角和思考模式，一份结构合理而完整的PRD模板可以帮助创作者聚焦问题并发散思路，当团队中所有人用一套模板时，有利于评审时文档阅读者快速检索定位到自己的目标信息。

相关人员。介绍清楚功能需求的相关方，包括产品Owner，相关PM，设计师，UX，研发leader，研发同学，算法leader，算法同学，前端，后端，SDK等。如果存在跨业务线的情况需要把相关同学全部写明，方便后续沟通复盘。

评审记录。因为一个需求有可能内部多轮评审，包括跟老板的评审，都会有一些重要的修改方向，通过评审记录完成关键意见和方向记录，因为通过静默评审答疑会在文档右侧的区域进行评论交流，所以评审记录更多是对每一次评审中重大改动意见的记录。

Change Log。因为会有可能出现多次修改，包括文字，原型图片等，包括进入测试环节的一些逻辑补全，都需要以表格的形式记录好，方便研发和测试同学查看。
名词解释。文档中可能包含一些需要说明的企业黑话或专有名词解释，方便非内部团队同学阅读文档，比如一些常规搜索评估指标，MRR，topN有点比，NDCG等
背景。用文字清晰的描述需求的背景信息，如果已有功能的优化，可以将数据看板挂在背景模块，背影模块需要写明为什么做这个这个功能，用户价值是什么，公司价值是什么，对齐那个年度或阅读OKR。
目标用户。包括主要用户，次要用户，关键用户，负面用户
用户场景。用实际的案例描述用户场景，比如小王在什么情况有什么诉求

产品方案：

解决哪些问题。以列表形式列出该功能可以解决的问题
目标。定义需求数据目标，如果包含了新的指标可以说明指标计算方法，指标可以拆分一级指标，二级指标或三级指标
方案设计。以金字塔原理组织需求内容，这块从阅读者视角去组织信息，总分结构，复杂功能可能涉及到功能模块的抽象和拆解

参考资料：

竞品分析。列出所选竞品，将竞品文档链接添加在此处。
相关文档。包括需求的历史相关文档，用户访谈文档，数据报告文档，埋点文档

当负责一些比较大型的项目，受限于当前技术能力或技术资源，需求需要拆分成多期落地实现时，微软的PRD模板比较好用，这是我在贝壳这边学到的，同样分享给大家。

Document Properties：

Feature Owner。同上文中的相关人员
Related Document。同上文中参考资料-相关文档

Abstract。对功能的顶层抽象，抽象出系统或功能的主要价值，一般3-5点。有点像是双月会上的产品用户价值，同时说明系统/功能对公司的价值，可以按照1分钟电梯演讲提炼和抽象内容。

User Scenario。描述清楚用户场景，同上文中的用户场景

Feature Requirements。明确列出功能需求，并且给出评级，通过p0s0-p2s2定义产品功能重要程度，通过功能列表的定义，确定哪些功能当前重要紧急，方便切分版本。

Scope for this wave。根据上面的评分，确定哪些功能在这一期的范围内，哪些不在。

Detailed Design。同上文的产品方案

与字节prd模板有以下几点差异，对功能的优先级和重要程度界定，方便后续版本管理和规划。

几个重点：

多思考，多问为什么。刚开始做产品经理的时候很容易凭感觉设计，感觉应该怎样就怎样，prd模板就是一套思考范式，梳理清楚背景，描述清晰的用户场景，明确要解决的问题，定义精确的目标，同时对竞品有深入的理解和调研，再来设计产品，这些前置的准备其实就是我们这个功能为什么这样设计的原因。而且因为评审方式的原因，就需要提前切换成文档的读者模式，看一下哪些点可能有疑惑。同时，为了防止评审中被challenge的尴尬，所以需要提前自己多问自己为什么这么设计，你的设计是当前能找到的最好设计吗？
终盘反推思维。在飞书学到一个产品设计思考方法，在产品设计的时候可以一定程度上先跳过技术和人力壁垒，考虑最优的体验应该是什么样的，然后在根据当前的实际能力和人力，去做方案降级，这样我们能确保产品的方向是对的，同时设计上可以更好的兼容未来的优化，不太会出现全盘推翻重做的情况。

2.3 产品复盘

不知道大家发现没有，每次我们准备跳槽面试的时候，我们往往会有一波感知明显的能力提升，因为我们需要对自己过去一段时间的工作进行系统性的梳理，这个过程伴随着归纳总结，并且找到一些数据去佐证自己的价值，为谈薪获取筹码。

笔者认为，产品的设计能力提升需要做定期的复盘，复盘包括几个方面：用户问题反馈，目标用户访谈和数据分析，因为飞书会有双月规划复盘会和年度规划复盘会，所以有一个机制帮助产品定期对自己所负责功能进行总结反思。

用户问题反馈。上线后会收到字节同学在bug或问题反馈群中提的意见，复盘中需要将这些问题梳理出来，确定是设计问题还是系统bug，并且与反馈问题的同学交流沟通，挖掘问题背后的诉求。

目标用户访谈。除了做问题反馈用户的访谈外，还需要做目标用户的访谈，关于目标用户访谈的方法网上有不少，就不在这块赘述，在双月会的汇报文档中可以将这部分内容放在相关文档出处，归纳提炼出来的一些意见可以放到正文中。

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

三、需求评审

现在发现并不是所有的公司的产品方案都会有一个严格的内部评审机制，飞书的评审机制比较完整，分享给大家。

第一轮，双月会上基于prerealease完成优先级拉齐
第二轮，产品团队内部的评审(复杂方案会切分成多轮多次评审)
第三轮，内部讨论一致的方案跟老板和各团队一起评审
第四轮，拿着产品团队对齐的方案跟研发评审排期

过程中都会与对应的engineer leader持续交流，会不断打磨产品方案。个人感觉上，这个过程是对产品来说压力最大也是提升最大的，后面换了新的产品老大，流程上做了一些调整，上了一套系统去管理需求，将产品上线相关的所有节点均包含在内，包括翻译，法务，数据等，因为后面的流程我没有走过，暂不做展开介绍。

3.1 向上-对功能的顶层抽象

因为需求评审的过程中会有高级别的老板参与评审，这类评审可能不太关注具体细节的设计（也有可能非常非常非常关注字节），但是会关注对功能场景的抽象是否准确和深入，用户需求场景的本质模型是什么？

一些顶级竞品如微软的Team，Google G suite是如何做的，当前这个功能是否与其他非直接竞品的底层逻辑一致，比如邮件服务是如何设计过滤器的，电商平台是如何做信息筛选的，如何实现的重要信息标记、提取和显示等。

为了可以顺利评审过关，PM需要做很多抽象工作，尝试回答现实场景中，用户需求的本质是什么，类似诉求下当前的解决方案有哪些，哪些我们可以借鉴，进而去设计我们自己解决方案，当然有可能抽象错了，也会在评审过程通过提问回答获得纠正。

3.2 向下-每个设计点多次自我拷问-我为什么这么设计？

评审过程中先是小团队内部多人评审，使用静默评审的方式，对文档中疑惑点或者问题点进行划线提问，默读过程中，功能owner先用文字回答问题，阅读完成后开始以回答问题为主的评审，如果文字回答满意可以不用复述问题，如果需要调整，评论下面创建todo。

因为参与到评审中的角色会比较多(组内产品和小组leader，相关功能pm，数据同学，算法同学等)，所以在上评审之前需要自己问清楚自己为什么这么设计。包括但不限于交互设计，信息结构，竞品设计，策略，埋点，指标等。

3.3 评审方式-静默评审

上一篇文章中提到了整体操作流程，这次补上一些图示。

创建日程，将参加评审同学添加至日程，并编辑会议摘要，说明评审内容，参与者收到飞书push日程的消息，会议开始前X分钟自动追加一个消息提醒
会议开始后，通过日程快速创建会议群，群内发出待评审PRD，大家在各自电脑打开阅读文档，对疑惑/质疑点时划线编辑评论
一次PRD评审控制在45分钟，PRD作者组织评审，一般会15分钟阅读文档，过程中PRD作者通过文字回答评论提问，阅读完成后文档底部点赞代表阅读完成，多数人点赞后开始对评论答疑讨论，并记录todo

好处：

通过阅读而不是presentation展开方案讨论，让评审更客观，不会被演讲者带节奏；
要求文档逻辑更加清晰简洁（15分钟可以读完）；
评审过程基于问答更加聚焦，不容易跑题；
问答过程记录在文档评论区，同时记录todo，节省部分会后整理会议纪要时间

看到这里，你可能会推理出飞书的评审会非常多，一个功能的迭代有可能多轮评审，而团队中每个成员还需要参与到组内或组间其他人的需求评审，所以评审比较耗时。

我的理解是飞书的产品设计过程通过这种评审会（30到45分钟的评审会），让想法充分交流，评审过程中的静默问答模式让产品对自己的方案更加负责，上线前长时间的内部灰度确保产品质量，所以这么多伦的评审也不是适用于所有组织和团队，但是这个过程中形成的压力会磨练pm做更深层的抽象，对每个细节都有充分的考量，长期训练下来，有助于形成产品体感。

而且评审过程中会看到高级别的pm如何提问，能问出好的问题是非常非常重要的。爱因斯坦曾经说过：“提出一个问题比解决一个问题更重要”。而静默评审是一个帮助低阶产品学习高阶产品如何看产品，如何提问题的非常好的学习场景。

四、高效协作

其实网上一直流传着产品和研发水火难容的故事，之前的公司中，与研发配合时感觉还好，都能很快跟开发打成一片，和小自己10几年的研发同学称兄道弟。

在58和字节的时候，都会有一个小圈子，也可以称为产品的智囊团。先有产品证明自己的专业性，同时找到想把事情做好的关键成员，PM说要做什么功能给出方案，前后端研发，算法，设计会帮着看方案是否有可以优化的点，哪里有漏洞帮我想到，研发主动提出更好的技术实现方案，大家为了把事情做成做好而愉快配合。也会遇到不好沟通的研发，但总能找到突破口。

但最近因为配合的产研团队都在其他城市，所以遇到了一些协作问题，这让我开始思考，为什么会有这种情况出现，是否有什么机制可以一定程度解决这个问题？感觉在58的时候是运气比较好，遇到了靠谱的同学，而字节是有一套机制和文化让人变得靠谱，文化的部分放到下一章，先来说一下机制。

本质上来说，产品经理和研发，设计，算法等工作性质不太一样，也就是为啥pm刚出来就是“经理”的原因，因为我们输出文档和原型，具体实现都是研发，设计和算法来落地，我们的价值是通过合作方来实现的，而且一般情况下产品会对产出负责。

就如同西游记中师徒四人，产研协作中，产品就如同唐僧，经常说的就是：“我要什么”，具体都要看孙悟空们落地。而这个过程中往往是产品经理扛着老板的压力和业务的压力，要给孙悟空们压时间和提意见，工龄长了之后，其实研发容易从对事情负责变成对任务负责，产品给出要给出没有问题的需求，研发不出bug的实现，一旦看到有问题的方案就会开怼。

笔者认为最底层上来看，这是把事做成做好的压力没有传达到团队成员的原因，更像是其他人在帮产品实现功能。如果希望团队高效协作，需要保证团队内部的成员大家对做成一个事情负责，而不是只对自己所负责的工作负责。

字节的解决方案时增加一个角色，项目级别团队都会有一个engineer leader，这个角色不单单只是协调研发测试资源，组织站会，为团队争取留时间余量和汇报进度，这个角色需要同产品owner高度配合，这个角色需要在研发评审前，和产品就产品方案达成一致，过程中可以提各种问题，但是对齐后，那么方案的设计和落地就是两人共担。

研发的老大开会的时候不会找产品，直接找对应的engineer leader，这个角色就是研发中的那个对项目结果负责的人，扛着对应的压力，因为他是研发体系的人，在处理内部矛盾上比产品直接协调好很多，而且我发现，越是高阶的研发负责人，越是懂业务，很多研发老板同时负责产研团队，换个角度来看，这种角色是研发负责人的种子。

五、Owner意识

这个话题前一篇文章也提到过，但是还是想拉出来说一下，之前和一个关系非常好朋友聊百度搜索广告面对客户需求，产品反应速度慢的问题（可能是有的产品哈）。

因为字节也在做搜索广告，所以有些类似的场景，面对客户的一个需求，字节可能是对接人快速飞书建群，拉上相关产研同学，锁定问题，讨论方案，排期规划，有可能1-2周内开发上线，效率非常高，百度有可能耗费更久的时间走流程，一个需求从一线到研发会经历很多个角色，每个角色可能都有自己的考量。

因为没在百度待过，但是当时在字节的时候也有百度跳过来的同学，感觉投入度超高，非常有Owner意识，闲聊时他们会说在百度并不是这个状态。从我对自己投入度复盘来看，字节让我投入度超高主要有以下几点原因：

承诺一致。《说服力》和《细节》中提到了公开承诺的力量，因为人本能的会保持自己行为和承诺一致，可能是人类为了协作对抗危险，演化写进我们基因中的一套底层编码，还记得前文中提到年度，双月，内部评审会吗？因为字节在乎数据，所以大量功能都会提前做出数据目标承诺，在多轮需求沟通（公开承诺）后，沉没成本不多增加，你会感觉这个需求或功能就是你的，千万不能做砸了，进而会给自己持续增压。

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

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

360环评。在字节，试用期需要邀请其他人360环评，8月（年中）和3月（年终）会有360环评决定绩效，环评中会需要对被测评人的字节范儿给出评分和描述，环评工具会举例可以如何去写，产品一般需要给20-50个合作方写环评，所以这个过程中自己持续的给别人打环评的过程中，变向的也是在告诉自己什么是公司鼓励的行为，也是讲抽象概念具象化到自己身边同学行为的一个过程。

周围同事都很拼。前文中提到了，评审会和讨论会占用大量的白天时间，虽然每个半小时到45分钟，但是产品有整块的时间还是要到晚上，因为字节有一个补贴政策，就是公司附近租房子有每月补贴1500元，所以很多同学都住得离公司特别近，而且字节的食堂，下午茶，晚上零食水果是真的香，所以基本上你会发现9点后很多人都不会走，也不着急走，而且确实又很多白天接回来的活要干，所以就出现了大面积的加班。

双月会汇报压力。在飞书经历了两个阶段，第一个阶段，飞书PM人数不多（60人左右），那时候的双月会都是每个人去说明自己的上个双月做了什么功能，上线后数据表现如何，与之前的数据承诺有何差异，未达成的原因，优化的思路是什么，双月会上大家往往压力报表。第二个阶段，飞书的PM人数太多了，双月会上是组长在替具体功能负责人解释说明复盘内容。就是这一点改变，压力指数会降低非常非常多。如果希望产品的投入度提升，可以考虑让执行产品直接给老板汇报，或者面对多人challenge的场景，汇报人的投入度和围观别人替自己汇报的投入度真的是完全不一样。

六、其他

飞书的有些功能非常赞，所以有些离开字节的同学会抱怨没办法再用飞书特别遗憾，文末我想分享一个飞书的小功能，其中部分模块我也有参与设计优化，真的感觉这个功能可以非常直观的体现飞书的产品定位和目标，分享给大家，大家做产品的过程中可以做类似的思考和细节设计。

前一篇总结中提到，飞书定位就是解决团队高效协同，希望让用户的每一次click都能是最快捷高效的，一次点击，即使帮助用户节省0.5秒，当一个企业每天几万人多次使用时，所节省出来的时间也将非常可观。本文想要分享的小功能是飞书的一个全局功能@，在IM和文档中可以快捷触发。

先来描述IM协调沟通中的几个办公场景的痛点：

经常需要在群聊中@群内某人/某些人，希望他们可以阅读所发送的消息，当群聊人数较多时查找列表低效，搜索不够高效
群聊中@的人，希望看到他们的阅读状态，而不是群全部已读列表中查找，谁看了这条消息
与其他人单聊或群聊中，需要介绍某个会话/群外的人，这个时候输入名字，担心名字输错了尴尬，需要列表中查到对应的人，复制其姓名黏贴到对话中
当我在与A的会话中介绍了某件事情可以找B，那么A同学还需要通过搜索去查找B同学，流程中有点绕，当超过万人的集团公司，可能多个人都叫B的名字有可能还需要逐个看汇报线和部门

针对以上四个场景痛点，IM中的@功能完美解决上述问题。

群聊中点击@后，飞书中优先展示可能@的人，当前来看，可能@的人点击占比与用户搜索点击占比类似，top1和top3有点比非常高（也就是用户触发@后，直接点击回车选中第一个推荐用户或前三个用户的占比非常高），也就是节省了用户手从键盘上转移到鼠标上，滚动滚轮检索或录入目标用户姓名检索的时间，点击@直接点回车，那种爽感，用起来就知道有多香，因为这块的规则策略我参与了设计优化，细节不便透露，大家也可以想一想，如果让你做规则策略，你会如何设计，期待留言区看到你的答案。
企业微信中也能在群聊中@某人，但是如果想要查看已读状态需要点击消息前方的气泡查看，飞书这块直接在@人的名字右上角有个空心气泡，如果对方阅读了，则变成绿色实心，目标用户是否已读一目了然
会话内可以@会话以外的人，比如我在和张三单聊，我直接@lisi，则触发公司内搜人接口，可以直接选择用户后回车输入，确保名字准确，如果李四是我的高频联系人，甚至可能只输入@l的时候就出现了李四的名字，因为针对人的搜索做了大量的搜索策略优化和算法优化
@李四后，@李四是一个可点击结构化组件，张三可以直接点击@李四，唤起李四的个人卡片，直接查看OKR或发起聊天

其他产品可复用的启发：

首先需要明确你的产品目标是什么，当你的产品目标有了，有哪些场景与这个核心目标相关，核心评估指标是什么，这些都明确了，可以考虑从推荐策略，交互优化，场景痛点/痒点入手，能推荐准的不用用户搜索，能直接点击的绝对不让用户再去复制、黏贴、搜索，用户在具体场景中期待看到什么结果，如果可以直接展示的，绝对不让用户到其他地方用眼睛检索。

希望本文对大家有所启发和帮助，如果感觉还有些用处，记得收藏点赞哦~