Changing the footprint of a skyscraper mid-construction is much more costly (if not entirely impossible) than changing the underlying architecture of almost any application in production. But even more importantly, you can change the features of an application and how it serves people much more quickly, by comparison.
A few years ago, I was talking with a non-technical CEO client of ours. He was trying to understand the agile development methodology. While he was direct and commanding, he was incredibly patient - I respect him for that.
Being in the software development world, the concept of agile development was known to me. Sprints, iterations, velocity,... were all definitions I knew. Now, this CEO came from commercial construction. So, when I said "development," he thought of constructing buildings where you build budgets, lay plans, pull permits, and contract folks, then construction begins, and a building goes up in a month or so: period, end of story.
The vision he had at the time for his newest venture was a vast and encompassing product that would easily take years to build. His "building" had features based on deeply held assumptions and hypothetical truths; yes, he had a deep well of experience to base those assumptions on, but, regardless, they were assumptions.
While he might be right, he was rolling those dice with millions of dollars on the line and a lot of precious time.
It's impossible to know what tomorrow will bring, let alone what months from now will require. Think of the impact the recent pandemic had on so many businesses, literally, overnight. Whether we like it or not, today's requirements are the only ones we know of.
Agile is an approach to product development that embraces this reality: reflect on yesterday; plan for the uncertainties of tomorrow; build for the requirements of today. The goal of being agile (little "a") is to maintain flexibility around the requirements. (Kevin Craine's post on maintaining an agile mindset is an essential read on the subject.)
This CEO didn't quite understand. Then one day, in the conference room, we're passionately debating the merits of an iterative process over a waterfall-like approach. It hits him, "We're building an amusement park!" "Uh... yeah(?)" I said.
Then he explains, "Disneyland didn't start the way it is today. It was entirely different, but Disneyland is still Disneyland. We're not building a skyscraper that sits in the sky forever and can't move. We're building rides in an amusement park, and when a ride isn't doing anything for anyone, we demolish or change it. We build what brings in customers."
Semantics aside, he was right. Product development is not immutable or linear, in the same way. Changing the footprint of a skyscraper mid-construction is much more costly, if not entirely impossible. But, changing the underlying architecture to almost any application in development or production is entirely possible. We assume we can always add/change/remove features, if needed. The same presumption lives on at an amusement park.
When Walt Disney built Disneyland, he could not have envisioned Star Wars' influence or the acquisition of Marvel comics. It didn't matter. He had a vision for how Disneyland would excite people. Disneyland's purpose was much more fundamental and purposeful. The "features" of Disneyland could evolve through its core purpose and not Walt Disney's future assumptions. Walt's guarantee was a feeling of delight. Delivering that emotion was Disneyland's core feature and much easier to have more quickly.
I'm proud to say the work we did with that CEO solved the problems of the day, and he and that company got out into the market much faster than they otherwise might have. Since then, they've continued to pivot and build features for their current moment in time.
Could we have achieved tremendous success with a few million dollars and years of development before launch? Maybe (?) But even if it could have been more successful, was the risk worth it or, more importantly, necessary?
Entrepreneurs have a strong tendency to risk more than others. That willingness to take chances sets many successful entrepreneurs apart from the pack, but that tends comes at a cost. The real question is whether the risks are calculated based on objective understandings or hypothetical assumptions.
Read about the rise and fall of Quibi. It is an apt example of what occurs when you combine assumptive thinking, deep pockets, and unyielding faith in the Midas touch of a few key people.
Reflect on your efforts as of late. When you consider what's driving your decisions, is it an objective understanding or an hypothetical assumption?
Which is it?
| Photo by Casey Horner