Scouting while building

There is a sentence I heard over and over in my years of ordinary software work: "Just lock the requirements and we will build." It sounds tidy, and for many projects it is right. But once I started on an AI project, I found that sentence suddenly hard to apply, because some things are only known once you try, and by the time you have tried, part of the structure is already standing.

What scouting while building is

Picture a road crew crossing unfamiliar country. One group goes ahead to read the ground: where the soil sinks, where it is better to go around. One group follows laying asphalt, making the actual road. Neither waits for the other. Wherever the discovery group gets to, what they learn immediately redirects the delivery group. That is the spirit of running two tracks in parallel (dual track): one track finds out what should be built, the other builds what is already firm enough to build.

Marty Cagan, a very influential voice in product work, credits Jeff Patton with introducing the term to him. The point both of them stress is that an idea should be validated while you are still scouting, ideally before any production code is written, rather than waiting until the work is done to learn you went the wrong way.

With AI the discovery track matters even more, because whether a model can handle our problem is something nobody can be sure of beforehand. And here is the difference that causes the most misunderstanding: an experiment that produces no result in AI is not necessarily wasted effort. Knowing that one direction does not work with the data you have is real knowledge too. It keeps the delivery track from pouring work into a foundation that will give way.

How this applies to running a business

The difficulty usually sits in expectations more than in the engineering. An owner used to signing off software on the basis that all the features are delivered will feel uneasy when the AI team reports that this month was mostly testing and discarding hypotheses. It looks slow, but that is in fact when the largest risk is being taken apart.

What someone running the business can do is separate two questions when reviewing progress. For the discovery part, the question to ask is what we learned this week, and how it changes the decision. Only for the delivery part do you ask about milestones. Mixing those two rulers is the quickest way to make a good AI team look as if it is standing still.

If your organisation has a project that still holds many unknowns, are you measuring it by the number of tasks completed, or by the number of things it has helped you understand better?