Only one part of the development cycle has actually gotten faster

We've been looking at our development cycles recently because the cadence that we used to expect has started to change. It’s not that the process is broken exactly, but we’re seeing developers run out of tickets to work on, while at the same time things are getting backed up during testing. Here's what we found.

1. Product planning: faster to produce, no faster to agree on. Research, synthesis, first passes at user stories, identifying edge cases. All of that comes together a lot faster than it used to. Unfortunately, what hasn’t changed is getting everyone to a shared understanding, in a form they can consume, before things get locked down. Generating more material does not help with that. It often makes it worse. You need to create enough text to get consensus, not look smart.

2. UX and design: faster to get started, no faster to be right. It’s easy now for a designer (or even a non-designer) to put several plausible-looking design directions together in a matter of hours. But knowing which one is appropriate for your users, chasing down the details, and validating that you’re right happens at the same speed as always.

Creating a design system and addressing user stories in a way that creates a coherent overall experience is less about drawing screens and more about balancing product/business requirements, technical considerations and user needs. Grappling with that challenge doesn’t get faster, and that’s the bottleneck when you take a quickly produced single mockup or basic prototype and turn that into usable artifacts for the dev team (or AI agents).

The thing that really pumps the brakes? Putting your product in front of real users and observing how it gets used in context – that’s the real test of whether you designed the right solution. Identifying where people struggle, diagnosing root problems, and knowing the appropriate fixes (that won’t have unintended consequences) isn’t getting faster because it happens at the speed of real-world adoption and usage.

3. Development: this is the one that changed the most. Work that used to take two weeks now lands in a few days. Five developers move like fifteen. The only hedging on this is that 10x (or 100x) efficiency is hype not born out in our experience.

We’ve all gotten good at identifying AI slop in writing – the same happens with code. The question is are you looking? The people who claim that development work is 10x faster may be kidding themselves about the quality and sustainability of that output. They also may be overlooking the cost of the tokens to get there (faster isn’t necessarily cheaper).

We do see those kinds of exponential efficiency gains in narrow cases – building commodity features for well understood problems and/or where the stakes are low. But when you’re working on new solutions, complex systems, and need to ensure data integrity, security, privacy, and scalability, there’s still some limit to how much faster things can move.

4. QA and testing: the new bottleneck. It’s not that testing got harder, but with development moving faster it’s hard to keep up. Like every other stage, generating the artifacts (refining acceptance criteria, writing test cases, etc.) has gotten quicker, but the bulk of the work takes roughly the same amount of time as it always has. And ensuring that you’re comprehensively testing the right things in the right way still requires human judgment.

Every stage has gotten faster at generating output. None of them got faster at the part where humans have to agree the output is right. Development is the stage where speed actually converts into finished work, which is exactly why the piles are forming on either side of it. Alignment upstream, verification downstream.

Downstream: testing is where releases back up

More code produced in less time means more functionality hitting QA at the same moment. Bigger changes, more of them, landing together.

It’s not just the pace. AI-assisted changes have a habit of doing exactly what the ticket asked and also touching three things nobody mentioned. Automated tests pass. Nothing obviously breaks. Then problems surface two releases later in an area that no one would connect to the original work.

What we're doing about it

• ‍Getting explicit with AI to limit the blast radius during dev. It helps to remind your AI agents to stay narrowly focused and minimize the changes it makes to just what’s needed to satisfy the requirements.
• ‍Diffing the ticket against the code. Before a change goes to testing, we ask AI a plain question: does this change do what the ticket says, and what else did it touch? Cheap step, and it has caught things we would have missed.
• ‍Cutting smaller releases more often. If the test surface of a release is too big to reason about, the release is too big.
• ‍Bringing in QA at the ticket, not at the build. If acceptance criteria aren't testable before the code exists, you find that out during testing, which is the most expensive moment to find it out.
• ‍Keeping human testing for what a machine can't judge. Real devices, real environments, degraded connections, the workflow someone performs while distracted and in a hurry. Automated coverage is table stakes now. Judgment about what's worth testing is not. Don’t rely on users in production to be the first humans to test what you’ve built.  

Worth a shout-out: our long-time partners at QA Camp bring a depth of testing experience that's hard to match, and we've relied on them for years.

Upstream: the constraint is alignment, not planning

Our old default team shape was roughly 1 product manager to 1.5 UX resources (design & research) to 5 developers. That ratio assumed developers were the slow part. Now those five developers work through a backlog faster than we can responsibly fill it, and the risk isn't idle developers. It's a very productive team building the wrong things very quickly.

The fix is not producing plans faster. We can already produce artifacts faster than anyone can read them, and that's part of the problem. A thirty page generated requirements doc that nobody reads isn't a plan. It's a liability with a table of contents.

What we're doing about it

• ‍Building artifacts people will actually consume. A one page brief, a clickable prototype, a five minute walkthrough. If it takes forty minutes to read, it won't get read, and you'll discover the disagreement halfway through the build instead of before it.
• ‍Writing the user stories ourselves, then using AI to flesh them out. Not the reverse. We still use the tried and true "as a…, I want…, so that…" form, because it forces the benefit into the open where a stakeholder can react to it. If you can't defend a story by making a compelling case for the benefit to the user, it isn't ready to hand off.
• ‍Getting agreement out loud, not by document. The test isn't whether people received the plan. It's whether someone else on the team can say it back to you and get it right. Then you lock it and build.
• ‍Agreeing about what we're not doing, and document when you'll revisit it. Most of the disagreements that surface mid build are about scope someone assumed was in.
• ‍Giving each person one specific piece to own end to end. Not a phase, not a list of tickets. A real part of the product with a result attached. Nobody complains about a hard problem being theirs. They complain about being partly responsible for five things and fully responsible for none of them.

The stage nobody puts on the diagram

There's a fifth one, and it's the slowest of all. Adoption. Your users form habits and opinions at human speed no matter how fast the four stages in front of them run. Shipping in two days instead of two weeks does not change how long it takes someone to decide your product is worth returning to.

Planning around that is its own discipline, and we wrote about it here: User Adoption Is the Real Speed Limit

If one stage of your cycle got fast and something else is now groaning under the weight of it, we'd enjoy comparing notes. It's most of what we talk about internally these days.