Discovery – Delivery
To continue with the series on common confusions regarding product discovery, in this article I want to tackle a very damaging anti-pattern that can sometimes arise where the product team essentially devolves into two different teams, where one team is doing product discovery (aka “discovery team”), and another team is doing product delivery (aka “delivery team”).
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.
This is key for both empowerment and for innovation.
Normally, each product team performs these two core activities, discovery and delivery, continuously.
Certainly, at any given point in time, different people on the product team may be focused on discovery activities or delivery activities, and obviously the product manager and product designer spend most of their time on discovery, and the engineers spend most of their time on delivery. But if you care about empowerment and innovation you will want to make sure that each member of the product team is engaged in both activities. It really doesn’t take much time at all for engineers to stay engaged with the ongoing discovery work.
Most people I meet already get this, but I do occasionally meet a team, or read some article, or see some tweet, where it’s clear the person has this very basic misunderstanding.
There are a few common manifestations of this problem:
The first is where the product manager believes it’s her job to define the product, and then hand-off “the requirements” to the designer and engineers to implement. Pretty much all pure delivery teams work this way, and most feature teams do too, although it may also be someone further upstream (e.g. a stakeholder or business owner) that is the one defining the solutions.
Another especially egregious example is if the company outsources their engineering to an agency or contractors.
Fundamentally we want to avoid having one person or group obtain the learnings, and then have to “hand-off” what they learned for another group to execute on. The group on the receiving end is inevitably going to feel like mercenaries, and not feel like their contributions on better potential solutions would be welcomed.
It’s the same reason that corporate innovation labs have such a poor record of delivering results.
It’s worth acknowledging that sometimes the people making the decisions and deciding what the solution should be may be very strong, such as a company founder or very experienced head of product. But there will still be a very high price paid in terms of motivation, and lack of ownership of the results, by the people on the receiving end, not to mention the substantially reduced likelihood of innovation.
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.
So if you’re working to create strong empowered product teams, be sure that each of your cross-functional product teams understands that they are responsible for both discovery and delivery work, and they are responsible for coming up with effective solutions and achieving the necessary results.
