David Meyer：产品管理、客户好奇心与团队建设

David Meyer 接受过土木和核工程培训，后来加入 Plumtree Software。他从质量保证转到工程岗位，随后一位经常受到他批评的同事推荐他负责产品。他起初认为工程工作太重要，不能放弃，但后来发现自己非常喜欢产品工作。

在质量保证岗位上，Meyer 开始调查另一名工程师代码中的缺陷。对方阻止他访问源代码管理系统后，Meyer 向 CEO 反映此事，CEO 解雇了那名工程师，并让 Meyer 来写代码。回头看，Meyer 承认批评一份自己从未做过的工作比亲自做容易。

Meyer 认为，如果不知道所谓不可能的事情能激发好奇心，那就是一种优势。Harry Stebbings 举了自己的例子：如果当初知道培养受众需要那么久，他可能早就放弃了。两人都认为，在没有完全意识到障碍的情况下仍愿意解决问题，可能是有益的。

Meyer 说，与满意的客户相比，不满的客户有时更值得会面：具体问题能提供理解和重新思考工作的机会。他首先不断提问，直到了解对方的工作、采取的步骤和真正想要的结果，而不是把每个提出的步骤都视为必不可少。

客户访谈很难，因为问题可能诱导回答。Meyer 请同事旁听并给予反馈，强调目标是求真，而不是证实自己的判断。即使看似开放的问题也可能引导答案，因此他尝试探索替代方案，而不是只展示演示并向客户灌输观点。

他区分单个客户和整体客户。产品团队应了解某个客户想完成什么，再检验这种需求是否普遍。照搬某一个客户指定的功能，可能让产品过度迎合个例，忽视更广阔的市场。

产品经理必须平衡客户、销售、工程和财务等各方相互冲突的重点。Meyer 开玩笑说，成功的产品经理可能让所有人都不满意：销售觉得长期工作太多，工程则觉得团队追逐交易太多。这个角色与其说是小 CEO，不如说是在可持续生存的前提下寻找可行妥协，逐步迈向愿景。

对于考虑转做产品的人，Meyer 会寻找证据，看他们是否即使没有头衔也忍不住做产品工作。质疑需求的工程师，或持续推动解决客户需求的售前工程师，都可能已经在实践产品管理。他会问候选人在哪里产生过影响，再追问这些影响如何与产品价值相关。

Meyer 说，Databricks 把一项价值观从“数据驱动”改为“求真”，因为人们可以挑选数据来支持几乎任何论点。指标应揭示盲点、促使团队提问，而不是成为目的本身。如果证据推翻了最初假设，正确的反应可能是调整目标。

一个人的初创公司可以持续调整假设；大型组织则必须考虑围绕目标运转的人员和系统。即便如此，Meyer 认为，不能仅因为目标按年制定，就让关乎生存的错误持续存在。他看重的是学习速度，而非单纯的发布速度，其中也包括可能被丢弃的实验。

Meyer 承认自己会反复查看仪表盘，尽管绿色纪录并不会促使他采取行动。他认为更大的浪费在于人们手工汇总无人使用的数字。有用的指标应指向决策并反映愿景；他也承认，任何指标都可能被人为操纵。

日活或周活等使用指标可能更难造假，因为用户要为产品投入宝贵时间。不过 Meyer 提醒，使用本身并不能证明收入模式可行。Stebbings 将订阅人数与更有意义的信号作比较，比如听众听完一集节目的比例，以及他们是否会推荐节目。

Meyer 认为产品管理常常吃力不讨好：产品经理更像幕后工作人员，而不是摇滚明星。他重视好奇心、韧性和可证明的影响力，并提醒人们不要以为在高速成长公司工作就意味着自己创造了增长。一个功能看似成功，可能只是因为它出现在不断扩大的用户面前。

被问及如今的产品经理平均而言是否不如过去时，Meyer 说自己无法确定，但怀疑快速扩张团队会让持续保持质量更难。他说，访谈时 Databricks 约有 6,000 名员工、1,000 名工程师和 100 多名产品人员。随着组织成长，他发现跟上产品变化和维持创新都更难。

Meyer 认为，乐观是打造起初看似不可能之物的核心。他举了 Zipline 用无人机运送医疗物资和人们第一次叫 Uber 的体验为例。创始人必须说服同事加入努力；乐观可以促成行动，但他后来也承认，过度相信自己的愿景存在危险。

