The Problem-First Manifesto: Stop Automating Broken Processes

There is a seductive trap waiting at the start of every automation initiative, and most organizations fall into it without realizing they've fallen. The trap is this: the moment someone says 'let's automate this,' everyone's attention immediately shifts to technology. Which platform? How long will it take to build? What's the license cost? The problem itself - the actual business pain that triggered the conversation - quietly slides out of focus, replaced by a solution conversation that hasn't yet earned its place.

This technology-first reflex is understandable. Technology is concrete and exciting. Platforms have demos and dashboards. Problems are messy, political, and often poorly defined. But skipping the problem definition step doesn't make it optional - it makes it expensive. You pay for it later, in the form of projects that miss scope, automations that break on edge cases, and implementations that nobody actually uses because they solved a symptom rather than a cause.

The Four Gates of Problem-First Qualification

The Problem-First methodology is a structured four-gate qualification framework. Each gate must be passed before the next is opened. This sequence is not arbitrary - it reflects the causal logic of good automation decision-making. Skipping a gate is the methodological equivalent of skipping a floor in a building: you might get away with it, but the structure is compromised.

Gate 1 - Problem Statement: Is the Problem Defined and Mature?

The first gate is deceptively simple: can you articulate the problem in one or two sentences that everyone in the room agrees on? Not the solution. Not the process that needs changing. The actual business problem - the cost it creates, the risk it carries, the opportunity it prevents. If you can't pass this gate, you don't have a project yet. You have a vague aspiration, which is a very different thing.

Gate 1 also asks about maturity. Is this problem stable and recurring, or is it still shifting? Automating a process that's about to change is one of the most common and costly mistakes in automation practice. A problem that's mature - that has been occurring consistently for at least six months, affects a predictable volume of cases, and has a stable current-state process - is a far safer automation target than a problem that's still being understood.

Gate 2 - Root Cause: Could Fixing the System Solve This?

This is the most important gate in the framework, and the one most frequently skipped. Before any discussion of automation, you must ask explicitly: 'Could this problem be solved by fixing, upgrading, or replacing the underlying system rather than adding automation on top of it?' This question needs to be asked out loud, directly, every single time.

The reason this gate is so frequently skipped is social. Nobody wants to tell a business sponsor who has been excited about automation for three months that their problem is actually a system replacement project. But the alternative - automating on top of a broken or inadequate system - is far worse. Automation embeds the current state permanently. If the current state is broken, you've now made it expensive and fragile to change.

Gate 3 - Pattern Matching: Which of the 7 Patterns Fits?

If Gate 2 confirms that automation is the right direction, Gate 3 determines which type of automation is appropriate. This is not a binary 'automate or don't' decision - it's a structured qualification across seven distinct patterns, each with its own technical requirements, cost profile, and organizational fit.

The seven patterns, in decision-tree priority order: System Integration / API (when two systems need to exchange data and APIs are available); RPA (when cross-system data operations are needed but no API exists); Intelligent Document Processing (when documents carry the data); Low-Code BPM (when orchestration across teams and approval chains is the primary challenge); Process Mining (when the goal is discovering where the bottlenecks are before automating them); Machine Learning (when decisions require judgment that can't be codified as explicit rules); and Generative AI (when unstructured language - emails, free-text, reports - needs to be understood or generated).

Each of these patterns has a different implementation pathway, different platform ecosystem, and different success profile. RPA deployed on a process that should have been an API integration will be fragile and maintenance-heavy. IDP deployed on a use case that should have been Generative AI will produce poor results on unstructured content. The pattern has to fit the problem, and the only way to ensure that is through structured qualification.

Gate 4 - Backlog Refinement: Expert or Citizen Developer?

The final gate scopes the implementation complexity. Is this something a trained business analyst or power user could configure with a low-code tool? Or does it require specialist developers - RPA architects, AI engineers, integration specialists? This distinction has profound implications for cost, timeline, and organizational placement of the work.

Getting this wrong in either direction is costly. Sending a citizen-developer-scope project to a specialist team wastes expensive capacity and creates unnecessary dependency. Sending a specialist-scope project to a citizen developer creates a half-built automation that breaks in production and damages the business's confidence in the entire program.

Why Sequence Matters More Than You Think

The Problem-First framework's power comes not just from the gates themselves, but from their sequence. Gate 2 (root cause) cannot be answered honestly until Gate 1 (problem definition) has been completed - because you need to understand the actual problem before you can assess whether the system could solve it. Gate 3 (pattern matching) cannot be correctly applied until Gate 2 has confirmed automation is appropriate. And Gate 4 (backlog refinement) is meaningless without Gate 3's pattern selection.

This seems obvious in the abstract. In practice, it requires discipline to enforce. Business sponsors want to jump to Gate 3. Vendors want to jump to Gate 3. Even CoE teams, under pipeline pressure, are tempted to jump to Gate 3. The discipline of working through Gates 1 and 2 first is the difference between a pipeline full of genuine opportunities and a pipeline full of expensive surprises.

"You cannot engineer your way out of a problem that was misunderstood from the beginning. The Problem-First framework is simply the discipline to understand the problem before you start engineering."

- Senior Automation Architect, Global Healthcare System

Making Problem-First Operational

The most common failure mode for teams trying to adopt Problem-First methodology is treating it as a checklist rather than a conversation. The gates work best when they're explored through dialogue - when the intake is conducted as a structured interview, not a form-fill exercise. The conversation surfaces ambiguities, contradictions, and insights that no static form will capture.

AI-powered intake tools are changing this. Conversational AI trained on the Problem-First framework can conduct the discovery interview at scale - asking the right questions in the right sequence, following up on vague answers, capturing structured data in real time, and producing a qualified assessment automatically. The methodology that once required a senior consultant can now be applied consistently across every intake, regardless of the submitter's sophistication or the reviewer's availability. And the same problem-first gates are the backbone of finding the next generation of candidates - see our pillar guide on how to find agentic AI use cases for the full discovery method.

Frequently Asked Questions