We won a project to rebuild a company’s core business system from the ground up. About three months of work. The requirements-definition kickoff was three weeks away.
Normally those three weeks become “time for reading documents.” The RFP, the specification of the current system, the business flows, the past correspondence. Read them, understand them, build a list of questions. That is what we were taught the entrance to requirements definition looks like.
This time we did not do that.What we did on day one was fix 82 things in a working prototype.
AI-driven development is assumed to be about making implementation faster. What actually changes is not only that.What changes is the way the earliest stage works — from sales through to the project kickoff.This series is the record of it.
Build something you can show before you start reading.
The reasons requirements definition goes wrong are almost always in the same place: the customer and we are not reading the written requirements with the same meaning. “Searchable from a list” says nothing about who looks at how many records, or how many seconds they have to decide.
A list of questions does not close that gap.Showing a screen closes it.
So we made it the first day’s job to raise the working prototype we had built during the proposal stage to a quality the customer could touch directly at the kickoff.
In one day: 82 issues, and 18 discoveries.
This is what the day held, as far as the record shows.
We ran QA across every screen for two passes and found and fixed 82 issues.Fixing what the first pass finds breaks a different screen as a side effect. That is why a second pass is needed.
We walked through the real build with human eyes, found 18 things, and fixed 14 of them on the spot.QA catches things up to “it does not work.” “It works but it is hard to use” only comes out when someone actually touches it.
We combed for gaps against what we had promised, using a gap analysis by priority.Where in the prototype is each requirement we had positioned as essential in the proposal? Anything missing was added that day.
And we ran two rounds of AI cross-review over all of it.Reviewing your own work yourself leaves the blind spots in the same places. Have a different AI review it from a different standpoint and points come out that you would never notice yourself. Several of that day’s fixes were things no human had spotted.
We turned 234 messages into a searchable asset.
There was one more piece of work — unglamorous, but it paid off.
Up to winning this project we had exchanged234 messages.Decisions, concerns that were hard to raise, changes to the terms — all of it is in there. And yet in practice, nobody can find any of it at the moment they need it.
So we reduced all 234 to a list with summaries: date, counterpart, gist, what was decided. Now “when, by whom, and in what context was that condition stated” can be pulled up in seconds.
What causes the worst friction in requirements definition is not the substance of the specification.It is the mismatch between “we agreed that” and “I never heard that.”Effort spent preventing it is always recovered later.
Traditionally, day one would not have ended here.
Consider what it would take to do everything written above with a conventional team.
Two QA passes over every screen. A walkthrough on the real build. A gap analysis by priority. Fixing the findings and re-verifying. Summarising 234 past messages.Normally that is a volume of work requiring several people for two weeks or more.So with the conventional approach, this work simply does not get done. The reason three weeks disappear into reading documents and writing a question list was never a matter of ability — it was a matter of volume.
Put AI at the centre of development and that volume fits into a single day. Andonce it fits, the moves available at the earliest stage change.The assumption that “a prototype is something you build after kickoff” collapses, and from day one you can talk with the real thing in hand. This is not a story about becoming faster. It is a story aboutthe order being swapped..
Day one’s judgement decides the quality of a meeting three weeks later.
If all you bring to the kickoff is paper, that day becomes a day of explaining. If something works, that day becomes a day of deciding.
The productivity of requirements definition is settled almost entirely by what you can bring to the first meeting.That is what day one was spent on.
In this series we will write the record of how this project got to requirements definition, across seven instalments.how AI-driven development changes everything from sales through to requirements definition — leaving in what went well, what tripped us up, and the judgements that later turned out to be wrong.
Next time: cutting our own company introduction out of the first meeting’s agenda.
* The counts in this article are our own side’s work records. Nothing identifying the customer or the system is included. Approach and time required vary with the scale and structure of the project.
Series “Project Diary” (7 parts)Part 1: 82 fixes to the prototype on the day we won the project (this article)Part 2: Cutting our own company introduction out of the first meeting’s agendaPart 3: Counting what we did not understand and putting it on the tablePart 4: Bringing the prototype closer to the real buildPart 5: Killing “it looks like it worked but nothing happened”Part 6: Cutting promises we could not keep out of the materialPart 7: Dropping the paper comparison and deciding by measurement