产品经验教训：与 Shreyas Doshi 和 John Cutler 的对话

已发表: 2021-07-13

在相对较短的时间内，Shreyas Doshi 已成为 Twitter 上最受欢迎的产品建议分配器之一。 为什么？ 他的作品清晰、谦逊且有自我意识——这些特质在热门话题中往往缺乏。 他选择的格式？ 线程。 还有很多。 交织而有条理。 280 个字符的字符串中蕴含着职业生涯的智慧。 这里的每个人都可以使用。

我很好奇（好样的）疯狂背后的人。 所以我们安排了面试！ 我们涵盖的主题包括领导力、成为更好的倾听者、中层管理人员的角色、职业和自我认同、固执、日历剧场以及将仪表板视为产品。

有什么突出的？ Shreyas 拥有丰富的产品管理经验。 他曾在 Stripe、Google、Twitter 和 Yahoo 等公司担任一线产品经理和产品经理经理。 他是一位伟大的作家和演说家。 但真正闪耀的是他的谦逊和体贴。 他警告人们不要盲目地复制他的建议，并公开承认他已经通过艰难的方式吸取了许多这些教训。

采访时间为 1 小时 30 米（见下面的音频播放器）。 如果您想跳来跳去，我们在下面创建了带有时间戳的采访大纲。 对于每个部分，Shreyas 都非常友好地提供了相关主题的链接。

对 Shreyas 有后续问题吗？ 请在推特上发布您的问题，包括@Amplitude_HQ、@shreyas 和#shreyasinterview。 如果有足够的兴趣，我们将尝试安排后续 AMA。

我有一个问题要问@shreyas 和@johncutlefish #shreyasinterview点击鸣叫

如果您想了解更多关于产品战略和产品管理领导力的信息，请务必下载北极星手册。 它充满了指导和框架，可帮助您立即为您的业务和团队带来影响。

面试目录

完整的成绩单包括上下文的相关推文。 感谢 Shreyas 为大家策划了这些！

  • 简介[00:00:00]
  • “不要相信我写的一切……” [00:01:07]
  • 了解自己[00:04:03]
  • 成为更好的倾听者[00:05:13]
  • IC 到经理的过渡[00:11:49]
  • 讨论不确定性和组织文化[00:14:10]
  • 中层管理和“真实” [00:16:52]
  • 产品领导的作用[00:18:01]
  • 专业身份（以及向领导角色的转变） [00:21:56]
  • 经理在帮助人们采取非默认行为方面的作用[00:25:39]
  • 心态、原则和战术（以及陷入战术） [00:30:29]
  • 高绩效团队的基础/基础[00:35:11]
  • 为什么有基础的团队会生产出糟糕的产品？ [00:37:31]
  • 故意和固执（与你想成为的公司） [00:39:24]
  • 分析和创造性的情报[00:44:14]
  • 影响级别、执行级别和光学级别[00:49:13]
  • 认知偏差和共享词汇[00:54:37]
  • 将仪表板视为产品[01:01:51]
  • 充实的日历、反应性、自我认同和积极/消极的习惯[01:08:20]
  • 改善当前状况（以及差距与当前思维） [01:14:24]
  • LNO：杠杆、中性和开销任务[01:18:10]
  • 结论[01:21:23]

面试成绩单

简介 [00:00:00]

John Cutler：早上好，Shreyas。

Shreyas Doshi：早上好，约翰。

约翰卡特勒：怎么样？

Shreyas Doshi：很好。 很高兴来到这里。

约翰卡特勒：所以这是我们第二次发言了。 我记得当我们第一次说话时，你说，我应该继续做这个 Twitter 的事情吗？ 或者，书呢？ 我不知道那是几个月。 我的意思是，感觉就像大流行时间一般会压扁一些事情，但已经有一段时间了，事情对你来说绝对是爆炸性的。

因此，我只想指出自我们上次发言以来的不同之处。 所以我猜，恭喜。

Shreyas Doshi：谢谢。 这很有趣。 只是写一些关于产品的想法等等。 一次 280 个字符。

John Cutler：对于那些不知道的人，Shreyas Doshi，我将给出最快的介绍。 他是产品经理。 所以最近在 Stripe，他在 Twitter、谷歌和雅虎都有背景。 是一位多产的作家。 我认为就是这样。

我想刺破无敌的面纱，如果可以的话就开始吧。 因为你的文字很简洁。 在过去的几个月中，您一直在努力解决什么错误。

“不要相信我写的一切……” [00:01:07]


Shreyas Doshi：是的。 所以我想对我的写作说一件事，首先，不要相信我写的所有东西，不要把我写的所有东西都付诸实践，因为你喜欢我的作品，或者因为这件事得到了很多人的喜欢，所以它一定是真的。 约翰，这是我在过去一年中真正开始写的关于我对产品、战略和组织等的想法的东西。

在我点击推文或发送按钮之前，我最大的恐惧是哦，如果脱离上下文，或者如果在错误的上下文。 这是我对自己所写内容的持续担忧，有时，写作的某些精确性，也许还有一些力量，如果有的话，听起来比在你的特定情况下实际情况更真实。

写作远非完美。 因为即使我试图让它更清晰或在胎面的某个地方，它也可能会遗漏许多细微差别。 所以这是一个。 第二件事是我，我想我几周前在推特上发了这条消息，你知道，我倾向于谈论很多关于不应该做的反模式的事情。 我谈论这些的原因，有时人们告诉我，哦，这创造了很大的清晰度。 我在我的团队、我的公司、我自己、我的经理身上看到了这种反模式，不管它是什么。 你是怎么到那里的？ 所以，我在推特上发布了这一点，你知道，我写的许多反模式，我一直是那个反模式。 对？

我在自己身上看到了它。

有时可能只是几个小时，哦，我进入了这种反模式，哦，我感觉到了，我停止了它，我成功地停止了它。 有时，我已经写了好几个月的某种反模式。 还有一些我多年来一直在做的事情，以及我自己并没有做得很好的事情。

所以有一个方面，你知道，我写的很多东西，我在自己身上看到了其中的一部分，或者在不同的时间段内看到了我自己的全部。 而且，我认为唯一的区别也许是你知道，是自我观察，对吧？ 我还想分享的一件事是我们可以谈论策略，我们可以谈论产品管理的框架、结构和模板。

了解自己 [00:04:03]

但在软方面，我认为对于我们所有人来说，作为产品经理要意识到并作为产品经理变得更好的一件非常重要的事情就是了解自己。 你知道，他们谈论的枢纽，哦，了解用户，了解客户，了解市场，了解竞争对手。

我同意所有这些。 但也要了解自己。 从了解自己开始。 现在你不会一下子了解你自己。 但是，如果您从了解自己开始，您会发现对用户的其他一些了解等等并没有变得更容易。

有很多很多事情我不是很擅长。 就在最近，我想我又在 Twitter 上进行了一次对话，有人问我哦，Shreyas，一个人应该如何在组织内管理得很好？

我说，看，我没有答案，因为多年来我一直不擅长管理。 Andrew Yu 给我寄了一本关于向上管理的书。 所以我说，嘿，安德鲁，你应该回答这条推文而不是我这样做。 所以这只是你知道的一个例子，我还没有完全破解。

成为更好的倾听者 [00:05:13]

约翰卡特勒：我真正喜欢的一件事是，通过你的线索，你是脆弱的，而且是谦虚的。 我记得有一条我非常喜欢的推文，你观察到年轻的自己是一个更好的倾听者，并且你陷入了一个你也没有倾听的时期。

这对我影响很大。 因为我想，我在我的生活中经历了这些阶段，这不是一个静态的情况。 你总是在学习。 我特别想知道那种情况，那种自我实现是什么样的？ 你知道，当你意识到这一点时，你是如何解决这个问题的？ 然后什么，你采取了哪些步骤？ 你开始在线程中详细说明它，但我真的很想你解释它并亲自听到它。

Shreyas Doshi：所以，我小时候曾经是一个优秀的倾听者。 在我童年的早期，我的记忆力也很强。 这已不再是这种情况。 我现在总是忘记事情。 但我是这样开始的。 比如学校里的很多事情，很早就开始了，对我来说很容易，因为我只是在听老师说的话。

然后我能够保留它很长时间。 在我十几岁和二十出头的时候，情况发生了变化。 你知道，我不知道为什么。 这一定是你年轻时所经历的。 你只是，在某个时候，我会在大学里完全调出。

