Product trio is essential to every product team, much like captains who steer a ship in the right direction. It brings together the diversity of a designer, product manager, and developer. But this is also one of its biggest challenges.
The diverse personalities and expertise within the product trio can lead to a divergence in focus, interpretation of insights, and capture of learnings. Each member may end up pursuing different opportunities and having separate visions, making alignment a crucial challenge.
Ensuring the alignment of the product trio is paramount to prevent everyone from pulling in different directions. This can be achieved by regularly sharing product insights and interpretations, fostering a streamlined flow of work.
The more effective techniques to share product learnings a trio develops, the more cohesive their direction will be, with less waste and repetition.
A product trio is a collaborative effort between product, design, and technical professionals, aimed at enhancing the product discovery process and shaping the team’s product roadmap.
It is, more specifically, the collaboration of product managers, designers, and developers:
In some teams, four or five people might participate in this collaboration. Sometimes, a team is small and product-oriented enough that everyone is part of the trio. In a startup, for instance, a PM might also be a designer; the product trio will have two people. So, the “trio” part refers to three points of view, not necessarily to three distinct people.
When collaborating in a trio, it becomes very important to share product learnings effectively. I’ll discuss a few of my favorite approaches to this:
Discovering daily is a lot like a daily meeting of the development team. The difference, however, is that this meeting focuses purely on discovery-related topics.
The structure, too, differs little from your usual standup. Here, you start with a quick update on what discovery-related activities you did the previous day and what your plan is for the next day. This helps the team stay on the same page about what learnings were captured and where the trio is heading.
What I love most about discovering daily is the motivation it gives. Although essential in product development, discovery activities are often the first ones we deprioritize when things hit the fan, but the vision of upcoming daily activities motivates me to get at least some discovery work done. It adds up.
Depending on your speed of product discovery and team composition, a daily discovery meeting might be a bit too much. So, you can consider having it every other day or just twice a week. The premise is to have this regular, recurring touchpoint to facilitate learning exchange and help the team move in the right direction.
And if you are worried about having too many dailies, consider if you really need to team with your development team on a daily basis.
Whether you do it as a separate meeting or part of your usual sprint review, dedicate some time every other week for a bigger learning review.
Everyone from the product trio should bring their most important learnings and insights and explain to the group why they believe these are important. The trio can then discuss the most intriguing learnings in more detail.
These recurring deep-dive discussions are essential. A developer interprets insights differently and sees different opportunities than a product or a design person. By regularly discussing all learnings together, the team can build on each other’s interpretations, build a cohesive understanding of the problem space, and find common ground in prioritizing which opportunities to pursue next.
Remember to capture conclusions and share them somehow, whether it’s a PPT, Miro board, or even an AI-generated summary. Other people in the company can benefit from staying up-to-date with your discoveries.
Having a shared channel focused purely on sharing product learnings is one of the easiest yet most effective ways to share product learnings within the trio and beyond.
There is no hard science here. Just create a shared channel in the communication tool you use and post there whenever you learn something new. You can standardize it — require a specific format for updates — or just let it be built spontaneously.
It’s also a great way to avoid turning discovery dailies and bi-weekly reviews into status meetings and keep them discussion-focused.
Ensure the channel is open for all and the rest of the organization is aware of it. Other people can benefit from what you learn and add interesting insights to your work.
You can align twenty times a day, but your memory is limited. So, you must store what you learn somewhere. Each product trio should have a minimum of three living artifacts per persona — user persona, user journey map, and an opportunity solution tree.
I recommend revising these together at every review meeting. As long as these stay up-to-date, you’ll always have your learnings neatly documented and organized.
Instead of combing through countless reports and Confluence pages, you can refer to the latest persona to understand key pain points, revisit user journeys, and explore the broader landscape of opportunities on a well-mapped tree.
Three or so ever-living and always up-to-date artifacts always beat excessive documentation and even the most beautiful PPTs.
I recommend challenging your main beliefs regularly.
A challenge session is a meeting to which you bring your most recent and/or most important learnings and work together to find the riskiest assumption — whether we are talking about desirability, viability, feasibility, or discovering contradictory evidence.
Something that seems like a common sense truth for a designer might be challenged heavily by a developer looking from a completely different perspective. By explicitly challenging every new insight, we can:
It doesn’t matter how often you talk to each other and how many learnings you share if you speak in different languages. And it might sound like obvious advice and a rookie mistake, but you would be surprised how often issues can arise from misaligned vocabulary.
Let me share a recent example. One of our key buyer personas was “parent.” The problem is we never fully clarified who a parent is. For some people, a parent means a legal guardian of a child who is already using our product, while others also consider a parent to be a prospective buyer for a child who hasn’t used our service yet.
This small difference caused us to lose a lot of energy and time in the long run and some needless heated discussions.
To avoid those, we started building a “key terms dictionary” — a file with all key and potentially confusing terms and a clear definition. Whenever we noticed that there might be some misalignment, we did a quick level-set to ensure we were thinking about the same thing. The quality of our conversations increased noticeably since we clarified all discrepancies in our vocabulary.
In a larger organization with more than one product team, you’ll have more than one product trio. It’s also important to ensure smooth knowledge exchanges between these different trios. This will help you avoid waste (more than one trio focusing on the same opportunity), build on top of each other’s learnings, and get a healthy dose of inspiration.
Some of my go-to tactics to align between trios include:
Product trios are critical in product development. They ensure the team heads in the right direction and focus on the most critical opportunities.
But this perspective difference, both within the trio (developers, designers, and PMs looking through different lenses) and outside the trio (different teams judging insights differently), poses its own challenges. To avoid misalignment, the product trio must share product learnings and perspectives with each other regularly.
There’s no official framework for how trios should work together, though. In this blog, I shared practices that worked for me in the past. However, you might need a different approach for your specific context.
Plus, I have never implemented all of these practices at once. For example, we had daily meetings with one team but no reviews at all, while with the other team, we had weekly reviews and focused most of our communication asynchronously using Miro and the opportunity solution tree.
So, choose one or two techniques that sound most exciting and test how they work in practice. Then, experiment on the go until you find a structure that works for you.
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Act fast or play it safe? Product managers face this daily. Here’s a smarter way to balance risk, speed, and responsibility.
Emmett Ryan shares how introducing agile processes at C.H. Robinson improved accuracy of project estimations and overall qualitative feedback.
Suvrat Joshi shares the importance of viewing trade-off decisions in product management more like a balance than a compromise.
Great product managers spot change early. Discover how to pivot your product strategy before it’s too late.
Learn more →
