Manik Gupta(前 Uber CPO、Google Maps)谈如何打造消费者应用、为什么对技术保持乐观很有用、如何在 PM 职业中创造拐点、CPO 角色的变化,以及更多内容

Manik Gupta 2022-07-14

Manik Gupta(前 Uber CPO、Google Maps)谈如何打造消费者应用、为什么对技术保持乐观很有用、如何在 PM 职业中创造拐点、CPO 角色的变化,以及更多内容


文字记录

Lenny: Manik Gupta 领导了历史上最成功的两款消费产品:Google Maps,他曾担任 Maps 团队的产品总监;以及 Uber,他曾担任首席产品官。离开 Uber 后,他把大部分时间花在一款帮助人们避免感染 COVID 的产品上,名为 CVKey;最近,他在微软担任企业副总裁,领导其多项消费业务。在我们的对话中,我们讨论了他关于打造成功消费产品的经验、如何搭建和招聘产品团队、构建消费应用、一个叫做”消费栈”(consumer stack)的概念、公司-市场契合(company market fit)与产品-市场契合(product market fit)、担任 CPO 是怎样的体验、在微软与 Uber 与 Google 工作分别学到了什么,以及大量给有志于成为 CPO 的人的职业建议。希望你享受这期与 Manik 的对话。

关于运气与风险

Lenny: Manik,欢迎来到播客。

Manik Gupta: 谢谢,Lenny。很高兴来到这里,兄弟。

Lenny: 不知道明不明显,但我真的很荣幸能邀请你上这期播客。你作为创始人领导了 Google Maps 团队,又在 Uber 做了大概四年的 CPO。现在你在微软做消费业务的高管。这是一段令人难以置信的职业轨迹。我的第一个问题是:回顾你的职业生涯,你觉得有一两件主要的事情帮助走到了今天吗?给那些可能还处于职业早期的人一些参考——他们应该关注什么?

Manik Gupta: 好的。谢谢你邀请我,Lenny。顺便说一句,我也是你的忠实粉丝。我很喜欢你的 newsletter,看到你不断扩大话题覆盖面和这个播客的成长,真的非常了不起。真的是忠实粉丝,再次感谢你的邀请。

Lenny: 谢谢。

Manik Gupta: 让我先谈谈我对这个问题的思考框架。我可能有点后知后觉,但我最近读了 Morgan Housel 写的《金钱心理学》(Psychology of Money)。如果有机会,我强烈推荐你的听众读一读。书里有一章讲到了运气和风险。他说,当我们审视个人的时候,去思考或询问他们做了什么才取得成功,我们往往把更多的分量放在努力上,而对运气和风险的强调要少得多。我非常认同这一点。回顾过去,重要的是看到运气发挥了多大的作用,当然,某个人所承担的风险也发挥了很大的作用。

与最优秀的人为伍

这一直是我自己思考很多的问题:那些经历过多重职业、走过一条学到很多并做出贡献的旅程的人,他们有什么共通的模式?我认为有两个模式很突出,不管是我回顾自身经历时,还是与我那些也做了很多有趣事情的朋友交谈时,都能看到。我想把这两点都谈一谈。第一点,是关于人——让自己被你能找到的最优秀的人所环绕。

很有意思,我昨晚在看勇士队的比赛。没错,勇士队拿了 NBA 总冠军。太棒了。

Lenny: 勇士加油。

Manik Gupta: 一位记者,我想她问主教练 Steve Kerr,“秘诀是什么?“他说,“就是跟超级明星待在一起。“他就这么说了,然后把话筒递给了别人,说,“看,这是一支跟超级明星待在一起的球队。“道理就在于此。如果你能创造足够多的机会,尤其是在职业生涯早期,去接触那些正在做有趣事情的人——他们在做与众不同的事,或者以不同的方式做事,令人兴奋——好的事情自然会发生。

在某种意义上我很幸运,恰好置身于那样的境遇中。我在印度长大,16 岁时获得奖学金去了新加坡读高中,然后读本科。那时候的新加坡——现在仍然是,但当时更是——是来自整个亚裔散居群体中最优秀、最聪明的人才的熔炉。我的同学和校友中有非常多极其聪明的人,我从他们身上学到了很多,这为我去做出有趣的事打下了很好的基础。大学一毕业,我就和两个同学一起创办了自己的公司。其中一个恰好是我从小到大最好的朋友之一,他也拿着同样的奖学金跟我一起去了新加坡。我们就是那个生态系统中的一部分,这给了我很多在大学期间尝试不同事物的机会。

对于职业早期的人,我想说的主要是:让自己被那些在各自领域真正优秀的人所环绕,向他们学习。顺便说一句,要做长期主义者。一旦你找到这样的人,就紧跟他们——只要他们还愿意和你待在一起,就坚持下去。因为在你整个职业生涯中,你会和同一批人一起做很多不同的事情。你与一流人才之间建立的共同信任和经验,将会让你受益匪浅。总之,这是第一个模式。我觉得它对我帮助很大,我在与我交谈过的其他人身上也看到了很多类似的经历。


技术乐观主义

Manik Gupta: 第二个模式是……这一点我个人非常有共鸣:我是一个坚定的技术乐观主义者。如今围绕技术总是有很多叙事,可能悲观色彩稍微多了一些,我觉得这很奇怪。我就是技术的坚定倡导者和乐观主义者,因为我认为技术是一股强大的向善之力。我自己是工程师出身,一直被那些能用技术解决真实人类需求的项目所吸引。我的创业公司如此,在惠普、在 Google、在 Uber 都是如此。当你是一个坚定的技术倡导者,深信技术真的能带来帮助时,这份热情会驱使你去选择一系列你想要大规模去做的事情。

比如,当我在印度加入 Google 做 Maps 时,目标是帮助数百万用户——尤其是亚洲的用户——更好地导航他们的世界。当时没有好的解决方案,那怎么用技术来真正解决这些问题呢?

Lenny,我觉得就是这两个模式。一是让自己被一流人才环绕,二是对技术抱有强烈的乐观主义和热情。至少当我回头看、把这些点连起来的时候,这些就是真正帮助了我以及我看到的许多处于类似处境的人的东西。我希望职业早期的人能认真思考这些。

Lenny: 我猜这两点之间有很大的交集——技术乐观主义和超级明星们。这很有意思。

Manik Gupta: 确实有。你说得真好。我之前还没想过这一点。你说得对,这两者之间确实有交集,因为处于那种状态的人,他们更容易聚到一起。我也是天使投资人,投了不少公司。Lenny,你和我一起也投了很多公司。就是这样——它真正关乎的是那些在世界观上有着相同频率、想要去做有趣事情的人。我认为这才是推动叙事前进的动力。

最引以为豪的工作

Lenny: 说到技术乐观主义和技术本身,在你做过的所有事情中,你觉得最引以为豪的项目、产品或功能是什么?