我不知道，我坐在那儿，但我不知道在说什么。 并且继续。 它只是变成了这种模式。 然而，当我开始我的软件工程师职业生涯时，不再是那种对会议上所说的内容或另一个人在说什么的冷漠程度。 但我只是失去了这项技能，因为那时我已经有五六年没有使用它了。

约翰·卡特勒：你有没有想过，等等，我丢了这个？ 就像，你是怎么做到的，你是怎么意识到的，或者它就像一个缓慢的燃烧。 或者可能是经理或与您分享消息的人？ 怎么样，你是怎么意识到的？

Shreyas Doshi：你知道，约翰，我很晚才意识到这一点。 所以我想说，在我开始我的职业生涯大约 12 年左右的时间里，我一直处于一个很好的倾听者状态。 当然，这意味着我在听。 我正在处理等等。 但我是在这种经典模式中形成自己的想法。 形成我的回应，并准备我的回应。 或者，不是真的听别人说什么，而是听我想听的。

因此，在我的职业生涯中，我处于那个阶段至少 12 年。 在某些时候，对我来说，主要的认识是理解对方的关键是确保他们知道我理解他们。 对？ 所以我从第一步开始。 这是一种非常战术性的，它不基于任何原则。 这是一种很好的策略。

约翰卡特勒：你必须在脑海中仔细考虑......

Shreyas Doshi：是的。 要成为一名优秀的经理，我需要确保对方明白我明白他们在说什么。 那是我开始的地方。 然后我做到了，我想说，这可能让我从 10 分中的 4 分变成了 10 分中的 6 分。这很好。 这是一个改进。

但是，下一个重要的认识，以及我能够做出的巨大改变，是当我意识到当你只听别人说的话，并且你全神贯注时，反应会自己塑造。 对？ 所以我实际上不必在你说话的时候思考。 或者我什至不必考虑我将如何总结你所说的话，只是为了确保我理解你。

我只想百分百在场。 我想好奇。 这就是变化。 是那种真正的好奇心并发展那种真正的好奇心，以及能够在场并能够观察我的部分的技能，并让自己完全回到所说的话。

然后当我这样做时，当我从这种真正的好奇心和存在中接近它时，我看到，哦，哇，当我这样做时，两件事正在发生。 一个是，我 [00:10:00] 只是遇到另一个人，因为他们对他们所说的内容更感兴趣。 其次，我的回复质量要高得多。

而以前，通常情况下，反应往往有一种感觉，好吧，我听到了你的声音，鉴于我的角色，它经常，就像我听到你的声音一样，这是我的建议。 或者这是我的答案。 回应变成了一个问题，而不是一个陈述。

他们就是这样理解我真的理解他们的。 我正在真正尝试进一步了解它们。 他们对我说了些什么。 我真的在场。 我真的很好奇。 正因为如此，我问了他们一个我本来不会问的问题。 这个问题使我们更接近能够更好地了解情况。 当我开始这样做时，我越来越意识到，哦，这真的很有效。 如果他们是正确的问题，向人们提问会更有效。 而且，如果它们是基于对他人试图对这种情况的看法的深刻理解，或者尽可能深入地理解。

约翰卡特勒：听起来你随着时间的推移发展了一些东西，并且在这方面变得更好。 就像，您可以一对一地提出更好的问题，等等。

Shreyas Doshi：当然。 而且，你知道，在我担任过项目经理的四家公司中，我都担任过项目经理的经理。 这四家公司中有三家是我作为个人贡献者加入的，包括我最近的雇主 Stripe。 我作为个人贡献者加入，然后开始管理人员。

IC 到经理的过渡 [00:11:49]


所以我已经完成了从 IC 到经理的过渡。 许多人经历过一次或两次。 嗯，然后他们仍然是经理。 我已经经历过很多次了。 而且我不介意在有意义的 IC 中工作。 所以它对我来说效果很好。

虽然每次都不一样。 因为随着我成长为一名经理。 我想当我开始管理时，已经是成为产品经理九个月了。 有人告诉我，哦，我们喜欢你的所作所为。 你为什么不管理一个小团队？ 回首往事，当时我并没有意识到，但回首往事，我觉得我是一个糟糕的、糟糕的 PM 经理。 这可以追溯到很多这些反模式。 我就是这样。 因为我记得很早，所以我很确定我有答案。

这就是其中之一。 其次，我认为我的工作是提供答案。 如果我的团队成员在接受或接受这个答案时遇到阻力，那么我觉得我的工作是通过非常分析的方式说服他们，为什么这是正确的答案，对吧？

那时我作为经理真是太糟糕了。 当然，现在我采取了一种非常不同的方法。 你知道，这很大程度上与培养真正的好奇心有关，我想，也与一般的生活成熟度有关。 但也只是能够观察我的想法，并了解 PM 经理应该做什么。

他们的工作是什么，他们的角色是什么？ 我现在有了更好的理解，而以前我只是被要求开始管理人员，就像我不知道我实际上应该做什么一样。

约翰卡特勒：当你想到你参与过的公司时，我的意思是，我认为我注意到某些公司文化的一件事是他们在讨论不确定性时的处理方式非常不同。 在某些情况下，您知道，除非您有绝对的计划来减少不确定性，否则永远不会提及不确定性。

而在其他文化中，他们似乎更愿意让领导者说，只是现在不知道。 那么你的游戏计划是什么？ 就像您曾经接触过这些组织一样，但是您如何理解领导者的脆弱文化？

因为它显然很重要，但它在不同的文化中表现不同。

讨论不确定性和组织文化 [00:14:10]

Shreyas Doshi：我喜欢你提到的文化，约翰，因为这一切都可以追溯到那个。 哪里有文化。 是的，你应该确定。 如果你不确定，如果你没有所有的理由，分析的理由，你被认为是无能的。

在其他文化中，一定程度的不确定性被视为我们所做工作的一部分，是的，我们不知道这将如何解决，没关系。

这并不意味着第二类文化不那么严格。 我认为它更严格。 因为它不是基于对基于某些输入的严格数学结果的幻想。 它了解您将 [00:15:00] 产品带到外界时所涉及的随机性。 它了解其他随机性，市场中的系统本身等等。

它适用于对这些事物的那种真实世界的理解。 与一些理想化的，你知道的，哦，是的，我们应该能够用电子表格的方法证明这一点。 条纹就是一个很好的例子。 你知道，我们会有产品评论，我们的创始人或我们的领导人会说，是的，我们无法确定这一点。

让我们了解客户反馈是什么。 让我们了解市场环境是什么。 然后在此基础上，我们将根据情况做出最佳决定。 但是，你知道，我们不必确定这会成功

约翰卡特勒：对。 这是令人难以置信的建模，对吧？ 就像从领导者的角度来看。 这意味着它还有很长的路要走。 如果领导这么说，那是肯定的。

Shreyas Doshi：是的。 是的。 而且，你知道，还有经典的单向门，双向门，我真的看到在 Stripe 练习过。 这是我们可以撤销的决定。 对？

所以让我们来吧。 没关系。 如果我们错了，我们只会撤消它。 撤消它的成本不会很大。 然后可能还有其他更难撤销的决定，或者我们无法撤销。 让我们真正花时间把这些做好。 再说一次，我在这里说的所有东西，约翰，感觉很明显，就像是的，当然在大多数情况下你应该这样做。

就像，你当然应该这样做。 问题是为什么这不会发生？ 为什么大多数组织在这个意义上是非常不完美的？ 而且，我认为，你和我已经讨论了确定性剧场这个话题。 而且，我认为这与文化为中层管理人员创造的心理安全感有很大关系。

中层管理和“真实”[00:16:52]

我对中层管理人员的看法是，他们是组织确保您能够了解真实情况的方式。 有事实真相，而且，你知道，人们非常直接地致力于这个真相。 然后当他们看到这个真相时，他们会将这个真相传达给中层管理人员。 然后中层管理人员充当了这个代理，就在你在实地看到的真相之间。 然后是公司高管在宏观范围内看到的真相。

所以我认为对于中层管理人员来说，自由地表达他们在双方看到的真相是非常重要的。 不必担心他们的工作会受到威胁，或者他们的职位会受到威胁，或者他们的职业成功会受到威胁。

如果他们能做到这一点，我认为这就是在组织内双向开启更好的真相流动的关键。

John Cutler：中层管理不只是一层。 在许多情况下，它是多层的。 那么，你如何让真相在两个或三个层面上双向流动呢？

