What I've learned setting up 6 Product Trios

What I've learned setting up 6 Product Trios
Photo by Pablo Guerrero / Unsplash

Product Trios is a concept popularized by Teressa Torres. You should check out her book Continuous Discovery Habits.

I helped setup 6 Product Trios in the last two years. And I've learned some things along the way. I'll mark key learnings in this article with a 💡.

What is a Product Trio?

"A product trio is typically comprised of a product manager, a designer, and a software engineer. These are the three roles that—at a minimum—are required to create good digital products." - Teressa Torres

It's kind of a team within the team. A PM, UX/PD and engineer take over all discovery work together. They develop a shared sense of the opportunities and how to solve user problems in a feasible, desirable and viable way.

💡 Many assume that a Trio somehow is a framework. It's not in my eyes. It's a very lose organisational concept. How do we work? How do we split work? How do we resolve differences in opinion/incentives/interests? That is all not defined and needs to be developed by yourself.

Instead of having a PM to make decisions, we aim for true eye-to-eye collaboration in the Trio.

Cross functional teams are so 2015

The problem:
"Oftentimes, the product manager doesn’t know what’s possible and the engineers can’t implement the requirements as written. This leads to rewriting requirements, redesigning mockups, and rewriting code. This is why so many projects end up over budget, under scope, and late." - Teressa Torres

Modern product teams swear they work in a cross-functional manner, but in reality the PM takes all the decisions. Some input might be heard, even considered, but true collaboration is not achieved. Marty Cagan called these teams "Mercenary Teams".

Mercenary Teams vs. Missionary Teams

'Mercenaries' are people who are fill their role, get paid for it and call it a day.
'Missionaries,' on the other hand, care about the outcome, the thing we're trying to achieve together.

💡 When trying to understand if a team truly works together on a shared mission, don't look at the org chart. You have to go in an get a feel for how decisions are made. Shadowing a planning session is the best way.

Great products are built by Missionary Teams. That seems uncontroversial.

Product Teams are a setup for that mission-driven work to occur. By creating a nucleus, a team within the team, a trio of three core disciplines we allow for true product collaboration to occur.

"When a product trio works together to develop a shared understanding of their customer, they are in a much better position to create products that customers love." - Teressa Torres

Joint Responsibility and Collaborative Work

When a product trio collaborates closely to truly understand their customer, they significantly increase their chances of designing products that resonate well with the audience.

💡 If your company does not believe the following logic: understanding user problems -> superior products for users -> better business outcomes; then do not start with Product Trios. It's just going to be painful overhead.

It's like when they decide to switch the pricing page to a per-seat model. This decision isn't just about changing numbers; it involves evaluating the product's viability, ensuring the user experience feels right, and making sure the technical side can support the new structure.

By working together, each member brings their expertise to the table. The job: the product change meets the customer's needs, makes sense from a business perspective, and is technically doable. We call these three factors "desirability", "viability" and "feasibility".

Naturally each "function" (UX/PM/Engineer) might have a bias towards looking our for "their interest".

Product Manager --> Viability
Engineer --> Feasibility
Product Designer (UX) --> Desirability

But that does not have to be true. I've also worked with engineers who do love users so much, they forget all about the technical challenges. So, clear role assignment is not needed or wanted here.

💡 When looking to setup Product Trios make sure the candidates for that trio understand that they will be given the autonomy to make decisions. With that they have more impact. Select people who want to have an impact.

Product Trios allow for better decision making early on.

Basically "what" gets build is decided by a more complete cross-functional set of people (the trio) and therefore will be of higher quality than if just the PM would decide.

Higher quality means:

  • Technical and UX perspective where really considered
  • Real product discovery is happening (user interviews, unmoderated tests) to falsify assumptions
  • New solution proposals from different perspectives were considered
