Discovery vs. Design

One nomenclature clarification before we dive into this:  Normally in my writing I try to be consistent and say that when I reference “design” I am speaking specifically about user experience design.  However, for this particular article, when I say design I mean both user experience design as well as software / architecture design.

I’m glad to see that many people now have a much better understanding of the differences between a feature team and an empowered product team.  

Just recently Jeff Patton shared a very compelling article digging into this difference, and describing his theory on the mindset behind feature teams.

In this article, I’d like to discuss one of the very common questions I get from people that are unfortunately working on feature teams: “Does the concept of product discovery even apply to feature teams?”

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 transforming, or be able to easily move to a strong product company.

At one level, this is an easy question.  Product discovery is about coming up with an effective solution to the problem we have been asked to solve.  

As you hopefully know, empowered product teams are given problems to solve, and empowered to discover a solution.

In contrast, the defining characteristic of a feature team is that the team is not given problems to solve; they are instead given a list of features and projects to build, usually in the form of a roadmap.

Whatever stakeholder requested the specific feature very likely has a problem in mind, but that person is essentially describing the solution they imagine will work best for them.

So by these definitions, discovery is not relevant for feature teams.

But this short easy answer is oversimplified, and it’s worth digging a bit deeper.  

Recall that in product discovery there are always four risks to consider: value, usability, feasibility and viability.  In an empowered product team we need the three critical competencies of product management, product design and engineering in order to address all four of these risks.

However, in a feature team, it is the stakeholder that is implicitly taking responsibility for value and viability (which is why on a feature team, the product manager plays more of a project manager role, but that’s a secondary point).

On a feature team, the stakeholders are counting on the team to address the usability and feasibility risks, which is why we still need product designers and of course engineers.

So you could argue that at least some discovery is still relevant to a feature team.  And I do point out to feature teams that they are building skills that can help them in the future on an empowered product team.

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).

In addition to the increased skill required, there is also significantly more pressure in that for a feature team, if the solution doesn’t work as the stakeholder had hoped, then that’s ultimately on the stakeholder.

But in an empowered product team, if our solution does not achieve the necessary outcome, that’s on us.  Being accountable to results is hard.

Another way of explaining this is that discovery is all about trying out different approaches to a problem to find one that works.  On a feature team, you are essentially already given the approach, and you need to do what you can to make it as good as possible.

In any case, the more the product manager of a feature team can do to demonstrate to leaders that she understands the various dimensions of the business (viability), and has an in-depth understanding of the actual customers (especially regarding value), the more likely the leaders will be to let the feature team try tackling a hard problem to show what they can do.