够低调解析_够好了

够低调解析

我们听到很多有关构建“足够好”或“勉强够好”的产品的信息。 我们如何知道“足够好”对我们的客户意味着什么？ 没有人真正告诉我们。

足够好的不同观点

有几种重要的方法来考虑产品是否足够好 –在本文中，我们将讨论的上下文限制为“足够好以交付给客户”或“足够好以使其不再变得更好（目前）”。 确定是否足够好将决定是否发货。 否则这都是学术性的

有足够好的几个观点很重要，但是对产品经理的帮助不足。 工作的主体似乎集中在善良方面，这些方面不会帮助产品经理制定优先级决策，从而为他们的路线图提供依据。 它们很重要–它们对于产品经理来说是必要的，但还不够。 在深入了解我认为缺失的部分之前，这里有一些指向一些很棒的东西的指针。

• 足够好并不意味着您只能完成您知道需要做的80％的编码工作，然后再运送产品-从而增加了技术负担。 Robert Lippert对此有出色的文章 。 技术债务在您的代码中堆积如甜甜圈堆积在您的腰围上。 这很重要，尽管它只会最终影响产品管理，因为代码库变得笨拙并限制了团队可以交付的内容，并增加了交付的成本和时间。
• 交付产品时，对完美主义要务实 。 史蒂夫·罗帕（Steve Ropa）对此有很好的文章 。 作为木工的同伴，他的隐喻引起了我的共鸣。 作为一名工匠，关键思想是认识到您在增加成本和工作量时会以客户永远不会注意到的方式提高交付质量。 这一点很重要，并且可能会影响产品经理，因为交付物成本的增加会影响到按需购买的计算 ，从而影响优先级决策。

精益创业公司和最小可行产品（MVP）拥有当前的思想份额，因此，在没有完全理解创意的情况下，人们跳进了很多好的创意的分析太浅了。 由于对“ 最低限度可行的产品 ”一词的误解， 导致产品失败 。

• 许多人误将MVP中的产品定义为实验 。 马克斯·邓恩（Max Dunn） 撰写了一篇出色的文章，阐明了人们如何将“运行实验”与“运输产品”结合起来，并对如何在区分方面没有足够的指导性进行了很好的评论。 这对于产品经理理解很重要。 向客户学习是很重要的-但这并不意味着您应该将半熟的产品运入市场以验证假设。
• MVP是一个实验过程，而不是产品开发过程 。 拉姆利·约翰（Ramli John）在一篇出色的文章中提出了这一大胆的主张。 如果我们可以让所有人阅读它，这可能只是解决问题的耳光。 MVP /精益创业是一个遵循科学方法，以假设检验为动力的学习过程 。 与其尝试将其拖入产品创建过程中，还不然。 使用概念来推动学习，而不是路线图。
• “我们现在有多少？” 对客户很重要 。 克里斯蒂娜·沃特克（Christina Wodtke） 撰写了一篇特别有用且出色的文章 ，内容涉及在制定路线图时将客户包括在内。 “现在，下一个或以后”是一个出色的框架，可用于同时获取优先级反馈并管理客户（和其他利益相关者）对交付的期望。 我担心的是，就对产品经理的指导而言，这是最好的。 大多数人管理“何时何地”，而不是“如何有效”。

三种观点

在做出关于产品投资的决策时，我们如何定义足够好的定义有三种观点。 Robert和Steve的前两篇文章（上面已链接）解决了有关团队何时停止编码以交付所需功能的问题。 还有一个有效的问题，即开发人员正在编写代码的特定设计是否足够好。 我将推迟讨论有关何时将特定功能（作为一组功能，交互等）交付的设计时间。 [到目前为止，我已经埋了700字来埋头了]。

对于产品经理，最重要的观点是意图。 我们正在努力使客户做些什么。 克里斯蒂娜（Christina）的文章（以上链接）专业地解决了管理意图的问题的一半 。 请注意，这并不是对她专注于“何时何地”的批评。

我们需要解决“现在的能力如何？”这个问题。

现在必须有多强大？

最后。 我写这篇文章的原因是， 每个人都只是对这个神秘的概念挥手致意，因为这个神秘的概念现在可以拿到东西，然后再做得更好。 但是没有人为我们提供任何工具来阐明如何定义“足够好”。 几年前，我写过关于交付尚未完美的产品并逐步满足您的客户的信-但是我没有提供任何工具来帮助从意图角度定义足够好的产品 。

一旦确定了要包含在发行版（或迭代版）中的特定功能，就必须定义该功能的能力。 这是我要描述的示例：

• 我们已经决定，使我们的目标客户“降低库存水平”是在此版本中进行的正确投资。
• 正确的目标数量是减少多少库存水平？

这就是问题所在。 什么足够好 ？

我们的客户拥有足够好的定义。 卡诺分析为我们提供了讨论的框架。 从客户的角度看， 更好的功能就是更好的功能（对于非母语为英语的人，“提高功能的有效性”具有基本相同的含义）会增加他们的价值。

我们可以在这条曲线的任何地方交付具有一定水平的功能的产品。 问题是–在什么水平上“足够好”？

一旦我们达到交付“足够好”的性能的水平，至少要从客户的角度出发，为提高该特定功能而进行的其他投资就值得怀疑了。

扩大问题

切换一下齿轮，并回顾您与开发团队进行的最新估算和谈判活动。 对于许多功能而言，使其“更好”，“更多”或“更快”也会使其成本更高。 “在2秒内获得搜索结果的成本为X，在1秒内获得结果的成本为10X。”

随着我们提高产品功能的能力，我们同时以越来越高的成本为客户提供了较小的收益。 这听起来像是微观经济学期末考试的问题。 利润最大化点必须存在于某处。

一个例子

驾驶节油能力更高的汽车节省的费用是描述收益递减的一个很好的例子。 向使用其他措施和货币的人致歉。 下图根据美国司机的一些典型值，显示了车辆的每日运营成本。

燃油效率每提高一倍，听起来就像是汽车的飞跃进步。 从内而外的角度来看， 80 MPG令人印象深刻的“优于” 40 MPG。 想象一下，为改善（或重新发明）技术而使燃油效率提高一倍的工程技术。 所有这些投资可以为平均每天节省驾驶员1美元。 根据美国汽车平均拥有时间，这不到2,000美元。

消费者为节省这2,000美元将支付多少费用？ 根据汽车制造商可能增加销售和/或价格的多少，该汽车制造商应投入多少以使燃油效率提高一倍？ 企业软件的经验法则建议制造商将价格提高200至300美元。 如果供应商的发展预算占收入的20％，他们将能够花40至60美元（每辆预期售出的汽车）来资助能力的急剧提高。

更近了一步

鉴于您的产品策略是独一无二的，对于客户，特定产品的特定功能而言， 足够好意味着什么。 没有一个适合所有人的答案。

也没有适用于所有人的统一方程式。 即使您建立了代表不断改进的收益递减给客户的模型，也必须将其放在上下文中。 给您的团队使用技术堆栈时，给定水平的改进​​成本是多少？ 改进对您的竞争地位有何影响 -无论是在这种能力方面还是在总体上。

您必须进行客户开发工作，并了解市场的行为方式和需求。

至少在使用Kano分析的情况下，您有了一个框架，可以就最终需要做什么以及现在需要做什么做出明智的决定。 另外，您可以在组织内进行明确的沟通（并达成共识）。

翻译自: https://www.javacodegeeks.com/2014/12/good-enough.html

够低调解析