Product trio to speed up product discovery
Many of us working with product development at Hemnet dig Teresa Torres. We have started using her opportunity solutions trees to visualize product discovery in more and more teams.
Another part of Torres' approach to product discovery that more and more product development teams at Hemnet are using is the product trio.
What is a product trio?
We want our teams to both figure out what we should build next (product discovery) and build high-quality stuff that we already know we want to build (product delivery). Preferably, in parallel.
Discovery and delivery are very different. Delivery is more predictable and plannable, we know what to do next. Discovery is messier, more unpredictable and we need to make many small decisions in a short time.
Also, discovery needs different perspectives at once and without lengthy handovers. What is good for our business? What works for our users? What is technically feasible? One way is to involve the entire product team in decision making so that all perspectives are covered, but this takes a lot of time.
In addition to this, not everyone is equally motivated by discovery work. For a product manager or a UX designer, it is a natural part of the job, but for a developer, the interest varies. In a true cross-functional product team, everyone should be part of product discovery at some point. But all developers might not want to spend a majority of their time on discovery.
In this case, we put together a trio where both business, user and tech perspectives are represented. A typical setup is a product manager/business developer, a designer/researcher and a developer/system architect. Exactly which people and competences depend on the team and the organization. And it doesn't have to be a trio, sometimes a quartet is needed.
Of course, it's still important to engage the entire product team in product discovery somehow. The trio here has the important role of determining when and how to involve the rest of the team.
What we learned
A while back, we did a knowledge sharing session where teams that had tried the product trio got to share how they did it and what challenges they saw.
- A first step that many teams have taken is to use the trio to set goals and metrics. We work with quarterly goals (OKRs) and have often held workshops with the entire team to brainstorm goals for the upcoming quarter. What has turned out to be more effective is to have a product trio prepare goals and key deliverables and presents them to the rest of the team for discussion.
- The role of a developer in a trio isn't for everyone. You'll need to like write less code, have more meetings/workshops, talk to users, do technical research and proof of concept.
- It is important to visualize product discovery (e.g., in an Opportunity Solution Tree ) to enable effective communication within and outside the trio. Visualization also makes it smoother to switch trio members. New members can get up to speed more quickly and understand the status of the discovery work faster.
- A product trio isn't only good for speed, but also to focus more on product discovery. With a trio set up, we are more "forced" to think of product discovery as an important part of the product team's work.
- For a trio, it can be a challenge to know when and how to involve the rest of the product team. It's both common to do too much before involving the team and to involve the team too much. It's important to set up good routines and have an ongoing dialog about how to improve the way you work.
Thanks to all the smart people at Hemnet who contributed with their insights!
Find more blog posts from Dan Kindeborg here.