产品领导的作用 [00:18:01]

Shreyas Doshi：第一个观察结果是，我们并没有真正谈论工作是什么，以及产品负责人的角色是什么。 对？

我的观察是，大多数这样的产品领导者都拥有丰富的经验和出色的简历。 如果你问他们，你的角色是什么？ 比如，你真正的角色是什么？ 他们会挣扎。 而且我不怪他们，因为就像，你知道的，没有人教他们他们的角色是什么。 所以他们只是开始做事，然后无论他们在做什么，如果它有效，如果他们得到了一些外部验证，他们就会做更多的事情。 然后他们压制了他们没有得到验证的东西。

所以以某种方式得出了某种风格，某种方法，或某种隐含的角色定义。 现在，这已经深深植根于他们的习惯中，以至于他们无法完全描述它。 就像，好吧，我的角色是 X、Y 和 Z。

我认为这非常重要。 一旦你理解了这个角色，你需要做什么就很清楚了，对吧？ 您需要做的是通过其他人使产品成功，对吗？ 就像这实际上是你在某个地方的中层管理中作为产品领导者需要做的事情。

为了通过其他人使该产品取得成功，我谈论它并创建自我管理团队，对吗？ 因此，创建自我管理团队非常重要。 理想情况下，作为产品负责人，你知道，你不只是喜欢灭火，喜欢出现在八条评论中，因为你需要在那里，你需要审查一切，没有你在场，什么都不会发生。

我知道这是许多产品负责人的现实，我们的日常工作，这就是为什么它经常压力很大的原因。 我相当定期地指导许多这样的产品负责人，[00:20:00] 令他们惊讶的是，它不必是这样的。 它不一定是你正在做的方式，你知道，每周 40 次会议或 50 次会议。

这个笑话我听过很多次了。 这就像，哦，所以你是产品负责人，所以你永远不会坐在办公桌前，对吧？ 就像你总是要参加会议一样。 哈哈。 我们接受这是现实。 我绝对拒绝这个前提。 实际上，作为产品负责人，您应该在办公桌上花费大量时间。 如果你不这样做，那意味着你没有履行你角色的第二个方面，即创建自我管理的团队。 对？

所以我确实认为这可以追溯到对角色的理解。 一旦你理解了你的角色，你的行动将在你如何委派方面完全不同，你不仅会说，嗯，我不喜欢你向我展示的这种流程方法，但我确实喜欢其他东西，而是说，看这里，这就是我的想法。

以下是我对用户目标的看法。 以下是我对我们的转化目标的看法。 然后这里也许有一些原则供我们考虑。 这里也许有一些指标供我们寻找，以找出正确的答案，对吧？ 就像这就是你作为产品负责人需要与你的团队进行的对话，因为这就是你如何创建一个自我管理的团队而不是哦，鲍勃，鲍勃只是喜欢单页流，对吧？ 喜欢，或单页步骤。 就像那只是鲍勃的怪癖。 所以只要确保这是产品经理告诉设计师的，只要确保你这样做，对吗？ 喜欢，但原因是缺失的。 更重要的是，哦，如果您想通过 Bob 审核成功获得它，您将需要这样做。 对。 这是没有意义的，因为现在你创建了一个自我管理团队的对立面。

专业身份（以及向领导角色的转变）[00:21:56]

John Cutler：我也想到一件事，产品经理似乎常常喜欢他们角色的这种模糊性，甚至从 IC PM 开始。 他们几乎自认是变形者。 有点强迫自己去做所有需要做的事情。

我可以想象那个人，当他们成为导演时，他们会升职。 也许有时他们不能放手。 也许这是导致无法澄清他们的角色的一件事。

Shreyas Doshi：哦，你知道，约翰，你刚才说的话引起了如此强烈的共鸣。 对此，我想分享两件事。 第一个，是你有这个经典的例子。 再说一次，这是很多很多年前的我。 这是12、13年前的我。 看似称职的产品经理，真正擅长产品管理核心工作的人。

谁说的，好吧，我们希望你管理 PM。 对，现在，在那种情况下发生的事情真的很有趣。 我认为如果这种情况发生在很多很多有能力的 PM 身上。 然后，这使他们的产品负责人能力稍差，至少是第一或第二……

约翰卡特勒：你是说项目经理随着他们在组织中的晋升而变得越来越不称职？

Shreyas Doshi：嗯，要求，标准发生了变化。 对？ 例如，就我而言，我仍在构建和发展我的核心产品管理技能。 它没有完全建成，但我被要求管理，这很好，这也发生在许多其他功能中。 但挑战在于我精神上也不在那里，对吧？

就像我知道我有这些差距一样，在我内心的某个地方，我仍然有那种动力来证明我是一个真正伟大的产品经理。 不是产品经理的经理，而是真正伟大的产品经理。 它在我的团队中表现出来的方式是，你知道，出现了一些事情，我走了，哦，这显然不是正确的答案。 这就是我们必须思考的方式。 就像，只要注意我的语言。 对？ 就像这些是我曾经使用的词。

而我真正在做什么，现在我明白了，我当时不明白。 我真正在做的只是试图向自己证明我仍然得到它。 并试图向他人证明和展示，就像我在核心 IC 个人贡献者工作中的出色表现一样。 啊，我在产品经理身上看到了这一点，尤其是在他们最初的三、四年，当他们进入产品经理的管理阶段时。 他们仍在尝试做产品管理角色，核心IC角色，而不是经理角色。

然后这给他们自己带来了各种各样的挑战。 因为，您知道，当您采用这种 IC 方法时，您将成为经理，他会说，[00:25:00] 哦，是的，我需要参加那个会议。 你能邀请我吗？ 因为您需要实地背景才能形成您对产品战略或产品方向的看法，对吧？

相反，通过你的员工培养理解这一点的技能。 然后它会惹恼你团队中的人，因为它就像，为什么我的老板会出现在这次会议上？ 这没有道理。 哦，我的老板是个微观管理者。 或者看，哦，因为我的老板出现在这个会议上，我现在需要在这个会议上表现出来，而不是仅仅让自己变得脆弱，提出合法和真实的问题等等。

经理在帮助人们采取非默认行为方面的作用 [00:25:39]

我会告诉你与我们正在讨论的这个主题相关的一件事，我想到的是查看经理的角色，特别是在产品管理的背景下，将经理的角色、总监角色、副总裁角色、CPO 角色视为旨在帮助人们了解何时应该采用非默认行为。

让我们举一个具体的例子。 你会发现，你知道，在博客文章的某个地方，或者可能是 Twitter 线程，这种，哦，这就是产品经理需要的……

John Cutler：顺便说一句，我们可能对这些共同负责。 所以我认为我们可以，

Shreyas Doshi：当然。 这就是我喜欢的东西，哦，我很紧张，点击发送…

约翰卡特勒： ……我做噩梦，所以我会拿着我的……

Shreyas Doshi：当然！ 所以，让我们假设一篇关于产品经理应该做什么的博客文章。 这就像一个产品经理在他或她的团队那里。 产品经理解除对团队的封锁。 产品经理与团队一起检查团队的需求，并交付他们需要的东西，以提高效率。

他们可以是有效的。 产品经理确保他们定期与个别工程师进行检查，以确保他们得到他们需要的东西等等等等。 对。 所以你可以想象这种假设的博客文章。

假设我是产品经理，或者是新产品经理，然后说，好吧，所有这些都是有道理的。 我将开始这样做。 而且，猜猜会发生什么？ 就像我开始做的那样，效果很好。 人们说，哦，你知道，Alice 加入了我们团队的 PM。 这太棒了。 这是一个白天和黑夜的区别。 我不敢相信我们在没有 PM 的情况下运营，这太棒了，更多的 PM，你知道吗？

让我们确保我们认可 Alice 作为产品经理等所做的贡献。 对。 好的。 效果很好。 那么现在会发生什么？ 如果我是产品经理，我会将此作为我的默认行为。 因为这是我从事这项工作的第一年。 我对各种不同情况下的产品管理一无所知。

我假设我正在对这些操作进行验证。 所以我必须做同样数量或更多的这些动作，对吧？ 现在，把我送到另一个团队。 或者不同的公司。 好的。 现在，在这家公司，或者在这个团队里，我们就说在这个团队里，工程师是非常独立的。 They are already talking to customers directly, right?

