我一直打算写这篇文章了很多年,但因为它是主要的历史在自然界一直存在更为迫切的话题。但每隔一段时间就会有人伸出手,因为他们正试图追查一词的由来,并在此大流行,不管是什么原因,我已经更频繁地获得了这个问题。

首先,我要明确的是,概念产品的发现已经存在了,只要软件,肯定远远长于我是见过世面的。

我们一直有,而且可能永远都会有,在软件两个基本问题:我们需要弄清楚的正确的产品,然后我们必须建立产品权

我一直有兴趣在这两个问题,但我认为首先是更硬,这是大多数创新发生的,所以这就是我最关注的我的注意。

自2005年左右,我开始尝试为我们如何找出打造术语“发现”,并在2007年,我决定去所有在术语,从那时起我已提到的第一问题,因为发现和第二个作为交货

2007年,我工作的启发第一版,和我有一个发布最后期限的临近,我不得不决定什么,如果有的话,有效期内使用。

当时,几乎所有的产品经理谈到“收集和确定需求,”但我认为这是为什么有这么多失败的产品在那里的根本原因之一。对我来说,谈论定义需求不仅误导,但傲慢。

我也可以看到,在优秀的球队,产品由工程师,设计师和产品经理之间真正的合作设想。不被一些产品经理宣称“这些要求,现在去设计和建造的。”

所以我想,在产品经理和产品团队的头脑编造了非常不同的图像的一个术语。我希望他们有一个开放的心态,知道他们不知道什么,承认他们不知道是什么。

我想强调的是,伟大的产品是产品,设计和工程合作的结果。

我希望他们可以考虑这样的“找出一个解决方案,我们一直是个问题要求解决”,而不是“口述功能的需求,我们一直在问打造。”

我发现从医药行业他们曾经拿出一个可行的药物治疗过程中的术语“发现”。不同于软件行业,医药行业公认的风险前面。他们预期许多如果不是他们的药物不会最终被安全和有效的,足以制造,分销及销售的大部分。

我也喜欢术语“发现”,因为它是技术不可知论者。有任意数量的用于与发现帮助技术,以及新出现的所有时间。一个MVP是发现技术,由于是设计思维,为客户是发展,是“乔布斯工作要做。”

因为我已经看到这么多的技术和方法,来来去去,所以我不想明确其中的任何关联,这是对我很重要。

我也很喜欢,术语“发现”鼓励产品团队去思考的价值,易用性,可行性和可靠性的风险。

总的来说,我很不愿意尝试引入新的命名。这是一个很难的事情,即使人们反应良好,它需要时间来传播,并且你确实需要将注意力集中在这样的事情你的战场。

但今天我很高兴看到这么多的产品团队理解这个概念,并至少有如何以及为什么我们做产品发现一个合理的认识。

现在我更侧重于确保产品团队正在努力在他们有权做产品的发现,而不是仅仅给出的路线图建立一个环境。

分享这个