MIT有一个研究表明：每一美元的科研投入，需要100美元与之配套的投资（人、财、物），才能把科研成果转化为产品。而且，从产品到商业变现还需要市场运营推广的投入。

对产品的定义随着时光的变迁往往有着不同的内涵，同样的，对产品经理的理解也可能有着不同的认知。

关于产品经理的出现

在20多年前笔者刚刚参加工作的时候，并没有所谓“产品经理”这样一个岗位。那时候，一个软件产品一般是由marketing 部门提出需求，系统工程师（在BNR时候的称谓）将需求转化为产品定义，项目经理组织软件工程师和QA组织实施。这大约就是传统的软件工程（参见）。

互联网的贡献，是通过优化和创造信息存储及传输的方式重新组合各种生产要素，即重构已有的商业模式和流程。当然，互联网同样改变了软件工程的自身。不只是从CS架构向BS架构的演进，也不是编程语言的更新换代，本质上，是连接性赋予了通信的普遍意义。简单地说，网络通信使软件的升级变成了一件容易的事，进而采用了快速迭代的可能。在笔者的记忆里，产品试错好像是和产品经理一同出现的。

遇到过的那些产品经理

即便有20多年的工作经历，但仍然微不足道，对产品经理的理解或许连一知半解都不是。但是，笔者遇到过很多的产品经理，大约有这么几种基本类型：

行业专家型：往往具备深厚的领域知识，尤其是对业务的流程有着深刻的认识，在2B行业而言不可或缺，但在跨领域方面可能存在鸿沟。

运营增长型：往往从数据分析和用户增长等角度出发，以数据为导向完成产品的分析及设计，但在定义和创新方面可能存在局限。

天马行空型：想象力是唯一的利器，但贫穷往往限制人的想象力。他们往往通过想象力来倡导自己认为的用户最佳体验。

技术导向型：一般由资深的工程师或QA转型形成，从技术导向及技术特点结合用户需求出发定义产品，在可实现性和进度把控方面可能对产品的帮助更大。

调研分析型：这一类型往往是主流，或者成为大多数。调研可以是用户访谈，也可能是竞品分析（copy 增强），所谓的微创新，可能是他们的一大工具。

当然，人都是复合的，产品经理也可能是诸多类型人才的复合，只是各方的技能占比的不同。但是，“人人都是产品经理”，这是一句鬼话，诋毁了产品经理的能力，技能和价值，大概从用户体验的视角，确切的说法大约是“人人都应该有产品思维”。

关于AI产品经理

和互联网不同，AI的主要贡献就是升级生产要素，进而推动产业升级。AI产品的目标是模拟和延伸人的感知（识别）、理解、推理、决策、 学习、交流、移动和操作物体的能力。

人对世界上绝大多数事情的认识是基于概率。AI产品的本质是通过概率思维来解决问题。合理的量化标准是对产品经理的一种要求。产品的设计应从需求而非技术出发。如果技术先进却对用户提出了较高的使用门槛，反而很难直接地传递价值，那么产品还是无法成功。同理心能够正确了解他人的感受和情绪，进而做到相互理解、关怀和情感上的融洽，做到认知共鸣、情感共鸣和身体感受的共鸣。

AI 产品的目标之一就是降低用户的使用门槛，尽量减少用户的交互流程，降低使用难度，让产品的使用过程更接近用户的自然行为。应选择用户最“痛”的点或者直接和利益挂钩的点作为需求切入点，例如：

• 该痛点涉及的面有多广，是普遍问题还是个别问题

• 是否符合政策导向或者是否合规

• 涉及的需求是否是高频应用

• 用户愿意付出怎么样的代价来解决这个问题

• 感觉到痛的人是具有采购的选择权

AI产品经理的角色可能是：1）拥有市场和技术前瞻性的带头人 2）技术赋能创新的驱动者 3）道德伦理的守护者

也就是说，AI产品经理的要求更高，不仅需要懂技术原理，还需要具备对技术发展趋势的洞见，才能最终设计出有竞争力的、有前瞻性的AI产品。AI产品经理的部分思维方式包括：

