The New SDLC is Full Stack and Concurrent

For most of my career, the holy grail was getting strategy, design, and engineering as close together as possible. The best version of this was small groups — the right people, co-located, maintaining tight context and shared alignment, collaborating in real time. When it worked, it was exceptional. But it was hard to get right, and it rarely scaled. Outside of small, high-trust teams, it tended to degrade into ceremony.

Ten years ago, I'd draw diamonds to explain how this works — the double diamond. Understand the problem, define the strategy, then explore and create the solution. Two phases, two mindsets, one team. With today's AI tooling, it looks different. The phases now stack on top of each other in one concurrent cycle, where just one person can direct and collaborate with agentic tools, working end-to-end from opportunity to working software.

Not discovery — I want to be clear about that. Understanding the problem, defining the strategy, making sense of the landscape — that work isn't going away. In fact, it matters more now.

It's mostly the Explore → Create cycle that collapses. The part where you go from a strategic direction to working software, iterating through design and engineering to find the right solution. That loop now runs so fast that the collaboration model around it can't keep up. We can ship faster than the time it takes to decide whether it's the right thing to build.

And here's where it gets interesting — and dangerous.

Role-blending is a superpower for individuals, and a trap at scale.

When one person can now work across product thinking, design, and engineering in a single loop, the temptation is obvious: cut out the human collaboration, and use agents to compensate for your blank-spots. Designers are Software Engineers. Product Managers are Designers, and so on. For an individual practitioner, it's genuinely powerful. I've been doing it, and it works.

But imagine three people working independently and stretching into adjacent disciplines, each confident they're making good calls. You don't get a team moving fast. You get three separate, potentially inferior solutions — each missing depth in perspective that was too easy to skip. That's not collaboration. That's Dunning-Kruger at team scale.

The goal isn't three people doing each other's jobs badly out of convenience. It's moving as one, at the speed of one, with many brains collaborating — human and artificial.

That's an unsolved design problem. And I think the answers look different depending on where you sit.

If you lead a product organisation

This one's for you first, because it's structural. The learning loop — the one that feeds insight from execution back into strategy — is now dramatically faster.

That means the quality of your strategic decisions can compound in ways that weren't possible when the build cycle took months. But only if you design for it.

Your org structure still assumes separate disciplines working in their own rhythm.

The question is how you restructure teams and governance for a world where the build cycle outruns the alignment cycle — without losing the multi-brain advantage that makes products genuinely better.

If you're in product

The first diamond is your home now. It always was — that's what product management actually is. But in many companies, product 'ownership' has been conflated with delivery administration. That work is being automated. What remains is the hardest, most valuable kind: making sense of complexity, creating clarity, and ensuring the right problems are being solved. Understanding the problem. Defining the strategy. Being decisive about what to build and why — and what not to. The artefacts change — requirements and roadmaps live in code now. But navigating ambiguity and aligning intent is more important, not less.

If you're a designer

There's a version of this conversation that reduces design to UI and tells you to be scared. Ignore it.

There's less shovel work now, but think about what that unlocks. You can explore more boldly, test ideas directly in the medium — designing and prototyping in code — and focus your energy on the things that require design expertise: understanding how people think and behave, intuiting your way around new interaction models, finding the beautifully simple solution where the best design is what isn't there. That's not diminished by AI. It's amplified — if you step into it.

If you're an engineer

Where your expertise creates the most value is shifting. When someone can go from concept to working prototype without deep engineering, the gap is everything that happens after the prototype: data architecture, scale, resilience, security — the invisible craft that determines whether something survives contact with reality. But there's another dimension too.

We've just multiplied a universe of people writing code who need to learn the craft — how to think about systems, how to build things that last. The teaching and mentoring role matters more now, not less.

The question is how you plug into a loop that's moving faster than your review cycle, and how what you're learning about what's possible feeds back into strategy. I'll write more on this in Part 2: What AI Native Design Looks Like, and Part 3: The Product Operating Model for AI Teams.

I've been testing the individual version of this — one person, one loop, hundreds of hours of building. It works, and it's taught me a lot about what's possible. But the team version is what matters at scale, and it's an open design question.

The second diamond collapsed. The first one didn't. Now we need to figure out how to collaborate inside the new loop, not around the old ones.

What's working for you? I'd genuinely like to know.