Start with the problem, not the AI

Why tool-first projects stall

When a project begins with a product decision, the work becomes about making the tool fit. The people doing the work were never asked what slows them down, so the result is usually a capable tool used by very few people.

Starting with the workflow flips this. You learn where time actually goes, which steps are repeated, where information is re-entered and where decisions wait on someone else.

A simple sequence that works

We use the same order regardless of size of organisation or ambition.

• Describe the workflow as it happens today, not as the process document says it should.
• Measure the friction: volume, waiting time, rework, manual re-entry, error rate.
• Separate the causes: unclear ownership, missing information, fragmented systems, repetitive manual work.
• Only then consider options: process change, automation, an assistant, a small internal tool, or nothing.
• Pick one narrow pilot with a clear success measure and a defined end date.

When the answer is not AI

Some processes are slow because two teams own the same step, or because approvals are unclear, or because the data is scattered. AI applied on top of that will produce faster confusion.

Removing a step, agreeing on one source of information or changing who does what is often quicker, cheaper and more durable than any model.

What good looks like after three months

A useful outcome is boring: one workflow is measurably faster or less error prone, people use the change without being chased, and you know what to try next.

That is the point of starting with the problem. It gives you evidence instead of enthusiasm.