Automation Is a Scoping Decision, Not a Technology One

4 MINS

One of the first real product exercises I ran at Unilever was sitting with a business team, mapping where their process was inefficient, and working out what was worth automating. Everyone arrives at that conversation wanting to talk about tools. Almost nobody wants to talk about the process as it actually exists, which is where the entire answer lives.

Map the process people actually follow

The documented process and the real process are never the same thing. The real one has a spreadsheet somebody maintains privately, a step that exists because of a problem fixed two years ago, and one person who is the single point of failure for a decision nobody wrote down.

If you automate the documented process, you ship something correct and useless. So the first job isn't capability mapping, it's sitting with the people doing the work until you understand why the weird step exists. Sometimes the weird step is the whole reason the process works.

Capability mapping is how you say no early

After the process is honest, I map it against what the technology can actually do and classify how complex each piece is. This step gets skipped constantly, and skipping it is how you end up with a scope that quietly contains one item that costs more than everything else combined.

Classifying complexity isn't a technical formality. It's the artefact that lets you have the scope conversation with facts instead of vibes. "This one is a six-week problem and delivers the smallest gain" is a much easier argument than "I don't think we should do that."

Scope finalisation is the actual product decision

By the time I'm writing the product definition document and building the implementation plan, the important decisions are already made. What's in, what's out, what's phase two. Everything downstream, sprint planning, the release schedule, is just the consequence.

I've come to think of scope finalisation as the moment the product exists. Before that, it's a wish. After that, it's a commitment with a date attached and people's time behind it.

The unglamorous conclusion

Automation projects fail on process understanding far more often than on technology. The tooling question is usually the easy one, and it's the one everyone wants to start with because it feels like progress.

Start with the messy human process instead. It's slower, it's less satisfying, and it's the only part that determines whether the thing you build gets used.

In FMCG, Stakeholder Management Isn't a Soft Skill

What Three Years of Writing Code Taught Me About Writing Requirements

Swathi skipped presentations and built real AI products.

Swathi Chandrasekaran was part of the June 2026 cohort at Curious PM, alongside 20 other talented participants.