They're talking to sales directly to understand requirements. They are talking to marketing. You know, the designers are doing end to end research and validation as well as again, kind of very customer centric. And it's generally a very high agency team, right?

Like again, the tech lead, or the lead designer, isn't afraid to go to the VP or the CEO and ask questions or ask for what they need and whatnot. 对？ You can bring in this product manager, who's performing these defaults, in this situation, what happens, right?

Same product manager, different teams. And the feedback is, oh, you know, we think Alice needs to create more room for ideas. We think Alice can sometimes create an unnecessary obstacle for us. We think that is a lot more process. We think there are many more check-ins than there need to be. We don't have to provide status on a daily basis for what we are doing, et cetera, et cetera. 对？ Same product managers, same actions, different contexts. 不工作。 So with this now let's get back to the thing I've been mulling over recently, which is where is the failure here?

I don't think the failure is at the level of the PM. It's not Alice's failure. It's the manager's failure, right? It's the manager's responsibility to help a PM understand the context within which they are [00:30:00] operating and then nudge them towards non-default behaviors.

John Cutler: It's funny you had that conversation. I think there was a thread with Dee Hawk where he said, I talk about principles and these deep things, and you actually made the point where you said most people just want to get ahead.

You know, so talking about principles is a little tougher. I'm paraphrasing. I think I remember this in the back of my mind. But I thought what was interesting — that point — is it's also the toughest thing, right?

Mindset, principles, and tactics (and getting stuck on tactics) [00:30:29]

Shreyas Doshi: So, so a couple of thoughts there. One is it does depend on where one is at, right? There are three things that one needs to understand and use in order to get really good at something.

There's mindset, there's principles, and tactics, right?

People often will start with tactics. Which is here is a recipe for how to run this meeting, right? Here's the template for a product review. Here's a template for a product strategy doc, or what have you, right. Tactics are amazing. You need tactics to figure out the basics of a role and to be productive in that role and to learn by doing right. So tactics are really, really important.

What happens though, is for many people, they get stuck at tactics for the majority, if not the entirety, of their career. And that's where there is a problem. 对？ Which is once you have reached a certain degree of proficiency, you are not going to be able to, you know, seek the 37th tactic for doing this thing in order to actually be effective. 对。 And, and so what you need at that point, is a better understanding of the principles. Because with the principles, what you will do is you'll know which tactic to employ. But even more amazingly, once you start understanding these principles, you can create your own tactics, right?

And then mindset is the most important thing. All of us know we need to do certain things. I know I need to write that PRD, why am I not writing that PRD? And instead, spending my time on Slack, and replying to email, and convincing myself that I'm being productive by doing that.

And there is a very good reason why I'm not writing that PRD. I need to understand myself. I need to understand what is really going on. What I'm really fearful of when I'm avoiding writing that PRD that I really should be writing. So there's much more to mindset than that, but the point is to achieve the highest degree of competence in a certain field — and particularly, I think, I can only speak for product management really to achieve the highest degree of competence in product management — you do need to understand each of these three extremely well.

Depending on the context, some of this is just not possible. Look, a lot of what I talk about the implicit background there is it's, we're talking about you know, like Marty Cagan calls it empowered teams, right? Where people are given the right tools, and the freedom to arrive at the right answer. Without taking tremendous personal risk in order to do so. I have been fortunate to have largely worked at organizations where the teams have just been empowered by default. My perspective comes from that. I frankly don't know what it's like, and what success is like, in environments where teams are not empowered, where individuals are not empowered. A lot of what I might say in that context can probably be boiled down to, grow as much as you can in the environment, such that now you will have the optionality to move to an empowered environment where you can really exercise your skill and achieve, hopefully greater potential.

But even as I say that I'm in two minds, right? Like, I feel like, okay, it makes sense to try to grow as much as one can, based on the cards one is dealt. 对？ It seems to make sense to do that. My own personal experience. I was very early in my career. I was in these highly disempowered teams. That's sort of what I tried to do, but again, I'm a sample size of one. What works for me doesn't necessarily work [00:35:00] for everybody. So that part of me says, okay, yeah, maybe this should work. But the other part I'm not quite sure about is just like is it possible in every environment where teams are disempowered? .

The basics/foundations for a high-performance team [00:35:11]

There are some basics that you need to have in order to have a chance of being a high-performance team or a successful team. Without those basics, yeah, with survivorship bias, you can find one team that managed to, against all odds, to succeed without those basics. But we can't really bank on that. 对。 Because we have one life, we have, you know, we are single threaded. We can't run a hundred simulations and then just pick the winning simulation. 对。 Or even like thread, like do three jobs on a given day. 对。 And see which one, see which one worked out better. And just like, uh….

John Cutler: A multivariate job experiment. 这是真的

Shreyas Doshi: So, so we can't do that. So, you know, any kind of like, oh, there's all these problems and they, yet we succeeded. So learn from us. 对。 Like there's very little to learn from that in my opinion. Because you're so single-threaded as a team, as a person, as a company it makes sense to just make bets that have a high expected value.

So let's assume that the basics are met. And what are some examples of basics that you have the right people in the right roles as an example, Right. It doesn't have to be the world's best people doing whatever, but at least there is some match to what the job is, and the people, who are supposed to do the job, as one thing.

You might even put a certain bar of empowerment. It doesn't necessarily have to be the highest empowered team ever. Because like that could have its own issues. But like a certain bar of empowerment. So anyway, you can make up some reasonable basics around, okay, any team or any situation needs to satisfy these basics, for it to have a shot at creating something that makes an impact, creating something that's remarkable.

好的。 Now that these basics are covered, what's next? What do we need to do to increase the probability that we can meet our potential as a team? You know, as a thinker I have been thinking a little bit about a lot of my writing and what the general theme is. And one of the themes that I've been able to extract after the fact, is that really I'm trying to answer the following question in many different ways.

Why do teams with the basics met produce poor products? [00:37:31]

And the question is why do smart teams with sufficient resources– by resources I mean, money, all of that, right, not number of people necessarily– so why do smart teams with sufficient resources still produce mediocre or poor products? The current environment, again, sort of certainly you know, with startups and high growth tech companies, is that we all like to think we have smart teams. In this current funding environment, we do have somewhat sufficient resources in most cases, perhaps too many resources in some cases, and yet, many teams are not as successful as they ought to be.

And so why does that happen? 对？ I don't think I've answered that question just for myself. First trying to do this for myself, and then for everybody else. But I think the answer lies in a lot of different things that we just talked about. Around, oh, you know, one of the aspects of success is understanding the truth.

A lot of this goes back to things like decision-making, how do you collect inputs, how do you determine outputs? How do you get to those outputs? And then what are the right outcomes for us to achieve? Are we being sufficiently both logical and creative about how we get there?

I don't have an answer to sort of like the overall question of what distinguishes, you know, either poorly performing teams or high-performing teams and how are they different. I like to think about it as like, you know, this concept of assuming the basics are met, what needs to happen in order to maximize chances of success? And that's where I think context also plays a pretty large role.

Intentionality and stubbornness (with the company you want to be) [00:39:24]


John Cutler: What I've observed, at least in some of the companies that I admire the most is that someone is around who is just really stubborn about something, you know. They are stubborn about maybe engineering quality, or they're stubborn about connecting with customers. So anyway, that's, I'm offering that up as maybe an area that I'm looking into. That's what I've been thinking a lot about lately is stubbornness. We should connect our threads of research on this because I think it'd be interesting.

Shreyas Doshi: Yeah. I want to take that and do a live mashup of what you're talking about, uh, with this other idea that I [00:40:00] often bring up in conversations with startups, particularly as they're kind of starting to think about scaling that product development efforts. As they're thinking of adding product management. One of the questions I will often ask is what type of company do you want to create? Concretely. This is in the context of, you know, oh, I'm looking to scale my engineering team, looking to scale my product management. And I ask people to be quite intentional about what type of company you want to…

John Cutler: Because it's easy to give non-answers to that. I've heard a lot of non answers to that question.

Shreyas Doshi: Yes. And as it pertains to product work, right? Like what is going to be your focus? So that's one way to look at it. Do you want to be a customer focused company? Do you want to be an infrastructure focused company? Do you want to be a growth focused company? Do you want to be a product focus company?

Do you want to be a sales focused company…

John Cutler: I want it all…

Shreyas Doshi: And exactly, right!

