Marty Cagan：产品发现、招聘与授权团队

Marty Cagan 说，他关注的是产品团队，而不只是产品经理：根据他的经验，优秀产品来自团队。他曾在 HP Labs 担任十年工程师，并开始好奇谁决定开发什么、这些决定如何作出，以及产品如何到达客户手中。

他后来加入 Netscape，负责开发者平台和工具，随后成为 eBay 最初的产品和设计负责人。他之后创办 Silicon Valley Product Group，帮助初创公司，并受益于此前工作中建立的关系。

Cagan 回忆，自己从 Marc Andreessen 与工程师、客户和初创公司的密切接触中学到了很多。他最强调的教训是认识到自己尚不能知道什么：客户是否会购买解决方案、开发有多困难，都需要调查，而不是自信地下结论。

他将 Ben Horowitz 直接但出于善意的反馈视为另一个影响。Pierre Omidyar 对 eBay 的愿景说服他去做面向买卖双方的产品，而不是继续只做自己通常偏爱的开发者工具。

初创公司创始人面临许多风险，包括商业模式、渠道、技能和技术。Cagan 说，人们经常关注自己熟悉的风险，却推迟处理核心问题：团队能否创造客户真正想要的产品？

他回忆，一位创始人花了数年时间改变定价、目标市场和推广方式，却没有实质性改变最小可行产品。Cagan 判断，该方案没有提供足够价值；这是他对一个具体案例的叙述，不是对所有停滞公司的诊断。

他区分了确认问题存在与创造比现有替代方案更好的解决方案。在他看来，发现尚未满足或满足不足的价值，通常比证明存在广泛市场需求更难。

Cagan 的产品发现框架提出四个问题：解决方案对用户是否有价值、是否易用、技术上能否实现、作为业务能否持续？业务可行性包括成本承受能力、分发、法律和监管要求；其中任何一项都可能阻碍成功。

他区分产出与结果。交付功能是产出；解决真实的客户和业务问题是结果。一个只追求增加功能数量的团队可能成为他所谓的“功能工厂”，却没有让产品更有价值。

初创公司资金可支撑的时间有限，大公司也可能耗尽管理层的耐心。Cagan 主张快速开展产品发现，而不是每次大型发布都等一年，让团队在资源或耐心耗尽前测试多种方案。

他以寻找产品市场契合时可能需要 50 至 100 次尝试作为粗略经验参考，并说产品发现技能可以让迭代快得多。这个数字是他的启发式判断，并非经过证明的要求，也不保证一定能找到契合点。

定量方法可以显示一项改变在规模化后是否有效，定性研究则有助于解释人们为什么遇到困难或拒绝产品。Cagan 说，优秀团队会结合两者，常常在大范围上线前用真实用户测试原型，迅速获得信息。

他提醒，不要只问客户是否会购买假设中的产品，或让客户自己设计解决方案，以此寻求肯定。他做定性研究的目标是找出人们不使用产品的原因，再由团队运用判断作出回应。

少量定性访谈不能替代关于总体的统计证据。Cagan 建议根据产品和情况寻找更强的价值信号，例如实际付款、投入时间的承诺或非约束性购买意向书。

他认为产品开发是艺术与科学的结合，需要判断什么时候更强的定量证据值得花费相应时间和成本。风险较高的投入可能比可逆的探索需要更多证据。

Cagan 偏好由创始人担任产品负责人，并说自己只投资至少有一位创始人展现过产品领导能力的初创公司。这是他的投资标准，并不能证明其他创始团队组成的公司不会成功。

假设已有这样的创始人，他以约 25 至 30 名工程师作为可能需要增加产品领导人才的经验参考。工程师分属较小团队，由资深技术负责人带领，因此创始人不需要直接管理每个人。

招聘前，他会先问创始人真正需要什么：更多工作能力、帮助落实愿景，还是另一种产品领导能力。明确职责比一个笼统的头衔更重要。

Cagan 说，招聘有经验的人和培养初级人才都可以成功。有吸引力的产品愿景可以打动有经验的候选人；但如果雇用初级人员时没有一位愿意指导他们的管理者，就会让他们难以成功。

对于没有经验的候选人，他会寻找好奇心、职业投入和遇到障碍时的坚持。他对简单的招聘测试持怀疑态度，因为根据他的经验，这些测试可能淘汰有能力的人，也不一定可靠地揭示他想要的特质。

他建议，有经验的管理者以大约三个月为目标，帮助初级员工达到基本胜任水平。这是他对得到支持的新员工的实践预期，并不保证每个人都会按同样时间表达到相同水平。

谈到行业知识，Cagan 更偏好优秀的产品能力和学习领域的能力，同时承认存在例外。他区分有用的专业知识与未经审视的行业成规，并说团队仍必须深入研究客户、财务约束和监管要求。

他说，在医学等专业领域，产品团队应能够接触合格的领域专家。他的意思并不是忽视专业知识，而是将其与能够学习、负责任地质疑假设的产品人员结合起来。

Cagan 回忆自己在 HP 从工程转向产品的经历。一位导师评估了他的长处和不足，并要求他在作产品决定之前拜访 30 位客户：美国和欧洲各 15 位。

他说，这些拜访很快暴露出自己对客户了解有多少不足，尽管他做的是面向工程师的工具，自己也是工程师。导师还安排他学习直销和经销商两种渠道，让他理解产品如何到达市场。

Cagan 几乎没有财务训练，因此导师安排他阅读书籍，并每周由财务同事辅导。他学会了产品关键指标的含义，也发现产品每卖出一份都在亏损，而工程团队此前并不了解这一事实。

他认为工程师的贡献不止是写代码，应当有条件理解客户和业务背景。他对外包核心工程工作的批评反映了他对获得充分授权的内部团队的偏好；他将其作为管理观点，而非普遍规则。

他说，入职培养从个人评估和辅导计划开始。有些人需要客户成功经验，有些人需要到一线实地学习，另一些人则需要财务知识；达到基本胜任之后，计划可以转向帮助他们发挥潜力。

针对同批新员工的入职项目也有助于他们了解客户、文化、领导层和决策方式。常见错误是假设一个人在知名公司成功过，就自动知道如何在另一家公司取得成功。

被问及产品与销售之间的紧张关系时，Cagan 认为产品团队应负责理解产品为什么卖不出去。这意味着与销售共同工作，调查客户是否看到产品、销售工具、客户案例、定价和产品价值，而不是远远地互相指责。

他区分了依靠流程扩大规模和依靠辅导扩大规模。Cagan 批评过度规定的流程，并对这种情况在欧洲的普遍程度提出概括性观点；访谈没有提供支持这一地区比较的证据。

他说，深入讨论和书面叙述可以让后续执行更快。在对产品经理的快问快答建议中，他强调结果，以及对客户、数据、行业和使产品成为可能的技术的深入了解。

获得授权的产品团队对解决方案的价值和业务可行性负责，而功能团队可能只是执行指令。Cagan 认为，给予团队真正的责任，有助于他们培养与创始人相关的判断力。

对于进入新岗位的产品负责人，他最先强调与其他领导者建立信任，其中一个方式是花大量时间接触客户。他希望同事知道，这位负责人理解客户问题，而不是只依赖内部报告。

Cagan 说自己支持 Agile，但反对把交付流程中的角色当成学习更广泛产品工作的替代品。2022 年，他称赞了 TikTok、Tesla、AWS 和 Stripe 的战略；这些是他当时的评价，而非对这些公司的独立评估。

Stebbings 感谢 Cagan 参与对话，Cagan 随后结束访谈。