Manik Gupta: 我再次说,我有幸参与了创造改变世界产品的非凡公司。我在其中只扮演了很小很小很小的一部分角色。我一直强调这一点。不是我,是团队。我是真心这么说的,不是因为上你的播客才这么讲,而是确确实实如此。我尤其为在 Google 和 Uber 做的工作感到自豪。我给你举几个例子来说明。

2008 年我在印度加入 Google 时,开始做 Google Maps。我记得这对所有人来说是多么反直觉——我的朋友、家人,还有我聊过的很多人。反直觉在于:为什么有人会在印度用手机上的地图?原因是当时的常态是,首先,这个国家是不可测绘的,因为没有好的地址系统。那你甚至怎么查找地点?其次是,周围总有人可以问,你只要摇下车窗问一句”嘿,我要去这里,能给我指个路吗?“这就是当时的常态。人们就是这么导航的,很长一段时间都是如此。

当我开始做这件事的时候,我的信念是——还是回到技术乐观主义这一点——为什么我们在印度不能拥有和美国一样高质量的地图?为什么不能?为什么不应该做?为什么这里的用户不能获得同样的收益和生产力提升,在日常通勤中少一些压力?

所以我们开始建设。我们开始构建数据,尽可能地去测绘这个国家。既是我们自己做的,也得益于我们用户的大量出色工作——他们和我们一起共同绘制了这个世界。随着时间的推移,印度成为了 Google Maps 全球用户量第二大的国家。当然,这在很大程度上是因为 Android。Android 普及了,而 Android 上有 Google Maps。但在短短几年内看到它变得如此实用,真是令人难以置信。我们不仅仅是把 Google Maps 通过 Android 分发出去了,人们是真的在用。人们真的在用它从 A 点到 B 点。

我为此感到非常自豪。团队付出了巨大的努力。甚至不是一个很大的团队,是一个相对小的团队,但非常充满热情地去做了这件事,我们把它做成了。

然后在 Uber,最初在我担任 CPO 之前,我负责地图和市场平台。当我负责地图和市场平台的时候,同样是这个问题——你打开 Uber 应用叫车时看到的 ETA 是怎么来的……全球平均 ETA 降到了五分钟以内。你想想这意味着什么。事实上,是在 75 个国家、超过 300 个城市——如果我没记错的话——你只需打开 Uber 应用,平均不到五分钟就能叫到一辆车。当然有大量的运营工作要做,但技术——尤其是市场平台技术,能够把正确的乘客匹配给正确的司机,加上底层的地图基础设施,确保车辆真的能在那么短的时间内到达你身边——我为那段时间所做的、让 Uber 在提供这类服务方面取得成功的所有工作感到非常自豪。

还有一个趣事,我的两个世界在那一刻交汇了,到今天想起来都让我震撼。我记得是 2015 年底加入 Uber,然后在 2016、2017 年左右回印度看父母。具体时间我记不清了,大概是那时候。当时我在班加罗尔的家里叫了一辆 Uber。司机来了,我坐进后座。他用 Uber 应用开始行程,然后点击导航,跳转到了 Google Maps。我当时坐在那里,心想:“天哪,这两个东西某种程度上都是我做的。“一想到我的两个世界在那个时刻交汇,真是太不可思议了。我至今仍清晰地记得那个瞬间,我为自己在两个产品中都有一点点贡献感到非常自豪。

Lenny: 这影响力真是难以置信。想想有多少人受到你和你的团队所做工作的影响,简直让人难以想象。印度有十亿人,全世界用 Uber 的人——太不真实了。如果是我目睹那样的体验,也会感到非常自豪。

职业生涯中的挑战

人们看到像你这样的职业轨迹时可能会想:“天哪,Manik 简直势不可挡。他什么都做成了。一切都很顺利,永远是赢家。“但我猜肯定也有一些时候你犯了错误,或者事情非常艰难。你觉得职业生涯中更具挑战性的项目或时刻是什么?

Manik Gupta: 对,绝对是的。这一点也确实很重要,值得聊聊,因为我们总是美化成功,却很少谈论挑战。我很高兴你问到了这个问题。我会给你讲两个时期,我从中学到了很多东西,但那对我来说都是相当艰难的时光。第一个时期是,我在互联网泡沫顶峰的时候创办了自己的公司。我们于1999年6月注册了公司,然后在2000年3月把公司卖给了一家挪威公司。那是互联网泡沫的最高峰。之后没过几个月,互联网泡沫就破灭了,情况非常糟糕。非常糟糕。我知道现在的经济环境也不太好,发生了很多事情。但当时真的很惨,因为身边的朋友都在失业。

幸运的是我们还有一些资金。我们之前已经拿到了部分融资,而且已经完成了一次收购。母公司的资产负债表还算健康,所以我们还能继续做下去。但情况并没有好转,Lenny。2000年过去了,2001年来了。我们一直在等形势好转,但始终没有好转。所以我们不得不转型。我们作为一家公司不得不转型。我的联合创始人当时实际上离开了公司。我还是想留下来,因为我真心相信我能继续推动这家公司往前走。然后我就和母公司的创始人们一起工作。我们转型了好几次,尝试了不少方向。我甚至从新加坡搬回印度去设立一个工程办公室,这样我们可以转向 SaaS(软件即服务)的模式,而不是继续做我们原来的电商公司。

在那两三年里我尝试了很多东西。而且要知道,那是我大学毕业后的第一份,所谓”工作”。我一个人扛了很多事情,那段时间确实非常艰难。但同时我也学到了很多。我对自己有了很多了解,学会了如何在模糊不确定的环境中前行,以及如何在艰难时刻保持团队的士气。这里面很大一部分也来自保持自己的积极性,因为人们从很远的地方就能嗅到恐惧和悲观。就像乐观是会传染的,悲观同样如此。作为领导者,如果你状态不好,大家都能看得出来。绝对是这样。大家都不傻。你不能装,你得真心有动力去坚持,至少我是这么做的,我从中也学到了很多。这是我经历过的一段非常具有挑战性的时期。

然后第二段是在 Uber 的时候。2017、2018年,Uber 简直疯了。天哪。领导层变动、品牌方面的问题层出不穷,各种事情同时发生。对我来说,有时候我从家里开车去办公室的路上,一边在车里听新闻什么的,就会从新闻里听到当天 Uber 发生的事情,比从公司内部知道的还早。当时就疯狂到这种程度。所以又是一片混乱,公司内部也有很多变动。那种情况下你只能低着头,专注于核心的事情。

我觉得正是在那个时候,Lenny,我内心的乐观精神在支撑着我——我到底在做什么?这项服务是不是真的惠及了全世界数百万人?我们是否在创造真正的改变?这些是我必须深入思考的问题,确保自己始终清楚我为什么在这里、我为什么还要继续留在这里,同时也要激励我的团队。但没错,这就是我职业生涯中经历的两段真正充满挑战的时期。

Lenny: 这两个例子太棒了。我想现在有很多创始人正经历着市场带来的种种艰难时刻,而我相信这些经历对你来说非常重要,影响了你后来承担更大角色、迎接更大挑战的能力。你是这么看的吗?这些经历对于作为产品领导者、乃至作为领导者来说,是否是重要的积累?

