Prototype first, plan later

The conventional wisdom in enterprise technology is: plan thoroughly, then build. Write the business requirements document. Get sign-off from stakeholders. Produce a technical design. Estimate the effort. Secure the budget. Then — months later — start writing code. This approach makes sense for well-understood problems with stable requirements. Building a new payments system? Yes, plan carefully. Migrating a database? Absolutely, plan every step. But most operational improvement work is not like that. The requirements are fuzzy. The users are not sure what they want until they see it. The real constraints only become apparent when you start building. For this kind of work, I have found that prototyping first produces better outcomes than planning first. A prototype is not a mockup or a wireframe. It is a working tool that solves a real problem, built in days rather than months. It does not need to scale. It does not need to handle every edge case. It does not need to pass a security review. It needs to demonstrate value clearly enough that someone says: I want this. The prototype serves three purposes. First, it tests whether you are solving the right problem. No amount of stakeholder interviews will tell you as much as watching someone use a working tool. Second, it surfaces technical constraints early. Can you actually access the data you need? Does the API work as documented? Is the data quality sufficient? Third, it builds momentum. A working demo generates more executive support than any slide deck. The risk of prototyping first is that the prototype becomes the product — accruing technical debt that is never repaid. The mitigation is discipline: treat the prototype as disposable. Learn from it, then rebuild properly if the concept is validated. The code you throw away is not wasted — the knowledge you gained from writing it is the real output. This is not an argument against planning. It is an argument for planning at the right time — after you have learned enough to plan well.