Like, so that's what people say quite a bit. But then they start getting it, which is like, oh Yeah, Okay. I like, I need to be like, as a founder, my company is my product. And so I need to be quite opinionated or stubborn– so, this is where I'm connecting to your stubbornness– about what I want to create.

Because what happens is you, you can't have it all. And if you're not intentional about it, you are focused on something it's just, you don't know what it is and then there's confusion, right. Like for yourself and for others. And so you take examples, right? It takes time to go through this conversation because, you know, it's, it's an odd

John Cutler: It starts out very high level too. It's like…

Shreyas Doshi: Right, it's, it's very high level…

约翰卡特勒： ……然后你必须走开去喝杯咖啡，等等，我们需要再往下走。

Shreyas Doshi：好的。 对。 而且，就像我观察到的那样，在 30 分钟内，20 分钟内 10 分钟内，对于创始人来说通常是一个灯泡时刻。 因为创始人通常也非常接近他们想做的事情。 因此，这也是其中之一，提出问题是主要的增值不一定是答案。

但如果你举个例子，就会更清楚，以谷歌为例，当然，在我在那里的那段时间里，大约是 10 年、10 年左右，它是一家非常专注于基础设施的公司。 那是他们隐含的焦点。 当我与一位工程师交谈时，我说，这就是用户需要的，我们应该如何构建它？ 答案是，哦，这很有趣。 这是一个了不起的问题。 我将不得不建立这个后端基础设施。 我需要六个月的时间来构建这个后端基础设施。 然后您将拥有此功能。 作为一个产品人员，当然，我会去等待，但这听起来很长一段时间，这不是一个巨大的功能。

比如，不，不，不。 这就是我们做事的方式，对吧？ 比如，我们需要有基础设施。 同样，没有错误或正确的选择。 我也想指出这一点。 对。 就像，你知道，你有 Facebook，这是一家非常，至少在我看来，从外部和与我交谈过的人看来，它是一家非常注重指标的公司。

他们根据主要移动指标的因素做出决策。 这就是为什么谷歌和 Facebook 的运作方式截然不同。 在内部，由于这种关注，它们的运作方式非常不同。

做出简单的选择是哦，我们希望以客户为中心。 然后我必须提醒人们，好吧，如果你是，如果你说你想成为一家以客户为中心的公司，但你正在销售企业软件，知道随着时间的推移，你实际上会成为一个以销售为中心的公司。 再一次，有一些非常成功的公司以销售为重点的例子。

所以，我并不是说这一定是一个错误的选择。 但只要有意识地去做，再把它与你的固执点联系起来，这是看待事物的一种方式，对吧？ 就像，这就是我们做事的方式。 我知道这听起来比应该的更消极，或者这对我们有用，对吧？ 这适用于我们拥有的文化。 这适用于我们雇用的人员和技能等。 这可能非常强大，特别是如果你是故意的。

分析和创造性的情报 [00:44:14]


约翰卡特勒：在我们的谈话中，有几次你提到了分析这个词。 然后你谈到了替代方案，也许是一种创造性的智慧。 你能深入研究一下吗？

具体来说，我正在考虑我的日常工作，我们考虑测量。 我观察到的一件事是，使用测量来控制人、控制叙述或获得完美答案与使用测量来学习之间存在巨大差异。 他们感觉非常非常不同。

你心目中的分析智能和创造性智能有什么区别？

Shreyas Doshi：从根本上说，他们建立在彼此之上。

然而，大多数业内人士并不这么认为。 而且我认为各个公司的实践，包括非常成功的 [00:45:00] 公司，往往往往认为一个比另一个更好。 通常——而且，我的背景很多来自，你知道的，基于山谷的公司或类似山谷的公司，无论它们在地理上的什么地方——不知何故，我们倾向于将分析原因视为极其重要和正确的。

我们倾向于打折产品创意，我们倾向于打折直觉和判断力以及其他各种方面

约翰卡特勒：有二元性，对吧？ 就像我们也很炒作人的本能，某些人的本能起来，但我明白你的意思。

Shreyas Doshi：是的。 所以这是一个有趣的问题，我认为，它又回到了核心问题，例如，为什么拥有足够资源的聪明团队仍然生产平庸或糟糕的产品。 我们忘记的是，许多团队和许多公司文化让人们很难想出创意。 再一次，在整体上非常成功的公司中。

很多这些从哪里开始？ 它从会议开始，对吧？ 因此，您可以像任何级别一样参加典型的产品会议。 你会发现，在大多数这样的公司里，如果你展示五张不同的图表，你会觉得自己更有能力。 你展示了几张桌子。 然后是一些定性的见解。 然后你说，因此这就是需要发生的事情。 我不认为这有什么问题。 对。

但是，这种方法和这种心态会发生什么，因此，你的结论或建议实际上是相当受限制的。 他们在这个盒子里。 你不知道它们实际上就像在这个盒子里。 但他们是，对吧？ 现在，如果你以同样的方式允许创造性智能，会发生什么结论会包含一些古怪的想法，对吧？ 就像不严格从数据中得出的东西，无论是定性的还是定量的。 也许它甚至在那个信封里，哦，我们对此没有强烈的信念，但我们应该试试这个。 再次，在会议中，召开产品审查会议，产品经理在提出创意时会感到困惑或奇怪的表情。

或者任何人，我只是选择产品经理作为一个角色，但工程师或任何人。 第二件事，他们可能会在事后从喜欢的经理那里得到反馈——而且它的框架方式不是那么多，不要带来创造性的想法，因为没有人愿意这么说——就像，你需要用数据备份您的提案。

你需要更好地支持事情，这就是我作为经理给你的反馈，对吧？ 即使在非常成功的公司中，这种现象也经常发生。 这阻碍了团队能够创造出真正实现潜力的产品，呃……。

约翰卡特勒：最近有人说我们公司的河马决策太多了。 我们必须使用数据，对吗？ 我们必须使用数据让河马离开。 然后我说，好吧，当你有一个直觉的想法时会发生什么？

他们说，好吧，好吧，当然，你知道，我们当然会使用相同的方法。 我们必须拥有所有数据才能做到这一点。 我当时想，看，你的问题不是河马。 因为最终你会想要有创造性的想法。

如果你只有一个想法，那就太可怕了。 如果你有 50 个想法，那简直就是瘫痪。 你可能有三个？ 我的朋友丹诺斯说，不，你想要七个。 因为第一个，第一个是你的想法，第二个二三四个想法基本支持你的想法。 所以你想要七个，因为在第四个，第五个，第六个和第七个是你走出舒适区的时候

影响级别、执行级别和光学级别 [00:49:13]

Shreyas Doshi：是的。 我认为一个框架是一个非常基本的框架，它跨越了大多数产品环境，当然还有我遇到的所有产品环境，我认为我们需要更好地认识它，这就是我所说的产品工作的基本框架。

所以我们做所有这些产品的工作，对吧？ 我们应该如何思考这个问题？ 我们如何看待这款产品的工作原理？ 我最近的见解是产品工作分为三个层次。 有影响水平。 有执行级别。 然后是光学级别。 产品团队、产品文化中的许多挑战 [00:50:00] 是因为我们讨论的级别不匹配或误解。 或者我们运营的水平。

通常，您会发现团队中的一个人在影响级别上进行操作和思考。 另一个人在执行层面上思考。 但他们不是在谈论那个。 他们正在就局势的细节提起诉讼，对吗？ 所以一个典型的例子是一个非常努力工作的PM。 可以这么说，在执行级别操作的 PM 非常努力地工作。

他们没有得到很好的牌，但他们创造了这个产品，对吧？ 就像产品是现实一样。 他们很开心。 团队很高兴。 工程、产品管理、设计、数据科学，所有这些都是，从事核心产品工作的人，对他们构建的东西感到非常兴奋。

对。 他们会把它带到你的执行审查，对。 或发布评论。 当然，发布审查中涉及一些演示。 再说一次，这些策略是如何同步或异步完成的。 关键是它得到了审查。 你有一个产品主管，他在影响级别上运作。 所以产品主管看着产品，基本信息是这还不够好。

约翰·卡特勒：威胁表开火了。

Shreyas Doshi：皮质醇水平上升。

约翰卡特勒： ……增加……

Shreyas Doshi： PM 很沮丧，也许 PM 经理也很困惑。 你能想象我们为了到达这里而必须解决的所有困难吗？ 我们应该被允许启动它。 我知道这就是所有这些缺陷，但不，不，不，不。 我们应该被允许启动它。

