The evolved squad.

My proposal on rethinking the agile team structure for an AI-native world.

Tried and true Venn diagram of representing business viability, technical feasibility and user desirability.

There’s a Venn diagram most of us have seen a thousand times showing the balance of business viability, technical feasibility and user desirability. The sweet spot sits in the middle, that magical place where good products live.

We’ve nodded at it in workshops. We’ve put it in decks. And then we’ve gone back to our siloed team structures that quietly undermine everything it stands for.

It’s time to close the gap.

Most teams I see today are built around professional identity: designers, developers, product managers. The assumption baked in is that your job title determines whose advocate you are. Designers speak for the user. Engineers speak for the system. PMs speak for the business.

That made sense when roles were distinct and tools required deep specialization. But AI has fundamentally flattened that, and it feels like we are all now simultaneously saying “I can now do ________’s job”

Front-end developers are prototyping UX flows. Product owners are generating content. Designers are creating roadmaps. The walls are down. But the accountability hasn’t caught up. In my opinion, much of it is ego driven around which discipline is ‘right’. The harsh reality we all have to accept is that maybe the title you identify with, isn’t reflective of the goals you see as successful. And in this new world with AI, maybe–just maybe–it’s the best time to shake things up.

The time for self-reflection is upon us.

I have seen many ‘designers’ who know Figma inside and out, but do not have a great eye for quality and whose output never evokes any emotion, let alone desirability. Similarly i’ve seen many ‘developers’ who live in code, but aren’t great at understanding the systems that connect everything together and how it scales. I’ve also seen many ‘product owners’ who know Jira inside and out, but are really bad at understanding business drivers and operations. But they show strengths in other areas. That same ‘bad designer’ is a great system thinker or understands business needs. That same ‘bad developer’ is passionate about launching something that will help the end user or hitting the metrics set by executives. And, that same ‘bad product owner’ get’s joy from vibe coding something or understanding how all the puzzle pieces fit together.

If AI brings upon anything, it should be that the titles and tools we pride ourselves on are a finite game. The infinite game we’re playing are bettering outcomes. If you’re like me and still believe that balanced outcomes behind customer desirability, technical feasibility and business viability are true–then you’ll get that it’s time for a change.

Becoming the Architects of outcome

What if we stopped organizing teams by siloed disciplines and started organizing them around thinking modes?

The org structure I’ve been noodling replaces the traditional design/dev/product triad with three architect types that map directly to the product Venn diagram:

Experience Architects (Creative & Empathetical Thinkers)

These are the advocates for human experience. Visual designers, qualitative researchers, content writers, front-end developers. Their north star is desirability — does this work for the person using it?

Technical Architects (Analytical & Systems Thinkers)

These are the advocates for how things work and scale. Interaction designers, quantitative researchers, back-end engineers, system architects, design system governors, content governors. Their north star is feasibility — can we actually build this well?

Business Architects (Strategic & Value-Driven Thinkers)

These are the advocates for why it exists and who it serves. Product owners, client partners. Their north star is viability — does this create and sustain value?

Notice something: a front-end developer can be an Experience Architect. An interaction designer can be a Technical Architect. The frame isn’t about what you do — it’s about what you stand for on a team.

How the Squad Actually Works

Each product line team carries all three architect types, led by a Business Lead, Experience Lead, and Tech Lead — plus a Delivery Lead who keeps the machine moving. Above them sits a Head of Product (Management & Operations) who acts as a neutral mediator, ensuring no one perspective dominates.

Projects are distributed across teams based on bench capacity, not skill specialty — because every team carries all the skills needed. This matters. It forces cross-functional thinking from day one rather than handing off between silos.

Teams are capped in size and project load (no more than four active projects at once), and new teams are scaled up by splitting off leads and moving ICs — not by ballooning headcount on a single team.

Each team develops its own working style under its leads’ direction. Executives and management are accountable for giving equal space to all three lead types. The Experience Lead doesn’t get treated as support. The Tech Lead doesn’t get to override the business case. The Business Lead doesn’t steamroll the human experience.

Why AI Makes This Urgent

The tools that used to require years of specialization are now accessible to almost anyone on a squad. Generative UI, AI-assisted research synthesis, automated content production — these aren’t future concepts. They’re in the hands of your teams now.

That means the designer who used to be the sole guardian of experience quality is no longer the only one making experience decisions. And if we don’t deliberately build accountability for thinking mode into our structures, quality will erode — not through malice, but through role confusion.

This model reframes the question from “what is your job?” to “what are you accountable for advocating?”

The Org Doesn’t Have to Change Overnight

This isn’t a full organizational redesign proposal. It’s a mental model shift that can be introduced at the team level. Start by asking on your team, who are the advocates the experience, feasibility and business impact?

So, if you have a PO who would rather vibe code the end product? Then they aren’t the PO they are the Experience Architect. And if they prove they can achieve experience goals, why stop them. Now is the opportunity to make those accountable for their own AI slop.

And if the Venn diagram is right. We just need org structures brave enough to actually live by it.