Sriram Narayan recently took a swing at a trend that has quietly become a corporate comfort blanket: treating “triads” as a hiring plan instead of a collaboration pattern. His point is simple and sharp. When leaders interpret triads as “a designer and a PM per engineering manager,” they create a “too many cooks” problem, especially on AI work where everyone wants a say. (LinkedIn)
Now let me take it further, because AI is not just stressing the triad. It is exposing the part we were pretending was not true.
The classic triad assumes that progress comes from three separate specialists negotiating a shared truth: product defines what, design defines how it feels, engineering defines how it works. That model made sense when creating options was expensive, when iteration required long cycles, and when the cost of getting it wrong was paid late. AI flips that. Options are cheap. Iteration is constant. And mistakes show up fast because the feedback loop is ruthless.
So the triad does not need to disappear. It needs to mutate.
The triad should become a set of accountabilities, not a 1:1 staffing ratio
Here is the uncomfortable truth: in a high-performing AI-enabled team, the “jobs” of product, design, and engineering are increasingly executed as a blended capability at the point of creation. What you still need is not three people to do three jobs. What you need is three accountabilities that are always present, even if they are carried by fewer humans.
Those accountabilities are consistent across nearly every product that wins:
Intent: What change are we driving, why does it matter, and how will we know it worked?
Experience: What should it feel like, where does trust get earned or lost, and what tradeoffs are we making?
Integrity: Will it hold up in production, scale economically, and survive contact with real users and real data?
If those three are present, the team can move with speed and coherence. If any one is missing, you get the modern failure modes: busy roadmaps with no impact, polished UX over fragile systems, or technically impressive outputs that users do not adopt.
The staffing implication is obvious and most organizations still refuse to accept it: you do not always need a dedicated PM and designer sitting next to every engineering manager to ensure those accountabilities show up. Sometimes you need one strong product-builder who can carry two of the three accountabilities, plus a lightweight review loop that protects the third.
Team size should dictate how “triad” shows up
This is where the discourse gets lazy. People argue for triads as if every initiative is the same size. That is how you end up with a bureaucracy for small work and chaos for big work.
When the scope is small and tightly bounded, the best teams run like a studio. A single lead can carry intent and experience, engineering carries integrity, and specialists are pulled in for targeted reviews. This is how you keep momentum without turning every decision into a meeting.
When the scope is medium and ambiguous, you want a core leadership triangle, but not a permanent committee attached to every slice of delivery. You need a small group that sets direction and quality bars, while execution is driven by builders who can iterate fast. The triad becomes a calibration mechanism, not an approval gate.
When the scope is large, the triad moves up a level. You need a leadership triad to set the narrative, constraints, and investment thesis, then teams beneath it run with autonomy. The mistake is cloning triads downward until coordination overhead becomes the work.
If you want a simple rule: the smaller the scope, the more the triad should feel like a lightweight editorial review. The larger the scope, the more the triad should feel like strategy and quality governance.
AI turns triad leaders into editors and context creators
In an AI environment, the scarcest resource is no longer the ability to produce artifacts. AI can produce endless artifacts. The scarce resource is judgment: what matters, what is true, what is safe, what is coherent, what is worth shipping.
That is why triads should move from “authoring” to “editing.”
Product leadership becomes less about writing PRDs and more about editing context. The highest leverage work is clarifying constraints, defining what a win looks like, and forcing the organization to choose. If the team cannot say what metric or outcome is supposed to move, they are not building a product. They are producing activity.
Design leadership becomes less about specifying screens and more about editing experience. In AI products, experience is not just usability. It is trust. It is how uncertainty is communicated. It is when the user is in control. It is when the system should refuse to act. That is not a pixel job. That is a judgment job.
Engineering leadership becomes less about translating requirements and more about editing integrity. AI prototypes lie easily. They can look “done” while hiding operational fragility, security debt, data leakage risk, and cost explosions. Engineering’s role is to enforce reality and build the guardrails that make speed sustainable.
This editorial framing is what allows you to break the 1:1 triad staffing assumption without losing quality.
“Demos instead of memos” is the lever that makes this work
If you want to shrink coordination overhead and still align fast, you have to stop using documents as the primary medium of truth. Long memos are a tax on momentum. They are also a magnet for politics because people can debate interpretations forever.
Demos collapse that debate. A demo forces clarity because it shows what exists. It forces prioritization because you cannot demo everything. It forces accountability because reality has no patience for hand waving. The discipline of demo-driven development is one of the simplest ways to keep triad responsibilities light while keeping outcomes strong. (Agile Budgeting “Demos” play)
AI amplifies the power of demos because it compresses the idea-to-prototype loop. When the loop is short, you can replace speculative alignment with concrete iteration. That is how triads become agile without becoming a permanent meeting series.
The reimagined triad is not “less collaboration.” It is sharper collaboration.
If you implement this well, something counterintuitive happens. You get fewer people involved in day-to-day micro decisions, yet you get more real collaboration where it matters.
You trade performative collaboration for high-signal collaboration.
You also change the culture of accountability. The team no longer hides behind “the PM owns that” or “design needs to weigh in” or “engineering will figure it out.” Everyone builds, AI accelerates, and the triad edits. That is the right division of labor for this era.
Supporting material: what I would change in a modern product operating model
You can adopt this without rewriting your org chart if you treat it as an operating shift, not a reorg.
- Keep triads, but run them like an editorial board that reviews intent, experience, and integrity through demos.
- Staff to scope. Use dedicated triads only where the problem size and ambiguity justify it.
- Replace long PRDs with a context pack that can fit on one page, backed by a working demo.
- Make impact explicit. If the team cannot articulate what changes after shipping, they are not ready to ship.
The answer is simple: triads were designed to reduce translation loss between functions. AI reduces the cost of creating and iterating, which means the new bottleneck is judgment and coherence. The teams that win will stop staffing triads like a ratio and start running triads like editors of meaning, quality, and impact.
bencoding 