Manik Gupta: 哦,绝对是。因为就像我说的,当你经历这样的处境时,你会对自己有很多了解。你既能发现那些困扰你、让你消沉的事情,也能发现那些给你能量的事情。有时候这很反直觉。当你处于低谷时,人们通常会说:“在坏时光里我只学到了坏的东西。“但你也会学到好的东西。比如,在困难时期你可能做了某件事,突然感到释然或充满活力,然后你回头看看会说:“等等,我在好时光里也应该多做这件事,因为你能想象那种复利效应吗?情况本来就不错,我又在做这件事,感觉会更好。”

我对自身的能量状态有了很多认识,了解了什么能让我兴奋、什么会让我停滞不前。同时,也学会了如何与团队协作,如何激励他们,如何埋头专注而不是分心,以及在产品路线图上应该做哪些决策。

我给你举个例子。在我的创业公司经历那段艰难时期时,为了激励团队,我想到的一个最好的方法——这个方法我也是从很多人那里学到的——就是给团队一个赢的机会。赢,真的能带来巨大的能量。我们当时面临一个选择:是做一个需要六个月才能上线的东西,还是以一种小规模的方式做一个一个月就能上线的东西。我们选择了后者,因为当我们这样做的时候,我记得大家互相击掌,互相说:“嘿,你知道吗?太棒了。我们把东西放到了客户面前。“我记得大概有十个客户用了它,因为我们当时是那种非常小范围的软发布。但这并不重要。关键是你从把东西做出来、推出去的过程中获得了信心,你会为自己是一个建设者、一个真正在创造改变的人而感到自豪。这能让团队脚踏实地、保持专注,意识到这里确实有真正的价值。

这些就是我在那段动荡时期学到的东西。即使在顺境中,我也一直在运用这些经验,确保我们持续打造好的产品。

打造消费产品的反直觉经验

Lenny: 这是一个非常实用的建议。找到一个赢的机会,保持人们的积极性。说到赢,回到 Google Maps 和 Uber,它们可能是全球使用最广泛、最成功的两款消费产品。我想不出还有哪些产品被这么多人使用了这么长时间。而现在在微软,你又在帮助微软在通讯领域进一步拓展消费业务。我想你对打造成功的消费应用应该颇有心得,所以我想在这方面问几个问题。关于打造消费产品,你学到的两三件令人意外或反直觉的事情是什么?

Manik Gupta: 好消息是……因为 Twitter 和其他很多渠道,顺便说一句也包括你的 Newsletter,我觉得如今人们的信息非常灵通。这我很喜欢。

Manik Gupta: 让我先稍微岔开一下,然后回到你的问题。Lenny,有一件事我观察到了,让我感到非常高兴——如今学习质量、洞察、框架和最佳实践已经如此普及。过去,你必须身处硅谷,或者成为一小群走在最前沿的人中的一员,才能获得那些关于如何找到产品-市场契合(产品-市场契合)之类事情的疯狂洞察。而现在,因为各种原因,我与世界各地的人交流,令人惊叹的是人们多么迅速地掌握了这些洞察和框架,然后将它们应用到自己的本地环境中。我觉得这是有史以来最美好的事情之一。

我想像你这样的人显然发挥了很大作用,因为你有全球的订阅者,你分享了一些最佳实践。但总体来说,这对世界来说确实是一件好事,人们能够获得如此清晰的思维。而且最优秀的人确实在把自己的经验分享出来,这很棒。

关于反直觉的事情,我觉得有两点。第一,打造消费产品非常困难。我觉得人们认为它很容易,因为我们每个人都是消费者。我们把自己当作好用户,把朋友当作用户,把家人当作用户。我们会说,“好吧,如果我们只是为自己、为家人和朋友打造它……”顺便说一下,很多伟大的消费产品就是这样起步的,所以我不是说不要这样做。但是天哪,这真的很难。要把事情做对需要很长时间。因为你在打造一款成功的消费产品时,本质上需要同时把很多事情做对。你必须能够触达一个庞大而异质的用户群体,他们有不同的需求、不同的视角。市场推广(go to market)总是非常有趣,因为你不能强迫人们使用你的产品。人们必须选择你,不是你选择他们。这就是问题所在——你如何驱动病毒式传播?你如何驱动人们对一款消费产品的真正热爱?它必须创造真正的价值。

关于时间的另一点是,为了找到产品-市场契合(产品-市场契合)并从那里开始扩张,你必须尝试很多不同的东西。虽然有理论上的方法论,但你必须亲身投入。回到我之前说的关于赢的观点——先获得一些胜利,看到结果,然后从那里迭代。我觉得这确实很难,而且比人们想象中消费产品所需的时间要长得多。相比企业产品或其他类型的产品,更是如此。这至少是我学到的第一个反直觉的事情。

第二个反直觉的事情是,在消费产品中你看到的关于用户界面的全球模式——人们做或期望的核心操作,到这个时候已经相当统一了。总有一种争论,人们会说,“嗯,美国需要一个产品,亚洲需要另一种不同的产品,非洲又需要另一种不同的产品。“我觉得我们已经过了那个阶段了。这又是一个反直觉的事情,人们花太多时间……我在很多公司都见过这种情况。人们花太多时间争论,“哦,X 市场的用户不一样。“嗯是的,他们不一样,但他们使用产品的方式是一样的。

这就是我认为……而且我不是在反对本地化。当然你需要在语言、定价方面做本地化,还有一些法律要求,所有这些东西。显然你必须这样做,否则你甚至没有在那个市场存在的资格。但总体来说模式非常相似。你看看全球产品,即使是 Facebook、Google 搜索、地图、Twitter 或 TikTok 等等,它们对整个世界都有类似的模式或类似的应用,然后不断在边缘进行创新或本地化。

这是人们应该了解的关于消费产品的另一个反直觉的事情。从第一天起就为全球而打造。理解在某些市场推动普及的过程中会有一些你需要解决的细微差别,但不要过度投入于打造针对特定市场的解决方案,因为消费者已经超越了那种模式。这两点就是这些年来我至少在产品打造方面总结出的反直觉趋势。

大公司中的公司-产品契合

Lenny: 在这次聊天之前,我们讨论过大公司中”公司-产品契合”的想法。这是在大公司内部打造新产品的一种方法。你能谈谈这个想法吗?

Manik Gupta: 当然可以。我一直在反复思考这个问题,尤其是自从我在微软担任这个角色之后。在那之前,甚至在 Google 时,这也一直是一个有趣的讨论话题。假设你正在打造一款新产品,或者领导一个新项目——在一家较大的公司里。事实上,这也适用于中型公司。我不会说对创业公司适用,但对中型公司来说是适用的。通常,当你在团队和领导团队中讨论这个问题时,大家的说法会是,“好的,我们必须去找到产品-市场契合(产品-市场契合)。“当然。没错。我们必须做一堆事情,正如我们刚才讨论的那样。消费产品需要时间。所有这些。

