Empowerment of an engineer means that you provide the engineers with the problem to solve and the strategic context, and they are able to leverage technology to figure out the best solution to the problem. An easy way to tell whether or not you have empowered engineers is if the first time your engineers see a product idea is at sprint planning, you are clearly a feature team and your engineers are not empowered in any meaningful sense. If you're just using your engineers to code, you're only getting about half their value.
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.
Feature teams look superficially like a product team. They are cross‐functional, with a product manager, a product designer, and some number of engineers. The difference is that they are all about implementing features and projects (output), and as such are not empowered or held accountable to results. 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).
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.
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.
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.
