字节跳动团队年度总结

字节跳动团队年度总结 第一篇

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

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

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

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

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

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

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

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

好处：

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

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

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

字节跳动团队年度总结 第二篇

互联网产品设计过程中一定会进行竞品分析，同类竞品和相关竞品分析较为常见，一般是在做某个功能时，将直接竞品的对应交互拿出来分析一波，结合自身产品的特点给出方案，字节的竞品分析给我感觉是更加的全面和实时。

直接竞品和相关竞品。PRD模板中竞品分析模块为必填项，需要对国内外竞品（直接竞品＋间接竞品）进行充分的分析，评审中会对当前设计和竞品设计进行多维度比较和讨论。

通过bot事实获取目标竞品更新信息，第一时间洞察目标竞品升级信息。

其他产品。字节中，用研部门定期对国内外主流产品的更新和交互进行系统分析总结，同时对国内外增长较快的产品进行跟踪分析，以分享会或文档的形式同步给其他团队，包括一些产品的新功能和新交互，这些产品可能与自己负责的产品线并不相关，但是一些精妙的设计有可能触发很多灵感。

通过话题群，大家将平时阅读到的一些优秀产品复盘文章和产品最前沿信息发到话题群中，经常可以在群中看到国内外最前沿的工作方法讨论，有趣的产品的更新，最新的产品设计总结文章等，一些酷炫的全新交互形式。

字节跳动团队年度总结 第三篇

如何评估企业员工表现是非常难的一件事情，字节通过三六零环评的方式对试用期，半年绩效评估，全年绩效评估进行评测，感觉这套评估体系比直属上级打绩效相对科学很多。

具体实现如下：首先自己对试用期，半年或全年工作进行总结，列出主要产出和产品收益，邀请合作产品，研发，设计同学进行环评，直属leader可以补充环评人，当时部门产品大佬要求产品经理的环评人数量必须大于一零人。

环评从绩效，字节范儿，投入度三三个纬度进行打分和评价，评价同学会勾选总结中与自己相关配合内容进行评分和评价，这就保证了员工不会夸大描述自己的产出。号称对结果总监层面会看到各种维度的分析，不同人的评分偏好分析等。

字节跳动团队年度总结 第四篇

二零一九年曾经参加过一场飞书的总结和规划会。这次规划会给我留下非常深刻的印象。

规划会开始对之前的工作进行总结，战略部门带来对国内外市场的定量和定性分析，同步大量市场行研数据，然后不同产品线的同学交叉分成多个小组，领取不同目标的市场和目标市场对应的收入和uv目标。

多个小组会领取到同一个目标市场，团队成员通过协同分工，获取目标市场数据，结合团队资源确定打法，将年度目标拆解为双月目标，进而拆解出双月okr，有点像创业拆解目。

第一天出方案，第二天开始讲解自己团队的方案，其他小组会质疑和挑战，Leader给出打分和建议，然后第二天下午完善方案，第三天上午讲解完善过的方案，然后Leader会进行总结，并同步新一年目标市场的打法。

第二天上午的展示相对来看很不成熟，有各种问题和盲区，经过一轮答疑和Leader点评，同时各团队互通一些市场数据信息，第三天的方向和展示靠谱很多。结合大家的计划，Leader给出更加完善的规划。

好处：

一，锻炼提升所有产品的能力，所有执行产品都从产品总监视角去评估当前资源和目标，思考可能打法和产品规划。

二，年度目标的拆解非常有参与感，所有产品在参与过程中对齐目标，而且自己参与制定的规划，自己得认，

三，每次评审环节高质量的问题把团队推到创业者视角，从创造的视角看问题，有些创业拉投资的感觉。

双月会应该是产品是压力最大的时候，个人感觉双月会是字节内部员工压力大和强度高的原因，有点像是将普通公司的半年总结压缩到两个月。

双月会主要工作两部分，第一部分，所有产品静默评审上一个双月的产出，上线功能核心指标表现，预计数据目标完成情况＋复盘。第二个部分，评审下个双月计划上线功能，上线功能的prerelease，预期核心数据指标表现，功能价值点，进而确定优先级。

好处：

字节跳动团队年度总结 第五篇

