The Product Trio: A 101

13 min readOct 12, 2021

The concept of a Product Trio has been around for a few years now. Both Marty Cagan (Silicon Valley Product Group) and Teresa Torres (Product Talk) have written about the role a Product Trio plays in the design & development of tech products.

We see real benefits in its approach, introducing the concept to some of our partner founders. So far it has been incredibly well received so we thought it was time to dig a bit deeper into what a Product Trio is, answering five key questions related to the concept.

When you think about it, as a founder growing a SaaS business you want the best chance of success. The #1 risk for you is building the wrong thing, wasting your time, opportunity and capital doing it. To succeed (there is not only one thing of course), but you do need to know (for sure) that you’re building the right things — things that your customers will want to use (over the things they are using today).

Building a tech product is very expensive — not just financially, but also in the time and energy spent in bringing a tech company to life and keeping it in business for the long term. Long gone are the days of doing some detailed planning, building a great idea, launching it and it just sells like hotcakes. That’s just not the way it works in tech products. Building tech products is about sensing and responding to what actually works, and for that you need to change how you approach it, what to focus on, and how you execute.

The Product Trio is the key for ensuring that you do that well.

1: What’s a Product Trio?

A Product Trio is an autonomous, cross-functional group of roles that work tightly together. They own the product strategy, making decisions on the ongoing discovery and delivery of the tech product.

As the name suggests, a Product Trio is made up of the following roles:

The Product Trio isn’t necessarily limited to these three roles. It’s just based on the reality that this trio is the minimum number of people required to have all the bases covered in tech product development. If other critical roles are required to make a specific business succeed (i.e. data science, AI, etc.) , then they can be integrated into the Product Trio also.

Just be aware that the more people you have involved in the Trio, the longer and harder it will be to make key product decisions.

A larger Product Team, by definition, includes a Trio, with more members with different and diverse skillsets. It is typical that most teams have more engineers on them and perhaps specialists in user research or analytics or security — whatever is deemed needed for that specific product. The minimum Product Team is ideally the Trio.

2: What is the Product Trio responsible for?

As well as the overall product strategy, and all of the design, discovery and delivery done on a product, the Product Trio have all decision-making power over the product (i.e. what to build and when). They are held accountable only for business results that their product can directly impact.

Each role has specific areas of focus and equal responsibility for the product.

When talking products, we will use the word “customer” to talk about the “buyer” of the product. We will use the word “end-user” to talk about the person who uses the product. This is an important distinction because the “buyer” is not always the “user” of the product, and a product has to appeal to both.

Design Lead

The Design Lead (DL) is responsible for the usability and desirability of a product from the end-user’s perspective.

The DL is concerned with:

Is the product usable, and can people figure out how to use it easily? Where is the product hard or confusing to use.
Does the end-user want and prefer to use this product when given a choice?
Does the product experience create changes in customer behaviour that results in positive product outcomes (i.e. more use, more conversions, more adoption)?

Common activities of the DL:

Designing and testing all end-user experiences; every touch point of the product, alongside others in the team.
Understanding end-user’s needs/struggles, and understanding the other options end-users may have (in-market), by interviewing, testing and observing them.
Performing, recording and gathering results from experiments/prototypes.
Observing and measuring the end-user’s experience and ensuring that the team actively participates in all discovery activities.

The scope of this role is the entire product experience, every touch point of the product, including representations and integrations with product marketing. A Design Lead is clearly far more than just a visual web designer, they have a broad range of deep skills in visual design, interaction design and in user research. The main superpower here is to be able to understand and articulate imagined use-cases and align the product experience with the end-user’s mental model.

Tech Lead

A Tech Lead (TL) is responsible for the feasibility of the product. The TL wants to know if the product (or changes to the product) can be built by the product team.

We are going to use the word “change”from here instead of the word “idea” or “feature” or “solution”, to describe the work being done by a Trio. Building products is about making changes to a product continuously. Each change has to fit the product (architecture, systems, support), and the overall product has to change and adapt to accommodate each change, without compromising the integrity of the product. Some changes are large, some small. All work together to make the entire product experience for end-users.

Common risks the TL will mitigate are:

Can the problem be solved with technology at all? What tech, where and how.
Do we have access to the technology, architecture, and systems available to build and support this change long term?
Do we possess the right tools and processes to be able to design, build and support the change long term? Do we need training or R&D?
Do we have (or have access to) the right people, with the right capabilities to design, build and support the change long term?

Common activities of the TL:

Designing and testing all software/hardware changes to the product/prototypes, alongside other members of the team.
Helping the team plan and breakdown solutions into smaller increments
Adjusting/evolving/extending the technical architecture to fit any new changes
Briefing and teaching the team new technical practices
Performing, recording and gathering results from experiments/prototypes
Measuring the user’s experience and ensuring that the team actively participates in all discovery activities.