但我觉得在那个问题之前还有一个问题,就是如何找到公司-产品契合(公司-产品契合)?我对公司-产品契合的定义是:公司本质上是一个产品组合,每家大公司、中型公司也有一个产品组合。它们有 10 个、20 个,在某些情况下数百个产品在组合中。每家公司都有独特的优势和劣势。这是经过验证的,但也很显而易见。我会鼓励很多人,当他们开始踏上这条真正打造产品的旅程时,去问这个问题——那个产品,假设它成功了……如果它不成功,反正也无所谓。但假设它成功了,它是否真正在公司产品组合中占据了合适的位置?还是没有?如果没有,就不要做。为什么要浪费时间?

很多时候公司会说,“我想做这个,因为其他公司也在做。“这不是一个好理由。你应该只投资于那些你能发挥自身优势、能创造独特消费者或客户价值的产品或项目。而且,顺便说一下,你能做得比外面任何人都好。这就是我所说的公司-产品契合。先走好第一步,理解这是否真的契合,它是否属于这个产品组合?它是否合理?


公司-产品契合的陷阱

Manik Gupta: 因为如果你能以足够的信心回答这个问题,那么你在寻找产品-市场契合(产品-市场契合)的下一步之路上就会容易得多,因为你不再有各种干扰。所有人都理解这件事。所有人都明白这是一项战略性举措。你在公司里得到了各个层级恰当的支持,你正在朝着这个方向执行、探索。假设进展不顺利,也没关系。人们会伸出援手来帮你。这种情况会经常发生,因为人们从本质上理解这件事——从公司-产品契合(公司-产品契合)的角度来看,这确实是值得追求的正确产品。这就是我一直在思考、也在不断践行的事情。

Lenny: 你能不能分享一个做错了的例子?无论是在你工作过的公司,还是你见过做得不好的公司。

Manik Gupta: 我得想想具体的例子,但公司们一直在做这种事,就是做这些产品线延伸。他们会说,“嗯,我们在某个细分市场已经很有吸引力了,为什么不去相邻的细分市场呢?只要再加两个功能,突然就能对相邻的细分市场产生吸引力了。“一个经典的例子是,你在做面向中小企业的产品,然后你说,“嗯,我现在只需要再加两个功能,就可以往上走进入企业级市场,跟企业级产品竞争了。“也可能反过来,你在企业级市场有产品,突然想下沉到中小企业市场。

在我看来,这很难。因为同样地,你需要的能力、需要的思维方式,你必须非常清楚地认识。这并不是说它一定不适合公司的产品组合。只是说,当你做这样的选择时,要确保为成功做好充分准备。这是等式的另一面。

消费栈(消费栈)

Lenny: 说到为成功做好准备,你还提出了一个消费栈(消费栈)的概念,我想你是在微软谈过这个。能不能聊聊这到底是什么?

Manik Gupta: 当然可以。我目前在微软做的事情之一,除了负责很多消费者通讯产品之外,另一件我真正在帮助公司思考的事情是:如何让微软打造出更多规模化的消费者产品。其中一部分就是提炼我这些年积累的经验教训。我认为有五个要点,我称之为消费栈(消费栈),本质上是一套公司要想在消费者产品上有较大成功几率所需要具备的能力。记住,没有人能给出一个打造成功消费者产品的剧本。这东西不存在。因为正如我们之前讨论的,消费者市场如此善变,打造一款成功的消费者产品需要太多事情都对。但至少你要有一套能力,让自己做好最充分的准备。

第一点,我认为是设计主导的思维,以取悦用户。回想你在 Airbnb 的日子,Lenny,我相信这对你来说很有共鸣。对于消费者产品来说,设计是建立正确用户拉力的关键部分。设计粗糙的产品现在完全没有机会。你的工艺水准和设计能力必须达到 A+。如果你还没有做到,那就真的应该在这方面投资。这不仅仅是拥有最好的设计师——当然你应该有——更重要的是那种思维方式,那种对细节的关注。关注像素级别的精确,关注从一个页面跳转到另一个页面的体验等等。你真的需要精益求精,真正清楚地理解它如何为消费者创造价值。我认为这是如今打造消费者产品的核心能力。这是第一点。

第二点是强有力的聚焦和优先级排序。你可以把强有力的聚焦和优先级排序应用到生活中的任何事情上,但我认为它对消费者产品更加重要。因为很多时候人们一想到解决问题,就想着同时推出 20 个功能,其实完全不需要。你不需要 20 个功能来解决问题。你只需要一到两个真正好用的功能就够了。这就是关键用户旅程的概念。如何确保,如果你在解决问题 X,产品中构建的每个功能……首先你的产品在初期应该只有很少的功能。但即便只有这些功能,也应该经过精心设计,并且有明确的聚焦和优先级,确保你只为关键旅程提供支持,让用户能够使用而不感到困惑。这是第二点。

大多数产品经理都完全理解这一点。聚焦和优先级排序就是他们的本职工作。但我感觉很多时候产品经理确实会变得很困惑、很分心,因为人们提出的想法数量如此之多,以至于他们想把所有东西都塞进产品里,这是行不通的。你必须对聚焦和优先级排序保持非常高的标准。这是第二项能力。

第三点是拥有正确的指标和埋点。这涉及文化中数据这一层面——如果你在产品初期、中期、后期没有关于优化目标的指标,你就无法做出正确的选择。你如何衡量成功?你如何说服自己、你的团队以及更广泛的利益相关者,这个东西到底是在起作用还是没起作用?拥有正确的指标很重要,但令人难以置信的是,多少次人们有指标却没有做好埋点。他们会有各种争论,因为产品的埋点做得不对。每个人都在谈论同一个指标,但他们的理解各有细微差异——“哦,这到底是什么意思?什么是日活用户?好,daily 我理解,是按天算的。那 active 是什么意思?“然后就会争论 active 到底是什么。选一个定义,埋好点,固化下来。不再有困惑。这是第三点。

第四点更多在工程层面,就是如何实现极高的发布速度,以及快速实验和学习的能力。从更宏观的层面来看,特别是在初期阶段,如果你不在学习,那你真的什么都没做好。你必须不断学习。学到好的、坏的,无所谓。你必须不断学习。拥有实验速度,建立一种工程师能够提交代码、看到结果、然后快速进入下一个发布周期的工程文化,我认为这对消费者产品来说非常重要。

最后,支撑这一切的基础就是拥有强大的人才。评估你的人才——你的产品人才、设计人才、数据人才、工程人才、营销人才,所有这些职能。你必须拥有一群喜欢创造东西的优秀人才,他们理解消费者,对消费者有共情能力。

消费栈的自我评估

