Prove the idea in three weeks
There is a moment in most modernization conversations where an idea is big enough to be exciting and vague enough to be dangerous. "If we had AI reading every incoming order, we could reroute the exceptions before they hit the warehouse." Everyone nods. Nobody knows whether it is true.
The usual next step is a strategy exercise or a large build. We prefer a third option: build the smallest tool that would tell you whether the idea is real, put it in front of the people who would use it, and find out in three weeks.
Why a tool beats a document
A strategy document about the order-rerouting idea will estimate volumes, guess at accuracy, and project savings. All of those are assumptions, and the document cannot test any of them.
A small tool that reads last month's orders, flags the exceptions the way the idea proposes, and shows the results to the warehouse lead tests every assumption at once. Was the volume what we thought? Did it catch the exceptions that matter? Did the lead trust it, and what did they want changed? You learn in a week what a document would have debated for a quarter.
The tool does not have to be production software. It has to be honest software: real data, a real user, a real result.
What "small" means
Small is one job. Not the order-rerouting system, but the exception-flagging step, on historical data, with a simple interface. Not the customer-service agent, but the tool that classifies last quarter's tickets and shows a manager how it would have routed them.
Small is also fixed. Two to three weeks, a written specification of the one job, a defined "done." The moment scope grows, the tool stops being a discovery method and becomes a project with no plan.
What you learn
Three kinds of things, and each is worth the cost on its own.
Whether the data is what everyone assumed. It usually is not. The fields are messier, the volume is different, the exceptions have exceptions. Better to discover this in a three-week tool than in month four of a build.
Whether the people would actually use it. A tool in front of a real user produces reactions no interview does. The warehouse lead who says "this is useful but the flag needs to fire a day earlier" has just told you the real requirement.
Whether the value is where you thought. Sometimes the tool proves the idea. Sometimes it proves a different idea, sitting next to the original one, that nobody had on the list. Both are wins.
What happens next
If the tool proves the idea, you have the specification for the real build and the evidence to fund it. The tool often keeps running in the meantime, because a working thing is hard to give up.
If the tool disproves the idea, you have saved a quarter and learned something specific about your business. That is not a failure. It is the cheapest possible price for that knowledge.
If the tool proves a different idea, re-sequence the roadmap. This is the case we see most often, and it is why we do discovery with tools rather than slides.
The tool is yours either way
One rule we hold to: the tool is built to a specification, tested, documented, and handed over with the source. Even a discovery tool. If it turns out to be useful on its own, the business owns it and can keep it. If it is retired, nothing is lost. Discovery should never create a dependency.
Most companies have three or four ideas of this kind sitting in the deck. Pick the one that would matter most if it were true, and spend three weeks finding out.