基于飞书日程的时间管理，让约会议变的非常高效，再也不用把几个同学拉倒一个群里逐个确认空闲时间。刚入职字节时，想要约一个同学开会，当问到什么时间方便时，对方会说看我日程约时间就好，问了几个同学后发现所有同学都会在日历中管理自己的时间。

因为所有人都维护好自己的时间信息，所以也会实际上就是在日程视图选择空闲时间就好，而且提供了基于群邀请人，基于日程快速创建群等快捷功能，查看群内成员忙闲也可以让查看忙闲变得非常容易。

字节跳动团队年度总结 第六篇

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

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

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

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

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

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

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

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

字节跳动团队年度总结 第七篇

飞书团队的产品方法论源于《用户体验要素》，书中将用户体验进行了五个层面的划分，分别是战略层，范围层，结构层，框架层和表现层。

让我印象比较深刻的是战略层面对高效协同办公工具本质模型的抽象，飞书现在官网的slogan是“成就组织和个人，打造高效愉悦的办公平台”。

从内部来看，战略层面上，希望通过产品的创新，创造一个全新的高效协同办公品类，进而提升企业中人和人的协作效率，所以从本质上来看，产品是要提升人与人之间的协作效率。

进一步抽象，协作的本质是多人间的信息传递，提升人与人之间的协作效率近似等同于提升人与人之间的信息传递效率，信息的传递效率可以联想到信息论中的信息编码和解码，而信息编解码过程中存在信息和噪音，经过抽象，我们发现我们的目标是提升信息编解码过程中的信噪比。

以reaction功能为例，使用微信办公的时候，经常会在群聊中看到at all的通知类消息，然后微信中的常见场景就是一堆人回复收到。

从发送者的角度来看，他的目的是希望一条信息传递给群聊中所有的人，而群中成员回复“收到”作为其对这个信息接收后的反馈，表面上看起来信息传递是没有问题的，但从信息和噪音的角度来看，当a回复“收到”时，其目标对象是发消息的人，而对其他群成员可能是一种噪音。

当“收到”的数量非常多时，对其他群成员的交流绝对是一种噪音干扰，同时发消息的同学也并不知道多少人回复或者阅读了这条消息，而且回复“收到”用户还需要输入两个汉字，信息的编码不够活泼生动，而reaction解决了这类场景中的问题，用户可以针对某条消息进行表情反馈，表情传递的信息更加丰富，同时不会干扰到群内其他的成员。

从编码和解码角度来看，也有很多尝试，举一个非常常见的场景，在群聊里我们经常会提到非群内成员，这个时候其实经常担心拼写时出现错别字，飞书针对为何编码需求，可以在群内@群外公司同事，通过提升搜索质量，解决这类需求，还有很多提升编解码效率的智能服务在内部灰度中。

收获：

做任何产品或功能时，都可以按照这五层架构进行拆解，经过逐层拆解后，你可能发现，你对一个具体的需求点可能有更加充分的理解，设计时考虑的更加全面，同时这种拆解会让产品从宏观上加深对这个产品的理解。

对战略层的理解可以从挖掘产品本质模型开始，当有了这个顶层的抽象模型，你会发现你看问题的角度可能变得不同。

字节跳动团队年度总结 第八篇

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

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

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

其他产品可复用的启发：

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

田宇洲（微信公众号：言之有术），人人都是产品经理专栏作家，北京大学软件工程管理硕士，北京电信四年产品经理，负责B二B电商平台的前后端产品设计，擅长游戏化产品设计，挖掘用户画像。

题图来自 Pexels，基于 CC零 协议

字节跳动团队年度总结 第九篇

前文中提到字节在招聘时筛选门槛非常高，聚集了如此多元文化背景，如此多经验丰富的同学，如何将他们内化后的经验或知识分享给公司其他团队，对于公司整体提升都是非常重要的。

字节内部有非常浓郁的分享氛围，每周都会有大量内部同学的精彩分享，同时也会邀请外部优秀团队成员进行经验和知识分享，当部门之间业务近似时也会有不同业务线的交流分享，比如lark海外用户需求调研时就会邀请tiktok用研团队成员分享其美国用户调研经验，以及如何提升onboarding的经验分享。

字节跳动团队年度总结 第一零篇

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

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

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

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

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

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

产品方案：

参考资料：

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

Document Properties：

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

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

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

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

Detailed Design。同上文的产品方案

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

几个重点：

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

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

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

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

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