There is a common sequence in most internal tool projects that don't work: the area manager describes the problem, someone proposes a technological solution, the tool is developed or configured, and three months later no one uses it or only uses it for a fraction of what it was supposed to solve.
Retrospective diagnosis always reaches the same point: something was built before we fully understood what needed to be built.
The discovery phase exists precisely to avoid that pattern. It is not a procedure prior to the real project: it is the step that determines if the real project will solve the right problem.
Nielsen Norman Group defines discovery as “the preliminary phase that involves researching the problem space, framing the problems to be solved, and gathering sufficient evidence before moving forward”. [1]
A lot of teams skip it. It's also the factor most correlated with failure. [2]
Why the area manager is not a sufficient source of information
The first meeting of an internal tool project usually has the same structure: the person responsible for the area responsible for the project explains what they need in terms of functionality (“I want a form that sends notifications”, “I want a dashboard with these metrics”, “I want to automate this process”).
That description is genuine and useful, but it's not enough.
The area manager describes the process as it should work, not how it actually works. The exceptions, the Workarounds, cases that occur 15% of the time but account for 80% of problems don't usually appear in that first conversation. [5]
They appear when you watch the real team work, when uncomfortable questions are asked (“and what do you do when that doesn't work?” , “who decides that when the usual person is on vacation?”) and when the parallel Excels that the team uses are reviewed because the official system doesn't cover that case.
61% of professionals working on discovery projects report difficulties in achieving Buy-in internal. [2]
The usual resistance is: “we already know what we need, we don't need to do more research”. The problem is that this certainty systematically precedes projects with more Scope Creep and more reworks.
What does a good discovery process include in internal tool projects
Observation of the actual process, not the described process
The first step is to understand how the process works today, with all its imperfections. This requires observing how the real team works (not the ideal flow of the diagram), reviewing the tools they use in parallel to the official system, and mapping what happens when something goes out of the usual flow.
Los Workarounds that a team has developed are the most accurate map of the gaps in the current system. [5]
Identifying exceptions before designing the main flow
Gartner identifies the lack of exception management in the initial design as one of three recurring patterns of failure in automation projects. [6]
A process that works well in 85% of cases and fails in the remaining 15% is not resolved: it's partially resolved, which can be worse than not having one.
Discovery maps extreme cases before the development team starts building.
Definition of who will be the owner of the automated process
An internal tool in production is software in production. When something fails, someone needs to know that they are responsible for fixing it. [6]
If that someone is not identified before the Go-live, the tool is a technical debt with an expiration date.
The discovery explicitly includes this question: not as an organizational detail, but as a project requirement.
The difference between a consultancy that executes and a consultancy that understands is not in the quality of the code.
It's in what questions are asked before writing the first line.
62% of the gap between automation potential and actual automation is explained by deficiencies in process design, not technology. [7]
Discovery is where you avoid that 62%.
References
1. Niels SenNorman Group. (2024). Discovery: Definition. https://www.nngroup.com/articles/discovery-phase/ — The discovery phase is a preliminary phase in the UX design process that involves researching the problem space, framing the problems to be solved, and gathering sufficient evidence and initial direction on what to do next. Many teams skip this important step, but it's crucial to building the right thing.
2. Niels SenNorman Group. (2024). How Well Discovery Phases Are Performed in UX Projects. https://www.nngroup.com/articles/discoveries-in-industry-revealed/ —In a survey of 436 UX professionals, 75% report that their organization is in the discovery phase, but many are too short, lack research with real users and don't involve the right people. 61% of comments on barriers mention lack of buy-in: stakeholders don't see the value of discovery and push to go directly to the solution.
3. Netguru. (2025). Design Process for Pros — Discovery. https://www.netguru.com/resources/design-process/discovery — A common mistake in the design process is skipping or shortening the discovery phase, with companies going directly to generate solutions based on assumptions. That leap can lead to solutions that don't address real problems, or worse, that address problems that barely exist.
4. PanoramaConsulting Group. (2024). 2024 ERP Report. Panorama Consulting. https://www.panorama-consulting.com/resource-center/erp-report/ —The most cited factor in the failure of ERP projects is the lack of definition of scope during the design phases (scope creep). Successful implementations have in common that they define precisely what processes are left out of the system and how they are going to be solved in another way. Without that prior diagnosis, any internal tool project replicates the same pattern.
5. ProCodersTech. (2025). UX Discovery Process from Experts: Pitfalls and Bottlenecks. https://procoders.tech/blog/ux-discovery-process-pitfalls-and-bottlenecks/ — Discovery involves observing real users in their real context, not just talking to the area manager doing the assignment. The exceptions to the usual process, the workarounds that the teams have developed and the extreme cases that occur 15% of the time are exactly what doesn't appear in the first meeting but that breaks any tool that doesn't contemplate them.
6. Gartner. (2024). How to Build a Business Case for Process Automation. Gartner Research. The three recurring patterns of failure in automation projects identified by Gartner are: automating the symptom instead of the root process, absence of clear ownership of the automated process, and lack of exception management in the initial design. All three are detectable with a well-executed discovery before starting development.
7. Deloitte. (2023). Automation with Intelligence: 2022 Global Automation Survey.Deloitte Insights. https://www.deloitte.com/us/en/insights/topics/talent/intelligent-automation-2022-survey-results.html — Deloitte identifies that 62% of the gap between automation potential and actual automation is explained by deficiencies in process design, not technology. Organizations that map the process prior to implementation achieve around 23% more adoption.
Heading
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.
Artículos destacados
Explora nuestros últimos artículos y tendencias.
