在我们深入讨论这个问题之前,先澄清一下术语:通常在我的文章中,我都尽量保持一致,当我提到“设计”时,我是指用户体验设计。然而,在这篇文章中,当我说设计时,我指的是用户体验设计和软件/架构设计。

我很高兴看到很多人现在对a和b之间的区别有了更好的理解功能团队和授权的产品团队

就在最近,杰夫·巴顿分享了一个非常引人注目的文章深入研究这种差异,并描述他关于特性团队背后心态的理论。

在这篇文章中,我想讨论一个很常见的问题:“产品发现的概念适用于功能团队吗?”

我想要谨慎回答,因为我不想成为产品发现概念完整性的捍卫者,我也充分意识到,不是每个人都能说服自己的公司去尝试转换,或者能够轻松地移动到强大的产品公司

在某种程度上,这是一个简单的问题。产品发现是关于提出一个有效的解决方案我们被要求解决的问题

如你所知,授权的产品团队是给定的问题要解决,并被授权发现一个解决方案。

相反,特性团队的定义特征是团队是给出要解决的问题;相反,他们会得到一份要构建的特性和项目列表,通常以路线图的形式呈现。

无论涉众要求什么特定的特性,他们都很可能在脑海中有一个问题,但这个人本质上描述的是他们认为最适合自己的解决方案。

因此,根据这些定义,发现与特性团队无关。

但这个简单的答案过于简单化了,值得深入挖掘。

回想一下,在产品发现中总是有四个风险需要考虑:价值,可用性、可行性生存能力.在一个被授权的产品团队中,我们需要产品管理、产品设计和工程三个关键能力,以解决所有这四个风险。

然而,在特性团队中,是涉众含蓄地承担责任价值和可行性(这就是为什么在特性团队中,产品经理扮演的角色更多的是项目经理的角色,但这是第二点)。

在特性团队中,涉众指望团队解决可用性可行性风险,这就是为什么我们仍然需要产品设计师,当然还有工程师。

所以你至少可以这么说一些探索仍然与功能团队相关。我也要向特色团队指出,他们正在培养的技能可以帮助他们在未来成为一个强大的产品团队。

但同样重要的是指出,这是一个级别的技能来设计一个可用的经验(设计师)和一个可行的架构(工程师)为一个特定的功能,但它是一个完全不同的水平能够发现一个有效的解决问题的办法(当然我们仍然需要设计解决方案)。

除了需要增加的技能外,对于特性团队来说也会有更大的压力,如果解决方案不能如涉众所希望的那样工作,那么最终这将取决于涉众。

但是在一个被授权的产品团队中,如果我们的解决方案没有达到必要的结果,那是我们的责任。对结果负责是很困难的。

另一种解释是,发现就是尝试解决问题的不同方法,以找到一个有效的方法。在功能团队中,你基本上已经知道了方法,你需要尽你所能让它变得尽可能好。

在任何情况下,特性团队的产品经理越能向领导证明她了解业务的各个方面(生存能力),并且对实际客户有深入的了解(特别是关于价值方面),领导者越有可能让功能团队尝试解决一个困难的问题,以展示他们能做什么。

分享这