Have you heard? My new book Continuous Discovery Habits is now available. Get the product trio's guide to a structured and sustainable approach to continuous discovery. 
In this short video, I address the most common question I’ve received since releasing my book Continuous Discovery Habits: Why didn’t you include my role in the product trio?
You can watch the video or read a lightly edited transcript below.
Who should you include in your product trio?
Does a product trio exclude everyone else from discovery decisions?
What about user researchers, data analysts, product marketing managers, and all your other favorite roles?
How do you decide who should be part of the product trio that leads discovery?
In my book Continuous Discovery Habits, I wrote that a product trio is typically comprised of a product manager, a designer, and a software engineer.
So naturally, everyone who has a title other than one of those three roles reached out to me. Some with quite a bit of outrage.
Why didn’t I include user researchers? Product marketing managers? UX writers? Data analysts? Data scientists? Business analysts? And so on.
Let me be clear: The product trio concept is flexible. It can expand and contract based on the roles available at your company.
The product trio concept is flexible. It can expand and contract based on the roles available at your company. – Tweet This
Every organizational context is unique. It’s not possible to create one definition that will work for every context. When I defined a product trio as typically comprising a product manager, a designer, and a software engineer, I was describing what I see at the vast majority of companies that I work with.
This concept is not new. We’ve been talking about three-legged stools, triads, and the three amigos for a couple of decades now.
The intent with a product trio is not to exclude other roles from discovery. It’s to highlight the need for cross-functional collaboration when building digital products. The most common form of cross-functional collaboration happens between product managers, designers, and engineers.
However, this concept can and should be adapted based on your unique context. For example, if you work on a machine learning API, it might make sense to include a data scientist in your trio, making a quad.
If your company is committed to user research and you have the luxury of having a user researcher embedded on each of your teams, you probably want to include them in most of your discovery decisions.
Like everything, defining your product trio requires judgment.
However, it’s important that you also consider the consequences of including more people on the team that leads discovery.
The more people involved in every decision, the longer each decision will take, and the longer it will take to ship value to your customers. Our goal is to balance speed of decision-making with the quality of decision-making. The key is to include the right roles for each decision.
Our goal is to balance speed of decision-making with the quality of decision-making. – Tweet This
Since my book has come out, I’ve heard from user researchers, content marketers, product marketing managers, UX writers, business analysts, product owners, scrum masters, project managers, and program managers. I’m sure after this video is released, I’ll hear from half a dozen other roles that I have yet to mention.
First of all, most companies don’t have all of these roles. To be clear, I’m not saying companies shouldn’t have these roles. Each company hires and designs their team structure based on their own needs. What I am saying is that if you want to build successful digital products, you need to take a cross-functional approach to decision-making.
Second, I am saying that not all of these roles should be involved in every decision. Teams need to be thoughtful about which perspectives are most relevant to any given decision. Trios should be consulting other members of the team, but limiting who leads the discovery process allows teams to move quickly.
Third, a product trio leads discovery. That doesn’t mean that other people on the team can’t (or shouldn’t) be involved in discovery. They should. The more exposure, for example, your engineers have to customers, the better they will be at their jobs. But that doesn’t mean they have time to come to every customer interview, be involved in the design of every assumption test, and be included in every decision. Your team’s output would grind to a halt.
Just like all five of your engineers don’t jointly write every line of code and your entire design team doesn’t collaborate on every interface element, your entire team doesn’t need to be involved in every discovery decision. It’s just not practical.
I get why people react strongly to the product trio concept. Nobody wants to feel left out. However, having 13 people involved in every decision just isn’t practical.
If you currently aren’t included in your product trio, I’d recommend starting by getting clarity on where you can contribute the most. Ask yourself, when and where is my expertise most valuable? What are the types of decisions where we have to redo work because my expertise wasn’t consulted early enough?
If your answer is everything, prioritize. What are the most important decisions for you to be included in? Focus there.
The product trio concept isn’t designed to exclude. Everyone plays a role in discovery. Start by getting clarity on where you can best contribute to the team and build from there.
