The feature teams get to work first designing the features on the roadmap, maybe doing a little usability testing, and then proceeding to building, QA testing, and deploying the features (known as delivery).
These feature teams sometimes claim they're doing some product discovery, but they rarely are. They've already been told what the solution should be; they're not empowered to go figure out the solution themselves. They're just there to design and then code.
In these feature teams, there is usually a person with the product manager title, but they are mainly doing project management. They are there to ensure the features get designed and delivered. Necessary perhaps, but this is not product management.
Because the teams are provided, or are pressed to provide, roadmaps of features and projects, the focus of the team is delivery—delivery of these features. And features are output. Even if someone were to complain of lack of business results, who would you hold accountable?
In contrast, in strong product companies, teams are instead given problems to solve, rather than features to build, and most important, they are empowered to solve those problems in the best way they see fit. And they are then held accountable to the results.
In the empowered product team model, the product manager has a clear responsibility, which is to ensure that the solutions are valuable (our customers will buy the product and/or choose to use it), and viable (it will meet the needs of the business). Together with a product designer who is responsible for ensuring the solution is usable, and a tech lead who is responsible for ensuring the solution is feasible, the team is able to collaborate to address this full range of risks (value, viability, usability, and feasibility). Together, they own the problem and are responsible and accountable for the results.2
So, to summarize feature teams vs. empowered product teams:
Feature teams are cross‐functional (a product manager doing mainly project management, a product designer, plus some engineers), and assigned features and projects to build rather than problems to solve, and as such they are all about output and not business results.
Empowered product teams are also cross‐functional (a product manager, a product designer, and engineers), but in contrast to feature teams, they are assigned problems to solve, and are then empowered to come up with solutions that work—measured by outcome—and held accountable to results.3
Product Discovery
If you have not yet read INSPIRED, then you might be wondering: What is so wrong with the business owners and stakeholders deciding what goes on the roadmap, and therefore what the engineers should build?
This is considered the first and most important principle of product discovery: our customers, and our stakeholders, aren't able to tell us what to build.
It's not because our customers or stakeholders aren't smart or knowledgeable.
There are two fundamental reasons why our customers and stakeholders aren't able to tell us what to build:
First, the customers and stakeholders don't know what is just now possible—they are not experts in the enabling technologies, so they can't be expected to know the best way to solve the problems we're focused on, or even if the problem is possible to solve. It's often the case that innovations solve problems in ways that customers and stakeholders had no idea was possible.
Second, with technology products, it's very hard to predict in advance what solutions will work. There are many reasons why product ideas don't deliver the results we hoped. All too often we are excited about some idea, but our customers are not, so they don't buy what we thought they would. Or, we discover the idea has major privacy or security issues. Or we find out the idea will take much longer to build than anyone expected.
Empowered product teams understand these inherent issues, and product discovery is about discovering a solution that our customers love, yet works for our business.
We refer to this as product discovery to acknowledge that we understand what we can't know in advance, and to emphasize that our task is to discover a solution that is valuable, usable, feasible, and viable.
Notes
1 1 For an unflinching critique of these companies when it comes to their policies, see the writings of Professor Scott Galloway (www.profgalloway.com).
2 2 To be clear, the designer and tech lead contribute much more than simply ensuring usability and feasibility respectively; what I'm referring to here is who we hold responsible and accountable for each risk.
3 3 There is actually a third type of technology team, which is referred to as a delivery team (or “Scrum team” or “dev team”). A delivery team doesn't even pretend to be a true product team. They are not cross‐functional, and they are not empowered. There is a product owner (responsible for administering the product backlog) and some number of engineers. They are purely about output (code and ship). If you're running a process like SAFe, then this is unfortunately you, and truthfully, I have no idea why you would want to read this book, since what I describe here is the polar opposite both philosophically and practically.
CHAPTER 2
The Role of Technology
I promise that this book is very practical, and you'll be able to directly apply everything we discuss. But in this one chapter, if you'll bear with me, we need to get just a little philosophical.
It is plain to see the difference between feature teams and empowered product teams.
It is plain to see when companies view teams as there to serve the business, versus when they're there to serve customers in ways that work for the business.
It is plain to see when a company is just trying to please as many stakeholders as possible, versus when they have a clear and intentional product strategy.
But while these differences might be plain to see, that does not explain why these differences exist.
If we hope to close the gap between the best and the rest, we need to look at the root cause of this gap.
Roughly a decade ago, Marc Andreessen published what I consider one of the most important essays of our time, “Why Software Is Eating the World.”1 He described why he believed that technology was about to cause major disruption across virtually every industry. He gave voice to what I had been seeing in my own work—primarily with the disruptors, but occasionally with those under threat of disruption.
Ten years later, it's clear he was remarkably prescient.
That said, most companies seem to have not really understood his warnings.
Yes, they're all spending more on software now.
Yes, they've (mostly) moved to Agile methods.
But most have not transformed