Product Trio

For most of my career, discovery worked like this: the PM did the research, wrote up the findings, and presented them to the team. The designers and engineers would nod, ask a few questions, and then go build what they were told. Everyone was doing their job. And yet something always felt off 🤔 The handoff. That’s what was off. By the time insights made it from a customer conversation through a summary doc into a design and then into a sprint, something had been lost. Nuance. Context. The thing the customer said that wasn’t in the notes but that changed how you understood the problem. The team was building from a translation of the research, not from the research itself. The product trio is the fix.

​

What is the product trio?

The product trio is a term Teresa Torres uses in Continuous Discovery Habits to describe the core team that should be doing discovery together: a product manager, a designer, and a software engineer. Not in sequence. Together. In the same room (or call), talking to the same customers, looking at the same evidence. The idea is simple: discovery shouldn’t be a solo PM activity that gets handed off to everyone else. It should be a shared practice, owned jointly by the people who are going to build the thing.

​

Why all three?

Each person on the trio brings a different lens - and more importantly, hears different things in a customer conversation. The product manager is listening for the business context - the opportunity, the outcome, where this fits in the broader strategy. They’re thinking about prioritisation, trade-offs, and whether this is a problem worth solving at scale. The designer is listening for the experience - the friction, the confusion, the moments where the customer’s mental model doesn’t match the product’s. They notice things the PM doesn’t, because they’re trained to see interfaces and flows as the customer experiences them. The engineer is listening for the technical reality - the constraints, the feasibility signals, the “wait, that’s actually really hard” moments that save you from designing something unbuildable. They also often spot elegant shortcuts the PM and designer would never think of. When all three are in the room, you get a richer picture than any one of them would get alone. And crucially - you get shared understanding. No translation required.

​

Shared empathy as a product advantage

There’s a less obvious benefit to the trio that’s harder to measure but might be the most important: when engineers and designers hear customers directly, they make better micro-decisions throughout the build. Every day in a sprint, engineers make dozens of small decisions. Which edge case to handle. How to deal with missing data. What to do when the user takes an unexpected path. If they’ve sat in customer conversations, they have a mental model of the real person using this thing - and their instincts are better calibrated. They’re not guessing what the PM would want. They know what the customer needs. Marty Cagan makes a similar argument in Empowered - the difference between feature teams (who build what they’re told) and empowered product teams (who own outcomes) comes down largely to how close to the customer the whole team is, not just the PM.

​

What the trio is not

A few things worth clarifying, because this gets misunderstood: It’s not a committee. The trio doesn’t make decisions by consensus. The PM still owns the product decisions. The designer still owns the design. The engineer still owns the technical approach. The trio is about shared discovery, not shared authority. It’s not the whole team. Other engineers, other designers, other stakeholders - they matter. But the trio is the stable core that does the ongoing discovery work together. Trying to do continuous discovery with a cast of fifteen doesn’t work. It’s not always the same three people. In reality, you might rotate the engineer who joins discovery conversations depending on what you’re exploring. The principle is that engineering is represented - not that it’s always the same person.

​

Making it work in practice

The most common objection is time. Designers and engineers have their own work to do - pulling them into customer interviews every week feels expensive. Reframe it: an hour a week in a customer conversation is cheap compared to a sprint building the wrong thing. The trio doesn’t replace the engineers’ build time - it makes the build time more valuable because everyone knows they’re building the right thing. Start small. One joint interview a week. Debrief together straight after - what did you hear, what surprised you, what did it change? That 15-minute debrief is often where the best insights crystallise. Lesson learned: the first time you sit in a customer interview with your engineering lead and watch their face change as they hear something unexpected - that’s the moment you stop wanting to do discovery any other way 🙌