Technological Discovery is not a phase prior to the project: it is the most important project of all. However, in many organizations, it is still treated as: a quick gathering of requirements, an initial conversation to “see what can be done,” or a necessary step before starting to build.
This superficial approach is one of the most common reasons why technology projects solve the wrong problems, cost more than expected, are delivered late, or end up underutilized by the operation.
Properly preparing for a technology Discovery means accepting something fundamental: this phase isn't meant to validate a preconceived solution, but to reduce strategic uncertainty before investing. When Discovery is done well, technology stops being a gamble and becomes an informed, defensible, business-aligned decision.
The core mistake: starting with the solution
One of the most common — and most costly — mistakes is starting Discovery with a solution already in mind:
· a specific ERP,
· an automation,
· an architecture,,
· a trendy tool.
When this happens, the entire process becomes conditioned. Discovery stops being exploration and becomes justification.
The questions are no longer:
· what is the real problem?
· where is the operational friction?
· what is limiting the business?
A successful Discovery requires temporarily suspending the urgency to implement and focusing first on understanding the business honestly.
This involves analyzing:
how processes are actually executed today,
which tasks consume the most operational time,
where information gets lost or effort gets duplicated,
what depends excessively on key people,
and what decisions are made without reliable data.
The right technology can only be defined after understanding this.
Documenting real processes, not ideal ones
One of the most uncomfortable and valuable moments of Discovery is when the real processes emerge. Not the ones in the manual, not the ones presented in the committee, but the ones that actually happen every day.
In practice, the real processes include: informal shortcuts, validations “via WhatsApp,” normalized reprocessing, tacit dependencies, exceptions that everyone knows but no one documents. When these elements are hidden or minimized, the technological solution is designed on a fictitious reality.
The result is often predictable: systems that "work" technically, but that the team avoids using because they do not reflect how work is done in practice. Preparing for a Discovery involves accepting that operational complexity and putting it on the table from the start, without makeup.
Understanding variations, exceptions, and unwritten rules
A process is almost never linear and yet, many Discoveries are built as if it were.
A critical part of the preparation consists of identifying:
frequent variations of the process,
"rare" but critical cases,
rules that depend on human judgment,
decisions that have never been formalized.
These exceptions are ultimately signs of pending design.
Ignoring them in the Discovery often generates fragile solutions: automations that fail at the first non-standard case, developments full of patches, or systems that require constant intervention. A well-prepared Discovery seeks to understand the exceptions to consciously decide what to do with them.
Aligning roles, responsibilities, and decision-making power
Another critical — and often underestimated — point is who actually participates in the Discovery.
It is not enough to involve those who know the process; it is also essential to clearly identify:
who makes decisions,
who approves changes,
who assumes risks,
and who will be responsible for later adoption.
When these roles are not clear: the Discovery fragments, decisions contradict each other, the scope constantly shifts, and the process drags on without making progress.
A company prepared for a successful Discovery:
brings in the right people,
sets clear expectations,
and establishes from the start who decides what.
Without clear decision-making power, the Discovery becomes an endless conversation.
Measuring before transforming
Impact cannot be demonstrated if there is no clear starting point. Therefore, serious preparation for the Discovery includes gathering baseline metrics before thinking about automating or developing technology.
Some key examples:
actual execution times,
transaction volume,
error and rework rates,
level of human intervention,
hidden costs associated with the process.
These metrics serve three critical functions:
1. They allow for prioritization with criteria
2. They make the real impact estimable
3. They avoid decisions driven by intuition or urgency
What is not measured beforehand cannot be justified afterward.
Finally, no Discovery works if approached as a commercial stage.
A true Discovery:
asks uncomfortable questions,
challenges assumptions,
slows down impulsive decisions,
and sometimes concludes that it's not the right moment to build anything.
A serious technological ally:
doesn't promise quick fixes,
doesn't force tools,
and doesn't avoid difficult conversations.
Their role is to help the company to: understand its operation, reduce risks, and make better decisions, even if that means waiting.
Technological Discovery does not accelerate the project but makes it viable. Preparing for this stage is a strategic decision that defines: the real impact of technology, team adoption, and the sustainability of the solution over time.
Investing in Discovery is investing in clarity and in technology, clarity is the most valuable asset. A good Discovery does not start with a tool, it starts with the right questions. To help teams prepare better, at EMAST we use a Technological Discovery Checklist that allows validating if a company is really ready to start a project without improvising. If you want to use it as an internal tool to organize conversations and decisions, you can request the Discovery checklist from us and work on it with your team before moving forward.