A Tech Lead clearly has far more responsibilities and experience than just any programmer. They are focused on the big picture of the tech and how it should evolve, and on the people, process and tools that are being used, as well as being a master of building software products. They must be a respected and effective leader, teacher and mentor for their team.

Finally, if there was just one role on a product team, it would have to be the tech lead, without which you can’t make or support any tech in your company.

‍Product Manager

The Product Manager (PdM) is responsible for understanding the business viability and the value to the business of any product idea. The PdM is responsible for (among other things) collaborating and coordinating with other business functions (i.e. marketing, sales, finance, legal etc) to ensure the product is beneficial for the business. In other words, that the product produces business results.

Common risks the PdM will mitigate are as follows:

Is the product viable to the whole business, does it violate legal, ethical, financial constraints?
Is the product valuable to the business?
Does the product actually move the needle on desired business outcomes e.g. increased revenue, increased market share, establishment of overseas markets etc?

Common activities of a PdM involve:

Coordinating and collaborating with marketing to bring more potential customers to the product
Collaborating with sales to find new market opportunities and gather customer context.
Consulting with other business units (i.e. finance, legal, etc) to ensure viability, and gain further business context.
Collaborating in the Trio to ensure the right product is built, to gain insights into end-users using the product, and from user research.

Ultimately, the Product Manager is accountable for the success of the product to the business, and as such must be wholly trusted and empowered by the business.

A final note, despite a similar sounding title, a Product Manager role is not comparable with a Product Owner role — these are two different roles in two different contexts, who do wildly different things.

3: What makes the Product Trio approach different?

It is worth noting at this point that while the Product Trio may be responsible for selecting and validating ideas, they do not have a monopoly on generating the ideas. Ideas for the product can come from any part of the business, or outside the business. However, all ideas come through the Product Trio for triage and testing, and they are all tempered by the Product Strategy.

The core principle of the Product Trio is to have a balanced view of what actually works for the product in market, and what (in the product) actually changes behaviour of end-users. They do this by increasing certainty of what works through experimentation (on the product and its end-users). This process ensures biases and assumptions are removed from the process, so that only the things that prove to work (on end-users) are invested-in and are built and maintained. This is what is known as Continuous Discovery. It is this process that informs any and all product development decisions such that the right product is built.

Our take on the continuous discovery process is based on three key stages in a cycle:

Learn — validate our assumptions about an idea for a change, gather evidence from running cheaper experiments first, gain certainty about actual success.
Build — create the changes for the idea (prototyping or building product)
Measure — measure the effectiveness of the change, and ensure that it really works, or abandon it for something more valuable.

For those who have read Eric Reis’e excellent book (The Lean Startup), you’ll notice that our take is based off his build, measure, learn model — with what appears to be a small change. However, this reordering is important, because effective discovery starts with learning, not building. (Albeit Learn, Build, Measure does not roll off the tongue as well as Build, Measure, Learn)

Learn

The learn stage looks at a number of possible changes — a.k.a ideas or solutions. These solutions are then broken down into a series of assumptions to be validated and experiments to be conducted with end-users. The purpose of the experiments is to gather actual results based on observations from things like application data, usage analytics, and tests on end-users of the product. This is important to do cheaply to build up some certainty that the proposed change has some actual measurable traction before it is built into the product. Since that effort is very expensive to build right (i.e. durable, maintainable, supportable). Once the results of the experiments are gathered and analysed, the product trio can then provide an informed position on whether to choose this set of changes or select another set (options).

Outcomes of this process normally reveal the following:

The end-user actually values the change, its usable and they would use it. Therefore it will be worthwhile building the change into the product.
The change doesn’t appear to have value to end-users at the present time. Either the change should be dropped for the time being, and we should select another change to work on, or
If the change needs refining, further experimentation should be conducted to check that the refined change is of value to the end-user and they would use it.

In most cases, what is learned by this process was not obvious at the start. Finding things that actually work on end-users is not obvious at all, even though many people think they are. The reality is that many of our ideas for change just don’t work for a multitude of reasons. So, weeding them out sooner than later is a prudent saving on time and money.

Build

If the outcomes of the learn phase are positive, then the first iteration of the change can moved into the build phase of the process. Coding, and testing (and often new metrics) are integrated into the product before releasing the increment to customers (sometimes that increment is hidden from customers until the next cycle). Alternatively, prototypes are built and tested on end-users to learn more about how to manifest this change. The point is that this stage is quick and is rarely done in one big push for the whole change. More likely the change is done in several thinner increments (increasing depth with each cycle).

