Background

When building a platform capability, the instinct is to make it complete before anyone touches it: the automation, the migration path, the polish, all in place before the first customer arrives. In this post I’ll share the opposite approach, which is to aggressively trim the requirements to the smallest scope that can reach a real customer, and to treat every requirement you defer as a deliberate trade.

The reasoning is simple. Every requirement you add delays the moment a real customer touches the feature, and until that moment you are guessing. Reaching a customer sooner does not mean shipping a smaller product; it means getting better information earlier, while there is still time and cheap to act on it.

How it works

Strip the scope to the core capability. Migration and automation are later iterations, not prerequisites; the question is not “is it finished” but “can one real customer do the one thing this is for”.

Dark launch to a small group of early adopters. You want the people with a high tolerance for rough edges, who are willing to collaborate, and who give high value feedback. A rough capability in front of the right five customers teaches you more than a polished one in front of nobody.

Fill the gaps left by deferred automation with hands-on support, temporarily. If the migration is not automated yet, the platform team does it by hand for those first customers. That hands-on work is not waste; it is how you learn which parts are worth automating, because you feel the pain directly.

Then let real usage drive what gets built next. You reintroduce the deferred requirements one at a time, with production signal behind each decision rather than a guess made before launch.

The trade, stated plainly

Every deferred requirement is a choice: you delay automation, migration and polish in exchange for faster customer contact. The thing you are optimising for is the length of the feedback loop, not the size of the first release. A shorter loop means better information, earlier.

The anti-pattern

The failure I want to name is treating automation and migration as prerequisites to initial delivery. The build cycle stretches out, nothing reaches a customer until everything is “complete”, and the first real signal arrives after months of work built on assumptions. When that signal finally contradicts an assumption, you have already paid for the wrong thing. Reaching the customer earlier is the whole point; everything else is negotiable.