Marty Cagan, a well-known reference in the digital product community wrote some time ago an interesting article about Product vs Feature Teams where he explains the difference between three types of product teams, Delivery Teams, Feature Teams, and Product Teams. He wrote a follow-up article where he summarizes the definition of each team type:
- Delivery teams are not cross-functional (basically just developers plus a backlog administrator product owner), they are not focused on outcome (they are all about output), and they are not empowered (they are there to code and ship).
- Feature teams usually are cross-functional (at least some form of designer and some form of product manager), but they are still all about output and not empowered.
- Product teams are cross-functional, focused and measured by outcome, and empowered to come up with solutions that work.
He explains that the best results for the organization that owns the product and the users of that product come from the teams he calls Product Teams. He has been using a lot the empowered word to describe these teams.
In this article, I want to provide a new perspective to help people understand the differences between these types of teams, why empowered product teams yield the best results, and some tools to help you build these teams.
Problem vs solution mindset
I’ve already explained the difference between problem vs solution mindset. When we learn about a problem, it’s human nature to jump into solution mode and try to come up with solutions to this problem. However, the more time we spend on understanding a problem, its causes, its context, and the motivation people have to solve it, the bigger the chances to find the best solution for the problem.
Any digital product exists for two main purposes:
- To help the company who owns the digital product to achieve its objectives.
- To solve the problems and fulfill the needs of its users.
So any digital product and its features are solutions to problems from the company that owns the product and solutions to solve user problems and fulfill their needs.
In this digital product context, when I say that spending more time understanding the problem yields the best solutions, I mean that we are able to deliver as fast as possible the best product and features to solve the problem at hand with good software quality and good user experience.
Problem solver vs solution implementer teams
What Marty describes as delivery teams and feature teams are solution implementer teams. These teams work on implementing a solution devised by someone else. This someone else is normally someone from the so-called “business area”, which can be someone from sales, marketing, client success, customer support, finance, operations, a C-level, or a founder. In such a team, the product manager mainly manages the backlog and helps the team deliver the requested solution, the product designer is mainly focused on designing a nice interface, and the engineers have to code and deploy the requested solution. The solution implementer teams implement what was asked, with little to no commitment to the quality of the solution, or even if the implemented solution actually solves the problem.
On the other hand, what Marty describes as empowered product teams are problem solver teams. These teams work on deeply understanding the problem’s causes, context, and the motivation people have to solve it. By doing so, they are able to implement the best solution to the problem at hand.
There are 3 main reasons why problem solver teams are more effective than solution implementer teams:
- Digital product literacy: There’s no one better than the problem solver team members to find the best digital product solution to a problem. A solution that is delivered as fast as possible, with good software quality and good user experience. This happens because a problem solver team is a multi-functional team composed of engineers, who understand the technology available, product designers, who have a deep understanding of the users, their pains and their needs, and product managers, who have a good understanding of the business context of the problem to be solved.
- Two heads are better than one: this old saying means that it’s easier for two people who help each other to solve a problem than it is for one person to solve a problem alone. A problem solver team will not discard any solution suggestion from the “business areas”. Actually, these solution suggestions are very insightful to help the team gain a better understanding of the problem, but these solution suggestions should be considered as what they are, suggestions. A problem solver team first deeply understands the problem and then analyses solution options.
- Commitment: an additional side-effect of a problem solver team is that the members of this team are deeply committed to the success of the solution implementation since they are deeply involved in the solution-finding process.
Building problem solver teams
Now that I explained why problem solver teams are the best type of product teams a company can have, I’ll explain how to build problem solver teams. There are three aspects that need to be considered:
- environment: it’s critical that the entire organization understands the power of having problem solver digital product teams. The speed and quality of the solutions delivered by a digital product team that always start solving problems by having a deep understanding of the problem is way better than solutions delivered by solution implementer teams. Consequently, the business results will be better and will be achieved faster. It’s the role and responsibility of the VP/head of product to help the organization understand this.
- what is the problem: a very effective way to focus the entire organization away from solution mindset and into problem mindset is to constantly ask “what is the problem we are trying to solve?” and “why is it important to solve this problem?”. This will help people from the entire organization change their perspective and, consequently, realize the importance of deep problem understanding prior to implementing a solution. This is a behavior change that the entire digital product team can help their organization to make. Whenever someone asks the product team to implement something, ask “what is problem”.
- trust: this is a critical aspect for building successful problem solver digital product teams. Normally people from “business area” believe they have a better understanding of the business the people from the product team. This behavior is even more visible when the digital product team is new in the organization. How can a new person in the organization understand more about the business than the people that are in the company for years? Probably this new person can not, especially if this person comes from a different market. However, the people that are part of the digital product team normally have a lot of experience in building digital products, probably more experience than anyone else in the organization. For this reason, it is essential that the “business area” educate the digital product team on the business aspects of the organization. This education seeking is the role and responsibility of the product managers, who must learn from the “business area” and educate the product designers and engineers about the business. One practical way to accelerate this learning is to bring people from the “business area” to the problem understanding sessions. This is how the product team earns the trust of the other areas of the organization.
By now I believe it’s clear the benefits of having problem solver vs solution implementers digital product teams. The entire organization needs to understand the difference in order to push for having more and more problem solver teams. The VP/head of product has this as one of her biggest responsibilities, to help build the environment and the trust needed for problem solver teams thrive.
Digital Product Management Books
Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success? Check out my new bundle Digital Product Management with my 2 books where I share what I learned during my almost 30 years of experience in creating and managing digital products.