Product Trio: Beyond the Obvious

Product Trio is not a framework, a strictly defined set of roles, or an exclusive group that performs product discovery alone.

Hey, Paweł here. Welcome to the premium edition of The Product Compass.

Every week, I share actionable tips and resources for PMs.

If you are not a subscriber, here are a few posts you might have missed:

• New Premium Notion Templates

• Continuous Product Discovery Masterclass

• User Interviews: The Ultimate Guide to Research Interviews

• How to Write a Product Requirements Document + Template

Consider subscribing and upgrading your account, if you haven’t already, for the full experience:

---

Product Trio: Beyond the Obvious

A Product Trio is a fundamental concept for teams performing Continuous Product Discovery.

On the surface, it seems easy to understand. Many interpret it as:

• A framework to follow

• A strictly defined set of roles

• An exclusive group that performs product discovery alone

And yet, the Product Trio is none of the above.

So, in today’s issue, I want to revisit the concept:

1. What Is a Product Trio?

2. 🔒 Product Trio: Nine Common Anti-patterns

3. 🔒 Summary and Conclusions

Important: I explained Continuous Product Discovery in a free post What Is Product Discovery? Product Discovery 101. You might want to read it first.

---

1. What Is a Product Trio?

A Product Manager can’t discover what to build alone. Even though you might have a diverse skill set, you are not a designer. And you are not a technology expert.

Here comes the Product Trio, a term coined by Teresa Torres, a Product Discovery Coach. She popularized it in her book Continuous Discovery Habits (2021).

The Product Trio represents a typical set of competencies required to perform product discovery work:

• Product Manager,

• Product Designer,

• Lead Engineer (originally: Software Engineer)

Working together is the best way to tackle the product risks. This allows you to include diverse perspectives. Make better, faster decisions. And build a shared understanding within the product team.

Who’s responsible for what?

According to the common knowledge, each person in the Product Trio has a specific area of expertise and is responsible for one of the product risk areas:

• Product Manager:

  • Value: Will it create value for the customers?

  • Viability: Will it work for our business?

• Product Designer:

  • Usability: Will users figure out how to use it?

• Lead Engineer:

  • Feasibility: Can it be done with the existing technology?

However, you shouldn’t take it at face value.

The Product Trio: Silos of Responsibility

As Marty Cagan explained in our email conversation:

“(…) The second is whether anyone on the product team should be able to raise an objection to any of the risks (…) I encourage engineers to not build something if they aren't convinced of the value or any of the other risks. Just like an engineer or product manager might not consider a design very usable.” - Marty Cagan

I also loved insights from Lean UX, in which Jeff Gothelf and Josh Seiden argue that while everyone has a core competency, allowing others to contribute in other areas creates more engaged, more effective teams:

“Too often, people in organizations discourage others from working outside the confines of their job descriptions (…). Silos are the death of collaborative teams.

For Lean UX to succeed, your organization needs to adopt a mantra of ‘competencies over roles.’” - Lean UX

The Product Trio: Competencies over Roles

Remember that regardless of your job title, you are not managing others. It's about collaborating, exploring, ideating, and tackling risks together, not about building walls that others cannot cross.

It doesn’t have to be a “trio”

One of the common misconceptions is that the Product Trio represents three predefined roles that perform product discovery.

But that was never an intention. The Product Trio represents just a typical set of competencies Teresa recommends. She clarifies:

“Defining the product trio as I have done here is not meant to exclude any of these critical roles (…) I put trio in quotes because your trio might be a quartet or even a quintet.” - Teresa Torres, Continuous Discovery Habits

It’s not even a “minimal set.” For example, you might not need a Product Designer for an API product.

Also, depending on the context, you might need to include other competencies:

• UX Writer,

• Data Analyst,

• ML/AI Engineer,

• Product Marketing Manager,

• UX Researcher (in many companies, a Product Designer takes on those responsibilities).

For example, in the past, I worked in the following configuration:

Pawel Huryn: Product quintet example

The Product Trio is not a framework. It’s a default recommendation that highlights the need for cross-functional collaboration. Consider your specific context and do what makes sense in your situation.

Teresa Torres summarizes it perfectly:

TLDR: The origins

While the Product Trio introduced by Teresa Torres was a new term, the concept wasn’t entirely new.

We can trace its origins to cross-functional teams promoted by Lean and Agile (late 20th and early 21st century) or even Total Quality Management (1980s).

In Inspired, the first edition of which was published in 2008, Marty Cagan explained the need for the Product Manager, Designers, Engineers, and Product Marketing Manager to perform Product Discovery continuously as a team.

2. Product Trio: Nine Common Anti-patterns

Here are nine of the most common anti-patterns I observed when working as a Product Manager and advising other companies:

#1 Anti-pattern: A strictly defined set of roles

We already discussed this anti-pattern in the previous point. Strictly defined roles and clear boundaries can lead to siloed communication, a lack of engagement, and handoffs.

Instead, I encourage you to embrace a collaborative approach in which everyone can contribute to the team’s objectives and voice their concerns openly.

#2 Anti-pattern: The exclusive group

In this anti-pattern, people performing Product Discovery separate themselves from the team and hand off validated ideas to other team members.

The more I work with Product Trios, the more I appreciate Inspired, which doesn’t clearly distinguish between “people doing discovery” and “the rest of the product team.”

The Product Trio: Building walls vs. including others

Allow everyone on the team to contribute to Product Discovery according to their skills and interests. Some team members might only join you occasionally and do not need to participate in every activity. It doesn't have to be all or nothing.

For example, if you have a dedicated Slack channel for the "Product Trio," invite your entire product team rather than keeping it private.

#3 Anti-pattern: No Product Designer

Ideally, each product team should have a dedicated Product Designer. In rare cases, I recommend one Product Designer for two teams. It’s already demanding.

Anything more than that might prevent your Product Designer from participating in activities beyond preparing prototypes and attending status meetings.

And don’t get me started on having only a UI Designer, or worse, no Product Designer at all, for a customer-facing tech product with a user interface.

If your company isn't serious about building products, perhaps you shouldn’t take them seriously either.

#4 Anti-pattern: PM dictating UX through wireframes

This one is tricky.