Product trio: What it is and what it does on your project

Most decisions that sink a digital product get made before development even starts. Why? An idea can look good on paper and still fall short on the business case, user needs, or the technical reality of building it.

Getting those things right takes more than one perspective. That’s why our projects always start with a product trio—a product manager, a designer, and a solution architect. You'll also see it called a product triad or the three-legged stool. Together, they look at the idea from different angles and help shape it into a product that makes sense for both the users and the business.

We’ve already covered what PMs actually do and why your project needs one. This is the next layer up: the team that makes early decisions stick.

Strategy first, then discovery, then code

At Applifting, every product goes through two phases before development starts. 

1. First comes strategy. We run feature breakdown and estimation workshops with you, work out what's worth building and at what cost, and use that to put together a proposal for the project. This happens before we sign a contract, and it's free. You only move forward if the proposal works for you. 

2. Once we kick off the collaboration, we move into discovery. This is where we test the strategy against real users and real technical constraints before anyone commits to a sprint plan. Finding out an idea doesn't work during discovery costs a fraction of finding out after you've spent three months developing it.

The product trio is involved throughout both phases, from the first call through to the start of development.

The four risks every new product faces

Before code, every digital product is a set of assumptions. Some are expensive to get wrong. According to Marty Cagan, who framed it in the book Inspired, teams need to answer four questions before they invest in development:

• Business viability: Does the product make commercial sense?

• Customer value: Do people actually want it?

• Usability: Can they figure out how to use it?

• Technical feasibility: Can the team build it in the time available?

No single person covers all four topics well. That's why every Applifting project starts with a small core team. The trio is our baseline. When the product calls for it, we might bring in a domain expert, a data engineer, or a security lead. The team grows or shrinks with the project, but the trio is always present. Here's what each role does.

#1 The product manager

The PM owns the question: Should we build this, and for whom?

During strategy, the PM gathers context from your team and drafts a development and release plan with the rest of the trio. Together, they shape a first version that delivers the maximum value for the budget. The PM also runs the estimation workshop, so you walk out with a realistic view of the build and running costs, rather than a vague sense of how it might go. If the numbers don't add up, you find out when changing direction is still cheap.

In discovery, the PM runs customer interviews to test whether the problem you think you're solving is the one your users have. We've seen interviews kill features that nobody needed and reshape entire products after learning the original idea wasn't actually a problem customers were trying to solve. 

#2 The designer

The designer makes sure people can use the product.

In strategy, the designer joins early conversations to make sure the design work is properly scoped, and the trio agrees on what good enough looks like for the first version.

Most of the design work then happens in discovery. For smaller projects, that means an interactive prototype tested with real users before any code is written. For bigger or riskier ones, we run a five-day Design Sprint: from the riskiest assumptions on Monday to a tested prototype on Friday. Five users is enough to catch about 85% of usability problems (per the Nielsen Norman Group), and that's dramatically cheaper than redesigning a live product. The design sprint also doubles as a value check. Users tell you fast whether they'd actually use what you're showing them.

#3 The solution architect

The solution architect is a full-stack engineer with hands-on experience building real products. 

In strategy, the architect translates your idea into a technical sketch: stack choices, integrations, infrastructure, scale assumptions, and security. That sketch is what makes the estimation workshop honest.

In discovery, when something looks genuinely new or hard (which describes most AI projects right now), the architect builds a small proof of concept to find the limits before they bite you in sprint seven. They also know when to pull in deeper specialists, like data engineering, ML, or security, rather than guess at someone else's territory.

Why a trio, not a solo expert

A PM alone can promise things the architect can't build. A designer alone can prototype interfaces that no one will use. An architect alone can build something elegant that solves nothing.

Three roles are the smallest team that can realistically cover the four risks. Each person challenges the others in real time, in front of you, before commitments are made. By the time we hand over an estimate, all three have looked at your product from their angle and agreed it holds up.

What you get, in the end, is a plan that's already been pressure-tested from three directions.

Give the idea room to breathe 

If you're starting a new product and someone suggests skipping strategy and discovery to go straight to code, push back. Those two phases are the cheapest way to find out you’re wrong.

A real trio—sometimes three people, sometimes more—is what makes it work. They're with you from your first call to the day development begins.

Thinking about a new product? Don’t rush into development just yet. Send us a brief, and we'll book a 30-minute discovery call to walk you through how the trio would approach it.