Friction was a feature

The title centred on a deep blue ground over faint requirement rows that fade out under the words.

AI removed the consultant's friction and the client's at the same time. One of them needs to come back.

If you're an enterprise software implementation consultant, you may have noticed an interesting shift in the discovery process lately. In the past, you'd usually come into an engagement pretty blind, so you would get on some calls with some stakeholders and then slowly pound out a list of structured requirements. Nowadays, we have AI, and so before you even get a chance to learn your client's name, they're sending you an email titled Business Requirements Document containing that structured doc that used to take you so much time.

I imagine the client's reasoning goes something like this:

  • The consultant is going to ask us for requirements
  • Requirements are a document
  • ChatGPT is great at writing documents!

"What a relief," you may have thought the first time this happened. "This will save me so much effort!"

But as time went on and you started to learn the mannerisms of Claude and ChatGPT—"it's not X, it's Y" and the overwrought, self-serious tone—you realized that they weren't saving any time for you at all. In fact, they were doing quite the opposite.

A requirements document comes from business facts, and those facts have to come from somewhere. Before AI, the only place you could get them from was the client's words, and getting them out was slow and uncomfortable. This is because most organizations don't spend the time (nor should they) to write down precisely how they work. Their processes are sometimes documented, often habitual, and it takes real skill to drag them out.

But when the client asks their favorite language model to write a requirements document for them, it doesn't have access to any of that. Oftentimes they are just working with a big copied-and-pasted dump of random context plus the client's chain-of-thought regarding a particular problem.

This is a problem, because the capable model produces fluent and complete-looking documents which actually say almost nothing about the client. The parts that make this company different from the norm are exactly the parts an implementation has to get right, and they're the parts that the consensus-trained model can't know.

This is not groundbreaking news. In consulting it's a given that if left alone, clients describe how things are supposed to work, not how they do. The consultant's real job is pushing until the client says something true. That pushing is where the requirements come from. The document is just where they get written down after.

AI removed both kinds of work at once. The consultant's writing got automated—which is great—but the client's thinking got automated too. It can look like discovery happened, but it didn't, and if you choose to build against it, you're going to have trouble in a few months when the client says "this isn't what we meant."

So, the goal isn't to bring all of this friction back. Making consultants hand-write specs again would bring back a lot of the friction with little of the value. The goal is to keep the writing and recording automated, but the thinking impossible to skip. This means letting go of customer-generated requirements lists, or at least only using them for a quick brief before meetings. It also means pointing AI at a different job during discovery. Rather than trying to automate the writing, find where it can help you in your thinking. Point your agents at the transcripts and the documents in an engagement and ask them, "what are the gaps?" Tell your agent to scan across all the context and cross-reference the words of different stakeholders and hunt for contradictions.

This changes what good discovery looks like. Page counts and line items are no longer meaningful (see Goodhart's Law). What really matters is how many real decisions the client has made and how many are still open.

This is a big part of what we think about at Datafruit: how to make the engagement's record track what has been decided, not just what has been written down. Software engineers have been grappling with the raw pace of AI for a few years now, and so far it's looking like the boring answer is probably true: code can come from anywhere, but someone has to understand it before it ships.

Discovery is headed the same way. By all means, let the model write the document. Just don't let it decide what goes in it. Get on the call, push until someone says something true, and then write that down.

A new standard for software implementations.