Running Your First Product Trio

The short version

A product trio is three people (PM, designer, tech lead) who own a product area together and make meaningful decisions as a unit. It's not a meeting. It's a weekly operating rhythm. The shape: 2 hours blocked weekly, 50 minutes of discovery together with raw notes and sketches, 10 minutes writing what we learned, 1 hour deciding together with committed ownership. The point is that alignment happens synchronously during discovery, not asynchronously in Slack threads where half the team never reads the context. Killed a "collaboration workspace" feature in week two of running my first trio at Smartcat because the tech lead's architecture question and the designer's "do customers actually want a workspace?" reframed everything. Pick one product area. Three people. One two-hour block. Start this week.

For the first six months at Smartcat, I was drowning in alignment meetings. Product strategy meetings. Design sync meetings. Engineering planning meetings. Stakeholder updates. Then a design decision I made without talking to our tech lead created three weeks of unexpected rework. A feature we shipped looked broken on mobile because I didn't involve design early enough. We kept making the same mistakes because the three people most capable of preventing them weren't actually making decisions together.

That's when we formalized the product trio.

What we discovered is that the trio isn't a meeting. It's an operating rhythm - a weekly pattern where Product, Design, and Engineering make decisions as a unit, not sequentially. It sounds simple. It's the hardest thing I've implemented in my career, and it's the highest-leverage decision I've made as a product leader.