所以这里的问题是高管——他们在影响层面上运作，他们正在考虑以这种质量推出产品对品牌的影响，也就是说，低于他们所拥有的标准. 这是一个有趣的情况，因为人们立即开始谈论修复，对吧？

这就像，哦，你知道，也许我们改变了这件事或第二件事——再说一遍，所有这些都很重要——但首先要认识到这种不匹配。 我还要说，这对 PM、工程主管或设计主管来说会很困难。 那里的人很难标记这一点，对，就像从心理安全的角度来看一样。

因此，管理人员可以更好地运作的方式，这适用于所有级别的人员，是认识到为什么团队为他们所做的事情感到自豪，他们实际上是在逆境中执行的。 而且，他们正在那个执行级别上运行。 然后明确地喊出来——而不是喜欢，啊，这不够好，或者这不符合标准或其他——这在执行层面上很好，这在影响层面上不足，我们如何才能达到你知道，这里有更好的结果吗？

作为示例的一部分，我要说的最后一件事是，您会发现在许多地方，人们在进行产品工作时都在优化光学级别。 CEO、创始人或有权有势的高管想出一种本能或一些创造性的想法，人们就会狼吞虎咽。 对？ 鲍勃这么说，所以让我们继续努力吧，因为就像，这真的是……

约翰卡特勒： ……他们非常果断。 就像，好吧，他们当然是决定性的。 他们是 CEO，你们都在听他们的。

Shreyas Doshi：然后另一件事就像边谈话一样，通常，是的，我认为这不会奏效。 但是就像，这就是 Bob 想要的，所以我们要这样做。 顺便说一句，它并不总是必须自上而下。 对？ 就像它有时也是相反的方向。 对？ 你建造了一些东西，并且为了管理光学，你有点把它定为比实际更成功。

所以我并不是说光学不好。 实际上，您确实需要管理一定数量的光学器件，这样您才能忠实地表达您的工作的影响和执行的质量。 光学层面应该有助于其他两个层面。 所以你需要在那里做足够的工作。 但是有许多团队主要针对光学进行优化。

人们谈论激励措施以及人们将如何基本上遵循激励措施。 等等。 我不使用激励语言。 我认为这里更基本的问题是，您的文化和您的组织在多大程度上迫使人们对光学进行管理，而不是对执行进行管理，或对影响进行管理。

认知偏差和共享词汇 [00:54:37]

约翰卡特勒：所以我与认知偏见世界的旅程的一部分，因为我在某个时候超级喜欢它。 我开始尝试研究我们有效抵消认知偏见的方法，即使我们知道它。 每次遇到沉没成本谬误时，它对我打击沉没成本谬误的能力并没有太大帮助。 你看到了什么不起作用，你看到了什么在试图抵消这些事情方面 [00:55:00] 起作用？

Shreyas Doshi：所以我认为这是关于你为团队创造的共享词汇。 而且我认为共享词汇只是另一个比认知偏见更广泛的话题，我认为这非常重要。

如果你想让你的团队更健康，或者更健康，也许想想你的团队围绕你所做的工作共享的词汇是什么？ 我指的不仅仅是行业流行语，如 Scrum 或其他任何东西，对吧？ 就像，我的意思是，不，不，不。 什么是您没有将其视为标准产品管理文献的一部分，但您将与团队分享的词汇。 为什么这在认知偏见的背景下有效，有人很难说鲍勃，你正在成为沉没成本谬误的牺牲品，或者可用性启发式，或者你有什么。 在大多数组织中，很难有人能够……

约翰卡特勒： ……你说的不是标准的票价会议谈话，这不像，谢谢，是的，我想指出沉没成本谬误……缩放会议很快就关闭了。 如果那个人开始……

Shreyas Doshi：没错！ 呃，就像，哦，这个人不适合与人相处。 管他呢。 对。 就像人们得到...

约翰卡特勒： ……他们读了太多的书。 呃，

Shreyas Doshi：他们被分配了标签。 所以我认为让人们知道这一点很重要。 这就是为什么我不谈论个人认知偏见的原因。 我通常在团队层面谈论我们的认知偏见。 对。 因为这样就更容易进行类似的对话，作为一个团队，这可能发生在我们身上。 我们可能会成为执行导向谬误的牺牲品。 这是我们决定做一些我们知道很容易执行的事情的地方，即使它可能不是合适的团队来执行，但它让我们对开始感到满意。 以及创造某些东西的满足感。

一旦你让所有人都知道，其次作为领导者——我要说的话的责任完全在领导者身上——就是说，看，我会成为这个的牺牲品。 作为一个群体，我们可能会成为这个的牺牲品。 我只是想设定我们将讨论这个的期望。 当我们看到这种情况发生时，我们会标记它。

如果我们标记这一点，这不是一个弱点。 它实际上是相反的。 我们能够了解真正发生的事情，并可能做出更好的决定或得出更好的结论。 所以我认为共享词汇，然后我刚才说的是共享责任

我通常讨厌问责这个词，但这完全是一个单独的话题。 但我确实喜欢在这种情况下，这是一种作为一个团队的共同责任，围绕着彼此提醒，并作为一个团队提醒我们自己，关于我们可能犯的错误。 或者我们可能缺乏清晰度。

举个例子，我最近在做这个项目，这是一个非常雄心勃勃的项目，有很多未知数。 我预先与团队分享了，实际上在这种情况下，我分享了两件事。 一个与认知偏见有关，也就是说，你知道，我们很可能会成为这些、这些、这些认知偏见或团队认知偏见的牺牲品。

所以让我们注意这些。 我标记的第二件事也是——细节并不重要，但这是一种非常复杂的情况，涉及多个团队，而且这些团队之间的合作并不多。 他们有点像第一次工作。

所以我和他们分享了阻碍我们前进的主要事情之一，就是我们不会直接和彼此开放，尤其是跨越这些团队边界。 与我们犯的任何分析错误相比，这很可能会导致该项目无法成功。

我对那个小组说得更清楚了。 我更关心的是我们能否很好地合作，彼此直接，了解彼此的观点，然后是其他任何事情。 我们正在谈论的任何其他类型的分析事物，例如，哦，我们如何在这个有限的空间内适应这三个导航选项或其他什么。 这不会决定我们的成功。 决定我们成功的因素是我们是否愿意就这些事情彼此进行艰苦的对话？ 我们愿意倾听彼此和彼此的观点吗？ 我喜欢的另一个策略是，我也指出，我还想说，也许你认为这是一个愚蠢的对话，因为它非常蓬松，对吧？

好像它不是分析的东西。 但是，如果您这么想，那么我的 [01:00:00] 请求是请实际与我谈谈这件事。 我们都需要彼此敞开心扉。 如果你发现这不是对时间的有用利用，那么这就是你需要真正向我敞开心扉的第一件事。 所以…

John Cutler：你已经预料到他们会怀疑你敦促他们……我喜欢它！

Shreyas Doshi：是的。

约翰卡特勒：基本上，你试图在这里覆盖你所有的基地。

Shreyas Doshi：在这种情况下我必须做的另一件事是，因为我没有与我们将要合作的一些团队成员一起工作，然后我设置你知道，一对一与一些关键团队成员一起，再次强调这一点。 就像，看，这是我作为团队负责人关心的问题。

并且通常要充分了解他们，以便他们能够在事情不顺利时感到有能力和代理来开放和分享。 所以，你知道，这是一个违反默认值的例子。 一般来说，我会避免这些定期的一对一签到，对吧？ 我们只是不断添加，在某些范围内，它会接管您的日历。

约翰卡特勒：如果你在过去五年里每周都这样做，你就不会交到很多朋友。 我认为这个答案最精彩的部分是当人们了解认知偏见时，这太疯狂了。 他们所做的是他们总是喜欢，嗯，这解释了其他人的疯狂行为。 啊哈。 现在我知道为什么高管们会这样行事。 就像每个人一样，在考虑认知偏见时，每个人都会经历基本的归因偏见，对吧？

Shreyas Doshi：我认为如果你不想相信——如果作为个人或团队，你不想相信大多数认知偏见——也许没关系。 只要你坚信两个：确认偏差和基本归因偏差。

将仪表板视为产品 [01:01:51]

约翰卡特勒：是的！

换档只是一点点，我想问你这个问题已经很久了。 您曾经将仪表板视为产品。 那个想法的灵感是什么？

