产品管理与机器学习一样是一个庞大的话题，所以让我们从一个基本问题开始。什么时候值得开发人工智能产品？当然，您也可以将此问题应用于更大产品的上下文中的功能。

大多数 PM 看到的一个有用的工具是 IDEO 推广的 Sweet Spot for Innovation（创新最佳点）。 它探讨了产品的合意性、 可能性和可行性，有价值的想法往往会触及所有这些方面。 如果你不熟悉这个框架，你应该阅读这篇文章。

• 技术可能性（feasibility）：我们现在有阶段真的能做到吗，可能吗?
• 用户合意性（desirability）：它能解决客户的问题吗?它是客户所期望的吗?
• 商业可行性（viability）：我们应该这样做吗?未来它会成功吗?

让我们从机器学习产品的角度来看这些概念。

技术可能性（feasibility）

可能性通常不是我建议您在评估产品创意时开始的部分。尽管如此，与传统软件产品相比，这可能是最不同的方面，尤其是因为我们还处于 ML 增强软件功能的早期阶段。

尽管时间估计仍然很困难，我们都非常善于评估软件的可能性。当您向开发人员描述问题时，他们已经在考虑技术和库。您可能正在考虑以前的产品已经解决了相关问题。随着时间的推移，机器学习会出现类似的思维模式。

在可能性方面，您应该问自己和您的团队的问题是：

我们要解决的问题是什么？

对于任何问题，问题设置都是必要的，但在处理更大的不确定性时更是如此。例如，假设我们的想法是检测生产线上有缺陷的产品。粒度在这里变得很重要：我们在发送给客户的有缺陷的产品中寻找多大的改进？

我们有关于这个问题的数据吗？如果没有，我们能否获得有关该问题的数据？

机器学习都是关于数据的。它并不总是意味着大数据，而是关于问题的足够的质量数据。某些数据很容易获取。例如，来自您的应用程序的用户操作。它们可能已经存储在某个地方。

而其他数据类型更难，例如：大量的标注图像集。查看我们的生产线示例，您需要一个图像集，其中包含完美和有缺陷的产品，并从您将传感器放置在生产线中的相同角度标注和拍摄缺陷。

数据中是否存在对算法有意义的模式？

机器学习的难点在于，数据科学家通常需要先进行大量工作来评估数据集并进行实验，以查看数据中是否存在 ML 模型可以理解的模式。与传统软件不同，如果不真抓实干，就很难评估可能性。例如，使用您的标注产品数据集（有缺陷的和无缺陷的），模型将能够区分两者。

在传统软件中，可能性几乎可以描述为二部分（可能与否）。然而，在机器学习中，技术可能性可能更多的是一个范围，它会溢出到用户期望的范围内。

用户合意性（desirability）

弄清楚人们想要什么是一项棘手的工作，而对于 AI 产品，也不例外。评估合意性表面上与传统软件相同，但有一个陷阱。让 AI 评估产品线上的每个产品似乎是非常可取的。事实上，许多公司都在研究这些类型的解决方案。但是您还应该问一些其他问题：

该算法的性能如何以及它需要执行的性能如何？

这个问题与解决方案的技术可能性和用户合意性有关。在数据科学家卖力工作之前，同样没有简单的答案。

您可能会发现算法会以很高的速度检测到有缺陷的产品，但也会产生误报。这对您的生产线意味着什么？也许生产工人会因为误报而完全忽略该算法，而您的解决方案变得不可取。

描述一个完全自主的解决方案很容易，但构建起来并不总是可行的。也许您可以切实构建的产品只是人类的计算机助手。完全自动驾驶汽车和计算机辅助转向在用户合意性上大相径庭。但最好考虑在您的上下文中某些东西变成用户合意的点，这也与下一个问题有关。

用户将拥有多少控制权？用户是否信任您的解决方案并以与您相同的方式看待价值？

信任是人工智能中的一个重要话题，并且有充分的理由。机器学习模型对于开发它们的人来说可能是黑匣子，所以想象一下最终用户的感受。要考虑的一个重要方面是您必须传达多少信息才能说服用户，以及您对用户的决策有多少控制权。

例如，在我们的生产线示例中，您是否需要展示算法对每个预测的置信度（即该产品有 70% 的可能性有故障）？您是否会赋予生产线经理调整缺陷产品被丢弃的置信度的能力？

这当然是一种简化。将算法的控制权交给用户可能难以实现并且用户难以理解。

这些问题在医疗保健等敏感场景中变得极为重要，因为意想不到的后果可能是可怕的。

商业可行性（viability）

如果您提出了一个可行且理想的解决方案，那么问题就在于它对用户以及最终对您而言价值是多少。评估商业可行性的方法有很多，而且 PM 必须经常考虑新产品理念是否符合公司战略。

一些与可行性相关的更多特定于 ML 的问题是：

长期产生的价值会大于短期成本吗？

开发 ML 功能的成本可能高得离谱。考虑到数据科学家和机器学习工程师是当今最受欢迎的人才。即使您的团队中已经有他们，他们也可以采取许多其他举措。此外，精通机器学习的设计师和主题专家可能更少见。获取高质量数据的成本也很高，而且训练模型也不是完全免费的。

从数据收集到模型服务，需要编写大量代码和建立基础设施。最重要的是，机器学习对大多数人来说都是新事物，并且所有利益相关者都参与了大量的教育和变革管理。

由于所需的成本和专业知识，也许总是值得从询问是否可以使用专家系统（即规则引擎）而不是 AI 来解决某些问题。其次，询问您如何确保您的团队使用其他人在他们之前建立的研究和技术。这两个问题可能会为您和您的公司节省一大笔钱。

问题会随着时间而改变吗？该解决方案能否扩展到其他领域？

另外两个方面会显着影响您的 AI 产品的可行性。

一方面是您部署解决方案的环境的动态程度。还是在我们的生产线场景中，产品型号会经常变化吗？如果是这样，为了维持解决方案的可行性，获取数据、训练 ML 模型和进行其他更新的成本将会加班加点。这个问题比你想象的更常见。

另一面可能是您的解决方案可以复制到其他类似的问题，您可以反复使用大部分工程。例如，您可能最初为单个产品设计了故障检测解决方案。尽管如此，同样的传感器可以安装在其他生产线上，并且可以收集训练数据。这些类型的机会可以证明许多重大的前期投资是合理的。

将它们结合在一起

在机器学习方面，产品经理（但不限于产品经理）有点天真。他们的态度从完全超出可能性范围的 ML 到轻松解决所有问题的 ML 。所以很自然的，事实介于两者之间。

正如本文所示，AI 产品中的用户合意性、技术可能性、商业可行性是相互关联的，与传统软件相比，揭示它们之间的关系将需要更具体的实验和原型设计。同时，数据科学家、工程师、产品经理和主题专家需要从一开始就一起工作。