Automation should begin with a hypothesis

Automation · Processes · Operations

Tools invite us to begin with what they can do. Connect two systems, generate a document, classify information. The more uncomfortable question tends to arrive afterwards: which business problem have we just solved?

At La Cucharona, I used spreadsheets, Apps Script, Shopify and AI tools to reduce manual work and bring information together. The best improvements grew from a specific hypothesis. The least useful grew from the urge to build.

The tool arrives too early

“We can automate it” does not explain why it is worthwhile. A hypothesis does: if we remove this manual copy, we will reduce errors and have the information before the decision. There is already an outcome to observe and a reason to stop if it does not appear.

It also forces us to consider a low-tech alternative: perhaps the step can be removed. Automating it would preserve a complexity nobody needs.

Real work is full of exceptions

From the outside, a process looks like a sequence. The person executing it knows the calls, corrections and decisions that keep the sequence alive. If they do not take part in the design, automation learns the official version and collides with the real one.

Testing early with genuine cases does more than reveal technical errors. It shows where human judgement sits and lets us decide what to automate, what to review and which risk we do not want to delegate.

Value appears when the outcome changes

Saving time matters, but we have to follow where it goes. If those hours end up in another manual task, we have moved the work. If they allow an earlier response, a better margin review or attention to an important exception, automation has changed something the business recognises.

The hypothesis keeps the conversation on that outcome. Technology stops being the news and becomes a way of learning how the work should operate.