Your delivery chain can compress from months to days. Not by generating code faster, but by changing what happens before the coding starts.
The chain
- We need a new checkout flow by Q3.
- Talk to the PM.
- PM needs a spec.
- That's the BA.
- BA needs screens first.
- That's UX.
- UX is mid-sprint.
v- So… Q3?_
Weeks later: engineering grooming. Sometimes months.
The chain existed because translating a fuzzy business idea into something an engineer could build is genuinely hard. Each handoff was a translation. Each translation takes time.
What has changed isn't the need to translate. It's who does it, and how fast.
From months to an afternoon
Your PM can now build a working prototype directly from a strategic idea. Not wireframes. Not a spec document. A working prototype, in hours, using tools like Claude Design.
Users validate the idea before a line of code is written.
Gone: the BA translation layer, the UX handoff, the approval loops. One person with the right tool can now do in an afternoon what the chain took weeks to produce. Your engineers receive something real to look at, to question, to build from.
The demo loop
That prototype goes to a pod of two or three engineers, not a grooming session. The PM walks each pod through it. Edge cases surface. Decisions land in real time.
A ticket follows. No user story - just what came out of that conversation: the edge cases, the decisions, the constraints.
What about everything that doesn't get said in that meeting?
Daily demos close the gap. The pod accepts the ticket won't be fully fleshed out from the start. Every day, they show running code (built since the day before) back to the PM. Feedback comes in. The work adjusts.
The org change nobody plans for
Your PM needs to be a different kind of person now. Not a spec writer or a backlog manager. Someone who can hold a product vision, prototype it in hours, and run a daily feedback loop with your engineers.
The old requirements chain didn't just slow delivery. It distributed accountability so thinly that nobody felt the full weight of a bad decision. The BA owned the spec. UX owned the screens. Engineering owned the build. When something shipped wrong, the gap between those handoffs was always where the blame landed - and where the learning was lost.
When your PM and the pod share a prototype, a daily demo, and a ticket that came out of a real conversation, something shifts. They are accountable for the same outcome. The gap disappears, because there is nowhere left to hand the problem off to.
The engineering manager's job shifts with it. Breaking the team into pods means fewer coordination meetings and fewer half-formed tickets. What appears in their place is harder to manufacture: engineers accountable for understanding what they are building, not just executing what someone else has written. That is a better job. Not easier. Better.
The experiment on my team
I've been running this model with a large team for the past several months. The daily demo cadence is still finding its rhythm. Some engineers rose to the accountability immediately; others are still waiting for someone else to do the discovery for them. That gap is now visible in a way it never was when tickets arrived pre-written.
Pod composition has proved messier than expected. When priorities are clear, the pods hold their shape. When they aren't, we add people, split pods, or run smaller groups than planned. The structure is more fluid than the model suggests.
What none of that messiness has changed is the result. The end-to-end journey from idea to production has compressed from months to days. Not by hiring faster engineers or buying better tooling. By changing what happens before the coding starts.
Filipe Albero Pomar is an engineering manager and speaker based in London. He writes about AI adoption, engineering leadership, and software delivery. Find him at alpomar.dev.
TechLeadConf 2026 · GenAI London 2026
Top comments (0)