Between Discovery and the First Row of Code, There Is a Document Nobody Writes
I have watched good discovery work turn into bad reports. Not because the discovery was wrong. Because nothing carried it across to the build.
The workshop happened. Stakeholders talked. Someone produced a discovery report, a slide deck, or a page of notes. Then the developer received all of it and was told to start.
If you build BI reports, you know the document I mean. Thirty slides of findings, priorities, and quotes from interviews. It tells you what the business wants. It does not tell you what to build.
So you start building anyway. You infer. You guess at the grain of the fact table. You assume a definition of "active customer" because the discovery report never gave you one. By week three, the questions arrive. And every answer changes something you already built.
You are not behind because you are slow. You are behind because you were handed insight and asked to produce a specification from it, alone, while coding.
Most people call what follows scope creep. It is not. Scope creep is the client asking for more than was agreed. This is the client asking for exactly what was agreed, described at a level too vague to build from. The change requests are not new scope. They are the specification itself, arriving one painful piece at a time, after the build.
Between discovery and development there is a document that almost nobody writes. Call it a Build Specification. It translates what discovery learned into what engineering must produce. Every metric defined. Every grain stated. Every source named. Every edge case that surfaced in an interview, written down as a rule.
Discovery produces agreement. Code needs precision. The Build Specification is where agreement becomes precision. Skip it, and the developer becomes the translator, silently, at the worst possible time.
At WizEmp, this step is deliberate. Discovery through Wit, WizEmp's smart discovery process powered by AI, produces the agreement: what the numbers mean, who owns them, which definitional conflicts were resolved. The Breeze Blueprint turns that agreement into a specification the developer builds from without guessing. The point is not more documentation. The point is that the guessing moves from week three of the build to before the build starts, where a wrong assumption takes an afternoon to correct, not a sprint.
If your last project went from a strong discovery session to a stream of change requests, look at what the developer actually received. Was it insight, or was it a specification? A discovery report answers "what does the business need." A Build Specification answers "what exactly must be built, measured how, from which source, at what grain." Those are different documents. Most projects produce the first and, much like when the specification is written without the developer, expect them to invent the second while the clock runs.
If you are the developer, you already write half of this in your head before you touch the data. Write it down instead. Hand it back for sign-off before the first sprint. The hour spent confirming a metric definition is the hour that removes a week of change requests later.
The gap between a discovery report and a developer's first sprint is where most BI projects start bleeding time and rework. That gap is not ambiguity. It is a missing document: a Build Specification that translates what was learned into what must be built, with enough precision that the developer does not have to guess. If your last project went from a strong discovery session to a stream of change requests, the specification was never written. → Close the build spec gap
Close the build spec gap.
Discovery produces agreement. Code needs precision. The document that turns one into the other is the one most projects never write, and the change requests are what fills the gap after the build. One structured session turns what was learned into a specification the developer can build from without guessing.
Book a 30-Minute Discovery CallFrequently asked questions
What is a Build Specification in a BI project?
It is the document that sits between discovery and development. Discovery captures what the business needs and what its terms mean. The Build Specification states exactly what the developer must construct: each metric's calculation, the grain of every table, the named source for every field, and the rules for the edge cases that came up in interviews. A discovery report is written for stakeholders to agree with. A Build Specification is written for one reader, the person who builds.
How is the specification gap different from scope creep?
Scope creep is the client wanting something that was never agreed. The specification gap is the client wanting precisely what was agreed, expressed too loosely to code from. The distinction matters because the remedy is different. You fight scope creep with a change-control process. You close the specification gap by writing the missing document before the build, not by policing requests after it.
Who should write the Build Specification, the analyst or the developer?
Both, in one room, before the build. The analyst holds what the business agreed. The developer holds what the data can actually deliver. A specification written by the analyst alone assumes fields and grains that may not exist. One written by the developer alone risks encoding a guess about intent. The document is only trustworthy when both perspectives sign the same page.
What does a Build Specification contain that a discovery report does not?
Precision that a developer can act on without asking. A discovery report might say "leadership wants a single view of customer profitability." The Build Specification says which profitability formula, at customer or account grain, sourced from which system, with which exclusions, refreshed how often. The discovery report names the destination. The specification is the coordinates.