There's a persistent belief in technology delivery that the real work begins when the build begins. Discovery… the phase where you observe, map, and understand the operation before designing anything --- gets treated as overhead. A project management formality. The box you tick before the interesting part starts.
This belief is responsible for an enormous amount of wasted capital.
The most valuable thing we do at RocketFin isn't building systems. It's finding out where the friction actually lives before we touch anything. And in almost every engagement, what we find is significantly different from what the client assumed the problem was when they hired us.
That gap between the assumed problem and the real one is where most transformation projects fail.
Why discovery gets underinvested
The incentive structure in technology delivery works against rigorous discovery. Clients want to see tangible progress. Vendors want to demonstrate capability. Both parties have an interest in getting to the build quickly.
Discovery is harder to show on a progress dashboard. You can't demo it in a steering committee. The outputs, workflow maps, friction analyses, integration specifications, don't feel like milestones the way deployed features do. So, they get compressed. A few workshops, a requirements document, a sign-off, and then the project officially starts.
The problem is that compressed discovery means incomplete diagnosis. And incomplete diagnosis means building against assumptions rather than evidence.
I've lost count of the number of projects I've encountered that failed not in the build phase but in the discovery phase, specifically because the discovery phase wasn't long enough, rigorous enough, or conducted by people with enough domain knowledge to ask the right questions. The build was technically competent. It just solved the wrong problem.
What rigorous discovery actually looks like
Real discovery in capital markets isn't a series of stakeholder interviews. Interviews tell you what people think the problem is. That's useful, but it's not the same as understanding what the problem actually is.
People narrate their workflows in idealised terms. They describe the intended process, not the actual one. They don't mention the Excel file that bridges two systems because it's been there so long they've stopped seeing it. They don't volunteer that the settlement team has a standing workaround every month-end because the system can't handle the volume. They don't think to mention that the junior analyst reconciles two risk reports every morning because the numbers never quite agree, it only takes ten minutes, it's become routine, and it doesn't feel like a problem worth raising.
These details are the diagnosis. They're the specific points where the architecture has diverged from the operation, where the system does something slightly different from what the desk needs, where the workaround has become load-bearing.
Finding them requires observation, not just conversation. It means sitting with the workflows, watching them happen in real time, mapping the actual decision paths, identifying the moments where the formal process and the real process diverge. It requires domain knowledge deep enough to recognise significance: to understand that a particular workaround isn't just inefficient, it's a regulatory risk, or that a reconciliation that "only takes ten minutes" is masking a data quality problem that will eventually surface as something much more expensive.
The diagnosis is the value
When discovery is done rigorously, something changes about the rest of the engagement. The build doesn't feel like exploration anymore, it feels like execution. The integration requirements are precise because we've seen exactly what needs to connect. The priorities are clear because we know which friction points are genuinely load-bearing and which are cosmetic. The risk of building the wrong thing drops significantly.
More importantly, the business case writes itself. When you can show a client exactly where their operational friction lives, specifically, with evidence, rather than as a general claim about "legacy systems", the value of fixing it becomes concrete. The conversation shifts from "we think this will help" to "here is what this is costing you, and here is what fixing it looks like."
That shift matters enormously in capital markets, where the appetite for transformation is always in tension with the appetite for certainty. A precise diagnosis reduces uncertainty. It gives decision-makers something to evaluate rather than something to trust.
The counterintuitive conclusion
Spending more time on discovery before building anything is not a conservative choice. It's the most commercially aggressive thing you can do.
Every day spent understanding the problem precisely is a day that reduces the risk of building the wrong solution, reduces the likelihood of an expensive reset, and reduces the probability that the new system will simply be worked around in the same way the old one was.
The firms that consistently get the most from their technology investments are the ones that are most rigorous about this phase. Not because they're cautious, but because they understand that the quality of what you build is determined entirely by the quality of your understanding before you start.
Discovery isn't the overhead before the work. Discovery is the work. The build is just the execution.