How to share product learnings in a product trio

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.

What is a product trio?

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:

• Designers ensure that the group stays focused on user problems and brings research insights to the table
• Product managers possess the broader organizational context of what’s viable and what’s needed the most from a business point of view
• Developers help both assess the feasibility of discussed solutions and propose new solutions based on what’s easily achievable from technical PoV

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.

Methods for sharing product learnings

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:

1. Discover daily

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.

2. Hold bi-weekly reviews

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.

3. Have a dedicated channel

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.

4. Build living artifacts

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.

5. Schedule challenge sessions

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:

• Spot product-related biases quickly
• Broaden our perspective, often leading to new insights and even better solutions
• Learn from each other
• Identify issues we missed before

6. Work on a key terms vocabulary

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.

Sharing product learnings inter-trio

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:

• Review meetings — The same principles apply, just on a more global scale
• Slack channel — I recommend separating the inter-trio channel from your internal trio Slack channel if you have more than three product teams. If too many teams start posting every tiny insight to a shared channel, you will get overwhelmed quickly
• Newsletter — All product trios should collaborate to publish a summary of learnings and discoveries every month. It not only forces alignment and knowledge sharing but is also a great way to propagate learnings within the organization
• Rotating members — You can rotate a few members for every review, challenge session, or daily to boost knowledge exchange and collaboration. The most recent company I worked for intentionally rotated designers between each team every quarter to boost this insight propagation

Key takeaways

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.