Product trios are cross-functional product teams who are responsible for both deciding what to build and then building it. The goal is for a product trio to represent balanced perspectives while still remaining as small as possible to facilitate and expedite collaborative decision-making.
The goal is for a product trio to represent balanced perspectives while still remaining as small as possible to facilitate and expedite collaborative decision-making. – Tweet This
In this article, we’ll cover what a product trio is, the benefits of working this way, who should be responsible for what in a trio, and much more.
Let’s get into it! You can read this article from beginning to end or you can use the links below to jump to whichever question(s) you’re most curious about.
- What is a product trio?
- Which three roles make up the product trio?
- Why is it important to work as a product trio?
- How does collaboration work in a product trio?
- How do product trios resolve conflict?
- Who is responsible for what in a product trio?
- How can you get your engineer to participate in your product trio?
- How can product trios work with user researchers?
- What about the other people on the team who aren’t part of the product trio?
- What if my job title isn’t reflected in the product trio (but I want to participate)?
- How should you run your product trio meetings?
- How can product trios adapt to remote work and distributed teams?
- Do product teams really work this way?
- How can you get started as a product trio?
What is a product trio?
A product trio is a subset of a cross-functional product team who is responsible for leading the product discovery process (i.e. the work in deciding what to build) that the full cross-functional team is responsible for building.
It’s important that the product trio be a part of the team responsible for building the product. It’s not separate from the delivery team.
It’s important that the product trio be a part of the team responsible for building the product. It’s not separate from the delivery team. – Tweet This
You can learn more about product trios in these articles:
Which three roles make up the product trio?
Most product trios are comprised of a product manager, a designer, and an engineer. But there can be other roles included as well, depending on the company. The product trio concept is flexible. It can expand and contract based on the needs of your team.
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.
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. – Tweet This
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 it 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.
Adapt the product trio concept to meet your team’s needs. The key principles to keep in mind when deciding who should be on your product trio are:
-
- Your product trio should be a cross-functional team.
- Despite the name, you don’t have to limit it to three people. However, the bigger your decision-making team gets, the slower you will move, so try to focus on the smallest team possible.
- The more relevant roles represented in your product trio, the better decisions you will make.
- There is an inherent trade-off between size and quality. Make sure to manage this. (See the answer to “What if my job title isn’t reflected in the product trio (but I want to participate)?” to explore this topic in more depth.)
You can learn more about the roles in the product trio in this article:
Why is it important to work as a product trio?
Traditionally, product managers, designers, and software engineers have worked in silos following a waterfall process with multiple hand-offs.
In a waterfall process, the product manager gathers requirements (typically from internal stakeholders), writes up a requirements document, and hands it off to the designer. The designer then attempts to do the design work required in the requirements document. Then both the requirements and the design get handed off to the engineers to build.
This sounds efficient, as we are leveraging each person’s unique talents. However, it doesn’t turn out to be efficient or effective in practice.
Here’s what happens instead: A product manager hands off requirements to a designer. The designer uncovers gaps in the requirements. The gaps expose some shortcomings that need to be addressed before the design work can be continued. The product manager iterates with stakeholders to close the gap. The designer gets a new requirements document. The process repeats itself.
The stakeholders, product manager, and designer go through several iterations, finally settling on a requirements document and design that can work, and they hand it off to engineers. The engineers scope the work and their estimate is for twice as long as the business expected. So they decide to iterate on the requirements, which leads to more design work.
They iterate back and forth again and again, and finally get the project back into scope. The engineers start building. Everything looks like it’s on track right up until the engineers uncover an unexpected issue that they didn’t predict when scoping the work. They need to add several days to the estimate. The business doesn’t want the project to slip, so they reduce the scope. This requires changes to the requirements document and the design and leads to some wasted effort on the engineering side.
We are lucky when these loop backs happen only once or twice. More often, they happen continuously. When we work in silos, we do more work, we take longer to complete that work, and we often build sub-optimal solutions.
When product managers, designers, and software engineers work together from the very beginning, they make better decisions about what to build. They make decisions that work for the business, that are usable and desirable by the customer, and that are feasible to build in the designated time.
How does collaboration work in a product trio?
A product trio is jointly responsible for a shared outcome. They interview customers together. They map out the opportunity space together. They choose a target opportunity together. They generate solutions together. And they iteratively test and develop those solutions together.
They work collaboratively from beginning to end, iterating their way to their desired outcome.
When teams interview together and visually express their thinking—through both experience maps and opportunity solution trees—they develop their knowledge and expertise together.
When teams interview together and visually express their thinking—through both experience maps and opportunity solution trees—they develop their knowledge and expertise together. – Tweet This
When it comes time to decide which opportunities to pursue or which solutions to consider, they can tackle those decisions from a shared starting point—their understanding of their customers’ context (captured by their experience map) and their customers’ needs, pain points, and desires (captured by the opportunity space on their opportunity solution tree).
When we work from a shared understanding, it’s much easier to agree on the best path forward.
However, there will still be disagreements. The difference is the disagreements will not be based on our personal preferences. Instead, we might disagree on what we think the customer wants or needs. The good thing about these types of disagreements is that we can quickly resolve them by testing our differences.
So if you’ve never worked in a cross-functional product trio and are worried about who gets to make the decisions, remember to shift the focus from your individual preferences to working to collectively understand your customers’ context and unmet needs, pain points, and desires.
Use this new shared understanding as your starting point for group decision-making.
Keep at it and you’ll be a high-performing product trio before you know it.
You can learn more about how to make decisions in a product trio in this article:
How do product trios resolve conflict?
Conflict tends to arise when we don’t take the time to understand the unique perspectives on the team. To avoid conflict, everyone needs to feel heard.
But remember, not all conflict is bad. When we disagree, it’s usually because we are working from different representations of the challenge in our heads or we are relying on different knowledge or expertise.
Think about conflict as a sign that you need to slow down and explore the diverse perspectives on your team. Doing so will help you develop a team perspective that is much stronger than any of the individual perspectives on your team.
That’s not to say you’ll always be able to resolve every conflict that arises. If you take the time to explore the diverse perspectives on your team and you still haven’t come to an agreement, you can try the following:
- Consider if someone on the team has more relevant expertise to make the decision. For example, if you are disagreeing on an issue related to feasibility, perhaps default to the engineer’s perspective or the more senior engineer’s perspective. However, only do this after taking the time to truly explore and understand the different perspectives.
- Run a quick assumption test to help you decide between the differing perspectives on the team. Be careful about invoking this too often, though. It will slow you down. Only do this for decisions that have important consequences.
Who is responsible for what in a product trio?
When building products, we need to ask a lot of questions about the underlying risks and assumptions. Is the product desirable, viable, feasible, usable, and ethical?
When assessing these risks, you might wonder whether certain members of the product trio should be responsible for specific risks. For example, maybe engineers should be responsible for feasibility and designers should be responsible for usability.
But I would argue everyone on the team is responsible for all of the areas of risk: desirable, viable, feasible, usable, and ethical. Yes, engineering is going to contribute more to feasibility and product managers might contribute more to viability.
However, if you say they are individually responsible, then you end up with competing interests and collaboration becomes impossible.
The trio is jointly responsible for building a desirable, viable, feasible, usable, ethical product.
This means that the whole team needs to be responsible for all areas. If you say an engineer is responsible for feasibility and a designer is responsible for usability, then what happens when the most usable design isn’t the most feasible? It puts the engineer and the designer at odds. But when both the engineer and the designer are responsible for both, they now have to work together, each contributing their own expertise, to find a usable and feasible solution.
Every member of the product trio is responsible and accountable for assessing each type of risk. I know this can be a hard concept to grasp in our current business context. Most of us work in silos. We’ve never had the experience of truly collaborating. But I do believe that if product trios truly want to collaborate, they have to learn to be responsible and accountable for all of the risks.
You can learn more about balancing different responsibilities in a product trio in this article:
How can you get your engineer to participate in your product trio?
While I’ve met many engineers who don’t want to do discovery, I’ve rarely met an engineer who didn’t have an opinion about what the team should be building.
Many engineers resist participating in discovery because of the universal fear of the unknown. Engineers don’t want to do discovery because they don’t know what it entails.
Many engineers resist participating in discovery because of the universal fear of the unknown. Engineers don’t want to do discovery because they don’t know what it entails. – Tweet This
You can help build momentum and enthusiasm for discovery by starting small and iterating. Just like we need to create a pleasant onboarding experience for our customers, we also need to onboard our engineers to discovery.
So don’t invite them to conduct an interview as a first step. Instead, ask them to watch a video of an interview you’ve already conducted and ask them to share their thoughts. Help them convert those thoughts into opportunities.
After that, invite them to observe your next interview live. From there, you might ask them to take notes. After that, you might ask them to suggest a question or two. Then you might role play some mock interviews where they conduct the interview.
Again, this isn’t unique to engineers. Most of us need time, space, and practice to get comfortable with a new skill.
As you gradually remove unknowns, you’ll see much of the resistance to discovery fade away.
To learn more about getting engineers involved in discovery, check out these articles:
- Why Engineers Should Participate in Discovery
- Core Concept: Getting Engineers to Embrace the Product Trio
How can product trios work with user researchers?
If you have enough user researchers to embed one in each product trio, be sure to include your researcher throughout discovery. They can help you improve the reliability and the validity of both your customer interviews and your assumption tests.
Be careful, however. Sometimes when we embed user researchers on product teams, it can be easy for the team to let the user researcher do all the research on their own. We don’t want this.
It’s important that the product trio conduct the research together so that they each have firsthand exposure to the customer. Remember, this is what allows us to avoid hand-offs, makes our research more believable, and helps us see the gaps between how we think of the product and how our customers think about the product.
Even when we have a user researcher embedded with the product trio, we still want the entire trio involved in the research.
If you don’t have enough user researchers to embed one on each of your product teams, you can assign a user researcher to several teams acting as a subject matter expert. Again, this does not mean that the user researcher does all of the research for each of their teams. This will create bottlenecks that will slow all of your teams down.
Instead, the user researcher should be available to give guidance on interviews and assumption tests. They can help their teams increase the reliability and validity of their research methods. They can help train the individual members of the trio in different techniques so that everyone gets better at research.
To learn more about how product trios and user researchers can work together, see:
What about the other people on the team who aren’t part of the product trio?
Each company hires and designs their team structure based on their own needs. If you want to build successful digital products, you need to take a cross-functional approach to decision-making.
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.
Trios should be consulting other members of the team, but limiting who leads the discovery process allows teams to move quickly. – Tweet This
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.
To learn more about collaborating with your broader cross-functional product team, check out:
What if my job title isn’t reflected in the product trio (but I want to participate)?
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.
With product trios, our goal is to balance the speed of decision-making with the quality of decision-making. – Tweet This
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.
How should you run product trio meetings?
This should be up to your team. But I’ll make some recommendations:
- You’ll need some real-time interaction every day. On some days, this might be as short as a traditional standup where you just check in and share your discovery progress with each other. Other days, this might be a longer working session where you choose a new target opportunity, story map solutions, or review assumption test results. These sessions can be in person if you are co-located or virtual if remote.
- It will be hard to break the habit of falling back on your functional silos. You’ll be tempted to defer to the person with the most expertise (e.g. the designer for all usability decisions, the engineer for all feasibility concerns). While you do want to take into account everyone’s expertise when working together, you also want to take the time to explore the different perspectives so that you make the best possible team decision that you can. Yes, the engineer might know the most about feasibility, but that doesn’t mean the product manager or designer can’t raise an issue that the engineer didn’t consider. When making key decisions, make sure everyone has a chance to develop and share their own perspective before you make a decision.
- Collaboration is harder than it sounds. When you are a newly formed trio, you may need to spend a lot of time together as you go through the storming phase before you find what works best for your team. Be patient as you go through this. It will get better as you work together more.
How can product trios adapt to remote work and distributed teams?
I don’t believe teams need to be co-located to do good work. We now have several examples of highly successful companies that are fully remote—Atlassian, Automattic (the creators of WordPress), and Zapier are a few that come to mind.
However, it is required that you have some overlapping working hours with your full product trio every single day. This is non-negotiable. Product trios need ample time for discussion, debate, and collaboration.
If you are working on a remote team, be sure to take the time to set team norms. Define your overlapping work hours. Set clear communication rules and boundaries. Make sure it’s clear when everyone is working and what types of communication are appropriate when. Agree on the virtual collaboration tools that work best for everyone.
Taking the time to establish team norms will help your team move through the storming phase faster and into the performing stage sooner.
To learn more about working with remote and distributed product teams, see:
Do product teams really work this way?
Yes. Here are several articles where teams have shared their experiences working as a product trio:
- Botify on the Road to the Product Trio
- Product in Practice: All It Took Was One Product Trio to Inspire Change—The Hemnet Story
- Product in Practice: One Product Manager’s Quest to Adopt Continuous Discovery at Her Company
- Product in Practice: When Travel Ground to a Halt, Seera Group Used Opportunity Mapping to Discover a New Market
- Product in Practice: How 2-Way Door Decisions Helped Simply Business Learn Fast
How can you get started as a product trio?
If you are new to the discovery habits, you can simply start by inviting your cross-functional colleagues to give input as you make decisions.
But if you have already adopted some of the discovery habits, there are several steps you can take. It’s important to make sure you’re aligned on your desired outcome, since this will guide your other activities and approach to decision-making.
As a trio, you can start interviewing customers, creating interview snapshots, and mapping opportunities on an opportunity solution tree.
You could also map your assumptions, decide which ones are riskiest, and agree on ways to test these assumptions.
No matter what you do as a trio, it’s important that you keep your stakeholders informed of what you’re learning and how that’s influencing your decision-making.
No matter what you do as a trio, it’s important that you keep your stakeholders informed of what you’re learning and how that’s influencing your decision-making. – Tweet This
Once you start to build some momentum, you might look for ways to help other trios get up and running. This could involve sharing tools and templates or offering training sessions.
To learn more about how one product trio got started and influenced others within their company, check out:
The post Product Trios: What They Are, Why They Matter, and How to Get Started appeared first on Product Talk.
Product Trios: What They Are, Why They Matter, and How to Get Started was first posted on June 5, 2024 at 6:00 am.
©2022 “Product Talk“. Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement. Please let us know at support@producttalk.org.
