First step is more important than anything else
We have only one chance to make the first impression; we have only one chance to take the first step
We have only one chance to make the first impression; we have only one chance to take the first step
I live in a coastal city. I love the fact that I can go to the beach any time of year. If I walk out of my house with the intention to take a walk to the beach, I need to make my first step facing west.
If I make my first step facing east, I won’t be able to get to the beach. Regardless of how fast I may walk eastward, and regardless how much endurance I have, the beach will remain out of reach for me.
To my way of thinking, making that first step is the most important part of the entire journey. Make that first step in the wrong direction, and everything else becomes nothing but a waste of time, money, energy.
What determines the first step we make?
We live in the world where we surround ourselves with familiar objects and situations. We crave comfort and predictability. So, whenever we are about to make a step with the intention to accomplish something, our previous positive experiences tend to lead us in the direction that we feel is safe and predictable.
We dislike uncertainty. To be in the position that reassures us that we will attain certainty and predictability, we prefer to stick with what we think works.
Which is to say, we tend to make our first step in a familiar direction.
How do we make our first step when deciding to build something?
Suppose we decide to make a beautiful acoustic guitar. What will our first step be? Most likely, we would make a decision on what type of a guitar it will be. Classical with nylon strings, dreadnought with steel strings, or some other variation of an acoustic guitar? Also, six string or twelve string guitar? Should it have a cutout?
Once we make that first step, the following steps unfold in a very predictable fashion. We could craft a blueprint of the guitar, start shopping for quality wood, and so on.
Many other objects we are familiar with offer similar levels of ease and predictability when it comes to making them. We intuitively understand how to make and use objects we come across in our daily life.
Naturally, when it comes to deciding to make a software product, we apply the same approach. Our first step is to envision the desired functionality of the finished product. Together with that vision, we usually also envision the look and feel of the finished product. There tend to be many details that we could envision as our first step when deciding to build a software product.
How is software different?
Our intuitive tendency seems to be to pull any unfamiliar situation into our familiar comfort zone. Sometimes that strategy works, sometimes it may backfire. Ever since we started building and releasing software products, we were quick to pull in various metaphors and analogies, to illustrate how software is basically the same as other familiar objects we surround ourselves with. When popularizing computers, for example, we described them as somehow being similar to a desktop, with file folders and files, etc.
Same goes for pretty much any other software related concept. People are rushing to quickly find an analogy, a simile, that would help us orient and guide our thinking in understand newfangled software products.
While all those attempts served great purpose in propagating and popularizing software, they have also created some unwanted side effects that are producing a lot of waste. This article discusses some of those problems.
To begin, software is not something we can easily envision. The reason for that is the fact that software is an abstract construct that has a very nebulous shape. To fight this amorphous nature of software, we insist on pushing it up onto screens, but the experience of a software product as it appears on a screen is only skin deep. The real working of even a simple software product is very deep, complex, and often recondite.
In a nutshell, it is a mistake to view and treat software products as if they are just another type of familiar physical products.
How should we make our first step when building software?
It is advisable therefore to abandon the familiar approach to building products (as illustrated by our hypothetical example of building an acoustic guitar).
Why should we do that? Isn’t it better to stick with the tried and true method when making our first step in making a product?
The most important reason we should abandon the familiar approach to making the first step lies in the fact that when making that familiar step for building a software product, we end up generating a lot of waste. That waste tends to pile up quickly, and quickly exhausts our means and our patience.
If we keep in mind that software products are abstract, amorphous, nebulous, and volatile, we can begin to understand why is it not advisable to treat them as if they’re concrete, with clearly delineated fixed shape, down-to-earth, and stable.
OK, so given such uncertain and volatile nature of software products, how should we make our first step when jumping into building a software product? Our best bet is to start in broad, vague strokes. The temptation is always to jump head first into hammering out the details, but when it comes to software, it is better to leave the details for the last responsible moment.
So, for the moment, we need to exercise patience and withhold our urge to begin fine tuning some features and functionality we may imagine our software product will provide. Instead, the best approach to making the first step is to build a walking skeleton. This walking skeleton must be devoid of any features, and its only functionality is that it can stand up the system and make it ‘walk’. By making it ‘walk’ we mean it is capable of standing up in production environment and connecting to all parts of the infrastructure.
It is not possible to envision an end state of a software product
Despite many claims to the contrary, when building a sophisticated software product, chasing after some preordained end state of that product always turns out to be fool’s gold. Software products, by their very nature, keep twisting and turning at every minor junction, which makes it pretty much impossible to predict how will something look and function, and also when will that functionality see the light of day.
As such, plans that contain roadmaps illustrating milestones that a software product is supposed to reach tend to be useless. If our first step when building a software product is to envision a detailed blueprint of that product, we’re already embarking on a losing path.
Instead, it is better to grow the product by focusing on experimentation, collecting early and frequent feedback, being interruptible and steerable.