播客笔记|Marty Cagan：产品的本质与优秀产品经理团队的养成
继续更新一期Lenny' podcast的播客笔记。
这一期嘉宾是Marty Cagan，这是一位硅谷产品领域老人，既在大型科技互联网公司做过高级副总裁，也具有丰富的产品咨询和顾问经验，更孜孜不倦地写文章传播富有洞察力的产品观点。
其经历贯穿了所谓的古典互联网时期与移动互联网时期，但又保持了很多古典互联网产品经理的特质，相较于功能型的、流程式的、项目管理式的产品交付（product delivery，build it，決定如何做出这个东西），他更加重视用户需求的洞察和解决方案设计主导的产品发现（product discovery，find out what build，決定要做什么东西）。
在这一点上，当前的很多产品经理已然变成了文牍产品经理或项目管理经理。说到这里，让人想起了纯银最近分享的观点，在高质量需求被挖掘殆尽的时候，产品经理将变成支持部门，运营的地位上来了，产品经理的未来在产品运营双修。
无论产品经理的未来如何，洞察用户需求并尽可能创造性地提出解决方案是任何商业组织不变的动力，不管是通过产品的方式、运营的方式、组织的方式、财务的方式或者其他什么方式实现。因此，Marty Cagan的观点或可一听，或许获得一些启发。
嘉宾背景：Marty Cagan
前网景公司 Netscape的副总裁，曾担任eBay产品管理及产品设计高级副总裁，创办产品咨询公司硅谷产品集团（SVPG），著有影响了很多人的产品圣经《启示录：打造用户喜爱的产品》（ Inspired: How To Create Products Customers Love）以及《启示录2：打造优秀的产品团队》（ Empowered ）。
播客要点（Takeaways）
功能型产品经理团队 VS 真正的产品经理团队
Marty Cagan首先指出，功能型产品经理与真正的产品经理使用同一条线，都称为产品经理，这是误导人的，二者具有显著的不同。（feature teams and real product teams should not use the same string product manager. The job is so radically different, that it's misleading to call them both product manager。）
具体而言，功能型产品经理是这样：
• 他们接手一份产品路线图，上面是经过优先级排序的功能或项目清单（you are handed a typical roadmap，everybody has the same thing, that it's a prioritized list of features and project）;
• 每个季度利益相关者聚在一起，动辄就是要做这功能、要做那功能（some stakeholders got together, usually quarterly, "Look, to run our part of the business, we need these features）;
• 经过一系列设计、程序编写、测试然后部署上线（you are being asked to do a little design and a lot of coding and then some QA and then deploy it）；
• 每天可能上线多次，但谁在乎（They're releasing many times a day. Who cares if you make another release? If it doesn't actually solve the problem, it's nothing to brag about）；
基于此，Marty Cagan将功能型产品比作herding cats（这是一个俚语，字面意思是“赶着一群生性跳脱的猫去同一个方向”，比喻把一群及其难管的人聚集起来朝着共同的目标努力，形容事情是一项极度困难或者不可能完成的任务），说明了功能型产品尽管在在支持业务发展（you're there to serve the business），但本质上是项目管理的角色（It's essentially a project management role）。
而真正的产品团队则如下面这般：
• 不同于给定带有优先级的产品路线图，真正的产品团队首先面对待解决问题（In a real product team, first of all, instead of being given a roadmap of prioritized features, they're given problems to solve）；
• 产品团队被赋能以便提出最佳的解决方案（the team is then given the skills so that they can come up with the best solution to that problem），这里Marty Cagan还提到了奈飞原则，即将决定权赋予拥有最佳解决问题的知识的人（that's the Netflix principle is push the decisions down to the people that actually have the knowledge to best solve the problem）；
• 工程师日复一日钻研可行的技术，产品团队每周调研用户（The engineers are working with the enabling technology every single day, the product teams are working with the users and customers every single week）；
• 产品团队以问题解决为产出，而不是（功能点交付）输出（product teams are about outcomes, they're not about output。when you're given a problem to solve, that's not output, that's outcome, so you either solve it or you don't.。As you probably know, most good teams today are doing continuous deployment, continuous delivery。In a real product team, you celebrate when you actually solve the problem, when you accomplish those results）；
• 设计师和工程师也要参与进来，关心你所开发的产品是如何构建的（what you build is how you build）；
总之，Marty Cagan认为，真正的产品不是遛猫那种项目经理的角色，而是发现这样的解决方案：对用户有价值（valuable）、易于使用（ usable）、技术可行可被打造（ feasible）、商业上可行（ viable）（on an empowered product team, where you're trying to come up with a solution that solves the problem you've been assigned, that's much harder because that means we have to discover a solution that's valuable, usable, feasible, viable）；
产品的本质
播客中，Marty Cagan如此说道：
也就是说，人们只会为解决方案付费，而不是问题。而且，你的解决方案是否比别人的更好？
比如说，人们告诉你他想要一匹更快的马，但你通过不断追问后明白，他的诉求其实是更快地实现从A点到B点的位移。而要解决这个问题，解决方案有很多，你可以造汽车、可以造飞机乃至量子传输。重要的是理清用户的动机和真正的需求，然后才是在解决方案里优中选优，考虑可行性、考虑差异化。
说到洞察用户需求这一问题，前些年有一个备受推崇的理论JTBD——Jobs-To-Be-Done（由颠覆式创新理论之父克莱顿·克里斯坦森提出，又称焦糖布丁理论，在书籍《与运气竞争》有叙述）。JTBD理论认为，人们不是为了拥有某个产品的所有权或某项功能，而是在特定场景下“雇佣”某个产品来达成某个目标和目的，产品和服务仅仅是达到目的的手段。就像现代营销学奠基人西奥多·莱维特(Theodore Levitt)所说的那样，“人们并不是想买一个1/4英寸的钻头，他们想要的是一个1/4英寸的洞。”。
类似JTBD理论这样不断深究用户真实场景下的真实动机和诉求的需求分析框架还有很多，而这是真正的产品团队应该孜孜不倦地追求的Product Discovery过程。
具有好产品文化的公司是什么样
Marty Cagan认为很多人对具有优秀产品文化的公司有误解，这在其著作《启示录2》中有剖析（why there's such a big difference between the best and the rest. In other words, why isn't every company trying to work like the best companies?）。其中一个原因在于，他们没有在这样的公司待过，没有经历过没有体验过（the biggest reason I see is that they have never worked at a company like that, so they don't know what it looks like）。
Marty Cagan推荐了几本书，从中可窥一斑：
• 介绍亚马逊公司文化的《逆向工作法》（Working Backwards）；
• 介绍奈飞公司文化的《不拘一格：网飞的自由与责任工作法》（No Rules Rules：Netflix and the Culture of Reinvention）；
• 介绍苹果公司文化的《构建》（Build:An Unorthodox Guide to Making Things Worth Making）：作者托尼·法德尔（Tony Fadell）领导了苹果公司团队创造了 iPod 和 iPhone；
优秀公司创新的丧失（The downfall of innovation in great product teams）
我们常常看到，在一片混沌之中，某些公司以革新者的姿态推出别具一格的产品，经过一系列狂暴突进后创新动力减弱、创新能力逐渐丧失。原来的创新的锐气不再，只有沉沦、泯然众人。
对此，Marty Cagan也在思考，并且特别推荐去看一看乔布斯1995那部纪录片《遗失的访谈》（The Lost Interview）。
这部纪录片采访的乔布斯当时已被苹果公司解雇，里面讲述了自己的感受心境，更为重要的是表达了乔布斯对产品和组织的洞见和智慧。
在回答优秀公司为何丧失创新魔力时（Why is it that so many companies lose that mojo?），乔布斯认为，随着公司变大，产品变得不那么重要（as a company gets bigger, product historically became less important），更受欢迎的是营销人员、销售、财务人员（The people in a company that would be celebrated were marketing people, sales people, finance people），如果一个公司停止创新，那么他们就是增长引擎，这些人会成为产品或公司的领导，那么接下来优秀的产品人员不想在那里工作，他们离开了，去了一家重视产品的公司。
这其实是很多公司的现实，产品推出后，增长成了头等大事，创新的重要性降低，而且创新是那么困难，为什么要继续创新推出一些有风险的新东西，为什么不继续销售这个似乎人人都想要的东西？
乔布斯称，这是一种疾病（disease）。
用户研究在构建伟大产品中的角色
Marty Cagan提到，多人做用户研究，但他们对用户研究所做的是测试他们的原型，当他们得到足够多的用户说他们有多喜欢它时，他们就建造它。而Marty Cagan认为，从解决方案发现的角度看，我们的大部分时间需要放在解决方案上，需要原型设计，需要与用户的测试、与客户的测试、与利益相关者的测试、与我们的开发人员的测试；而且我们不断地测试不只是试图找出用户是否喜欢它，相反，我们寻找所有他们不喜欢它的原因。事实上，这是埃隆·马斯克的一句话：当你做用户研究时，你应该专注于找到他们不使用你的产品的所有原因。
此外，Marty Cagan还直言讨厌用户研究人员自己去做研究并带回一份报告。Marty Cagan给用研团队制定的规则是，如果产品经理和设计师在他们的产品测试期间不能到场，就取消测试。
这就要求产品团队必须亲临用户研究一线，而不是面对一个枯燥的研究报告。在这一点上，我近期刷到的一些产品帖子都在强调。比如Deborah Liu（Facebook前全球产品副总裁、财务软件上市公司Intuit董事、硅谷生物科技公司Ancestry的CEO）在帖子中提到的几个词：
• Dogfooding：Dogfooding一词最早出自于1970年代的一则Alpo牌狗粮的电视广告中，洛恩·格林表示他用Alpo牌狗粮喂食自家的狗。 而在IT业界这句俚语可能最早是于1988年开始使用的。当时微软公司的高级主管保罗·马瑞兹曾写过一封题为“Eating our own Dogfood”（自己造的狗粮自己吃吃看，自己拉的屎自己先吃吃看，自己做的产品自己内部先用用看）的邮件，在邮件中他向微软局域网管理工具项目的测试主管布莱恩·瓦伦蒂尼提出“提高内部使用自家产品比重”的挑战。而从此以后，这一俚语在公司内就传播开来了。
• Follow-me-homes：不断邀请普通人，有时甚至是没有电脑操作经验的人们来使用，自己只是坐在旁边观察，总结其使用习惯、遇到的问题，再从产品上予以改进，从而避免了先入为主与自我陶醉。就是跟着用户去观察和了解他们生活、工作的地方，在一个沉浸式的氛围里去了解他们的生活。个人感觉，一定程度上类似可用性测试，或者类似人类学田野调查。
• Ride-alongs：“跟随对象并观察”，具体指花一天时间跟着销售，陪着他们打销售电话、观察其与用户的对话，尤其在B2B销售行业（“spend a day with a salesperson… accompanying them on sales calls and observing conversations with customers”，“These structured ride-alongs allow you to observe sales reps on the job and provide insights and coaching to improve performance and drive more revenue”）；
• genchi genbutsu：日语“现地现物”，来自丰田管理术，指的是现场发现问题并解决问题。它是精益生产词汇中最重要的一个用语。在英语中，它作为一种指令，通常被翻译成『自己去看』（“go and see [for yourself]”），以便人们基于深刻的第一手信息，作出商业决定。
如何向优秀产品文化的公司学习
Marty Cagan指出，首先，你需要确保团队有问题要解决，而不是有功能要构建。
而产品经理需要做的第一件事是让自己做好准备，以工程师设计师等需要的方式为团队做出贡献。一般来说，这意味着四件事。
首先，他们必须真正了解用户和客户，他们必须被认为是用户和客户方面的专家之一。Marty Cagan提到，当他还是一个想要成为产品经理的工程师时，指导我的人明确地说，在拜访完30个客户之前，不允许为团队做任何决定。说到这，你可能听过有个说法，在腾讯有一个 “10/100/1000法则”——产品经理每个月必须做10个用户调查，关注100个用户博客，收集反馈1000个用户体验，这也是要求产品必须贴近用户的方式。
其次，他们必须是数据方面的专家。你的产品是如何使用的？随着时间的推移，它是如何变化的？销售分析是什么？用户分析是什么？所以你必须知道你的产品实际上是如何被使用的，这只是了解你的客户的另一种方式。
再次，这通常是最难的一件事，也是你的利益相关者会评判你的一件事，就是你必须学习业务涉及的不同部分（部门）。你必须知道它是如何营销的、如何销售的、如何支付的，如何货币化的。如果有任何合规、监管、隐私、安全问题，你需要知道这些是什么。而且你需要与企业的不同部门建立信任。
最后，你必须了解竞争情况。你必须了解这个行业、了解趋势。
Marty Cagan所提到的这些其实也是产品的基本要求，这体现在基本产出中，也体现在跨部门合作之中。
此外，Marty Cagan还表示，对于产品团队来说，除了获得赋能、明确战略背景外，还需要掌握产品发现的技能。Marty Cagan在此推荐了两本书籍：
• Teresa Torres的《Continuous Discovery Habits》；
• 杰克·克纳普（Jake Knapp）的《Sprint：How to Solve Big Problems and Test New Ideas in Just Five Days》（中文翻译为《设计冲刺 : 谷歌风投如何5天完成产品迭代》）（注：Jake Knapp是Google设计冲刺（Design Sprint）的发起人，其在Google与Google Ventures任职十年，也是在同一时期孵化了设计冲刺（Design Sprint）这一概念与实践框架）
产品管理角色的发展变化
Marty Cagan发现，在整个欧洲，产品所有者是由敏捷教练教导的，而他们中的大多数人一生中从未做过一天的产品，他们所知道的只是流程，所以他们在教一个流程。
这就是Marty Cagan担心的，他建议产品始终关注三件事：Direct access to customers, direct access to the engineers, direct access to the stakeholders。
此外，Marty Cagan还提到了产品运营（Product Ops ）这一岗位的增多，但他认为这可能是一个流程角色（ process people），因为它并没有切中产品（发现）的核心。
参考资料
做产品真的难于上天！ — Marty Cagan 70 分钟演讲2万字中文翻译（建议收藏）
The Inconvenient Truth About Product
【纪录片】《史蒂夫·乔布斯：遗失的访谈》（The Lost Interview）
什么是风靡UX圈的谷歌设计冲刺Google Design Sprints？
揭秘Google设计冲刺 · 谷歌UX设计师Vivia | Techtopia·科技物托邦 第3期
How to Win the Netflix Product Manager Interview
Tony Fadell: iPhone, iPod, Nest, Steve Jobs, Design, and Engineerin