Shreyas Doshi：这是我多年来对如何使用仪表板所做的一些不同观察的集合。 以及人们（产品团队）一般如何看待仪表板。

约翰卡特勒： ……我们正在谈论的高度分析的人。

Shreyas Doshi：是的。 就像，哦。 你应该有一个仪表板。 很好，我会有一个仪表板。 因此，让我分享一下我在此过程中所做的一些观察。

首先，有许多 PRD 是关于一个重要的功能或产品的，它们没有涵盖仪表板对于这个功能或产品的外观。 没关系。 就像，我要的不是这里的详细模型。

给我看一个项目符号列表，对吧？ 就像这里是我们要跟踪的指标以了解使用指标，例如，这个功能是如何使用的？ 用户在用这个做什么？ 第二个是影响。 有时会非常关注影响指标，而对使用指标的关注不够。

约翰卡特勒：当然。

Shreyas Doshi：但是就像，我会争辩说……

John Cutler：不要把它称为成功的标准。 因为再谈心理安全！ 这一切都在那个时候完成了。 关键绩效指标，你知道的，它是……

Shreyas Doshi：是的。

约翰卡特勒： ……在这一点上没关系。

Shreyas Doshi：同样，词汇非常重要。 这是一个很好的观点。 它需要由产品经理或执行该角色的任何人拥有。

John Cutler：你需要大量的领域知识才能做到这一点，对吧……

Shreyas Doshi：对。

约翰·卡特勒： ……这种用法有其独特性。

Shreyas Doshi：大多数团队都有另一类指标，即健康指标。 因为通常工程团队会确保他们拥有正确的仪器和正确的仪表板。

这是第一个观察结果，我们没有充分说明这一点。 对。 所以第二件事是让我们假设一个团队确实指定了它，仪表板或一些指标电子邮件，我不在乎它是什么。 就像建造了一些东西，现在开始让你深入了解重要的事情。 人们如何使用它，采用率如何，影响如何，就是这样，很棒。

我所做的第二个观察是没有人在看那个仪表板。

John Cutler：我可以根据提供这些工具之一的人来证实这种动态，其中很多工具就像倒在森林里的树。 有仪表板的墓地。 让我们这样说吧。

Shreyas Doshi：当然。 如果这是您和您的团队，请不要难过。 这是我在不同点遇到的 90%。 对。 是的。 我们已经花费了所有这些精力来创建这个仪表板。 几乎没有人在看它。

所以，这是第二种观察。 当我注意到这一点时，我意识到，哦，等一下。 我们没有对我们的指标仪表板做任何事情，[01:05:00] 我们所说的对我们的产品做正确的事情。 所以这里有某种自我参照。 也就是说，你知道，如果我们构建一个产品，你清楚地知道正确的做法是跟踪它的使用情况、跟踪指标等等。

因此，如果您正在查看仪表板，它可以让您深入了解您的产品，为什么不将其视为产品本身。 并跟踪仪表板的使用指标。 例如，像一个简单的计数器。 有多少人查看了我们在过去一周花费大量时间创建的这个仪表板。

对？ 就这么简单，只是一个视图计数，作为一个例子。 然后你可以看看，哦，等一下，实际上没有人在看指标。 这样就产生了两种可能性。 一是它在洞察力或决策方面没有用。 或者有一些问题，对，就像我们一样，我们需要解决。 但是，只有将其视为产品，您才能开始这样做，对吗？

当然，一旦您开始将仪表板视为产品，您就会为仪表板创建需求，并使其成为原始 PRD 的一部分。 就像，这就是我们需要跟踪的。 这就是为什么我们需要跟踪它。 这就是我们将如何跟踪它。 然后，您显然会以您了解其用途等的方式在仪表板中进行检测。

我要说的最后一部分是，所有这一切的很大一部分都不是意图或能力或其他任何东西。 我不认为这是因为人们无能导致这些事情发生。 我认为这是因为它很难。 我认为它实际上就像摩擦一样简单，对吧？ 这是您在忙碌的一天中必须考虑的另一件事。 你知道这是正确的做法。 每隔一段时间喜欢查看您的使用指标。 或者至少在您做出下一个决定时参考他们。

但是有摩擦。 您必须管理认知负荷。 所以现在，再次将其视为一种产品，您现在可以开始考虑如何消除摩擦？ 因为这就是我们在自己的产品中所做的，对吧？ 就像我们考虑什么是用户摩擦以及我们如何消除它？

这导致了有趣的可能性。 就像我多年来的一个习惯一样，在这一点上，我在 Chrome 中有我的 pin 标签。 我有我的电子邮件、我的 Slack 和我的日历，它们是固定的。 固定的另一件事是我的主要指标仪表板。 所以它就在那里。 我不必打开新标签，输入任何 URL，它就在那里。 我注意到的另一件事是人们喜欢电子邮件指标。 为什么？ 因为它消除了摩擦，对吧？ 它只是出现。 我们至少与自己签订了​​这种合同，我们应该查看电子邮件。 所以最终发生的事情是，人们更关注通过电子邮件发送的指标，而不是他们必须主动寻找的指标。

所以很多时候对于重要的项目，我会说，哦，你知道的，让我们也发送一封摘要电子邮件。 它可以像一些预告片高级统计数据一样简单，并且只是指向仪表板的链接。 即使是通过电子邮件发送给您的链接也会让您更轻松，并消除摩擦。 与必须考虑并做到这一点相比。

充实的日历、反应性、自我认同和积极/消极的习惯 [01:08:20]


John Cutler：当你看到这些人的日历时，你会看到这些 PM 一直处于被动模式。 他们甚至没有时间考虑这些事情。 你给他们的第一条建议是什么？ 他们是如何统治这一切的？

Shreyas Doshi：我在 PM 职业生涯的前五年一直处于极度压力之下，并且一直处于相当程度的守势。 我需要确保事情不会分崩离析。 这就是我正在做的所有事情，这占用了我所有的精力。 当然，我认为其中很大一部分是我在这个角色上的能力可能要差得多。 所以事情过去需要我更长的时间，等等。 所以我不想打折扣，你知道，有一条学习曲线，这条学习曲线是有成本的。 这是每个人都需要经历的旅程。 对。 所以。 是的。

我认为这不一定是一件坏事。 你使用习惯这个词，我认为这就是问题所在。 之所以会发生这种情况，是因为这些早年，我们作为产品经理的成长期，我们养成了某些习惯。 假设，就像，我们实际上相当擅长我们正在做的事情，我们会看到成功。 所以你肯定会想，好吧，是的，我似乎在做正确的事情。 所以我应该做更多这些事情。 每周与团队中的每个工程师进行一对一的交流确实很有帮助，与他们一起检查正在发生的事情，然后在个人层面上与他们建立联系，等等。 所以我会做越来越多的事情。 伟大的。 当您的团队中有 10 名工程师时，它会起作用，现在您有更多的范围。 现在有 20 个，然后是 30 个。 [01:10:00] 什么，你做什么？

约翰卡特勒：对吧？ 与此同时，他们为自己感到自豪，自我认同，因为与每一位工程师都有如此良好的关系。 一对一的黑洞……

Shreyas Doshi：是的。 所以约翰一世，我认为这引发了一些有趣的事情，也就是说，我认为这可能是两件事。 这是它的习惯和身份。 这就是我。 这就是我做事的方式，对吧。 哦，你说的那个东西，还是这个人说的那个东西？

不，不，不，不，这对我不起作用。 对。 就像我不一样。 这就是我的身份，这就是我的运作方式。 所以有习惯和身份。 而且我一直看到，人们只是处于完全无法控制的情况。 他们不知道该怎么做。

他们只是认为事情就是这样。 有时他们的经理会告诉他们，是的，这就是 PM 的工作。 看看我的日历，更糟！ 然后还有一点比较，就像，哦，谁的日历更差。 就像，那个人更像是一个PM，对吧？

由于习惯和身份问题，这很难。 人们很难接受这里有一条替代路径。 如果你想想观众，他们在听这个，无论何时发布。 肯定会有一群人会说，是的，这里讨论的任何内容都不适用于我的情况。 它不适用于我的公司，因为我的老板，因为这个原因，因为我的团队不同，因为无论我不同，我都有更宏大的抱负，无论如何。 所以，你知道，我想说的是，除非你接受实际上有更好的方法，否则这是无法解决的。

