The bottleneck was us

Our engineering team had been planning a move to agentic development for months. It had been treated as an engineering delivery decision rather than a design one, so nobody thought to involve us, and I found out how far along they were when the first product scoped for it turned up ready to build.

The LMS was a new product area with new surfaces, new navigation and no precedent to follow, and the agentic build meant fast delivery with less need for pixel-perfect design before development started. PMs began sharing AI-generated wireframes directly with the dev team. They were following a process that had no design step in it, for a build that no longer needed finished screens to make progress.

I went to our CPO and VP of Engineering and made the case for experience architecture as a stage in how we deliver, rather than asking to be put back into a process that had already moved past us. The argument was about cost: structural decisions made without design expertise are cheap to take and expensive to unpick. I brought a proposal for how it would work rather than a complaint about being left out, which I think is why it landed.

We caught IA decisions and design system discrepancies before they were built. The product is still in development, but the fixes weren’t really the point. The point was that going around us had been a reasonable thing for the organisation to do, and that if I argued my way back into the old position I’d be arguing to be a bottleneck again.

So I didn’t argue it. Within a few weeks I’d rewritten how Product Design engages with delivery, and repositioned the team around it.

PMs used to request design work from us, so everything queued behind the same six designers supporting a platform used by two million people a month. Every settings change, every new report added and every bounded update came to us and waited its turn.

The cost wasn’t only throughput. It was that we weren’t doing the work only we could do, the micro-interactions and richer animation and onboarding states that make a new product feel considered rather than assembled. We were too busy servicing the simple to deliver the exceptional.

Agentic development didn’t create that problem, it made it impossible to ignore, because the simple work could now feasibly ship without us while the structural work was getting locked in before we ever saw it. When building gets cheaper, decisions about navigation and hierarchy get baked in sooner and cost more to reverse, and you can’t QA your way back to coherent IA.

So the question was not how to get design back into the process. It was: which part of the process should design actually own?

So I gave work away. Product Design would stop being the team you request design from and become the team that decides where design is needed, with bounded work that sits inside established patterns moving to PMs, who design it themselves in Claude Design working from our design system, with every output reviewed by us before build.

In exchange, we’re involved at the start of every structurally significant project, before anyone specs and before anyone builds.

It’s a trade rather than a land grab. We gave up execution on the work where our design system already knew the answer, in order to buy the upstream position on the work where it didn’t.

Renaming the team from UI/UX to Product Design followed from that, along with the job titles and a career framework rewritten underneath. A rename on its own would be decoration, but attached to a change in what the team is accountable for it was the cheapest way to tell the organisation that something had genuinely changed.

I split delivery work into two tiers. The tier is assigned at scope review.

Tier 1 is experience architecture and we’re involved at kickoff, covering anything that introduces a new surface, changes navigation, restructures a journey, crosses product areas, touches a hero feature or needs a pattern that doesn’t exist yet. The LMS was Tier 1 on every one of those tests, which is exactly why it shouldn’t have reached development without us.

Any one of those signals is enough to make something Tier 1. Tier 2 is PM-led, and every one of these has to be true instead: an existing surface, unchanged navigation, a single PM domain, and every component already in the design system.

The part that mattered most was who assigns the tier. The guidance I wrote puts that with product leads at scope review, and that’s where it needs to end up, because if Product Design decides how much Product Design is needed then nothing structural has changed and we’ve just formalised the request queue with better paperwork. We’re still doing the tiering ourselves for now, which is deliberate. We’ll cautiously hand it over when we’re done trialling.

I wrote “under-tiering is the failure mode to protect against” into the guidance and told people to default to Tier 1 whenever they were unsure, and almost everything came back Tier 1. I’d built a system whose entire purpose was to stop us being the bottleneck and then tuned it so conservatively that it recreated the bottleneck on day one.

The instinct to protect quality is the same instinct that keeps design teams servicing work they should have let go of years ago, and mine turns out to be as strong as anyone’s. We’re relaxing the criteria gradually and evaluating as we go.

I expected pushback from PMs taking on extra work, but it came from my own designers instead. We’d been talking about AI’s effect on our workflows for months, but that didn’t stop the more junior members of the team hearing “PMs will design some things” as “design decisions are going to non-designers, and eventually you won’t be needed”. That’s a reasonable reading if you’re early in your career and your value still feels tied to producing the artefact.

It took several uncomfortable conversations, and what landed was the move from designing at the feature level to designing at the system level: the system is what carries our judgment into work we never personally touch, and stewarding it is a bigger job than executing screens.

They’re engaged with that framing now, and cautiously optimistic, though not free of the general anxiety about AI running through the industry at the moment. I’d be suspicious of a team that was.

I don’t think that argument is finished, though. It gets settled by what actually happens to their work over the next two quarters, not by anything I said in a team meeting.

The trade only works if quality survives, so I built an AI design review agent that runs across all design output, ours as well as PM-led, checking against the design system, content guidelines, UX practice and WCAG 2.2 AA. It runs in Claude Cowork with the Figma MCP and integrations into Jira and Confluence, so it reads the designs, the tickets and the documented standards together rather than assessing a screen in isolation. In its first three weeks it reviewed 15 tasks.

It’s surfaced content and pattern inconsistencies we’d previously have missed, but there’s been a more useful behaviour: it cross-references, so content gets reviewed in the context of the wider platform rather than one ticket at a time, which a human reviewer looking at a single ticket can’t easily do. For now it produces a report for a person to act on, and I’m not in a hurry to make it a gate.

PM-led design is running as an open-ended trial on a bounded set of work, new reports and settings changes, and the first nine tasks have been through it. The bar is no bottleneck in the design phase, and delivery that adheres to the design system. If PMs tell me they’ve absorbed too much work, or if a structurally significant project reaches build without us, that’s a failure of the tiering and I’ll pull it back.

The time it gives back is going into the design system and into the craft of the product itself, the finesse we’d been skipping. We’re also starting to originate product improvements rather than only responding to requests for them, and the first of those is a modernised, streamlined approach to reviewing candidates in our talent acquisition product.

The career framework is approved and communicated, and landed well with the team. Additional Jira automation and the roll-out to the full PM org are deliberately gated behind the trial rather than shipped alongside it.

This is a bet rather than a finished transformation, but I’m confident about the reasoning behind it. When development speeds up, building the wrong structure can send you pretty far down the wrong path quickly, and a design team that responds to that by trying to keep hold of every screen will get routed around by an organisation that’s moving faster than it is.