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. If you’ve ever felt like working as part of a product trio was hard, you’re not alone. We often field questions or comments from people who are skeptical about how this type of collaborative decision-making can work, so we’ve known anecdotally for quite a while that this is a challenge. But now we also have data to back this up.
Back in the fall of 2022, Teresa ran the inaugural CDH Benchmarks survey, which asked roughly 2,000 people about their discovery habits.
(By the way, we are running this survey again. We’d love to learn more about how your team works. You can fill it out here. All respondents will be entered in a raffle to win free Product Talk Academy courses.)
We were thrilled to see that 62.7% of respondents indicated they worked in a trio and 69.3% said their trios were made up of the typical roles of product manager, designer, and software engineer.
But in her analysis of the data, Teresa wrote, “It’s one thing to work in a product trio. It’s another thing entirely to work well with your trio.” To try to get more accurate data on how well people were working in their trios, Teresa asked additional questions in the survey, including how many hours respondents spent collaborating with their trios in the past week, how long the trio has been together, and whether they felt like everyone had an equal say in decisions that were made in their product trio in the past week.
And this is where things got interesting.
While 69.7% of respondents said they feel like everyone had an equal say all or most of the time, 30.3% of respondents said this was only the case some of the time or it never was.
For those who said, “No, only some of the time” or “No, rarely or never,” the survey also asked, “Why wasn’t everyone able to have an equal say?”
While 69.7% of respondents said they feel like everyone in their product trio had an equal say all or most of the time, 30.3% of respondents said this was only the case some of the time or it never was. – Tweet This
The responses were fascinating, so we spent some time combing through them to identify whether there were any patterns. We ended up identifying 12 main categories. In this article, we’ll take a closer look at each category, share a few specific responses, and provide some thoughts on how you might try to overcome these challenges to work more effectively in your trio.
Reason #1: The Product Manager Makes the Decisions
This was the most commonly cited reason, and there were several variations in responses, including points like the PMs are the ones who are held accountable for the trio’s success or failure, they have closer contact with customers, or they’re more highly regarded within the company’s organizational structure.
A few sample answers included:
- “Because Product Managers hold the final accountability of what we’re building.”
- “It can be very difficult for a PM to not introduce their bias – even if they do not intend to do this and therefore I think this role can have slightly more decision power in our org.”
- “I’m a product manager and want to introduce this new practice in my team. So for now I mainly introduce the topic and schedule interviews. I first show by example and progressively they’ll take more ownership.”
Reason #2: The Engineer Makes the Decisions
Another common response, this also had several variations in the explanations, including points like engineering tends to be more respected or drive more organizational decisions, engineers’ time is seen as more valuable, and engineers have strong personalities and opinions.
A few sample answers included:
- “Dominant engineering manager bound to strict deadlines set by management, vetoes complex solutions and dictates how feature must look like and behave for his team to meet the deadline.”
- “Engineering driven organization, sometimes not fully driven by customer needs.”
- “Engineering has the most say as the perception is that they drive the feasibility of products.”
Reason #3: Engineers Don’t Participate
While some trios found that engineers were overly domineering, another common barrier to collaboration was the opposite—engineers don’t participate at all. Some of the variation within responses in this category included points like engineers are involved too little or too late in the process, they don’t consider discovery to be part of their job, or they’re too focused on execution.
While some product trios found that engineers were overly domineering, another common barrier to collaboration was the opposite—engineers don’t participate at all. – Tweet This
A few sample answers included:
- “Because our lead engineer has limited time that he can spend on discussing solutions and is mostly busy managing the rest of the devs.”
- “Engineers don’t consider it their job to challenge assumptions or present their own ideas.”
- “The engineer team is very focused on executing rather than discussing.”
Reason #4: Designer Doesn’t Participate
Interestingly, we didn’t see a pattern of responses indicating that the designer was overly authoritative within the trio. But another category and pattern did emerge: designers tend to be splitting their time between different teams or are contractors rather than full-time employees, which means they’re often missing context or don’t feel comfortable expressing their opinions.
Designers tend to be splitting their time between different teams or are contractors, which means they’re often missing context or don’t feel comfortable expressing their opinions in a product trio. – Tweet This
A few sample answers included:
- “Designers are shared across pods and rotate into Trios for a set period of time. They generally end up having less say as they lack the same amount of context.”
- “Our designer is a contractor which affects the dynamic.”
- “We use a shared resource model for design/UX team. They don’t have enough time to spend with us.”
Reason #5: Stakeholders Dictate Solutions
Another common roadblock to product trio collaboration is when external stakeholders (often the CEO or some other leader) dictate the solutions the trio pursues. Respondents indicated that their CEOs or other leaders set business requirements or founders are very hands-on (to the point of being micromanagers) with the product.
A few sample answers included:
- “CEO trumps all.”
- “Decisions are dictated top down.”
- “Power dynamics of the organization.”
Reason #6: Different Levels of Experience
Ideally, everyone in a trio should have equal say, equal accountability, and equal responsibility. But many respondents indicated that this is not the case because certain members of their trio have joined the company more recently, some have less overall work experience and confidence, and some are simply less familiar with discovery.
A few sample answers included:
- “Dev has been at the company very long and PM and design are pretty new which creates an imbalance.”
- “Engineers and designers don’t know about continuous discovery habits or feel it’s not their role, I continue to try to educate.”
- “Newer staff who don’t have context of industry weren’t able to contribute as fully.”
Reason #7: No One Can Agree
This category of responses indicated fundamental differences in personality, communication style, and understanding of everyone’s roles, all which added up to trios who simply could not reach agreements.
A few sample answers included:
- “Confusion about roles, limited knowledge about product management.”
- “Difference of opinion.”
- “Different areas of expertise.”
Reason #8: Some People Don’t Speak Up
While we saw earlier categories that called out designers or engineers specifically for not participating fully in the trio, this category more broadly includes people not speaking up, either because they’re shy, hesitant to share their opinions, or because they’re working remotely and not as engaged.
A few sample answers included:
- “Personality differences – shyness gets in the way.”
- “They have the opportunity to have a say, but some members of the group are not equally engaged or vocal. We assume that silence = consent, but I’m not confident that’s always true.”
- “Remote Work makes some more closed to participate.”
Reason #9: One Member Dominates
Again, while earlier categories specifically called out the engineer or PM as the primary decision-maker (but never the designer!), there were also a number of responses indicating that there was a single person whose personality or opinions dominated or who was less willing to listen to others and consider their perspectives.
A few sample answers included:
- “I guess some voices are just naturally more opinionated/stronger than others.”
- “One pushes his opinion without taking into account other perspectives.”
- “One person dominates decisions.”
Reason #10: There’s No Time
Given the fact that companies are always asking more of their product teams, it’s not too surprising to hear that not having enough time is a common reason for failing to work successfully in a trio.
Given the fact that companies are always asking more of their product teams, it’s not too surprising to hear that not having enough time is a common reason for failing to work successfully in a trio. – Tweet This
A few sample answers included:
- “Time constraints.”
- “We had hard commitments to customers.”
- “We’re often under the pressure of delivering things fast, which let leading roles need to act nimble. As a result, ideas cannot be discussed or tested as we want. As we often commented in the team: this is not our priority now. Maybe in the next phase.”
Reason #11: It’s a Newly Formed Team
It can take time for members of a product trio to feel comfortable with the group dynamic and confident in their own decision-making abilities. A few variations within this category included that new members haven’t built trust yet or figured out the ideal ways of working together or that they haven’t yet clearly defined each person’s roles and responsibilities.
A few sample answers included:
- “Early in our relationship, as we build our roles and trust.”
- “New team. We’re trying to grasp how to work together (Design is the newest to the party).”
- “The formation just started, and the team is still finding out the best frequencies and best working mode.”
Reason #12: We’re Focusing on Technical Debt Instead
In some cases, product trio members (or their stakeholders) feel the need to focus on technical concerns like building the tech foundations, addressing more urgent engineering issues, or catching up with delays.
A few sample answers included:
- “We need to go back to the drawing board of the architecture and set the tech foundations before we can advance on creating more value for the business and the customers.”
- “Because we have delays on the development roadmap, we have to wait for development support to optimize other product flows that can improve user retention, new user acquisition, and increase revenue.”
- “Because engineering issues seem more urgent.”
Key Learnings and Takeaways
The survey results showed us some of the common challenges product teams face when it comes to working in trios. Wondering what you can do if you’re experiencing something similar? For this next section, we turned to Teresa for her advice. This is what she recommends.
We can’t simply form product trios and expect everything to work perfectly. We need to help our teams learn how to collaborate cross-functionally effectively.
We can’t simply form product trios and expect everything to work perfectly. We need to help our teams learn how to collaborate cross-functionally effectively. – Tweet This
The first thing we can do is make sure that our teams are fully resourced with a product manager, a designer, and an engineer. But that’s not enough.
We also need to make sure they understand that they are jointly responsible for their outcome, that they share discovery responsibility, and we need to help them learn how to work together.
In each of our courses, we don’t just teach the skills required to build strong discovery habits, we also teach participants how to do each habit effectively as a team. We find this is often one of the biggest sources of learning for our students.
We need to set outcomes at the team level and each discipline leader (product, design, and engineering) needs to hold the cross-functional team accountable for the same outcome, rather than falling back to our functional silos.
And the hardest piece of all, we need to empower teams to find the best path to their outcome without dictating specific solutions. If you manage cross-functional teams and want to learn more about how you can effectively do this, see these resources:
- Everyone Thinks They’re Managing by Outcomes. Here’s How to Actually Do It.
- Building a Culture of Accountability for Empowered Teams
- Doing Discovery Well: How to Measure and Guide Your Team
If you are an individual contributor working in a product trio and want to get better at cross-functional collaboration, these resources might help:
- Core Concept: Collaborative Decision-Making in a Product Trio
- How do product trios resolve conflict?
- How can you get your engineer to participate in your product trio?
- Or you might consider enrolling in one of our courses with your product trio.
If you are new to the product trio concept or want to explore how to get started with product trios, check out our in-depth product trio guide.