你必须明白你想解决这个问题，而不是认为这就是它的方式。 But once you start entertaining that thought, that there are other ways that this problem can be solved or at least should be mitigated, now we can talk. 对？ So now we are at a smaller part of the audience that is really stressed, but it's perhaps more open to sort of exploring those ways.

And then what I would say this goes back to the role of a product manager and particularly the role of a product leader. Remember we talked about building self managing teams. 对。 Well, what happens when you actually build self managing teams? You have to do less management, right? Because they're self managing. That's sort of the goal. Now, it doesn't solve the problem because how do we get to the goal?

The way one needs to think about these situations is you know, yes, I can stay on top of everything. And you know, in some cases, like we talked about, the context requires you to stay on top of everything. But, you don't have to make that your default, and you don't have to do it in every single situation.

So one of the things I like to tell, especially new managers, is assume there are things you are not going to be on top of. Because then you will have to go to every single meeting. You'll have to accept every single input in order to, sort of, figure out what to do.

So assume that's not going to happen. And what you need to do is to figure out ways in which now you're going to get those inputs through people on your team. And you are going to organize your one-on-ones in a way that you're able to get those inputs. You're, uh, you're going to organize rituals on your team, whether it's product reviews, or other rituals on execution check-ins or what have you, in order to get the right signal .

This is all easy for me to say, but it is hard to do, and it requires practice. And it requires trying to identify your unique style of doing it, et cetera, et cetera. But the beautiful part, when you cannot like, do this, and do this with some degree of success, is now all of a sudden you are able to be much more useful, and much more effective, right?

You are able to get more clearly to the thing that matters, right? You are able to help your team members. You are kind of like coaching them through experience around expressing to you the stuff that matters. 对。 And then you are able to also give them the independence, and the leeway, to be able to operate on their own versus kind of handling them through all of this.

Improving the current situation (and gap vs. present thinking) [01:14:24]

So, concretely, the common sort of argument I hear is yeah, yeah, things are horrible right now, but it's because I don't have a full team. Like I have this four or five head count. Once I get these people, and get them to be productive, things will be better. And guess what happens? You get those four or five engineers on the team, or four or five PMs on the team if you're a PM manager. Situation is worse, not better. But at that time, it's like, oh, you know the problem is we are not organized properly. My team should not [01:15:00] belong to this organization. It should be in this other part of this organization. And that's what's creating the problem for me. You know, so it's like this, kind of, basically we are on the treadmill forever right?

I'm not discounting the validity of these reasons. What I am suggesting is that regardless of external factors, which we should try to improve, and we should feel high agency towards making the organization better, and improving whatever situation we are in. But we need to also be very cognizant of how I can best manage the current situation I'm in. Versus like, basically I noticed that especially the managers and product managers that tend to get extremely stressed, and let the work affect all parts of their personal lives and whatnot is… they're constantly looking for the next thing that is outside of them that's going to fix this issue. And then that results in burnout, that results in frustration when it doesn't happen. And they don't pay enough attention to, okay, given this current situation, what do I need to do differently?

John Cutler: My friend Jabe Bloom has this interesting thing, which is gap thinking versus present thinking. And he makes the point that standard business school, standard consulting is all about the gap. What's the current thing? Exactly where do we need to go? How are we going to get across that particular gap?

Like that's a very tried and true way to think about it. And then he presents this other idea that present thinking is not adverse to thinking ahead. It's like, what's going on right now? What do we visualize as the better version of right now? Where do I have agency to act right now? Instead of just the gap, you know, it's like there and you have to go across it. It's kind of like little mini gaps, right. But the one part, the one thing you said that really resonates there is, you know, in some ways, as humans by, gap thinking is always a way to also “other” the problem.

It's the tendency of people to combine gap thinking with fundamental attribution bias, which is like, not only is there a big gap that we need to get across and there's the perfect plan to get across it. But the road involves other things in the org that have to happen, et cetera, to make it to it.

So I don't know if that's, I've liked that distinction between gap thinking and present thinking. One thing that's hard is that a good chunk of modern business is centered around gap thinking. What's the gap, bring me solutions, not problems, you know, like how are we going to get across the gap all the time? 所以…

Shreyas Doshi: Yeah, that resonates a lot. One other thing I want to share around this topic of PM stress and this constant feeling of inadequacy, and I'm not doing enough to move the product forward, and and my schedule is crazy, and I'm just not able to perform at the level I need to et cetera, et cetera. All of which, by the way, again, a common theme is this was me for the first five PM career. And I used to share all of this with my wife all the time and like, you know, huge kudos to her to just like, listen…

John Cutler: She taught you how to listen…

LNO: Leverage, Neutral, and Overhead Tasks [01:18:10]

Shreyas Doshi: Exactly. So I think one key thing that was a turning point for me was the understanding of —uh, and I don't even know where I read it, it was some blog posts that I read and what I'm about to share is a paraphrasing of that, I can't find the blog post anymore for whatever reason— but it's what I termed as the LNO framework for PM effectiveness. Which is the observation that there are three kinds of tasks that I tend to do as a PM.

There's a leverage task, there's a neutral task, and then there's an overhead task. The leverage task, you know, as the name suggests, gives greater than what you put in. The neutral task will give you the same. And the overhead tasks will give you less. What most PMs do, and certainly what I did during those highly stressful days of my career as a PM, was I approached every task, any given task in the same way. Which is, oh, I'm going to try to do an awesome job. I was like some, you know, inner perfectionist, et cetera, et cetera. So I would spend a ton of time without understanding whether this is a leverage task, a neutral task, or an overhead task, right?

And, and what's right for the company you work for– and certainly for your team and very likely for you– is for you to understand that upfront. And then, you know, adjust the amount of energy and the amount of time based on that understanding. And I think what that does is, it certainly did for me, is it means spending more time and exerting more energy on certain things.

Because now you understand that this is a leveraged task. So instead of spending two hours on writing that, you know, completing that PRD, maybe you ought to spend four hours today to do that. Now of course, that extra two hours have to come from somewhere else. So find out [01:20:00] what are your neutral tasks or overhead tasks.

And so one example of, you know, usually a neutral, sometimes an overhead task, is you will get some requests for certain reports from finance, like, what's our 24 month projection for how the product is going to– like how much headcount do you need or whatever. Now, you know, I look at those things and, you know, there's the perfect way of doing it. And I see all these sometimes PM leaders, especially going to these meetings, and talk about all the analytical stuff of what's going to happen in September of 2022. And, November of 2023. And people are having all these discussions. Again, it goes back to, oh, we think we, we have certainty around what's going to happen.

They end up spending a ton of time on all of these things. And, what I typically do is like, again, usually– you know, sometimes it's an exception– but usually when I get these requests, I get them done in five, 10 minutes. 对。

Like these, these are the assumptions. 干得好。 And if you need something more detailed, then please let me know how this is going to materially change, you know, things from a budgeting perspective or something else.

So that's just an example of where you kind of get back that time. And what I found is that as I started doing more and more of this, and on a tactical level what I would do is I created the to-do list, I would actually prefix the task just as a reminder to myself with L, N, or O .Right?

So when I started doing the task, I was like, okay, this is a leveraged as to how I'm going to approach

Conclusion [01:21:23]

John Cutler: I love that. I love ending with something really actionable. And so that's something that I'm going to do with the rest of my day too. To do these things. But, Shreyas, I wanted to thank you. We could have gone on for hours cause there's just so much, uh, so many questions I have. And I'm amazed too, about your ability to weave in and out your frameworks too. So you've actually inspired me thinking about how to be more actionable in these types of conversations. Because you've left people with specific frameworks, but we also went really deep into everything about intentionality, and culture, and stuff. So I really, really appreciate it.

And I'm super grateful for the opportunity to chat with you. And yeah, we'll stop now. But we should do it again at some point. Maybe people will have questions. Maybe we could do a follow-up like rapid fire, uh, answers to those questions if that would work for you.

Shreyas Doshi: Yeah, I would love that this was a blast. 你是对的。 We could have gone on for hours and this is fun stuff. 所以谢谢你。

John Cutler: I want to leave people with that one thing that Shreyas opened with. We've both probably learned the hard way. So when you see us tweeting assume that we've made the mistake 55 times, and we've had to work through it, context always matters, that would probably be like a footnote on those things. And three, I loved your statement too. You know, if you're in an unhealthy environment, you know, don't just assume you can just jump in. I think taking care of yourself, that's my theme, you know, as the tail end of the pandemic, is that people need to take care of themselves too.

Product Analytics for Dummies