Manik Gupta: 对我来说,我认为这五种能力……作为领导者,或者产品领导者,或者工程领导者,或者任何负责在小公司、大公司、中型公司运营产品的人——这不重要——如果你在消费领域,我的想法是,如果你审视这五个类别和五种能力,你真的应该有一张成绩单,然后问自己:“好,我给这些打几分?“如果让我看自己的团队,我认为设计思维做得怎么样?专注力和优先级排序做得怎么样?我们是在做 A 级的工作吗?B 级?C 级还是 D 级?“我的观点是,随着时间的推移,如果你达到了 A 级——因为不是每个人第一天就能做到 A——但如果你逐渐达到了 A 级,我认为你会开始看到非常有意义的成果。这就是我对消费栈的思考方式。

Lenny: 太好了。我本来想问你是如何将这套框架落地操作的。听起来这会变成 Manik 的消费栈评分卡,大公司可以在自己内部利用它,然后给经理看:“嘿,我们推进得真的很慢。也许在大力押注消费者业务之前,我们应该先集中关注这个领域。”

Manik Gupta: 是的。我现在就在自己的工作中尝试将其落地操作,而且我之前也用过某个版本。我的意思是,这不是我刚刚想出来的东西,而是在我脑海中酝酿了一段时间,以某种形式使用过。但在我的休息期间,尤其是在加入微软之前,这些想法对我来说整合成了一个更具体、可以直接使用的东西。然后我开始应用它,所以我觉得效果还挺有意思的。

Lenny: 太好了。我希望这能在更大的公司中传播开来,成为一个可以追溯回这次对话的东西。

CPO 角色的演变

Lenny: 稍微转向一下 CPO 角色和你在几家公司担任过的产品副总裁角色。理论上,这算是产品领导者的一个终极状态。每个产品经理,如果一直沿着产品经理的职业路径走下去,最终都会在某个地方成为 CPO 或产品副总裁或产品负责人。这里有几个问题。第一个是,你有没有一个感觉,有多少产品经理真的留在这条路径上,最终达到这些角色,又有多少转向了其他角色或方向?

Manik Gupta: 这个问题问得好。我想说,CPO 这个角色的比例——拥有 C 级头衔、担任 CPO——我认为这个比例仍然相对较小。这只是我的直觉,我没有做过具体的数字统计来给你一个更准确的画面,但我觉得这个比例比较小。因为我认为这在很大程度上取决于公司是如何组织的。公司可以按职能组织,也可以按业务单元组织,如今通常是两者的混合。如果你看任何一家公司,他们会有一些 C 级职能高管,但在他们之下会有 GM(总经理)。组织设计本身就是一个不断演变的领域。正如人们所说,公司会把钟摆往一个方向摆,然后说”哦,时间长了发现不行”,然后再把钟摆往另一个方向摆,然后就这样来回摇摆。我认为 CPO 的比例,至少在我心目中,可能没有人们想象的那么大。正如我所说,这取决于公司的组织方式。

Manik Gupta: 我觉得有趣的是,根据我个人的观察——我自己做过 CPO,也和社交网络中的很多人交流过,还观察了很多不同的公司——我认为 CPO 这个角色正在演变。或者说产品负责人这个角色也在演变。我觉得它很大程度上正在向 GM 模式转变,你不仅负责产品管理,还可能同时负责产品管理和工程,在一定程度上还有设计和数据科学。你本质上变成了公司整体的技术产品领导者。

Manik Gupta: 之所以会出现这种情况,原因在于问责制。在于谁能成为那个单线领导(single threaded leadership)——这个人可以在权衡取舍、运营路线图等方面做出所有决策。顺便说一句,这并不是在所有情况下都理想的。因为这意味着,要做到这一点,那个人必须在所有其他职能上都非常非常出色,这样组织中的每个人才会信服。否则人们会觉得”在这个模式中我是二等公民,这个人对我的职能一无所知”等等。所以这更难,但我确实感觉到,为了优化决策制定、实现单线领导和问责制,产品领导角色本身正在朝着这个方向发展。至少根据我的经验是这样的。

Lenny: 你的感觉是不是 CPO 这个头衔可能会逐渐消失,而 GM 成为各个公司中更常见的路径?

Manik Gupta: 如果你逼我说的话,我会说这可能就是我们未来的方向。我觉得思考一下 CTO 也很有意思。如果你看 CTO 角色与 SVP of engineering 或 VP of engineering 之间的对比,CTO 角色正在发生什么变化,这也是一个有趣的讨论。如果一家公司纯粹按职能来组织,我认为 CPO 这个角色绝对是正确的选择。但随着公司的变化,思考如何推动更多的问责制和更多的业务单元等等,我觉得它可能会变得更加以 GM 为导向。这并不意味着 VP product 会消失,也不意味着 VP engineering 会消失。这些角色仍然会存在。但那个向 CEO 汇报、只负责一个职能的 C 级头衔——如果我从长远来看,也许这个角色会比现在少得多。

Lenny: 你认为这部分是因为 CPO 和 CEO 之间存在一种奇怪的重叠,经常会出现谁在领导产品的张力吗?你见过这种情况吗?

Manik Gupta: 是的。我觉得这确实也是一个有趣的问题。我的意思是,如果你想一想,根据我的经验,CPO 到底做什么?他们的工作描述是什么?我觉得值得好好想想这个问题。一般而言——我们总是可以在泛化的层面上讨论,因为这是思考的方式,而每家公司都是独特的——但一般你会说 CPO 负责推动公司的产品愿景,而产品愿景不能脱离公司愿景。实际上,这在领导团队内部也经常造成冲突——产品愿景方面,人们会提出这些宏大的计划,比如”哦,我们会做这个,我们会做那个”,但这并没有真正立足于公司的实际情况。总之,就是围绕产品愿景,确保它与公司愿景保持一致。

Manik Gupta: 然后 CPO 工作的第二大块是路线图的执行和优先级。人们有时候认为,嘿,我到了 C 级职位,就不用操心执行了。绝对不是。如果你是 CPO,尤其是 CTO 和工程负责人,执行非常重要。卓越运营。因为事情太复杂了——我的意思是,我们现在处于很多人远程工作的状态,有各种不同的工具集,有各种不断涌现的新技术,有不同的竞争者。执行至关重要。如果人们不理解这是他们到了高层后工作的重要组成部分,我认为他们就错了。执行是另一个关键部分。

CPO 的核心职责

Manik Gupta: 第三,对于 CPO 来说,尤其是科技公司,因为你确实在推动产品路线图,这是一个杠杆率很高的职位。这意味着你必须真正与所有其他同级合作,不管是营销负责人、销售负责人还是业务单元负责人等等,确保你真正深入地了解实际需求,这样你的产品路线图才能真正落地。从某种意义上说,这是一份被极度放大的跨职能工作。

Manik Gupta: 关于 CEO 和 CPO 之间的关系,我觉得重要的一点是……这其实也是我给一些公司的 CEO 的建议,当他们开始寻找产品副总裁或 CPO 的时候。这几乎像是我给他们的一份问卷。我问 CEO 的第一个问题是:你想做什么?这是最重要的问题。因为很多时候,CEO 要么是技术创始人,要么是产品创始人。也可能是销售创始人。这都没问题。但你想把时间花在什么上面?因为如果你要招一个 CPO 或产品副总裁,但仍然想掌控产品路线图和执行,那就别招了。因为那个人要做什么呢?这是我倾向于在寻找 CPO 或产品副总裁的 CEO 之间首先澄清的问题。

