Executive takeaway
Writing the pipeline is the fast part. Understanding the business well enough to know what pipeline to write is the part that actually determines whether the project succeeds. The teams that skip discovery do not save time, they just move the delay to the end of the project, where it costs more to fix.
The mistake most organizations make
Most engagements start with a kickoff call and a data model by the following week. That feels like momentum. It is usually the opposite.
A model built before the business is understood is a guess wearing a schema. It will run. It will load data on schedule. And it will quietly encode a wrong assumption about the business that surfaces three months later as a number nobody trusts.
A simple example: what counts as a customer
Skip discovery and you get: a customers table built from the CRM, on schedule, in a week, that counts every contact record as a customer.
Do discovery first and you learn: the business defines a customer as an account with a signed contract, and half the CRM contacts are prospects, vendors, or duplicates.
Both paths produce a customers table. Only one of them produces a number finance will actually use in a board deck.
- The rushed model has to be rebuilt once the wrong definition surfaces.
- The rebuild costs more than the discovery would have.
- Trust in the whole project takes the hit, not just that one table.
Good discovery does not slow the project down. It moves the expensive mistakes to the cheapest possible moment to catch them, which is before anything gets built.
Why this distinction matters to leaders
When discovery gets treated as a formality instead of real work, the cost does not disappear, it just relocates to a worse point in the timeline.
- Rework replaces progress. Weeks of engineering get spent rebuilding a model around a definition that should have been settled on day one.
- Domain knowledge lives in one person's head. Without discovery, the model reflects whatever the engineer assumed, not what the business actually operates on.
- Stakeholders stop trusting the numbers. One wrong definition in an early report makes every later report harder to sell, even after it gets fixed.
- Scope grows instead of shrinking. Without a clear picture of what the business actually needs, projects default to building everything instead of the right thing.
The questions every leader should ask before a project starts
Not about timelines or tools. About whether the business has actually been understood yet.
What does this term actually mean here?
Words like customer, active, or revenue rarely mean the same thing across two departments. Discovery means writing that definition down before it gets encoded into a table.
Two teams use the same word in a meeting and mean two different things by it.
Who actually owns this process today?
Every business process has an owner, even if the org chart does not say so directly. Discovery finds that person and asks them how the process really works, not how it is documented.
The documented process and the actual process have not matched in years.
What decisions is this project supposed to change?
If discovery cannot name the decisions a project is meant to inform, the project does not have a clear target yet, no matter how detailed the technical plan looks.
The technical requirements are detailed, but nobody can name the decision behind them.
What happens if we get this wrong?
Discovery should surface the cost of a wrong assumption before it becomes one. If nobody can say what breaks downstream, the risk has not actually been found yet.
A definition gets assumed rather than confirmed, and nobody notices until a report looks off.
What real discovery looks like
The output is not a longer timeline. It is a shared, written understanding of the business that the entire project gets built on, instead of built around.
Key business terms are documented in plain language before any table gets designed.
Every business process in scope has a person who confirmed how it actually works.
The project can point to the specific decisions it is meant to inform, not just the data it moves.
Anything uncertain gets confirmed with a stakeholder before it gets built into the model.
The Canonica approach
Every engagement follows the same principle. Understand the business before a single table gets designed.
Listen
Sit with the people who run the process daily and learn how it actually works, not how it is documented.
Define
Write down what key terms mean in this business, in language everyone agrees on.
Confirm
Take those definitions back to stakeholders and get explicit agreement before any modeling starts.
Build
Design the model on top of a shared understanding, so it holds up under scrutiny later.
The Canonica Principle
Discovery exists to make the build fast and right, not to slow it down.
Code is cheap to write and expensive to rebuild. Understand the business first, then build only what that understanding requires.
Start a conversation →