The Drafting Got Cheap. The Thinking Didn't.

For about twenty years, I've helped teams gather and write software requirements in professional services, financial services, and healthcare. These aren't industries that dismiss the discovery phase. And in my experience, they can invest a considerable amount of time in it.

What are we building? Who are we building it for? What problem is it supposed to solve? These questions get asked, workshops are held, and documents are written. The captured requirements are reviewed and approved.

And teams sometimes still build things that very few people use. Because asking the questions isn't the same as understanding the answers.

A requirements spec usually captures what users and stakeholders said during discovery. Sure, that can be very useful, but it isn't automatically the same as what the business needs, what their customers need, or where the real opportunity is.

Getting from what people initially ask for to what they really need, and to what's actually worth building, has always been the hard part. AI hasn't changed that. What it's changed is how quickly we can turn an idea into something that looks real.

Three different research groups, measuring three different things, pointing at the same gap. We got much faster at producing the work. We did not get better at deciding what the work should be.

We Can Produce the Artifacts Much Faster

A team can now leave a working session with a transcript, a summary, an initial set of requirements, several possible workflows, a draft UI, and a clickable prototype made with real code.

This can now happen in a fraction of the time it once took, and AI is genuinely useful here. It can help capture a conversation, organize a large amount of information, find patterns in research, suggest scenarios we missed, generate alternatives, and turn a rough idea into something people can react to.

This is a meaningful change, but it also creates a new temptation.

When an idea can become a polished prototype in an afternoon, it's easy to mistake the quality of the artifact for the quality of the thinking behind it. The screen looks convincing, the workflow feels complete, and the prototype looks great on a demo call. But none of that tells us whether the idea solves the right problem.

The people best equipped to catch that seem to be the ones most on guard about it. In the same Stack Overflow survey, trust in AI accuracy fell 11 points in a year, and more developers now actively distrust the output than trust it. The experienced ones are the most cautious of any group: 2.6% say they highly trust what comes back, 20% highly distrust it. They use the tools more than almost anyone and believe them least, which is roughly what judgment looks like from the outside.

The DORA research is the clearest version of this. Both of those findings hold at the same time, and that's the part worth paying attention to. Teams can move more work through the system while also creating more instability downstream. DORA's own explanation is that AI generates code faster than review and deployment can absorb it, so the volume finds whatever was already weak.

The same thing can happen a layer up, at the product level. A team can generate more requirements, more concepts, more screens, and more code without increasing its understanding of the customer or the desired outcome. The production numbers improve. The product stays where it was.

AI doesn't solve that problem. It exposes it.

When generating the work was slow, teams had fewer opportunities to act on weak assumptions. Now those assumptions can spread through requirements, designs, code, tests, and production before anyone stops to ask whether the original idea was right.

Requirements Should Reflect What We Learn

I've never thought of design, prototyping, and requirements as separate steps. Ideation gives the team different ways to approach the problem. Prototyping gives people something tangible to react to. Research and testing tell us if and where our assumptions were wrong. The requirements should change as a result, and that's the point.

A prototype isn't valuable because someone produced it, but because the team can put it in front of intended users and product managers before committing to production code. We can watch where a person hesitates. We can see whether the language makes sense. We can discover that the workflow doesn't match how the job actually gets done. We can learn that the feature people asked for doesn't address the underlying problem.

Then we can change the requirements while changing them is still inexpensive. The UK Government Digital Service says much the same thing in its guidance: prototypes exist to explore, share, and test different designs before committing to a build, at only enough fidelity to test the idea, and most of what you explore should be thrown away. AI makes that cycle much faster, but that should mean more learning takes place before production, not less.

The Business Case for Design Isn't About Making Things Look Better

There's evidence that poor requirements are expensive, though it's older and softer than I'd like. PMI's Pulse of the Profession research on requirements management found that nearly half of unsuccessful projects, 47%, failed to meet their goals because of inaccurate requirements management. That figure is from 2013, it's self-reported by the organizations involved, and blaming requirements is a comfortable answer, so treat it as directional rather than precise.

The design-side evidence has the same problem. A 2018 Forrester study commissioned by IBM found that organizations applying IBM Design Thinking cut the time required for initial design and alignment by 75%, reduced development and testing time by 33%, and halved design defects. Before anyone quotes those numbers at you, they come from interviews with four IBM clients and 60 survey respondents, modeled into a single composite company. Four clients. IBM paid for the study. Read it as a vendor's best case, not as a measured result.

What both studies point at is not the workshop. The more likely reading is that teams make better decisions when they stay close to their users, test ideas early, work across functional boundaries, and treat design as part of how the work gets defined rather than decoration. Doing more thinking up front didn't slow those organizations down, because they carried fewer misunderstandings into development.

AI Makes Product and Design Thinking More Important

Even in the age of AI and prompting, the order still matters. We need to understand the problem we're solving and the audience we're solving it for before we start coding.

That doesn't mean spending six months producing a perfect requirements document. What it takes is enough shared understanding to make an informed first decision, something small enough to test that decision, and the discipline to update our understanding as we learn.

Design thinking helps us understand the people involved.

Who are they? What are they trying to accomplish? What gets in their way? What have they already done to work around the problem? Does our proposed solution make their job easier, or does it simply give them another system to maintain?

Product thinking connects that understanding to the business.

What outcome matters? Why is this worth investing in? What's the smallest thing we can build to test the idea? What would tell us that it worked? What would tell us to stop?

AI can support both disciplines. It can pull themes out of research, suggest questions, create journey maps, generate concepts, draft requirements, and build prototypes. What it can't do on its own is supply the organizational and customer context nobody gave it. It can't decide which stakeholder has correctly described the problem. It can't know that a technically reasonable workflow will fail because it conflicts with how the organization actually operates. It works from the understanding we give it. If that understanding is incomplete, the output will be incomplete too. It may simply look much more finished.

Which is why the most useful thing a product person does now happens before anything gets generated. Define what good looks like, and what would tell us we got it wrong, before an agent produces twenty versions of it. That isn't less work. Just less production work and more deciding.

The Work That Builds This Judgment Is Going First

There's a second-order problem here, and it may end up mattering more than any of the above.

The Stanford research above measured employment across AI-exposed occupations. It didn't break out designers, product managers, or business analysts, so what follows is my read rather than their finding. But the shape of it is hard to ignore. AI isn't replacing experienced practitioners, it's removing the entry-level work they used to do on the way up.

Think about what that work was. Reading a bad brief. Redrawing a screen four times. Watching someone senior frame a problem in a discovery call. That's how the judgment got built, and it's the work an agent is best at.

So every junior who learns the tools before the disciplines is probably a senior who won't exist when we need one. By 2030 the group of people who can hold the whole chain, business need to customer need to outcome, will likely be smaller than it is today.

What Buyers Should Ask

"Do you use AI?" is no longer a particularly useful question for a delivery partner. Almost everyone does.

The better questions are about what happens around the tools. Mine are some version of the three I opened with, pushed a little harder.

• ✓How do you determine which problem is worth solving?
• ✓How do you involve the people who'll actually use the product?
• ✓How does research change the requirements?
• ✓When do you prototype, and what do you expect to learn from it?
• ✓How do you decide which AI-generated ideas to reject?
• ✓What outcome are you designing for?
• ✓What evidence would cause you to change direction?

Those questions reveal whether AI is being used to improve learning and delivery, or simply to increase output.

Output isn't the scarce part anymore. Understanding what deserves to be built is the part that never got cheap.

AI can help us capture more, explore more, and deliver faster than we could before. But somebody still has to understand the problem well enough to know whether we're delivering the right thing fast.