在我们潜入之前的一个命名澄清:通常在我的写作中,我试图保持一致,并说当我引用“设计”时,我会特别地对用户体验设计进行讲话。但是,对于这种特定的文章,当我说设计时,我的意思是用户体验设计以及软件/架构设计。

我很高兴看到很多人现在有更好地了解A之间的差异功能团队和授权的产品团队

刚刚最近杰夫帕顿分享了一个非常引人注目的文章挖掘这种差异,并描述了他在特征团队背后的心态的理论。

在这篇文章中,我想讨论一个很常见的问题,即不幸的是在功能团队上工作的人:“产品发现的概念甚至适用于特征团队吗?”

I want to be careful with my answer as I don’t want to be in the role of some sort of defender of the integrity of the concept of product discovery, and I also fully realize that not everyone will be able to convince their company to try转变,或能够容易地移动到一个强产品公司

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

正如您希望的那样,给出了赋权的产品团队解决问题,并赋予发现一个办法。

相反,特性团队的定义特征是团队是不是给予解决问题;相反,它们通常以路线图的形式构建的功能和项目列表。

无论利益相关者是否要求具体的特征很可能会有一个问题,但该人基本上描述了他们想象的解决方案将为他们最适合工作。

因此,通过这些定义,发现与功能团队无关。

但这种简短的答案是超薄的,它值得挖掘有点更深。

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

但是,在一个功能团队中,它是利益相关者,隐含责任价值和可行性(这就是为什么在一个功能团队中,产品经理更多地播放了更多项目经理角色,但这是次要点)。

在一个特征团队中,利益相关者正在依靠团队来解决可用性可行性风险,这就是为什么我们仍需要产品设计师和历时工程师。

所以你可以争辩说一些发现与功能团队仍然相关。我确实指出了他们正在建立技能的特征团队,这些技能可以帮助他们在授权的产品团队中帮助他们。

But it’s also important to point out that it’s one level of skill to design a usable experience (designers) and a feasible architecture (engineers) for a specific feature, but it’s a whole other level of skill to be able to discover an effective solution to the problem (and then of course we still have to design that solution).

除了所需的技能增加之外,如果解决方案曾希望的解决方案并不能正常工作,那么特征团队的压力也明显更大,那么这最终是在利益相关者身上。

但是,在一个赋权的产品团队中,如果我们的解决方案没有达到必要的结果,那就是我们的必要结果。负责结果是艰难的。

另一种解释方法是发现发现不同的方法来找到一个有效的问题。在一个功能团队上,您基本上已经赋予了这种方法,您需要做您尽可能擅长的事情。

在任何情况下,特征团队的产品经理越多,可以向领导者展示她理解业务的各个方面(可行性),并对实际客户有深入的了解(特别是值),更有可能的是,领导者将让特征团队尝试解决一个难题来展示他们可以做的事情。

分享这个