Measure

We’ll have an expectation on how the change will perform based on the work completed in the Learn phase. However, it is still very important to assess how the change actually performs in a live environment with real end-users. Remember those metrics that were added in the Build phase? That is the purpose of this Measure phase. By observing real, relevant metrics, further insights are gained into how the change is performing (or not). These insights then help to inform whether more work on this change needs to be done in another cycle, or whether to switch focus.

From the graphic above, you can see that the process never really stops. Every phase is reliant on the previous phase to inform decisions about product development.

4: How does this discovery process differ from the traditional approach?

The continuous discovery process differs from the traditional “build it and they will come” approach significantly. There is a strong tendency in product development to just talk to some prospective customers, derive a common idea from across these conversations, and then dive straight into a complete build phase — believing you have uncovered a working solution from your customers that will work for your product and for your customers.

However, designing a product (or feature) from a bunch of conversations with customers can lead to untested, biased and even flawed assumptions that are very hard to see past. As luck would have it, some of these ideas may actually hold some value for end-users — but is a very risky strategy to base the business upon, and the likelihood of this approach being successful for the product in the long run is incredibly low. This is why so many products fail, and so many products build the wrong thing.

The other significant difference with this approach of using a Product Trio, and one particularly necessary for tech startups, is the separation of the product aspects of the business from other business functions e.g. sales, marketing, finance that tend to compete for control of the business and control of the product. Separating the product strategy from the business strategy enables people in the company to focus on what they do best. For example, the CEO can focus on growing the business and attracting investment to the business and trust that the Product Trio will focus on making viable and valuable product outcomes for its end-users that actually deliver business results.

Mixing the two roles (i.e. CEO and Product Manager) into one person often results in a confused product strategy and that results in taking shortcuts in discovery, relying only on gut feeling and pure guesses. Savvy tech investors are wise to this risk, and the common outcomes it produces, and just simply won’t invest in companies where this is the case.

There’s an important point to remember here:

As a tech product business, if your product isn’t doing well, your business won’t do well. It is the creation of product outcomes that drives positive business outcomes. There are no production handles that can be cranked faster to produce more business outcomes for a tech product company, like there are for other kinds of businesses.‍

5: What are the benefits of this approach, and does it have any weaknesses?

The real benefit of the Product Trio is building the right thing. The continuous discovery process is the removal of assumptions, biases and blind luck from what is built. Ideas inherently have biases, regardless of where or who they come from, and most of them simply don’t or won’t work. Through the combined focus of the product trio and by focusing on changing customer behaviour combined with robust experimentation methods, these biases are removed, and certainty about what actually works is slowly gained.Its not about sprinting to build more and more features hoping to satisfy as many customers as possible before time is up.

This means that product decisions can be made from a reliable and predictable process, mitigating the risk of building the wrong thing while increasing the likelihood that end-users will desire and use the product or features you build for them.

Sounds great, what are the weaknesses?

There are two obvious weaknesses around deploying a Trio — particularly for small startups.

1: Number of roles required — As identified above, the realistic minimum number of people required for a Product Trio is three (PdM, TL, and DL). This ensures that all the responsibilities of building an effective tech product are covered. Having at least this number of people focused on product can be very costly especially to small startups.

2: The right people, with the right skills — Linked to the above point, each of the roles in the Product Trio require a broad range of skills and deep proven experience to make the product trio successful. While it may be easy to find people in market that tick a couple of the required boxes or skillsets, finding the full pack of skills and experience will be much harder- especially in a tight talent market.

3: Relinquished controls — To be effective, a Product Trio has to be empowered and trusted by its company and leadership teams to be able to do the right work to deliver the right business results. This can be very challenging for some founders and leaders who believe that to be effective they have to control the product development process, perhaps because it is foreign to them, or they have never seen it work well before. Or that it is unlike their prior experiences with other kinds of management.

While these are weaknesses, we still believe the long-term strengths of the Product Trio approach far outweigh all of these challenges. The ultimate waste of tech capital is building the wrong product, so ensuring that the right thing is built must be the top priority. Building the right things based on robust results from end-user observations is the foundation of transforming an idea into a scalable technology product business.

This is why engaging an existing virtual product team that includes a high-functioning Trio, already skilled and experienced in building tech product, is such an accelerator for startups to get to market with building the right thing.

Want to know more?

As you can tell, we’re passionate about this concept and the long term benefits it has for our founder partners and those growing tech product companies.

We’d love to answer any of your questions, or discuss any aspects of this article in more detail — just get in touch at info@end-game.com or with me jezz@end-game.com‍

Originally published at https://www.end-game.com.