💡 If team members have never done Discovery, putting them in a Trio won't help. They need to understand / be taught the basics of modern product development. Here are some pointers of things a Trio can't succeed without (as I've painfully learned)
impact through better product decisions

Requirements for Product Trios

Assumption based thinking

Assumption-based thinking requires a shift in mindset. If you're not used to working with hypotheses – which are basically educated guesses like 'if we believe A is true, then we're assuming B is also true' – you might find it challenging to navigate decision-making in the Trio.

This approach is crucial for pinpointing where the uncertainties or 'risky bits' are in your project and determining where you need to dig deeper with research. It's about being smart and strategic with your team's efforts by identifying and testing these assumptions upfront, rather than learning the hard way later on.

Problem and solution space are different

Simple concept, but hard to teach.

The idea that the 'problem space' (what the user is struggling with) and the 'solution space' (the fix we come up with) are completely different territories might sound straightforward, but it's surprisingly tough to grasp in practice.

It's easy to blur the lines between understanding a user's issue and jumping straight into solving it. But truly separating these two - recognizing that fully digging into and understanding the user's challenges is one phase, and brainstorming and crafting solutions is a whole different ballgame - requires deliberate practice. It's about resisting the urge to immediately fix things and instead, taking the time to really get to the heart of the problem first.

A teams goal is a measurable impact

The goal of a team should be to create a measurable impact – this might seem obvious, but it's vital. A product team, much like a startup team, needs to demonstrate a tangible shift in user behavior.

💡 If your company is not in the mode of honestly measuring impact of teams, I'm not sure product trios are more than a social experiment. Meaning, they can make a team feel more collaborative. But don't expect better business outcomes.

Let's consider a straightforward example: your team focuses on improving the user onboarding experience. So, what's the objective here? Essentially, it's to enhance the onboarding process. But what exactly does 'better' mean in this context? It likely refers to ensuring users grasp the process effortlessly and encounter no hurdles during onboarding.

But how do we measure this change in user behavior? We use proxies – for instance, monitoring the drop-off rate at different stages of the onboarding process (a quantitative measure) and gathering positive feedback post-onboarding during user interviews (a qualitative measure). Granted, proxies aren't perfect; in fact, most have their flaws. However, the idea of working on a product for six months without delivering a measurable impact is unacceptable for product trios. Why? Because without measurable results, they won't know if their efforts are truly making a difference. And that's the core of a trio's purpose: to drive significant product changes through a synergistic, cross-functional collaboration.

Product Trios won't save you

Check out this short video on my take on why just introducing the concept of Product Trios is not what you want.

Niko Noll on LinkedIn: #productmanagement #productdiscovery #uxresearch | 11 comments
Product Trios are not going to save you. Cross-functionality? What does that even mean anymore. As if we need to define that the function "Manager" should… | 11 comments on LinkedIn

How to start with Product Trios

  1. Ask yourself as a Product Leader / Decision Maker: Do you want this?
    1. Read Continuous Discovery and Empowered
    2. Ask yourself if you are ready to give up control of the outputs of teams.
    3. Do you know the clear business outcomes you are looking for? If not, get clear on that.
  2. Recruit: Communicate the requirements for Product Trios
    1. Interview interested colleagues about their perspective on how to make product decisions. Ask: What is the goal of your product team? Try to identify mission-led people.
    2. Get interested people without adequate experience to read Continuous Discovery and Empowered.
  3. Select the right people for the initial Trio
    1. This choice doesn't need to be final. The setup can change.
    2. The engineering manager doesn't need to be the tech person in the Trio. It can be any curious, mission-led engineer. Technical QA's can also make great members.
  4. Give the Trio space and a problem to solve
    1. What's the strategic objective or business outcome you'd like the team to focus on? Give them that and 4 weeks. With the sole task of: Come up with validated solutions that drive this business outcome.
    2. These 4 weeks are about Product Discovery. And learning to work with each other as a Trio.
    3. Offer support if you can. I find in this phase hands-on coaching support is highly impactful, because the Trio can really learn by doing. If you can't, just be available as a leader to clarify and make decisions if the Trio gets stuck.
  5. Bring the rest of the team on-board (Engineers, QAs, Analysts, stakeholders)
    1. After the first Discovery push the Trio communicates what they've found, what opportunities they identified and in which solutions they see the most promise.
    2. Now, the whole product teams needs to start delivering the first little solution. Just to get used to that.
  6. Continuous Discovery
    1. The Trio has the task for the next 4 weeks to
      1. keep steering the delivery of the validated solution &
      2. continue discovering the next solution to build
    2. Have regular (monthly) check-ins with the Trio to question where they are at.
      1. Tip for leaders: Speaking the language of "user problem", "opportunity", "critical assumption" helps enormously in framing the work of the Trio and make them focus on the right things.

Okay, that was a lot. Hope that helped somebody.

In case you have questions about Product Trios in particular, don't hesitate to reach out on LinkedIn.

If you know somebody who will find this valuable, share this post with them, it's free and takes 10 seconds. That somebody might thank you for it.