Manik Gupta: 另一个问题是,你是在优化流程?还是在优化战略?还是在优化团队建设和人才吸引?我觉得这真的是很大的一点。有时候你需要找到合适级别的领导者来为团队吸引更多人才。因为人们会说,“哦,那个人在那家公司工作,我也想去他的团队。“你怎么看待工程、数据科学和设计?你怎么看待总经理和运营?在决定是否要招产品副总裁或 CPO,以及要招什么样的人之前,有很多这类设计层面的事情需要想清楚。

Manik Gupta: 我觉得这就是为什么 CEO 和 CPO 之间的工作交集——尤其是对于科技公司来说——甚至我还想把 CTO 也纳入进来——必须非常清晰地界定,否则会造成很多混乱。这些是我从不同公司的工作模式中观察到的一些东西,也是我在指导和顾问过的公司中经常出现的问题。

首位产品经理的相似挑战

Lenny: 有意思的是,这和公司招第一位 PM 的经历有这么多相似之处。感觉他们需要和创始人进行同样的对话。你想做什么?我来承担什么?我们怎么避免一直踩到彼此的脚?

Manik Gupta: 这确实是个……我从来没这样想过,Lenny。我觉得这个观点很好。你说得完全对。显然,如果你在一家较大的公司,你在找产品副总裁。如果你在一家超大型公司,你在找 CPO。但你是对的。作为创始人,你招的第一个产品人,你们基本上会有同样的对话,确保有清晰的职责划分和责任归属。

Lenny: 有意思。我想一定要问你,作为大公司的产品领导者,我很好奇,你在寻求晋升的 PM 身上看重什么?或者说,你如何判断一个人准备好晋升或承担更多责任了?你会看重什么?那些想被视为晋升人选的人应该注重什么?

判断晋升的标准:成果、方式与追随力

Manik Gupta: 我非常看重”做了什么”和”怎么做”两个方面。他们完成了什么,以及他们是怎么完成的。因为这两者是一个整体。如果你只看其中一个而忽略另一个,我觉得你就会犯错误。通常来说是这样。关于”做了什么”,这部分通常更客观。我看重的——当然,这也取决于个人的级别。不要用早期的标准来衡量一个刚入行的人。你得考虑到他们处于学习阶段。如果他们更资深,你当然要用不同的标准来衡量。但最终,如果我要把”做了什么”归结为一点,那就是真正可展示的影响力。一个理想的例子是,某人有一个有力的产品假设,他团结了一批人。这个假设不一定是他提出的。没关系。可能是别人提出的,这不重要。但他相信它,他带领团队朝着它推进,并创造了影响力。

Manik Gupta: 这种影响力不一定总是正面的。也可能是我们学到了很多东西,我们从中学到了,然后我们继续推进,做了下一个版本。等到做下一个版本的时候,我们变得更聪明了。一个完整的产品周期中清晰可展示的影响力,对我来说大概是判断一个人是否准备好承担更多责任的最好指标之一。而你基本上也想给他更多,因为他现在已经有了正确做事的模式。这是第一点。

Manik Gupta: 关于”怎么做”,我特别喜欢那些能够同时创造能量和创造清晰度的人。想想反面。那些不能创造清晰度的 PM 简直是时间黑洞,团队非常痛苦。我相信我们所有人回想过去,也许我们自己某个阶段也处于那个位置。但我们也和那些总是搞不清楚状况、不会总结、不会跟进、不能就我们需要做什么创造清晰度的人共事过,那种感觉有多糟糕。能够创造清晰度、并带着能量推动事情完成的人,我觉得这就是”怎么做”的核心。这对于决定一个人的职业发展轨迹非常重要。

Manik Gupta: 最后一点我想说的是追随力。对 PM 来说非常重要。人们想和他们一起工作吗?随着他们晋升到更高层级,人们愿意为他们工作吗?最终人们会做出选择。如果你身边有一群聪明人,他们在做出明智的选择,选择跟随这个人、和这个人共事、主动找到这个人,而你也不断听到这样的话——某某想和这个人一起工作,因为这个人太厉害了——这其中有巨大的价值。

Manik Gupta: 这三点,如果我真的要归结的话,不看具体级别,我觉得我一直都在寻找这些特质。

Lenny: 这些太棒了。如此简单、清晰、简洁。我喜欢你把追随力与领导力对立来表述的方式。关于 PM 的素质,人们谈论很多领导力,而把追随力理解为——有多少人愿意跟随你、兴奋地去做你想让他们做的事情——这种角度非常好。很酷。

PM 职业转折点

Lenny: 顺着这个思路,当你想到那些在职业生涯中有转折点的 PM,你有没有发现什么与他们职业进步出现巨大拐点相关联的东西——就是他们突然开始做得极其出色?

Manik Gupta: 我自己经历过几次转折点,几乎每一次都是因为组织发生了一些变化,所以我得到了一个机会。这里总有那个运气因素,回到我们一开始讨论的第一个问题。

PM 职业转折点(续)

Manik Gupta: 但总的来说,我认为拐点出现在两个地方。一是当有人真正成功地改变了一个产品的态势,或者更准确地说,改变了它的轨迹。这是一个巨大的拐点。公平地说,这种情况并不常见。但当它发生时,你会知道的。作为领导者,你会知道这个人参与了这项工作,而且实际上领导了这场变革,现在我们在玩一个不同的游戏了。我们在玩一个更大的游戏、一个不同的游戏,诸如此类。

换句话说,我想说的是,职业生涯的拐点与产品的拐点高度相关。如果你能把这两者联系起来,找到其中的因果关系……如果其中存在因果关系,而不仅仅是相关性,如果确实有因果关系的话,我认为那绝对意味着你发现了一个赢家。你真的应该押注在他们身上,必须给他们更多的事情做,因为他们有能力做到。这是第一点。

第二点是,随着人们在职业生涯中不断上升,他们通常开始管理团队。成为一名管理者,然后你变成了管理者的管理者,再然后你变得更加资深。这是组织层级中自然发生的轨迹。我观察到的一个拐点是,当你从一名管理者、一线管理者,变成管理者的管理者时,如果你能够非常高效地驾驭这个转变,你就会知道。如果你是他们的上级或者他们的领导者,你会知道这个人已经准备好了。因为管理独立贡献者和管理管理者完全不同,因为你现在需要建立结构。你需要决定放权多少。你怎么辅导?你怎么辅导你的管理者做正确的事?如果你看到有人有效地完成了这个转变……当然你需要给他们一些时间,但如果你看到了,并且知道他们确实在做到,而且同样地,有很多追随力、很多其他好的事情在发生,那么你就知道他们正处于拐点,准备好承担更多了。

