What makes product trio a product trio
#48: Dispelling misconceptions about the product trio
Welcome to Fundament, a weekly product design newsletter where we share actionable tips and insightful stories with the worldwide design community.
Despite the fact that we have recently published a brightly written article on the concept of the product trio, something triggered me to sit down and write this follow-up. A few weeks ago, I attended a product management meetup where, you wouldn’t guess, the theme was product trio. While I was listening to the panelists discuss how some of them employed this concept in their organizations, I rolled my eyes so many times you’d think it was really disrespectful.
Luckily, I was sitting at the back so they couldn’t see my reaction.
In this article, I aim to dispel three main misconceptions about the product trio that I’ve heard from the stage on this day. I wish other organizations would not repeat the same mistakes.
If you work in a product trio (or think you do), but find any of the following points valid, you should stop and think for a moment.
Something is wrong with your product trio.
The three main misconceptions about the product trio:
Continuity: The product trio is project-based.
Size: The product trio can grow to the size of the entire product team.
Implementation: The product trio has to be introduced from the top.
Let’s delve into each point.
Continuity
According to Teresa Torres’ product trio guide, a product trio is a subset of a cross-functional product team focused on product discovery. While the product discovery process is continuous and ongoing until the product is shut down, ergo the product trio lasts for the same amount of time, or at least its existence or composition is not project-based.
Imagine a typical product team. Here’s a product manager, five software engineers, and a product designer. This product team could be responsible for a relatively small and simple product or a subset of a larger and more complex product, such as a checkout process in an e-commerce platform.
Whereas product discovery experts recommend weekly touchpoints with customers, the fact is that for some teams, it can be challenging to accomplish. As a result, our product trio talks to customers bi-weekly. In addition, they review the data in product analytics on a weekly basis to identify emerging trends, gaps in the experience, and spot opportunities. They also leverage insights brought by the commercial and customer support teams, stored in a single repository.
Employing all this knowledge, the product trio decides what to build next. Ergo, they are responsible for determining the direction the product will take. To successfully do that, the existence and composition of the product trio cannot be project-based.
If it were project-based, the team wouldn’t be doing product discovery but rather some sort of user research. Most likely, the requirements would flow from the top through a product manager down to a designer, who would create a mockup and then hand it off to the engineers. That’s exactly the opposite of a product approach. In that setting, the product trio doesn’t make any sense.
Size
Despite the name of the concept, which stands for the body consisting of three people, a product manager, a product designer, and an engineering lead, nothing stops you from adding one (product quartet) or two (product quintet) more persons, such as a researcher, and another engineer (if you have a clear split between frontend and backend engineering in your team setting). However, you must remember that the more people you include in this body, the more complex the decision-making will be.
The trio, quartet, or quintet should remain a subset of a bigger group, your entire product team. This body drives product discovery and identifies the problems the whole team should focus on now, as well as how these problems can be addressed. In other words, they dictate what to build.
Once the problem space has been explored, the product trio can (and even should) consult with the entire product team on how to approach the possible solutions. That’s exactly what I do with my team. In our product trio, we discuss the problems we want to invest our time in over the next couple of months. Then, either during an ideation brainstorming session or an asynchronous ideation week (I’ll publish a separate article focused on this topic in a few weeks), we involve everyone on the team. Every engineer can submit their idea to address a specific user pain point we have previously identified. At the end, we vote on ideas and pick the best one we want to bet on.
With such a setting, the product trio is responsible for driving product discovery, and the whole team contributes to the product delivery. Everyone on the team has some influence on the product's shape, and the team dynamic remains relatively healthy.
Implementation
Not every organization works in this model or even has heard of the concept of the product trio, which may be surprising for some, given that Marty Cagan introduced it in the first edition of his book titled “Inspired” almost 20 years ago. Even if you argue he didn’t call it a trio by that time, it’s been four years since the release of “Continuous Discovery Habits” by Teresa Torres, where she explicitly called this concept the product trio. Nevertheless, I’m not surprised by the slow adoption, so that’s why our recent article offers some tips on getting started with the product trio in your organization.
So, how can you, as an individual contributor or first-line team manager, make a step towards change?
Start by building awareness around the concept of a product trio and educating your team on its benefits.
Mateusz Litarowicz, Fundament #40, The Product Trio
Once you fall in love with the idea of being a missionary rather than a mercenary, this initiative of implementing the product trio in your team and eventually the entire organization needs to come from you. Begin discussing it with your product manager. Get closer to them and probe if that’s something they would like to try. Once you have a good rapport, identify who’d be the best pick for an engineering atom in your trio. It usually is the most senior person, but it doesn’t have to be. The engineering lead in the product trio must be someone who can be trusted, communicate effectively, and doesn’t pull the string too much in one direction.
While some may think the change should come from the top, I believe the best way to implement the product trio is from the bottom. Not to mention that oftentimes, when a major change in ways of working is coming from the top, it affects the entire organization and brings chaos.