为了说服工程师，Meyer 会一起推演某个选择的后果，而不是直接下命令。例如，自定义 API 可能很优雅，却需要说服数千名开发者并建立生态；沿着这个逻辑思考，工程师可能会选择现有标准。他说，这是帮助对方用自己的思维方式理解推理过程。

当团队改变方向时，领导者必须承认人们对自己作品的情感投入。Meyer 说，应明确指出损失并给予时间哀悼，而不是指望他们自行推断工作为何被放弃。他认为，情感也能帮助产品负责人让客户相信未来的可能性。

Meyer 说，自己曾希望同时学习美术和工程，但得知期待中的双学位无法实现，最终选择了工程。如今，他在产品工作和为人解决问题中找到了创造力。他认为工作需要让从事它的人感到振奋。

他认为上线后的观察必不可少：团队花了几个月打造产品，就应关注人们如何使用它。他补充说，发布产品或把它放上网站，并不等于营销；团队必须接触真正有这个问题的人。他也承认，自己没有负责过营销，有时却太快告诉营销人员该怎么做。

Meyer 尝试从同理心出发：一个人可能正受到同事看不见的压力影响，却已尽了当时最大的努力。他不会先假定同事懒惰或犯错，而是询问什么限制或背景解释了这种选择。他经常发现，资源和相互竞争的需求才是行为背后的原因。

被要求划分产品工作中艺术与科学的比例时，他说，如果严谨的系统思考和数据观察已是前提，产品工作可能有 90% 是艺术。如果这些习惯并非自然而然，就需要投入更多有意识的努力。他提醒，复杂模型会制造虚假的确定感：细节丰富并不能证明假设正确。

Meyer 说，自己需要先理解系统，因此可能是个让人抓狂、有时会微观管理的上司。他希望人与人之间的联系能让自己的意图更清楚。Stebbings 认为，领导者应根据接受反馈的人调整方式，而不是使用统一公式；Meyer 同意，人们需要感到自己被看见。

Meyer 说，反馈也应该邀请对方回应。领导者可以坚定地提出所需改变，同时询问为什么对方看起来痛苦或失去投入。如果不了解对方的反应，即使最初的反馈正确，管理者也可能失去这个人。

Meyer 告诉直属下属，如果他们想离开，他会帮助他们寻找好的下一份工作。首先他想知道，他们是想逃离一个他可以修复的问题，还是奔向一个极具吸引力的机会。他承认，组织中与他距离更远的人可能不够了解或信任他，无法坦然接受这一承诺。

他会问同事，自己是否表现得像“海鸥式”管理者：突然飞进会议、批评工作，然后离开。熟悉他的人可能理解其意图，但新产品经理可能有完全不同的感受。他也承认，如果其他人没有认同愿景，他的乐观就可能落空。

字幕在转入产品聚焦话题时存在缺口。在可见的讨论中，Meyer 和 Stebbings 提醒，不要过早扩大目标受众。试图服务所有人的产品，可能失去那些会推荐产品并推动团队突破难题的忠实用户。

服务热情用户的同时让新人也容易上手并不简单。Meyer 建议经常使用产品，理解用户实际的工作流程。一个人要求的功能可能给另一个人增加摩擦，因此参与度或完成任务所需时间等数据，可以揭示复杂性是否造成了损害。

Meyer 反对认为选项越少产品就一定越简单。在 Databricks，他最初注意到视觉上的不一致，但他说开发者更在意执行速度和代码补全。衡量标准是用户能否完成重要工作，而不是界面是否符合新产品经理的审美。

他回忆，一款熟悉的 Atlassian 编辑产品发生变化后，部分脚本功能变得更难使用，这让他感到沮丧。但他仍认为，这种改变扩大了市场。做此类决定时，应清楚自己可能失去哪些人；他说，对 Databricks 而言，开发者仍是愿景的核心。

Meyer 认为，产品评审随着团队使用和测试产品持续发生：核心团队经常看演示，管理层定期评审。创始人可以在早期提供重要背景，但许多创始人一起争论细小的视觉细节也会浪费时间。他希望决策会议的人数足够少，以便坦诚、高效地沟通。

Stebbings 建议以四至六人进行有效决策；Meyer 同意大型会议容易沦为仪式。即使有人远程旁听，也会改变会议氛围，因为简略表达或直白言论可能被误解，再脱离背景传播。具体人数是他们的判断，而非普遍规则。