• 资源管理思维：算法、数据资源（训练集、研发集、测试集等）、硬件资源（计算芯片、存储及各种构成产品的硬件组件）。产品管理本质上就是一种固化的流程，流程不仅保证了效率，还提供了创新的机会。

• 解决方案思维：主动寻求解决方案需要产品经理具有异于常人的非线性思维和资源优化的能力。

• 目标导向思维：离开行业理解谈创新是站不住脚的，在AI 工程实践中，带有情感倾向的词语领域适应性较差，提炼出场景中可以帮助产品建立优势的关键点。

AI 产品经理的一些技能

需求永远是第一位的，业务需求包括业务机会、业务目标、成功标准以及产品愿景。从产品的微观目标中拆分出不同的场景目标，可以定义量化的标准，体现了AI产品经理对需求的把控。AI产品经理的输出需求未必是确定的页面内容，可能是一堆规则和策略。在明确的产品架构中定义功能需求可以保证需求的目标明确性及合理性。

对数据的应用能力更胜以往。“Garbage in，Garbage out”，数据作为AI的养料，其质量决定了最终AI模型和落地效果的成败。数据问题是AI产品的天花板。通过“数据驱动”的思维指导产品设计，即让机器从大量的数据中进行学习，然后将学习和训练好的模型直接用于产品。数据干净与否大约可以从四个维度考量：关联度(relevancy)，可信性(Reliability)，范围(Range)和时效性(Recency)。

算法是对AI产品经理的另一挑战，算法选择因素可能包括：

• 数据量的大小、数据质量和数据本身的特性

• 机器学习要解决的具体业务场景中问题的本质是什么

• 可以接受的计算时间是什么

• 算法精度要求有多高

非功能性需求是成功的AI软硬件架构必须关注的关键要素，例如安全性、可用性、可靠性、性能、可维护性。在互联网产品中，系统响应时间可能是2/5/10秒原则，但移动互联网又有所不同。可维护性是指产品可被修改的能力。

如果是AI智能硬件，那又是一番天地，没有下过生产车间的AI产品经理是难以想象的。

DuerOS 技能产品经理的只言片语

AI产品经理的技能要求较高，但并不意味着将AI引入到我们的产品中，因为AI本身意味着生产要素的升级。

DuerOS 作为对话式AI操作系统，相当于基于AI的开发框架和平台，极大地减少了产品经理对AI技术掌握的依赖。设计DuerOS的技能服务，和设计一个web 应用没有太多的不同，难点只要一个——就是将原来的键盘/鼠标/触摸屏的交互方式转化为面向智能语音的多模态交互方式。

DuerOS 的技能就相当于互联网上的Web应用，或者移动物联网上的App，甚至各种平台上的小程序。关于DuerOS 技能的交互设计乃至技能开发，可以参考笔者的DuerOS 关联文字。

参考资料与关联阅读：

• 张竞宇,《人工智能产品经理-AI时代的PM修炼手册》，电子工业出版社，2018

• 连诗路,《AI赋能：AI重新定义产品经理》，电子工业出版社，2019

• 林中翘,《产品经理进阶：100个案例搞懂人工智能》，电子工业出版社，2019

• https://dueros.baidu.com/dbp

• 《智能语音时代》的读书笔记

• 再看语音交互设计

• 语音交互设计的一点认知

• 百度AI开发者大会之DuerOS 回顾

• AI开发者大会中的公开课解读——DuerOS技能开发与CFC编程

• AI开发者大会中的公开课解读——如何在DuerOS技能中实现用户支付购买

• DPL 来了——百度2019AI开发者大会DuerOS公开课解读之三

• 故事工厂在DuerOS技能开发中的应用——百度2019AI开发者大会DuerOS公开课解读之四

• 企业赋能  AI 服务生活

• DuerOS 走进初夏的成都

• 放心用吧！浅谈DuerOS的安全性

• 智能音箱场景下的性能优化

• 在校大学生能成为DuerOS 的独立开发者吗？

• 生动化你的表达——DuerOS中的SSML应用

• 用JavaScript打造AI应用-从Nodejs SDK 看DuerOS的技能开发

• 从Java SDK看DuerOS的技能开发

• 面向接口/协议？看DuerOS的技能开发

• 感知自然语言理解（NLU）

• 感知人工智能操作系统