刘飞：在 Grab 做 PM 和在国内有很明显的差异吗？ Doris：你刚刚讲的基本是 to C 的产品，如果是做基础功能的话，基本上你的需求，或者是你想要做的这件事应该是怎么样的，应该是产品来定，因为这比较像是一个从0到1的过程，然后可能就是看数据说话了，或者说让运营去看各国、各地、各个市场的情况，对于国内的情况来说，可能就是针对不同类型的用户分层或者是用户群体画像，做一些调整。我觉得这个东西在基础的方法论上面，大家遵循的原则是非常相似的。 可能唯一不一样的地方，就是在整个团队的协作当中，产品这个角色是处于什么样的位置？TA在团队中起到的作用？TA跟哪些利益相关方打交道？比如说你在滴滴的时候，你跟各地的运营打交道，对我们来说，可能就是各国的运营，然后法务、数据隐私、风控、客服、司机端……我们还有一个专门的 business owner 。 刘飞：类似于一个品类的业务负责人吗？ Doris：对，但这个角色也不是每家公司都有，可能是一个比较 Grab 的事情，然后有专门写文案的文案设计师，所有的文案需要有翻译，所以文案设计师还是一个整个团队，你要跟这个团队打交道。 刘飞：这个蛮有意思，比如说我在滴滴就没有见过文案设计师，文案基本上是产品经理和设计师商量写出来的。 Doris：我只有在小团队里面决定过文案，那都是很早期的事情，我到新加坡之后，就没有写过任何一个产品上面的文案，就是有专门的人来写，而且这些人是非常专精于这件事情。而且如果你要做一个 AB test ，判断两个文案怎么样好怎么样不好，那可以让TA来写，然后接下来还要翻译成各国语言，所以你还要考虑到排期的问题，一旦排起来，跨部门搞得跟跨公司一样。 刘飞：这样听下来我觉得反而还是挺像的，就像你前面提到，因为公司规模的差异更大，我之前也在阿里待过，做一件事情，它的排期、跨部门协作的复杂度就高很多。我理解中间可能有些角色不一样，比如我们都没有文案设计师，但在推进项目的时候，还是都要产品经理去推动一个一个利益相关方解决。
04 不同公司工程师的话语权有多大差异
Doris：可能比较不一样的地方，就是说什么归产品去驱动，产品是一个主导的位置，还是补位的位置，你的队员之间有多少自驱力，有多少能够自己独当一面的。 刘飞：其实听下来没有特别明确的职责，就像一些传统行业一样，或者说工作流是一定要按什么步骤、负责哪些事情，这个过程当中可能还有很多比较模糊或者灰色的地方，可能产品经理要补位，有一些可能是业务来补位，但这个是比较灵活的。 Doris：我觉得还是公司一旦发展到规模比较大、业务相关比较多，那么这些所谓的流程、步骤的规定的程度就会相对来说更高，所以“是谁负责什么样的事情、大概由哪一个工种去发起或者去跟进会更有效”，对于每家公司来讲是会逐渐形成规范的。 刘飞：感觉上这个可能确实也跟公司规模、业务类型有关，比如这个业务可能是运营的往前占得多一点，那个业务甚至可能设计往前占得多一点，那个业务研发往前占得多一点，都是跟具体做什么产品比较强相关的。 Doris：跟具体在哪个公司首先是强相关的。比如说在 Facebook ，就是工程师的话语权特别大，我是绝对不会告诉工程师说你非要做什么，我做不了这个主，我一般就是告诉工程师说：这个事很重要，往这个方向去，我们要解决这么一个问题，至于怎么解决，我现在看到是这几个方向，你觉得哪几个能成项目然后搞一搞。所以我现在都不写 product spec ，都是工程师写。 我们有一个同事写了一条非常著名的 tweet ，TA说我加入 Facebook 已经一年多了，而并没有写过任何一个 ticket ，没有写过任何一个 user story ，我觉得这样很 work ，我觉得这样很爽。 刘飞：所以这些都是研发部门搞吗？ Doris：对，我们工程师是万能的。 刘飞：在不同的公司，工程师文化确实不一样，国内的有些公司，比如百度和阿里的工程师其实还是挺强势的。他们不会像你描述的一样，把一些活都干了，但是他们会有一票否决权，比如说评审会上研发部门觉得你讲的这个用户需求不合理，或者你说的这个项目收益我不认同，那他就可以不做，是用这样一种方式来介入这个话语权的。
05 以滴滴和 Grab 为例对比下产品经理的工作流
Doris：我在 Grab 确实要写 ticket ，要写 user story，还是逃不掉的。 刘飞：你说的 ticket 就是需求文档吗？ Doris：国内大家写 PRD 嘛，但是 PRD 通常一不小心就写很大，但有一些东西是小需求，一点一点做，或者是做实验决定要不要往前做，通常对于这种拆出来的东西，我们会写一个文档，大概就是产品规格应该是什么样子，有点像是一个小的 PRD ，不是一个很大的、从头到尾的东西。 刘飞：是个简述对吧，一个简单版的？ Doris：就是你要做什么事、要解决什么问题、是怎么解决的、针对谁解决的，有一些 user story ，为了搞定这个 user story ，可能下面会有好几个 to do 要把它变成 ticket ，需要去提出来给相关的人，就是拆得特别小的一个待办事项。 刘飞：所以这个是更像项目已经决定要启动了，启动的时候该怎么分配任务的一个东西？ Doris：有点像，或者说在启动之前，你就已经先想好这个事情拆到这么一个一个小的需求点上面，为了完成你可能会开始请你的各个利益相关方、业务相关方、合作方先开始写这些待办事项，他们会帮你把东西拆到一个可执行、可分配的大小，然后他们来决定说到底是哪一个工程师帮你把这件事情做完。 刘飞：这个时候 roadmap ，就比如说项目节奏，以及说具体需求的细节都已经完成了吗？ Doris：其实一般来说 roadmap 里面不仅会包括这么一个事情，我们以前做是做三个月的 roadmap ，然后一个季度即将结束的时候做下一个季度的 roadmap ，半年会有大一点的 roadmap ，但就会写得比较糙，但当你要开一个三个月的东西的时候，通常就已经写得非常细了，什么都还没开，这些东西就已经全都拆好了。真的要启动的时候，通常就是需求过完评审，所有的细节都已经跟各个相关方谈妥了，大致的方向、做法、可能出现的问题等等，这些都已经聊过了，然后你才会开始来排一个优先级。 刘飞：听起来非常类似，基本上也是首先有全年规划，后面还有季度规划，还有可能像字节是双月度规划。每个阶段每个项目都会再起一个 kick off 会，所有的相关方碰在一块，大家去评估一下这个项目能不能按照原定的项目节奏去完成，评估完了之后就开始进入一些细节走向了。 然后在我经历的公司里，通常来说可能有一些大项目是独立推进的，比如说淘宝的双11，网约车也有几个固定的大项目，这几个项目是会有很多资源去保证的；其他的会有各种小的需求，就都是按部就班地去推，就有这种日常的评审会，比如说每双周一个评审，就跟着版本走。