The product trio: when shared thinking makes a better user experience

The product trio: when shared thinking makes a better user experience

Working with Adi and Roy, product managers at Zap Group, taught me how much value comes from connecting product thinking, design and technical understanding. On the people, questions and decisions behind digital products used by millions.

One of the things I love most about working with the product managers at Zap Group is the moment we sit together in front of a problem that has no clear solution yet.

Adi and Roy bring their knowledge of the products, the business needs and the users. I bring design thinking, user experience and my background in development. From these conversations come ideas, sharper questions and directions we wouldn't necessarily reach on our own.

In the photo with this article, both of them are with me, partners along the way. For me, this photo stands for something bigger than another work meeting: the understanding that a good user experience begins long before the first screen, in a conversation between people looking at the same problem from different angles.

What is a Product Trio, really?

Teresa Torres, author of Continuous Discovery Habits, made the Product Trio a central idea in how we talk about building products. The idea is simple: to make good product decisions, you need to bring together three key perspectives: product management, design and engineering.

But the interesting part of the approach is that it isn't necessarily about three people or three job titles. It is about three capabilities that need to take part in the thinking.

Marty Cagan, co-founder of SVPG, describes four key risks to examine when building a product: will users want the solution, will they be able to use it, can it be built and does it fit the business needs. No single role holds all the answers.

The product manager brings business understanding and priorities. The designer focuses on the user experience and how the solution works. The developer brings technical understanding, the system's constraints and sometimes new possibilities that weren't on the table.

When this thinking happens together, problems can be spotted earlier and solutions explored more broadly.

From our work together at Zap Group

At Zap Group, which runs a range of digital products and services across different fields, the product challenges vary from one product to the next. Each platform has its own users, business needs and processes, but in all of them the same core question comes back: how do you turn a complex need into a simple, clear and effective user experience?

Working together with Adi and Roy, we examine business needs, analyse user flows, think through solutions and refine the way people meet the group's digital products.

For me, specification and design are not separate from product thinking. Understanding the problem directly shapes the information architecture, the content hierarchy and the way the user moves through the flow. My background in development lets me look at the technical side too, understand what design decisions mean and speak a shared language with development teams.

And that is exactly the value I find in this collaboration: each of us brings different expertise, but we all work together to reach the right solution for the user and the product.

Why collaboration matters more than handing off tasks

In traditional processes, tasks sometimes pass between roles like a baton in a relay race. The product manager defines requirements, the designer plans the interface and the developer receives the design to build.

The problem isn't the division of responsibility itself, but what can get lost along the way. When each person sees only the result of the previous stage, they don't always know the reasoning behind it. Why did we choose this solution? What other options were explored? What did we learn from users?

Early collaboration keeps that context alive and reduces misunderstandings.

When the people planning the product understand the problem together, they don't just agree on the solution. They also understand why they chose it.

That doesn't mean everyone has to be involved in every small decision. Quite the opposite. When there is a shared understanding of the goals, each person can lead their own area more independently and precisely.

How do you build collaboration that really works?

In my experience, good collaboration doesn't necessarily need more meetings or a complex methodology. It needs a few simple habits:

• Start from the problem, not the solution. Before talking about screens and components, make sure everyone understands what the user is trying to achieve.
• Bring in technical thinking early. Don't wait for the design to be finished to check feasibility. Development questions can open new possibilities, not only set limits.
• Explore several directions. A simple sketch or a quick prototype can help the team understand an idea long before investing in detailed design.
• Share the reasoning behind decisions. Knowing what was decided isn't enough. It matters to understand why.
• Keep areas of responsibility clear. Shared thinking doesn't mean everyone decides everything. Each person brings expertise and leads their area, while listening to the others.

In the end, the goal isn't a process with more participants, but a process where better decisions are made.

When the trio doesn't really work

The fact that a product manager, a designer and a developer attend the same meeting doesn't guarantee real collaboration. Sometimes the meeting only exists to approve a solution already decided. Sometimes development enters the picture only at the estimation stage, or the designer joins after every step of the flow has been defined. In such cases, much of the value of shared thinking can be lost.

The challenge isn't getting everyone to agree on everything. Professional disagreements can actually lead to better solutions, as long as they come from a shared goal and real listening.

What I learned from sitting in both chairs

Over the years I have worked as both a designer and a developer, and connecting the two worlds has strongly shaped how I approach digital products. When I design, I don't think only about how the screen will look, but also about its behaviour, the structure of the information and how it can be built and maintained. And when I look at a solution from the technical side, I try not to lose the user's point of view.

But one of the most important things I have learned is that you don't need to know everything to be a good partner in product thinking. You need to know how to ask questions.

A developer who asks what the user is really trying to achieve. A designer who examines the technical consequences of a decision. A product manager who suggests testing a small idea before committing to a big solution. These are the moments when real shared thinking happens.

For me, a good Product Trio isn't three people who each bring their own answers, but people who help each other ask better questions.

And working with Adi and Roy reminds me again and again that a good user experience isn't only the result of the right design decisions. It is also the result of the people, the conversations and the collaboration behind them.