The smallest group of caring, empowered, competent people who trust each other and are driven by a common mission is what I call the Product Team Kernel.
The kernel is the first part of the operating system to load into memory during booting (i.e., system startup), and it remains there for the entire duration of the computer session because its services are required continuously. Thus it is important for it to be as small as possible while still providing all the essential services needed by the other parts of the operating system and by the various application programs.
http://www.linfo.org/kernel.html
What combination of people make up an ideal product team? Who knows. There is no generic formula. It depends on the tasks at hand, the business context it operates in and the resources available. Even with that clarified there are many possible combinations that could work. Or fail.
Instead of trying to find the perfect combination of people, let’s focus on what the product team is here for: “solve hard problems in ways their customers love, yet work for their business” (Marty Cagan, Empowered Product Teams).
Solving hard problems
To solve hard problems we must understand the problems. The problem solvers should hence be competent in listening and abstracting the feedback from customers to identify the underlying job the customer is trying to accomplish.
The same group needs to be able to come up with a solution to the problem too. This solution must not only address the customer’s problem within the constraints of the business. The solution also needs to be understood and usable by the customer. Above that, the team needs to be able to deliver the solution.
In a tech company a group that will be competent for this is the classic trio of Product Manager, Designer and (Senior) Engineer. Give or take.
These 3-ish people form the product team kernel.
Trust and speed
Wouldn’t a solution benefit from more brains? What about the marketing input? Sales, success and support have great ideas too. And data-scientists. Definitely data-scientists.
Maybe.
In some situations (like when you are actually in a ML-product team) other capabilities can be helpful, even necessary. Usually they are not part of the kernel. The main reason for the kernel of the team to be as small as possible is two-fold:
- Trust: The members of a high-performance team need to trust each other. They will engage in many discussions and should always feel safe to voice their opinions freely. This requires trust. The larger a group, the harder it is to build a high-trust relationship among ALL members.
- Speed: The number of connections is proportional to the square of the number of connected people (n2). Keeping less people in the loop is faster. Creating a shared mental model among fewer people (who already trust each other) is faster. Collaborating daily in quick iterations is far easier to achieve with 2-3 people than with 4+ people.
| The Need for Speed In this context I am referring to the speed of learning (and especially not the velocity at which development teams deliver features). Great teams understand that it matters far more to build the right things, than to build many things. Every shipped item has costs (maintenance, support, dependencies etc.). These costs compound over time and take away capacity of a team, as it faces an increasing amount of “keep the lights on” work. There are only three ways to deal with this inherent decay of team capacity: (1) split the team/add resources, (2) kill features that don’t work, (3) ship more impactful features. The latter being the most effective way of dealing with the challenge, a team needs to optimise for finding the most impactful solutions to the customers problems. With the vast amount of unknowns in this kind of process, the team must optimise for learning. Its main task – given any problem – is to reduce uncertainty. |
Attitude
While each member of the product team kernel brings their expertise to the table, there are a few traits that all of them should have:
- Outcome-driven: Teams exist for a reason. Teams tackle problems for a (strategic) reason. All members of the team, especially the product team kernel, need to keep the desired outcome front and centre.
- Customer-focused: The kernel of the product team needs to know their customers in and out. Learning about human behaviour, the context of the needs and the interactions of people with the technology the team produces are the paths to a better understanding of the problem. A better understanding of the problem space will yield the necessary insights for good new solutions.
- Resourceful: There are many constraints when building products. Even more so when moving fast and experimenting rapidly. Having people on the team that are resourceful is imperative. This is a team of doers. Be it finding users to talk to, whipping up a quick prototype, getting help on a technical question or recording a user’s facial expressions on an interview – overcoming the obstacles is the name of the game.
tl;dr
An effective product team has a kernel of as few people necessary tasked with reducing uncertainty about the problem, so they can find the most impactful solution fast. This product team kernel requires high trust among members, expertise in their respective fields, and an outcome-driven, customer-focused, resourceful attitude.