产品的拐点——体现在真正的产出上,以及管理能力的拐点——体现在能够有效地从一级跃升到下一级,从管理者变成管理者的管理者;我觉得这两个地方是我认为如果看到有人做得好,我就知道他们准备好承担更多了。

Lenny: 你发现这第二个方面是不是一个过滤器——在这个管理者-管理者的角色中表现良好并继续越做越好的 PM,和大量因为无法胜任而被淘汰的人之间的过滤器?

Manik Gupta: 是的,我觉得是这样。也许在这个问题上我偏传统一些。我知道还有其他不同的观点,我也尊重。很多时候人们会说,“通常最好的 PM 是独立贡献者 PM。他们有这种疯狂的、不可思议的、无穷无尽的精力,他们不想把时间浪费在管理和诸如此类的事情上。“因为 PM 工作中很大一部分,顺便说一下,是通过影响力来管理。PM 通常没有庞大的团队。事实上,在几乎每家公司中,PM 都是最有杠杆效应的团队之一……因为谈到 PM 的管理比例、PM 与设计师的比例,从来不会是一比一左右,或一比五左右,或一比六左右。有时候会是一比十。在 Google 过去是一比八到一比十左右。

我个人认为这个转变……如果有人成功完成了这个转变,并且从中获得了好的评价,交付了产品,团队的产出也很显著,我绝对把这看作是一个很好的筛选标准,说明我们可以押注这个人。

常见的 PM 职业陷阱

Lenny: 你发现 PM 们在职业生涯中有没有什么共同的习惯或容易犯的错误会让自己搬起石头砸自己的脚,尤其是刚入行的时候?

Manik Gupta: 哦,这种事我见得多了。有几个我总结出来的问题。顺便说一下,我自己早年也犯过这些错误,是吃了苦头才学到的。第一个我想说的是,你刚入行的时候,每个人都期望你做的就是管理事务、管理流程之类的。确保一切按时推进之类的。顺便说一句,这对于刚入行的 PM 来说确实非常重要,要理解这一点。这确实是你工作中很大的一部分。我们不要把 PM 过度美化。PM 初期工作的一大部分基本上就是做团队需要你做的任何事情。但我认为其中一个陷阱是,如果你开始把流程凌驾于进展之上,那就是个问题了。

我的意思是,你想在团队做的几乎所有事情中引入流程,但在发布方面却不够灵活,以及各种可能阻碍进展的事情。如果流程在帮助进展,很好。但如果流程在阻碍进展,你不应该是那个说”不行,不行,不行,不行。我们不能这样做,因为我太执着于流程了。因为作为 PM,这就是我负责的东西。“我是说,作为 PM 你通常不写代码,也不写设计文档,你写的是产品文档。有时候你会觉得,到底我拥有哪些东西?尤其是刚入行的 PM。你会想,“我拥有这个流程。我拥有这个每周站会,或者我拥有这个迭代计划,或者其他什么。“然后你变得过于执着,以至于忘记了那只是达到目的的手段,而你最终被衡量的标准才是目的。这是我看到人们早期会犯的一个错误。

PM 不是产品的 CEO

第二个是变得过于自我中心。一切都是关于我,而不是团队。我是 PM。有一个一直流传的神话。PM 是产品的 CEO。这是世界上最不正确的说法之一。PM 是一个赋能者。我之前说过,这是一个杠杆型工作。你的工作是真正让团队成功。当然你需要有产品思维和路线图之类的,但有时候这些东西会让人冲昏头脑。然后人们变得过于自我中心,那就是一个危险信号。

第三个就是不承认自己的错误或从中学习。在职业生涯早期,你唯一应该优化的就是学习。当然,你会犯很多错误。你还不懂多少东西。你刚刚开始这段旅程,你应该保持谦逊,不断学习,你应该说,“哎呀,我在这里搞砸了。“这没关系。这没什么。顺便说一下,如果你工作的公司不接受这一点,你不应该在那家公司工作。有什么意义呢?你应该真正地以学习为优化目标,向其他人学习。人们应该说,“没关系,别担心。你犯了错。从中学习就好。不要再犯同样的错误。没关系。“但这就是你应该为自己选择的那种文化。

这就是我看到的三个陷阱,尤其是人们在职业生涯早期容易掉进去的。

不同公司的 PM 工作差异

Lenny: 你提到了不同的公司有不同的运作方式,在 PM 身上寻找的东西也不同。我想问你的是聊聊在 Google、Uber 和 Microsoft 做 PM 的区别,以及一般来说这些公司做产品的方式有什么不同。我尽量在这档播客中多做这件事——就是给出不同公司做产品是什么样的一个概览。你在最大的三家公司都工作过,所以我很好奇你能分享些什么。

Manik Gupta: 确实很有意思。这三家公司截然不同。Google 的核心基因非常偏工程。事实上,公司内部曾有一个框架,叫做”技术洞察驱动创新”。核心思路永远是:我们能做出的最好技术是什么,这项技术将如何推动创新,并且要有足够长远的眼光,等市场追上来。这一直是 Google 的哲学。作为 Google 的 PM……我离开已经六七年了,情况可能有所变化,但至少 2008 到 2015 年我在那里的时候,特别是在 Google Maps 团队,你的工作就是如何基于扎实的技术洞察做出好的长期押注,然后借助 Google 搜索分发的力量把产品推出去。就是这样。

在 Maps 团队,我们的创新基本上是围绕众包所有人的位置信号来做交通信息。这是一个巨大的成就。我们拥有世界上最好的交通模型。然后在此基础上实现了疯狂的路线优化来提供导航。再之上还有搜索技术栈,这本来就是从 Google 搜索继承来的,所以你可以搜索任何地址、任何商家等等。

总之,作为 PM,核心就是与工程师密切合作,真正地把工程师的想法放大和落地。我想那个时期 Google 的很多 PM 都非常技术化。非常非常技术化。因为这就是理所当然的事。公司期望你至少能够参与工程层面的讨论。我在 Google 做 PM 期间,尤其是初期,很大一部分工作就是跟工程师一起深入技术细节,认真钻研我们能做什么。这就是 Google 的模式。

Google 的 PM 不用操心商业模式

顺便说一下,在谈其他公司之前,关于 Google 还有一点要提——在 Google 做 PM,至少一直到我升到总监的时候,我从来不需要考虑商业模式。从来没有。这一点非常奇妙。你处在一种奇怪的状态里,可以专心做产品、获取消费者用户,诸如此类,但你从来不需要考虑利润表(P&L),从来不需要考虑收入。

Uber:运营驱动、商业导向

然后我去了 Uber,情况完全不同。Uber 非常偏运营,非常商业导向,非常关注利润表。事实上 Uber 做了一件非常厉害的事——他们有一个仪表盘,公司每个员工都能看,上面有上周的收入、上周的订单量,你可以各种维度地切片分析等等。随着后来上市,这在某种程度上有所变化。但关键是,这些数据始终就在你面前。每周发出的内部 Newsletter 里全是增长数据,全是业务数据,全是这类内容。非常运营、非常商业。所以在那边做 PM,很大程度上是管理更多的利益相关者——运营团队、市场营销团队、政策团队等等。你怎么跟他们合作,把产品部署到各个市场。当然,很大一部分工作仍然是跟工程团队协作。但在这一点上确实有所不同。

