The Triad Is Not a Seating Chart: Make PM, Design, and Engineering Actually Decide Together

You put a product manager, a designer, and an engineer on the same team and call it a triad. Then you wait for the magic. It does not come. The three of them nod in meetings, walk out, and go back to their own tools, their own language, and their own version of the plan. You did not remove the silos. You just moved them one desk closer.

The triad is a good idea that most leaders install as a diagram instead of a practice. Three names in three boxes is not collaboration. What makes it work is boring and specific: a written agreement about who owns what, and a shared ritual where the three of them prioritize and shape work together before anyone builds. Here is how to set that up.

Three risks, three owners, one decision

Start with why the triad exists at all. Each seat owns a different way the product can fail. As Salman Ladha lays it out, the PM owns value risk (will people use it), the designer owns usability risk (can people figure it out), and the engineering lead owns feasibility risk (can we actually build it). Three real risks, three real owners.

The trap is treating those lanes like walls. When each person guards their box, the user gets a product stitched together from three separate goals. Karishma Irani makes this concrete: give the same feature to three groups in isolation and design maps a UI, engineering builds a flexible API, and nobody is solving the customer's actual problem. Handoffs, she says, are deadly.

So the lanes are for accountability, not for keeping people out. Everyone owns one risk and everyone shows up for the whole decision.

Write the agreement down, or you do not have one

Most triads run on assumptions. Everyone thinks they know who decides scope and who breaks a tie, and everyone is guessing a little differently. A written working agreement kills the guessing. Allison Winter's take on the triad treats a clear agreement as the starter ritual a new trio needs before anything else.

Keep it short. Name where your three lanes overlap and who has the call when they do. Set how often you meet as a trio and what you decide in that room versus alone. Irani's point about tie-breakers matters here: in a real triad, no single person plays the bad guy pushing ideas back. The three share ownership, which pushes decisions forward faster and more consistently.

One page. Revisit it when it stops matching reality. That is the whole artifact.

A shared ritual beats a shared calendar

Meeting more is not collaborating more. You need a repeatable moment where the three of them shape work together, early, before scope is locked. Tim Kolke's team at Later built exactly this, and his story carries the real lesson. They adopted the Shape Up model, but the designers rejected it at first because it read like a PM process written for PMs.

The fix was not a better process. It was building the process together. Later runs 1.5-hour sketching sessions with one person from each seat, working from low-fidelity drawings, not polished wireframes. That gets engineers in early enough to flag feasibility before it becomes a bandaid, and it gets designers real influence instead of waiting to be told what to draw.

Kolke's blunt thesis: process alone cannot solve a human problem. The ritual works because the three people who use it own it.

Cross the language barrier on purpose

Here is the part leaders skip. The triad fails not because people disagree, but because they do not speak each other's language. A designer pitches a customer problem. A PM wants strategic fit and business numbers. Neither hears the other, and good ideas die because they showed up in the wrong dialect.

Later solved this with an idea rationale template that anyone, designer, dev, or PM, uses to submit an idea. As Kolke admits, no designer would naturally pitch in that format. But if you want your idea taken seriously, you translate it into a language your partners understand. His rule is simple and it should be yours: go out of your way to learn the other seats' concerns, rather than waiting for them to learn yours.

This is culture, not paperwork. But the template forces the culture into a habit.

The deep cut

Roman Pichler's work points at the thing that quietly decides whether any of this holds: the triad has to be genuinely empowered to own its goals, not just handed a plan and told to align. A team that owns its product goal and its roadmap has a reason to shape work together. A team that is only executing someone else's spec will treat the ritual as theater.

And notice what Pichler says about the tie-break. He is a fan of collaborative decisions, but someone still needs authority to decide when the trio cannot agree, so the team is not trapped in endless argument. Empowerment plus a clear tie-breaker is the balance. Too little authority and you get paralysis. Too much and you are back to one person deciding while the other two nod. Write down who breaks the tie, then hand the goals to the team and mean it.

Three questions for your team

1. Do we have a written triad working agreement that names where our three lanes overlap and who breaks a tie? If not, draft one page this week and test it on your next real decision.

2. Where in our process do PM, design, and engineering actually shape work together before scope is locked? If the answer is a handoff, borrow Later's move: a short, small session with one person per seat working from rough sketches.

3. Are we copying a structure like Airbnb's because it fixed a problem we actually have, or because it looked good? Lenny Rachitsky's breakdown of what Airbnb really changed is a good gut check: name your problem first, then decide the right PM shape for your org.