There’s something inherently problematic about the way we plan our products and services. An uncomfortable truth that’s rarely stated.
David M. Upton and Bradley R. Staats wrote the following on IT projects:
“The fundamental problem with these systems is that for the most part, they’re constructed using what programmer and open source champion Eric Raymond dubbed a cathedral approach. Like the great edifices that Europeans erected in the Middle Ages, enterprise IT projects are costly, take a great deal of time, and deliver value only when the project is completed. In the end, they yield systems that are inflexible and cement companies into functioning the way their businesses worked several years ago, when the project started.
In my mind this holds true to all software projects, even the ones that run “only” 6–12 months long. While both cathedrals and software are engineering endeavors, a cathedral is mostly a one-time effort and a well-defined one. You can, in fact you must, plan every aspect the cathedral years in advance and in fine detail. No such thing with software projects. Requirements are always in a state of flux as user needs, market realities and company goals are prone to change. Worse, the requirements are often based on what we assume the users will find valuable, but invariably users are of a different mind (read about it here). The classical cathedral-like approach of creating long and convoluted specs that lead to long and convoluted projects culminating in complex, feature-rich products is therefore self-defeating. The uncomfortable truth is this:
- You’ll never know all (or even most) requirements before you actually tried the product on real users.
- Product specs are at best educated guesses. Sticking to them at all costs distracts you and your team from real-world needs.
- Products are always evolving — the “Launch” milestone is important, but not final.
Upton and Staats touch on this:
“Instead of building systems that are legacy from the day they are turned on, managers can and should develop systems that can be improved — rapidly and continuously — well after they’ve gone live. […] We call it a “path based” approach, because rather than attempting to define all of the specifications for a system before the project is launched, companies focus on providing a path for the system to be developed over time. The approach’s premises are that it is difficult and costly to map out all requirements before a project starts because people often cannot specify everything they’ll need beforehand. Also, unanticipated needs almost always arise once a system is in operation.”
So the approach suggested is to treat your product as a living organism, an experiment— start it simple and relatively bare and build into it the ability to grow and adapt quickly. You’ll hit the market sooner and get real feedback earlier, letting you build new functionality that’s actually needed. Over time the product will turn complex and finely-detailed, but will do so based on real-world needs rather than on perceived ones. Call it Lean, Rapid Prototyping, or whatever, I believe this approach is more in tune with the true nature of software development. It injects flexibility and growth into an otherwise age-old engineering process.
Itamar Gilad (itamargilad.com) is a product consultant helping tech companies build products that deliver and capture tremendous value. He specializes in product strategy, product market fit, growth and innovation. Previously he was lead product manager at Google, Microsoft and a number of startups.