我觉得在 Uber 还有一点不同,就是它更加是一个实时业务。我的意思是,Google 也是实时的,Google Maps 也是实时的,有数十亿用户在使用。但 Uber 是……每天都有市场上的事情在发生,你必须持续保持紧迫感——怎么确保你的产品保持竞争力、运行正常、不出故障。所有这些都极其重要。

Microsoft:技术实力与信任文化

最后说说 Microsoft。Microsoft 已经有相当长的历史了。这家公司经历了太多事情,而在过去几年里,特别是在 Satya 的领导下,表现得非常出色。无论是公司文化的转变,还是推向市场的产品,以及市场占有率,都做得非常好。

我觉得我会这样描述 Microsoft——首先,它是一家技术实力非常强的公司。这里的工程师太厉害了。天哪,能和这些我职业生涯中合作过的最优秀的工程师一起工作,我感到非常幸运。但与此同时,这里也有大量的历史遗留。有很多产品存在了非常长的时间,这有好有坏。好的一面是,他们几乎见过所有的模式。事实上,很多模式就是他们自己创造的。不好的一面是有时候变革很困难。你怎么说服大家我们要走一条不同的路?作为 PM,很大一部分工作是引入外部视角,带来清晰度:“嘿,这其实在其他地方是这样做的。“带一个具体的例子过来。试试看效果如何。

最后我想说的是,这家公司深植于信任。如果用一个词来概括 Microsoft,那就是信任。他们真的非常关心客户。客户也非常信任 Microsoft。我自己参加过一些客户会议,完全能听到客户的说法。一切都围绕信任。他们期望稳定性,期望产品能正常运行,期望当他们的 Surface 出了问题时 Microsoft 会负责解决。这是他们长期积累下来的。作为 PM 在这家公司工作,你会把这些铭记于心——我们在这里做的很多事情,都是为了真正帮助我们的客户。

Lenny: 回到你提到的公司-产品契合,这些文化和运作方式刚好完美契合它们最终做出的产品。我在想到底是先有鸡还是先有蛋。

Manik Gupta: 确实如此。这个话题完全可以另找时间深入聊,我在这方面有很多想法。但我只想回应你刚才说的——这就是为什么当公司启动新项目时,必须非常非常慎重。这是我们该进入的领域吗?或者说,我们进入某个领域的条件和理由是什么?我们必须对此非常清晰。因为如果起始条件不对,你就是在消耗团队。团队会一直在某个东西上工作,但始终找不到正确的内部契合。所以这一点超级重要。

对 Google Maps 和 Uber 的遗憾与期待

Lenny: 你做过 Google Maps 和 Uber,我想你现在还在经常用它们,可能每天有数十亿人在用。有没有一个功能是你当时在团队时希望做出来但没做的,或者有哪个功能你觉得应该砍掉、让你觉得烦的?

Manik Gupta: 哇,好的。这个问题很有意思。我不知道这算不算当时在 Google Maps 能做出来的东西,但有一件事很有意思——自动驾驶技术的发展速度就是不够快。我觉得最聪明的那批人已经在做了,而且还在继续做,它终究会实现的。我对此深信不疑。但时间线确实因为各种原因推迟了,因为这真的是一个非常难的问题。看到 Cruise 现在在旧金山做的事情其实很有意思。他们已经启动了试点,所以我非常高兴看到一些进展。我知道 Waymo 在这方面也已经做了不少。

但如果当时能实现就好了。我们在 Google Maps 团队时经常讨论的一个话题是:当人们坐在自动驾驶汽车里时,导航产品应该怎么设计?当时我们有一些非常有意思的想法,但始终没能落地。不是因为我们没有优先考虑,而是技术还不成熟。我一直在密切关注这件事,看我们什么时候才能走到那一步。这还需要很多年,但这真的是一个完全不同的范式。就像计算机和计算机对话,算法和算法对话。最终当然还是要服务于人,但人本身不再那么主动发起操作了,很多事情就在你身边自动发生了。

总之,这件事在我看来算是未竟之业吧。希望随着技术的成熟,它能最终实现。

Lenny: 太棒了。Manik,你真的非常慷慨地分享了这么多时间。最后两个快问快答。大家如果想联系你或者了解你在做的事情,可以在哪里找到你?另外,听众怎样才能帮到你?

Manik Gupta: 好的。你可以在 Twitter 和 LinkedIn 上找到我,就这两个地方。最近我在两个平台上都不太活跃,没有怎么发内容,但作为消费者我还是会经常刷。如果你有任何问题或想法,很希望能听到你的声音,欢迎给我发消息。

至于听众怎么能帮到我,我就是想了解有什么新鲜的东西、外面在发生什么。我有幸曾在这些了不起的公司工作过。我现在还在做这行,原因就是我仍然想学习。如果你看到了一些更好的模式,特别是关于如何打造产品方面的,我很想了解。或者其他人对于如何找到产品-市场契合(产品-市场契合)有什么不同的思考方式,也请告诉我。因为这实在是太难捉摸的一件事,我一直在反复思考。如果你有一些技巧、建议或最佳实践,而且对你确实有效,请一定要联系我。我很想学习,因为持续进行这种对话对我们来说太重要了。

Lenny: 太好了。和你聊天总是一件很愉快的事,我每次都能学到很多。这次也不例外,再次感谢你来做客。

Manik Gupta: Lenny,非常感谢你提出这些问题,也感谢你给我机会分享这些年来学到的经验。谢谢。

Lenny: 完全是我的荣幸。非常精彩。感谢收听。如果你喜欢这期对话,别忘了订阅播客。你也可以在 lennyspodcast.com 了解更多。我们下期再见。

术语表

原文中文
Anneka GuptaAnneka Gupta(人名,保留原文)
company market fit公司-市场契合(公司-市场契合)
company product fit公司-产品契合(公司-产品契合)
consumer stack消费栈(消费栈)
critical user journey关键用户旅程
CruiseCruise(自动驾驶公司名,保留原文)
dotcom boom互联网泡沫(互联网泡沫)
dotcom bust互联网泡沫破灭(互联网泡沫破灭)
go to market市场推广(go to market)
instrumentation埋点
line extension产品线延伸
Manik GuptaManik Gupta(人名,保留原文)
Morgan HouselMorgan Housel(人名,保留原文)
NewsletterNewsletter(Newsletter)
P&L利润表(利润表(P&L))
product market fit产品-市场契合(产品-市场契合)
SaaSSaaS(软件即服务)
SatyaSatya(人名,指 Microsoft CEO Satya Nadella)
ship velocity发布速度
Steve KerrSteve Kerr(人名,保留原文)
SurfaceSurface(Microsoft 产品名,保留原文)
WaymoWaymo(自动驾驶公司名,保留原文)

此文档由 AI 分片翻译(translate_long_document)