What Operators Leave Out of Their First Directives

The previous post covered what every directive needs: a clear success criterion, the binding constraint, what the product must not be, and who the primary user is.

This post covers what most operators actually write.

Most first directives are a list of features. "Inventory management, POS, compliance reports, supplier management, dashboard." That's scope, not intent. It tells the system what to build but not why, not for whom, and not what the experience should feel like.

The gaps are consistent enough to be predictable.

What Gets Left Out

Why this exists. Every product exists to solve something. Off-Licence OS exists because tracking inventory on paper is error-prone and compliance reporting is time-consuming. Knowing that changes what the system optimizes for — not feature completeness, but reducing those two specific pains. A directive that explains the problem it solves lets the system make better tradeoffs throughout the build.

The existing workflow. Most software replaces something. Paper, spreadsheets, a previous system, a manual process. The system doesn't know what it's replacing unless the operator says so. "Replace a spreadsheet the owner has used for three years" is very different from "replace an enterprise inventory system that's costing €500/month." The first suggests the system needs to feel familiar and low-friction. The second suggests it needs to match a specific feature set.

Who isn't the user. Operators often specify who will use the system — but not who won't. "The owner uses this daily" doesn't say whether staff also uses it, whether accountants access it periodically, whether a regulator might need to audit it. Specifying the non-users sets important boundaries. A system optimized for the owner's daily workflow looks different from one that also needs to support occasional accountant access.

The non-negotiable user experience moments. Every product has 2-3 moments where the experience must be exactly right. For a POS system, completing a sale is one of them. For an inventory system, stock take at end of month is another. These moments are disproportionately important — they're the ones where friction causes real problems. Operators rarely identify them explicitly, but they're the first things that surface in post-delivery review: "the checkout flow has too many steps."

The data that already exists. Most systems need to be seeded with real data: products, suppliers, prices, history. Operators often don't mention this until the system is built and they discover they need to type 300 product entries. The directive should specify: what data exists, in what format, and what migration is expected.

The integration points. Off-licence management connects to other systems: the supplier for ordering, the accountant for financials, the regulator for compliance reports. These integrations aren't usually in the initial directive. They surface later as "it would be useful if..." But some of them (like export formats for compliance reporting) are load-bearing architectural decisions that are much harder to add after the fact.

Why These Things Get Left Out

They get left out because they're obvious to the operator. The operator knows the existing workflow because they live it. They know who uses the system because they manage the staff. They know the critical UX moments because they've felt the friction.

The system doesn't have any of this context. It builds from the directive alone.

The gap between what's obvious to the operator and what's in the directive is where first deliveries most often miss the mark.

The Structural Fix

The fix isn't to write longer directives — it's to ask better questions before writing one.

"What problem is this replacing, and what's the worst part of the current solution?"

"Walk me through the one thing this product will be used for most often."

"Who uses this and when? Is there anyone who shouldn't have access to certain parts?"

"What data do you have today that needs to be in the new system?"

"Are there any external systems this needs to talk to — exports, integrations, reports for anyone outside the organization?"

Five questions. Ten minutes. Enough context for the system to make good inferences throughout the build.

The second directive is always better because it's based on seeing the first build. But a better first directive means the second directive improves the fit rather than correcting the fundamentals.

This is part of an ongoing series on directive quality and autonomous software delivery. Previous: What Makes a Directive Work.