要继续就共同的混乱有关产品发现的系列,在这篇文章中我想解决,有时可能会出现在产品团队主要的不满转化两支不同的球队,其中一个团队在做产品发现一个非常有害的反模式(又名“探索队”),而另一个团队正在做产品交付(又名‘交付团队’)。

Of course, I would hope anyone that follows anything that I’ve written, or really any modern product practices, knows that this is not how you want to work, and we just have a single, cross-functional product team, responsible for both discovery and delivery.

这是两个关键权力革新

通常,每个产品团队执行这两个核心活动,发现和传递连续。

当然,在任何给定时间点,不同的人对产品团队可以专注于发现活动或交付活动,显然是产品经理和产品设计师花费大量的时间发现和工程师花费大量的时间交货。但是,如果你在乎授权和创新,你会希望确保该产品团队的每个成员从事这两项活动。这真的没有花太多时间在所有的工程师住宿订婚与正在进行的工作发现。

我已经可以满足大部分人得到这个,但我偶尔会遇到一个团队,或者阅读一些文章,或者看到一些鸣叫,其中很明显的人有这个很基本的误解。

有此问题的几个常见的表现:

第一种是产品经理认为这是她的工作来定义产品,然后切换“的要求,”设计师和工程师来实施。几乎所有的纯交付团队,以这种方式工作,而且大多数功能团队做太多,但它也可能是有人进一步上行(例如一个利益相关者或企业主),这是一个确定的解决方案。

另一个特别恶劣的例子是,如果该公司的外包工程,以一个机构或承包商。

从根本上说,我们要避免一个人或一群人获得所学的知识,然后还要“切换”所学到的另一组执行上。在接收端的组不可避免地会感觉像雇佣兵,并没有觉得他们对更好的潜在解决方案的贡献将受到欢迎。

这是同样的道理,企业创新实验室有交付成果的这样的不良记录。

这是值得承认,有时候人们做出的决定,并决定该解决方案应该是什么可能是非常强的,如公司的创始人或产品非常有经验的负责人。但是,仍然会有一个极高的性价比支付动机方面,缺乏成果的所有权的,由人民在接收端,更不用说创新的大幅减少的可能性。

And over time, the people on the receiving end will self-select to those willing to work like this, and that’s when I meet founders or product leaders that complain to me about the lack of skill, initiative or ownership from the people on their teams.

所以,如果你正在努力打造强大的产品增效队伍,确保每个跨职能的产品团队能够理解,他们同时负责发现和传递工作,他们负责想出有效的解决方案并实现必要的结果。

分享这个