Automation is often marketed as a no-brainer: fewer repetitive tasks, more value, fewer errors. On paper, it makes perfect sense. But in practice, the reality is often different: projects that take longer than expected, costs that spiral out of control, stress, frustrated users, and exhausted teams.
The problem? It’s almost never the technology. Behind the promise of smooth operations lie pitfalls related to design and decisions made early on. And at the heart of it all: overlooking the simplest question of all. Who is it for? What is it for?
1. Why automation often fails right from the start
An automation project rarely fails because of a bug or a poor tool. The problem has its roots much earlier: in the design phase. More specifically, it stems from a failure to answer a fundamental question: What value does this bring to those who experience this process on a daily basis?
1.1 We automate without understanding the actual use case
Trying to automate without first observing, questioning, and thoroughly understanding how people actually do their work only increases the number of potential points of failure.
Just because a process is documented doesn’t mean it’s understood. Documentation describes what should happen. Users, on the other hand, describe what actually happens: workarounds, unnecessary steps inherited from the past, and unspoken frustrations.
The consequences of a lack of understanding of actual usage are immediate: a never-ending analysis phase, critical issues discovered too late, surprises in production, and, ultimately, a partially automated process that is delivered late and costs more than expected.
1.2 We're trying to automate everything at once
Trying to automate everything all at once is tempting… but dangerous. The broader the scope, the more complexity skyrockets, dependencies pile up, and risks increase. Ultimately, the entire project slows down or even grinds to a halt. And often, users don’t see any tangible value for months.
2. What the experiment teaches us
2.1 Investing in Discovery—For Real
Discovery isn't just a box to check before "moving into development." It's the most important part of the project.
The goal is to understand:
- Who experiences this process on a daily basis, and under what actual conditions?
- What problems does this process cause them? Wasted time, errors, frustration, lack of visibility?
- What would be a concrete sign that automation has improved their situation?
This means that business stakeholders are involved from day one—not merely as validators at the end of a sprint, but as co-designers. They are the ones who ensure that we don’t just “skim the surface” of the subject from a functional perspective. They become ambassadors for the project because they have contributed to it. The final adoption process is much smoother.
2.2 Prioritize based on user impact, not technical complexity
Should we focus on a complex process that occurs rarely, but where each instance is critical for the user? Or should we tackle a frequent process that causes daily friction, even if the benefit per instance seems small?
This question isn’t just about financial ROI. It’s about the value perceived by those who use the process.
Data helps us move beyond intuition:
- "Rare" or "frequent" translates to actual volumes
- "Easy" or "complex" translates into processing times and error rates
- "Important" refers to the impact on the user experience and on business objectives
From that point on, it’s no longer just a hunch: it’s an informed strategic decision, not just a technical workload optimization.
2.3 Focus on Outcomes, Not Deliverables
Automating without a clear goal regarding the expected value is like delivering a product without knowing what it’s for.
The real question isn’t “Have we implemented automation?” but rather: Do users find this process easier to use than before?
Define clear outcomes before you begin:
- Has the processing time for the end user decreased?
- Has the rate of human error decreased?
- Has the level of frustration expressed by field teams changed?
These outcomes guide decisions throughout the project: at 40% automation, if the value is already there for the user, it can be counterproductive to aim for 100% if complexity skyrockets. Automation must be useful before it is perfect.
Turn these outcomes into KPIs that can be monitored continuously. Automation evolves, drifts, and sometimes degrades. It must be managed just like any living product.
2.4 Break it down to deliver value early
Delivering brick by brick is as much a principle of agility as it is a principle of product value: each increment must provide something concrete and measurable to those who use it.
This requires full transparency with the business and the developers:
- Temporary steps (sometimes manual)
- Transitional solutions
- Technical or Organizational Debt That Needs to Be Managed
This is not an admission of failure. It is a strategy for delivering value incrementally, which safeguards the investment and reduces risk.
3. The Pitfalls of design
3.1 Reproduce Existing Defects
We often do a good job of creating documentation (customer journey, user flow, etc.). But this documentation doesn’t always explain why it exists.
If we stop there and simply replicate it exactly as it is, we aren’t automating a process—we’re automating habits, with all their flaws.
Yet behind every step, there’s a reason. We still need to verify that it’s still useful to the user today.
Example: A manual acknowledgment of receipt intended to reassure a waiting customer becomes a nuisance notification if the automated system responds in 3 seconds. What was once a thoughtful gesture becomes a distraction.
For each step in the process, ask yourself three questions:
- Why does it exist?
- What value does it provide to the user?
- What happens to him if we remove it?
3.2 Underestimating the Role of People
Automation often aims to completely eliminate human involvement. That’s a mistake.
An automated process is dynamic: it involves incidents, changes, and exceptional situations. If there’s no room for human intervention, you end up in firefighting mode, with developers debugging in production under pressure. The expected gains on the business side turn into losses on the digital side.
This is what’s known as “Human in the Loop”: keeping a human capable of intervening without breaking everything. In practical terms, the process must be able to be paused, resume where it left off, and incorporate human intervention if necessary.
The goal isn’t airtight automation. It’s a resilient process that remains under control.
4. The Technical
4.1 Underestimating integration and dependencies
An automated process never operates in a vacuum. It depends on other products, other teams, and other data sources. That’s often where things go wrong: a change in a third-party source breaks your automation—or worse, compromises part of your IT system.
Upfront architecture work (“Sprint 0”) is not a luxury. Its goal is to identify existing rules, data flows, and cascading impacts. Without it, you’ll end up cobbling together quick fixes in production.
Document your architectural decisions (ADRs, Architecture Decision Records): why you made that choice, and what assumptions it was based on. When things change, you’ll be glad you understand the original reasoning.
4.2 Ignoring Volume
An automated system that’s supposed to save time but ends up being slower than a human—it’s a classic scenario. An ill-suited architecture, poorly estimated data volumes, and ignored scalability requirements. Automation is meant to handle the load, not become the new bottleneck.
Be careful of the opposite effect as well: over-engineering. You can spend a year planning for scalability to handle volumes that may never actually materialize. Finding the right balance—that’s part of the job, too.
4.3 Sacrificing traceability and monitoring
Under pressure, with tight deadlines, and as priorities shift, the “should-haves” often end up being sacrificed. Among them: traceability and monitoring.
This isn’t just about having nice-looking dashboards. It’s a matter of resilience and value-driven management.
Resilience: when things break (and they will), are you able to pick up exactly where you left off? Without detailed traceability, you’ll have to restart everything from scratch, create duplicates, and perform SQL surgery in production under pressure.
Management: In production, you’ll need to understand what’s working, what’s causing issues, and what keeps coming up. You don’t need a complex tool. A well-structured log table can be enough to:
- Quickly Analyze an Incident
- Understanding Users' Actual Usage Patterns
- Determine future developments based on the value generated
These aren't just hunches anymore. It's data-driven decision-making, focused on serving users.
5. In summary: the 7 golden rules
- Start with the users: observe, ask questions, and understand their actual usage patterns before designing anything
- Define your outcomes before your outputs: What measurable value, and for whom?
- Involve subject matter experts from day one—not as approvers, but as co-designers
- Prioritize based on user impact, informed by data (volumes, durations, frequencies)
- Break it down to deliver value early: each increment must be useful, not just deliverable
- Keep people in the loop: a resilient process is a guided process
- Monitor continuously: automation can degrade, evolve, or drift. Treat it as a living product
FAQ: Automating processes
Where should you start before launching an automation project?
Before any development begins, the first step is Discovery: understanding who actually uses the process, under what conditions, and what specific problems it causes. This exploratory work (interviews, observations, analysis of actual usage) determines the relevance of everything that follows. Automating without Discovery often means automating the wrong things in the wrong places.
How do you decide which process to automate first?
Prioritization should be based on two factors: frequency of use (how often is this process performed?) and user impact (what level of friction, error, or wasted time does it generate?). A frequent process that causes daily frustration takes precedence over a rare process, even if the latter seems more “spectacular” to automate. Data (volumes, durations, error rates) allows us to move beyond intuition and make objective decisions.
What is the difference between an output and an outcome in an automation project?
An output is what is delivered: the automation system is in production, and the workflow is running. An outcome is what changes for users: processing time has decreased, errors have gone down, and the mental workload on field teams has been reduced. Outcome-based management means giving yourself the means to verify that automation has actually created value—and not just been delivered.
Why not automate everything at once?
A scope that is too broad increases dependencies, lengthens timelines, and delays the delivery of value. By breaking the project down into increments, each stage can be tested, validated, and refined with real users. This approach reduces risk, improves adoption, and allows for course corrections before the entire project is built.
What is "Human-in-the-Loop" and why is it important?
“Human-in-the-loop” refers to the ability to incorporate human intervention into an automated process without causing everything to break down. An automated system encounters exceptional situations, errors, and changes. If there is no mechanism allowing a human to take over, we end up in “firefighting” mode. A good automated process is one that can be paused, resumed, and monitored at any time.
How do you measure the success of an automation project?
Success is measured by the outcomes defined before launch: reduced processing time, lower error rates, fewer manual tasks, and improved satisfaction among the teams involved. These metrics must be monitored continuously, not just when the system goes live. Automation can deteriorate over time: without monitoring, problems are only detected after they have impacted users.
Why involve business units from the very beginning of an automation project?
Business experts are the only ones who truly understand real-world practices: workarounds, exceptions, and steps that no longer make sense. Without them, we end up automating a theoretical view of the process. By involving them from the Discovery phase onward, we minimize surprises in production, improve the relevance of design choices, and facilitate final adoption, as they become ambassadors for the project rather than resisters of change.
Should a process be 100% automated?
Not necessarily. The optimal level of automation depends on the balance between the value provided to the user and the complexity of implementation. Even 70% automation that resolves the most common cases can already deliver the bulk of the value. Trying to cover the remaining 30% (often rare and complex cases) can triple the cost and time required for only a marginal gain. Automation should be useful before it is perfect.
Product Owner
Product Manager