决策记录很重要，因为信息必须传达给没有参加会议的人。Meyer 说自己不擅长记录和发送笔记，因此与擅长项目管理的人合作对他有帮助。当聪明的团队成员做出糟糕决定时，他首先会问自己是否没有提供必要背景。

招聘时，Meyer 会询问候选人产生的影响，并持续追问，直到理解其背后的系统。对于企业软件，他希望产品经理了解产品如何运作，以及依赖关系如何影响决策。他也会问及困难局面、责任归属，以及过程中是否伤害了其他人。

第一次对话既要尽快识别不合适的候选人，也要让有潜力的人愿意继续交流。Meyer 认为，真正的好奇心能让对方感到被看见。为了测试协作，他喜欢用候选人熟悉的问题做低风险练习，改变一个约束条件，看看对方如何应对。

Stebbings 指出，候选人可能比面试官更了解自己的领域，使薄弱的回答看起来很出色。Meyer 接受这个风险，但认为持续提问可以暴露内部不一致。他关注的是对方如何推理，而不只是成功结果是否归功于自己。

一个招聘错误是，假定在一家公司表现出色的人，在另一家也一定适合。文化和需求各不相同。Meyer 建议组建小型跨职能招聘团队，纳入受尊重的技术和产品人员，以及愿意质疑决定的人，避免领导者的热情影响所有人的判断。

随着产品组织扩大，领导者可能不了解一线员工每天如何使用时间。小小的汇报要求不断累积，最终使人们忙于维护流程，而不是理解客户。Meyer 建议定期参与客户支持，并大致把时间分给客户、产品与工程工作以及思考；他说这是一种理想，而不是实际日程的描述。

他认为销售与工程之间常有摩擦：销售追求近期交易，工程则保护长期一致性。他说，在 Databricks，双方曾都认为对方影响力过大。产品团队可以通过研究客户要求的功能是否是解决根本问题的唯一方式来调解。

第三种方案可能满足客户的真实需求，同时不打乱产品路线图，但 Meyer 承认这样的方案并非总存在。他自己的乐观有时会产生复杂的替代方案，在他脑中看似可行，却难以大规模协调。教训是，应与负责执行的人一起检验替代方案。

Meyer 区分有说服力的愿景和有害的现实扭曲。领导者可以让人们围绕困难目标团结起来，帮助他们完成过去认为不可能的事。但如果信念取代求真，人们可能花多年追逐无法实现的目标，而领导者忽视其中的妥协与损害。

谈及产品负责人和创始人 CEO 的关系，Meyer 说 CEO 最终拥有愿景的决定权。双方都可能缺少部分背景，因此需要坦诚沟通并共享目标。在 Databricks，他会争取 Ali Ghodsi 对重点事项的认同、发送进展；通常没有异议时，他就继续推进。

Meyer 希望提高自己对言语和肢体语言如何影响他人的觉察。由无关事情引起的情绪，可能被误解为对当前讨论工作的失望。他主张直接、坦诚地说明情况，让人们能结合正确背景理解互动。

领导者职位越高，短暂接触可能越不对称。一次简短而疲惫的交流，对见到领导者的人可能比对领导者本人的意义大得多。Meyer 描述了会议日的压力：主题演讲、客户会面和大型晚宴接连进行，之后他需要安静。

对于希望晋升的产品经理，Meyer 建议熟悉产品，并从整体上理解客户需求。他说，创始人应明确产品负责人的自主权程度：创始人 CEO 可能希望深入参与。他在 Databricks 学到，Ghodsi 希望创始人参与细节，而不是等到成品完成后才看。

新任产品负责人应避免一上来就强加全面框架，或在前 90 天改变一切。早期成果可以有帮助，但 Meyer 更看重实质性的人际成果，而非虚荣式的胜利。他回忆自己曾请前上司教他产品管理，对方回答说，这不是简单就能教会的。

如果能在第一次做父母前给自己建议，Meyer 会说保持惊奇感，不要催促孩子赶上一个又一个成长里程碑。他说，孩子长大后育儿方式也会变化，平衡工作和家庭改变了他对“自私”的理解。他承认，自己倾向于妥协，但这并不总能替代设立边界。

Stebbings 欣赏 Notion 和 Canva 的模板策略。Meyer 尤其对不寻常的商业模式创新感兴趣，并以他认为与能源效率激励相关的 Opower 为例。他相信，能源转型、社会和经济公平等难题需要创造性的商业模式；这是他的观点，而非访谈中经过检验的解决方案。