Clients Are Co-Creators, Not a Source of Requirements

We stopped doing requirements gathering about two years ago. Not because we got sloppy about understanding what clients need. Because the premise behind it stopped being true.

Requirements gathering assumes the client has a vision locked inside their head, and your job is to extract it. Ask the right questions, fill in the template, translate their words into a format the development team can work from. The client is the source. You are the miner.

That assumption made sense when clients showed up with nothing but an idea and a budget. It doesn't hold up when they show up with an 80-message ChatGPT conversation that maps an entire product architecture. Or a Figma Make mockup with real user flows, already tested with three potential customers.

These aren't requirements waiting to be gathered. They're indications of intention. Not every decision in an 80-message thread was deliberate. Some were AI suggestions the client accepted because they didn't know what question to ask next. But the direction is real. We read these artifacts and see what someone is actually reaching for, then dig into whether there's a better way to get there. The people who made them aren't passive sources of information. They're co-creators.

The extraction model

For decades, the relationship between clients and builders followed a predictable script. The client describes what they want. The builder listens, asks clarifying questions, writes it down in a format the development team can work from. Then the client steps back and waits.

This is requirements gathering. The name tells you everything about the power dynamic. You go to where the requirements live (inside the client's head), you gather them (extract, document, formalize), and you bring them back to the people who can do something with them.

Nobody designed it to be adversarial. But the structure creates distance by default. The person who knows the problem is in one room. The people building the solution are in another. Between them: documents, tickets, specifications. Each translation loses context. Each handoff loses intent. The client had a vision. What gets built is a version of a version of a version of that vision.

And the extraction model worked well enough when clients had no alternative. When the only way to build software was to hand your ideas to someone who could code, that model was the best available option.

It's not the best available option anymore.

The parallel worth hearing

In 2001, the Agile Manifesto named something everyone in software already knew but fought against: requirements change. Waterfall treated changing requirements as a planning failure. Agile said: that's not a failure, that's reality. Build the methodology around it.

That was radical. It moved clients from the periphery to the conversation. But even Agile's version of "collaboration" still assumed a specific shape: the client informs, the team builds. The client participates through standups, reviews, feedback loops. Enormously better than waterfall. But the client is still fundamentally a source of input, not a participant in the making.

The shift happening now goes further. Clients aren't just informing. They're creating. They show up with working prototypes, AI-generated designs, detailed product thinking that would take an outside team weeks to develop.

Agile embraced the reality that requirements change. The new model embraces the reality that clients create.

The question isn't how to gather their requirements more efficiently. It's how to channel the creative energy they're already bringing.

What co-creation actually looks like

Co-creation isn't "the client gives feedback on our work." That's consultation. Co-creation means the client is in the work, shaping it as it takes shape.

A healthcare executive sits with our team while agents generate interface options based on our discussions. She doesn't wait for a review meeting. She reacts in real time: "That's not how triage works. The nurse needs to see acuity level before the patient name." The change happens immediately. Not in the next sprint. Now.

A logistics founder sketches a routing workflow on paper, and within the hour, a demoable version exists that we're both trying and improving. He spots an edge case that comes from fifteen years of running the routes. No requirements document would have captured it because he didn't know it was a requirement until he saw the screen.

A compliance lead at a financial services firm brought a specific frustration: every reporting tool she'd evaluated organized data by regulatory category. That's how developers think about compliance data. It's not how compliance officers actually work. They work by deadline, by risk level, by the question "what's going to get us in trouble this quarter?" She couldn't articulate this in a requirements document because every template she'd been given already encoded the wrong assumption. In the work, seeing options generated in real time, she could finally show what she meant instead of trying to describe it in someone else's language.

That pattern is the important one. The most valuable requirements don't exist until the co-creator sees the work in progress. They can't be gathered in advance because they emerge from the collision between domain expertise and working software. They're not sitting in someone's head waiting to be extracted. They're created in the act of building together.

This is why the old model fails in ways that feel like bad luck but are actually structural. The team built exactly what was specified. The client looks at it and says "that's not what I meant." Everyone is frustrated. Nobody is wrong. The process guaranteed this outcome by separating the person who knows the problem from the moment the solution takes shape.

The new relationship

Treating clients as co-creators isn't a philosophical stance. It's a structural advantage.

When the person who's spent fifteen years in the domain is in the room while the product takes shape, the product reflects fifteen years of expertise. When they're separated from the build by three layers of translation, the product reflects a two-page requirements summary. Same client. Same expertise. Different outcomes, determined entirely by whether the model lets them create or reduces them to a source.

The artifacts clients bring (prototypes, conversations, designs) aren't raw materials to be refined by professionals. They're the starting point of a collaboration where both sides contribute what they do best. The client brings domain expertise and creative energy. The team brings product thinking and the methodology that turns co-creation into production-grade software. AI agents accelerate the cycle between them.

Our clients aren't a source of requirements. They never really were. We just didn't have a model that let them be what they actually are.

The best products we've shipped weren't built for our clients. They were built with them.