Product trio

Run continuous discovery as a trio — PM, designer, and engineer — mapping opportunities, testing assumptions, and shipping only what customer evidence supports.

About this template

This template turns the product trio operating model into a working board. Instead of a relay race where the PM writes a spec, the designer mocks it up, and the engineer estimates it at the end, all three people share the same evidence at the same time.

The flow follows the opportunity solution tree: one Outcome the trio owns, Opportunities discovered in customer conversations, Solutions generated against those opportunities, and Assumptions pulled out and tested before anything gets built. Work only reaches Building after it has been Validated.

Dedicated Product Manager, Designer, and Engineer fields keep all three names on every item, so shared ownership is visible rather than assumed. Confidence, Evidence Count, and Risk Type make it obvious which ideas are backed by real customer learning and which are still opinion.

What is the product trio framework?

The product trio is a cross-functional team — typically a product manager, a designer or UX researcher, and a tech lead engineer — that jointly owns product discovery and delivery. Popularized by Teresa Torres in Continuous Discovery Habits (2021), the model replaces serial handoffs with shared customer learning. All three people attend customer interviews, map the opportunity space together, and decide together what to build next.

The framework exists because output-focused teams waste enormous effort. Industry research has repeatedly found that a large share of shipped features are rarely or never used, and "no market need" remains one of the most common startup failure reasons. A trio attacks that waste at the source: a bad idea has to survive the business, design, and engineering perspectives simultaneously, rather than clearing them weeks apart when it is already too late to back out.

Four habits make the model work. Weekly customer touchpoints attended by all three members. Orienting around one measurable outcome instead of a feature roadmap. Externalizing the opportunity space so alignment happens through evidence rather than politics. And testing the riskiest assumption behind an idea before committing engineering time to it.

This board covers all four. The Outcome column holds the single metric the trio owns. Opportunities and Solutions map the tree. Assumptions and Testing enforce the discipline of de-risking before building. And the Interview task type plus the Interview Date field make the weekly research cadence something you can actually audit at the end of a quarter — not something you assume is happening.

What’s inside

Columns included

OutcomeOpportunitiesSolutionsAssumptionsTestingValidatedBuildingShippedDiscarded

Task types

OutcomeOpportunitySolutionAssumptionExperimentInterviewInsightDecision

Custom fields

Product ManagerDesignerEngineerOpportunity LinkOutcome MetricRisk TypeConfidenceTest MethodCustomer SegmentEvidence CountTrio DecisionResearch LinkInterview DateDecide ByEffort

Key features

Discovery-to-delivery flow from Outcome through Opportunities, Assumptions, and Testing
Dedicated Product Manager, Designer, and Engineer fields on every item
Confidence and Evidence Count to separate opinion from customer evidence
Risk Type tagging across value, usability, feasibility, viability, and ethics
Interview task type and Interview Date to keep the weekly research cadence honest
Trio Decision field to record pursue, park, and kill calls with their reasoning

Who is this template for?

Product trios running continuous discovery
PM, designer, and engineer sharing one outcome
Teams adopting the opportunity solution tree
Product orgs moving from feature factory to outcome ownership
Founders doing discovery before committing engineering time
UX researchers making findings visible to the whole team

How to use this template

Use this board to keep discovery and delivery on one surface, so the trio can see which bets are backed by customer evidence and which are still guesses.

Step 1

Set one outcome and name the trio

Create a single card in Outcome with the metric you own this quarter, such as raising trial-to-paid conversion from 12% to 18%. Fill in the Product Manager, Designer, and Engineer fields. If the board has more than one outcome, the trio will drift back into feature-factory mode.

Step 2

Interview weekly and turn findings into opportunities

Log every customer conversation as an Interview card with its Interview Date, Customer Segment, and Research Link. Promote what you learn into the Opportunities column as customer needs, not solutions, and raise Evidence Count and Confidence as the same pain repeats across conversations.

Step 3

Generate solutions and pull out the risky assumptions

For each opportunity, add Solution cards linked back through Opportunity Link. Before estimating anything, break each solution into Assumption cards, tag them with Risk Type, and move the riskiest ones into Testing with a Test Method and a Decide By date.

Step 4

Decide as a trio, then build only what survived

When a test finishes, record the Trio Decision as Pursue, Park, or Kill. Only Pursue items move to Validated and then Building. Killed ideas go to Discarded with the reasoning intact, so the same idea does not come back in three months without new evidence.

Step 5

Close the loop after shipping

Once work reaches Shipped, compare the actual result against the Outcome Metric you wrote down before building. Tracking how often shipped features hit their hypothesis is the leading indicator that tells you whether your discovery is getting sharper.

Ready to get started?

Learn how to create a board from this template in just a few steps.

Read the step-by-step guide

Frequently asked questions

What is a product trio?

A cross-functional team of a product manager, a designer, and an engineer who jointly own product discovery and delivery. The defining trait is shared decision-making: no spec handoff, no "designer delivers mockups," no "engineer estimates at the end."

Do I need exactly three people?

No, but keep the decision-making core small. Add a data analyst, a marketer, and a CS rep and the trio becomes a committee. Bring specialists in for specific consultations instead. In small startups the designer role is often a UX-leaning founder or generalist.

How is this different from a Scrum or Kanban board?

Scrum and Kanban organize delivery. This board organizes discovery and connects it to delivery. Columns like Opportunities, Assumptions, and Testing exist specifically to stop ideas from reaching Building before anyone has checked whether customers want them.

How does this relate to the opportunity solution tree?

The board is a flat implementation of the tree. The Outcome column is the root, Opportunities are the branches, Solutions hang off them, and Assumptions and Experiments sit at the leaves. The Opportunity Link field preserves the parent-child relationship.

How do I actually sustain weekly customer interviews?

Make it a recurring calendar block treated like a sprint ceremony, and log every conversation as an Interview card. Filtering by Interview Date shows you at a glance whether the cadence held or quietly died three weeks ago.

What is the Confidence field for?

It makes the difference between opinion and evidence explicit. Guess means no customer input, Weak signal means one or two anecdotes, Emerging pattern means it repeats, and Validated means a designed test confirmed it. Nothing should reach Building at Guess.

What if leadership hands us a feature roadmap instead of an outcome?

Put the mandated features in Solutions rather than Building, and work backwards to the opportunity and outcome they assume. That surfaces the underlying bet and gives you a concrete way to negotiate with evidence instead of pushing back on principle.