What a Product Trio Actually Is (And Isn't)

Let me be clear about what this isn't. It's not a standup where the PM reports progress and asks for status. It's not a weekly design review. It's not an engineering estimation session. It's not approval theater where the PM brings fully-formed ideas and the other two rubber-stamp them.

A product trio is three people - a PM, a designer, and a tech lead - who own a product area together and make meaningful decisions as a collective. The trio has decision-making authority. The trio owns the outcome. The trio is accountable together.

The weekly cadence has a specific shape: discovery together, decisions together, and then execution in parallel. What matters is that alignment happens synchronously during discovery, not asynchronously in Slack threads or emails where half the team never reads the context.

Here's what happens in reality: without a trio, the PM discovers a problem, figures out a solution, hands it to design, gets feedback, revises, hands it to engineering, negotiates scope, and then wonders why the thing that ships doesn't match the vision. Six months later, you find out there was a technical constraint that would have changed the entire approach if someone had known about it in week one.

With a trio, all three perspectives are baked into the discovery work itself. The tech lead spots architectural implications while you're still talking to customers. The designer surfaces usability concerns before you've settled on a direction. The constraints and possibilities come into view early, not as friction later.

The Weekly Cadence: How We Actually Run It

Every week, we block two hours. That's it. Two hours, same day, same time. No prep work required (though some is helpful). No massive documents. No pre-reads.

The structure is:

Hour 1: Discovery Together

We pick one problem we're investigating. It could be a customer complaint that came in, a metric that's moving the wrong direction, a feature request that came from multiple customers, or a directional decision we're trying to make. One problem, not four.

For 50 minutes, we're in conversation mode. The PM might have done a customer interview earlier that week - they share the raw notes, not a polished synthesis. The designer brings sketches or screenshots if they've been exploring the problem. The tech lead brings any technical constraints they're aware of. No one is in "presentation mode."

Then we spend 10 minutes writing down what we learned. Not a 20-page document. A bulleted list: what's the actual problem, what assumptions did we just question, what are our constraints, what do we know we don't know?

Hour 2: Decision Together

Armed with that learning, we make a decision. What are we going to do next? Do we need more customer input? Are we ready to prototype? Is there a technical spike we need to run? Who's going to do what by when?

The critical piece here is that we're deciding as a unit. The PM doesn't decide and then get feedback. We talk through the options, test them against what we learned, and land on a direction everyone has ownership over.

If we disagree, we make the decision anyway. We don't table it. We don't ask for more time to think. We commit: "We're building this prototype by Thursday. We'll test it with three customers by Friday. If that fails, we pivot." The disagreement doesn't disappear - it becomes testable.

How to Convince Your Designer and Tech Lead to Try This

Here's where most PMs fail. They say, "We're going to start doing trios" and then show up with a fully-baked feature spec and an agenda. That's not a trio. That's a meeting where you're asking for approval.

What actually works is this: you go to your designer and your tech lead separately, before you propose the formal thing, and you say something honest like:

"I've been thinking about how we make decisions. Right now, big decisions get made through a bunch of separate conversations and Slack threads. Everyone's halfway informed. We end up reworking things. I think we could make faster, better decisions if the three of us sat down together once a week and actually talked through problems together - not in a status meeting way, but in an actual working session. Nothing scary. I want to try it for four weeks and see if it helps. I have no agenda beyond spending less time on alignment and more time on execution. Are you interested in trying?"

Most good designers and tech leads are already frustrated with the status quo. They've already been burned by decisions they weren't part of. They want to be involved earlier. They're waiting for someone to ask them.

When they say yes, you don't launch with a big announcement. You just show up next week with one problem and ask, "Want to think through this together?"

The First Two Weeks: What to Do

Week 1: Start with an Existing Problem

Don't start with a new feature or a greenfield problem. Start with something you're already working on that's been messy or contentious. It could be a feature that's halfway through design and engineering wants to change the approach. It could be a metric that's broken and you're not sure why. It could be a customer support issue that keeps coming up.

Bring the raw information. Not a polished analysis. A support ticket. A customer conversation note. A graph with a confusing trend. Something real.

Spend that first session just understanding the problem together. Don't try to solve it. Just get aligned on what's actually broken and what might help. Write down what you learned. Commit to what you're going to do next.

Week 2: Make a Real Decision

By week two, you should have enough information to make a decision. It doesn't have to be a perfect decision. It has to be a committed one.

This is where you learn if trios actually work, because you'll see the difference immediately. Whatever you decided on in week one, you're probably already partially executing it by week two. The designer's already sketching. The tech lead's already been thinking about architecture. By the time you're in the room together, you're not starting from zero - you're refining something that three minds have already been working on.

Write down the decision. Assign ownership. Commit to when you'll reconvene.

That's it. Two weeks of rhythm. Not a miracle. Just decision-making that's tighter than before.

Common Failures (And How to Avoid Them)

Failure 1: The PM Dominates

This is the most common one. The PM comes with a fully-formed opinion and uses the "trio" as a way to get buy-in. The designer and engineer can feel it immediately. They stop contributing. The meeting becomes theater.

If you're doing this, you'll know it when the designer stops talking and the tech lead starts answering questions instead of asking them. The fix is brutal: you have to stay genuinely uncertain. Go into the meeting with a real question, not a disguised answer. "I don't know if we should add this feature or just make the existing feature faster. What do you think?" is genuine. "I think we should add this feature, right?" is theater.

Failure 2: The Designer Disengages

This happens when the designer doesn't have time to participate meaningfully. Maybe they're juggling five other projects. Maybe they're overwhelmed with execution and don't have time to think. Maybe the PM is making design decisions before the trio meets.

If this is happening, the trio isn't working because there's no design perspective in the room. The fix: stop making design decisions alone. Wait. Let the designer catch up or reduce their other work. A trio where the designer is silent is just a PM and a tech lead in a room.

Failure 3: The Engineer Only Comes to Say No

The tech lead shows up, listens to the idea, and says, "That's not possible" or "That will take three months." They're not participating in problem-solving. They're gatekeeping.

This usually means the tech lead isn't actually a product-minded engineer. They don't think about trade-offs and constraints as a way to find better solutions. They think of them as reasons things can't happen. You might need to change who your tech lead is, or you need to have a direct conversation: "I need you to come in here as someone trying to solve the problem, not someone trying to block the idea. If you think something won't work, help us figure out what would work instead."

How Trios Change the Quality of Decisions

After six months of running trios, we shipped faster. Our features had fewer rework cycles. Our designer was happier. Our tech lead felt like they were solving problems instead of cleaning up messes.

But the bigger change was the quality of thinking. When you're in a room with your designer and tech lead, actually thinking together, ideas get better. Constraints become catalysts instead of blockers. Someone surfaces a technical limitation and suddenly you realize a better approach. The designer sketches something and the engineer says, "What if we did this instead?" and the PM sees a use case that changes everything.

That can't happen in email. It can't happen in separate conversations. It only happens when three minds are wrestling with the same problem at the same time.

The Sanitized Example: The Feature We Killed

Here's something concrete. Six months ago, we were planning a "collaboration workspace" feature. It would let teams organize projects, share assets, and comment on work. Big feature. Roadmap item. Executive stakeholder wanted it.

We'd been in the early design phase for two weeks when we brought it to the trio. I'd done a few customer interviews. The designer had some mockups. We were excited.

In that first 50-minute discovery session, our tech lead asked a simple question: "How are we storing these workspaces? Are these separate database tables? Do they live inside accounts?"

That question opened up a can of worms. If we modeled them one way, we'd have to migrate thousands of existing accounts. If we modeled them another way, we'd have architectural debt. There was no clean way to do it without either a massive migration or accepting technical compromise.

The designer said, "Wait - do customers actually want this as a workspace, or do they just want better organization within their existing account?"

We decided to do three customer interviews in the next two days, specifically asking whether they needed a new container (workspace) or just better organization inside their existing container (account).

Three customers. All three said the same thing: "I don't want another dashboard to log into. I just want to organize things better here."

By week two of the trio, we'd killed the feature. Not because it was a bad idea. Because we discovered a better idea: a lightweight tagging and filtering system that gave customers what they actually wanted without the architectural nightmare.

That discovery happened because three brains were in the room. The PM would have pushed forward. The designer might have designed it beautifully. The tech lead would have built it. But together, in 90 minutes, we saved months of work and three months later shipped something customers loved instead of something they tolerated.

Starting Your First Trio

If you're reading this and thinking, "That sounds good in theory, but my org doesn't work that way," I get it. Most organizations don't. Most are still structured as sequential handoffs: PM to design to engineering.

But a trio doesn't require org-wide change. It requires three people who decide to work differently. You can start with one product area. One PM, one designer, one tech lead. One two-hour block on the calendar. One problem.

The hardest part isn't getting everyone to agree. It's staying patient enough to make it work.

Block the time this week. Bring the three of you together. Pick one real problem. Spend 50 minutes understanding it and 10 minutes writing down what you learned. Then commit to what's next.

Don't expect magic the first week. By week four, you'll know if it's working. By week eight, you won't want to go back.