The ancient idiom The Quick and The Dead conjures up images of a shootout in a good old-fashioned Western movie of the same name, featuring a cowboy drawing his pistol from his waistband, pointing it, and eliminating the enemy in seconds.
Similarly, in the Wild West of software development, it often is the speed of the draw that determines the winner. How quickly you bring a new product to market can be the difference between success and failure. The speed vs quality debate rages on, but in our opinion faster software development is often the only way to survive. Let’s explore this idea a bit further.
The word quick in archaic definitions means living or alive; therefore, the saying “The Quick and the Dead” translates into ‘the living’ and the dead.
We draw a parallel with the need for speed in software development if you want your tech product to survive, as opposed to being dead in the water, if, for example, a competitor brings their product to market faster.
The quiet confidence and focus with which the cowboy prepares for the quick draw can be compared to the sharp vision and determination needed by the leader of the tech development team who needs to get everyone’s buy-in to ensure a speedy delivery. There can be no hesitation or faltering, only a single-minded focus to be the first to market.
One of the key advantages of being the first on the scene is that a blue ocean tech product sets the tone for a broader market discussion, even if the product itself may not be perfect.
This raises the question: What does quality mean in software development? The answer is not straightforward, but when it comes to quality vs. speed, it is often a question of survival of the fittest, and in the case of software companies, that often means survival of the first.
Not only will a new product launched before the rest put pressure on competitors to improve their functionality before their own launch, but early adopters who try out the new product will often be reluctant to switch, even if a later product potentially offers them better functionality. This is a clear competitive advantage.
However, if you wait longer before releasing a more ‘perfect’ product in a red ocean where sharks have been circling for some time, the new product will face more intense scrutiny and comparisons with competitors, which could kill it. The Quick and the Dead.
Speed as a strategic approach is not new and is not limited to the tech industry by any means. World history offers many examples where the surprise factor (i.e. what equates to being the first to market) was arguably more important than capability when it came to victory over the enemy.
“Speed is the essence of war. Take advantage of the enemy’s unpreparedness; travel by unexpected routes and strike him where he has taken no precautions.“
“It is even better to act quickly and err than to hesitate until the time of action is past.” and “The backbone of surprise is fusing speed with secrecy.”
When it comes to winning, Nobel Prize Laureate scientists such as Japanese stem cell researcher Sinya Yamanaka regularly own up to the many failures they’ve experienced on their path to success, often more than their peers. The number of failures they fit into the span of their research years becomes a determinant of their success. More failures equal higher success, or to put it differently – failing quickly and repeatedly, is an indicator of success.
For software developers, this means cultivating adaptability and getting back to the drawing board quickly. The failing software product didn’t exist before, so it may only need a few tweaks or a different presentation before bringing it to the market again.
In our example above, the timing of the cowboy is everything. Waiting for the perfect moment when the heavens are aligned, may cost him his life. He has to judge the situation and pull the trigger before it’s too late.
So, how do you know when something is good enough? Again, this is not an easy question to answer, particularly if you have nothing to compare it with, i.e. if it is the first product of its kind.
For example, in the 1968 classic movie Chitty Chitty Bang Bang, the magical flying car may not be pretty, but hey, it is a flying car after all! The novelty factor outweighs the appearance or perfection of this new invention.
It’s the job of the experienced tech leader to judge the timing of the release of a new product and to keep asking and challenging the team by asking, “When?” and “Why then?” or “Why not now?”
We’re also reminded of US army General George S Patton’s famous statement:
“A good plan, violently executed now, is better than a perfect plan next week.”
War is certainly one situation, where you want to trust your leader’s judgment when it comes to the timing of your actions in the face of the enemy.
The 80/20 rule (when something is 80% there, it is good enough) is adapted in many different contexts, for example, in the music world where jazz bands release a piece of music as a work in progress to be improved and added to with every performance.
In tech, the idea of being ‘good enough’ is inherent in the concept of the MVP (Minimum Viable Product) where the M stands for minimum or ‘small body of work’ which is then quickly brought to market. The intention is to iterate fast on the MVP once it’s released. An agile development process means adding small features to a basic product that isn’t perfect at the start.
Iterative software development allows for early feedback, which is crucial for developing a better product in the long run.
Sometimes, designing a product to demonstrate a blue ocean tech idea and making it available to them quickly, while perfecting some of its key features behind the scenes in parallel, can be a great strategy for tech product developers.
Sometimes a team of developers will lock themselves in a room for months, while their rival brings an ‘inferior’ product to the market and walks away with the prize! The product could end up being over-engineered, in other words, they try to do too much at once, instead of focusing on the MVP and releasing it to the market quickly with good enough features, which can be improved with the feedback from early users.
In the world of intellectual property, speed can also be important in some industries and specific situations, which often results in a race to be the first to file.
While in some industries, such as the pharma or biotech sector, your product, in this case, drug molecules, is doomed if your competitor is the first to file a patent, this is often not true in other sectors.
Particularly in software development, IP considerations can sometimes place an unnecessary brake on the process, causing startups, in particular, to lose out to competitors for the wrong reason.
Founders in the software development space should carefully weigh up these considerations before allowing IP concerns to hold up product delivery and speed to market.
Of course, there are situations and industries, where quality outweighs speed as a business strategy. For example, in the medical industry or finance industry, where users’ health or privacy considerations could mean a bigger emphasis on accuracy and perfection.
Similarly, when the product timelines are longer, for example, if we consider General Motors’ and Ford Motor’s different approaches to the future electrification of pickup trucks, speed may not always be the right approach. Whereas Ford slapped a battery into the regular truck chassis and got to market first, GM is building a better solution from scratch and taking its time. Which is the better strategy, in this case, remains to be seen.
These types of multi-decade solutions typically have longer timelines and reputational issues also come into play. Will GM’s release of a superior product, in the long run, make them the winner in this case? Or, perhaps Ford’s strategy is to release a ‘placeholder’ MVP product while working on the real thing in parallel. Which one is better in this type of industry, is less obvious.
However, when we talk about tech startups, with a few exceptions mentioned above, speed usually wins.
So far, we’ve talked about the need for speed pertaining to the product release and the development team, but in order to succeed in the cutthroat tech startup world, speed and agility need to be part of the company’s fabric.
The iterative model (failing fast) and not being perfect, as well as fast release, is inherent or ‘par for the course’ for this type of business. It’s what you sign up for when you develop an MVP.
The emphasis on speed and agile approach should start at the lab and be carried through the entire organization, including agile teams and agile methodologies. As such, it should be reflected in every product decision, right from the word go.
This is also where you need a strong tech partner, or leader, with the software engineering experience to judge the timing of the development process and has the discipline to stay focused on the MVP and not allow team members to get distracted by non-crucial or ‘luxury’ features.
It’s only through the experience of launching (and failing) many tech products, that a leader or tech partner is able to judge the exact moment to pull the trigger to finish off competitors and keep the product alive.
At REEA Global our versatile team of founders has many years of experience in launching and failing at our own tech products, which means we know how to be single-mindedly focused on using speed as a strategy to bring a good enough product to market first.
Contact us to chat about your faster software development strategy to ensure your product is the first to market.
Managed Service Providers (MSPs) play a critical role in helping businesses maintain robust, secure, and efficient IT infrastructures.However, as the demand for more sophisticated and comprehensive IT services grows, MSPs are increasingly partnering with software engineering firms to enhance their capabilities.
Private Equity owned companies in the midmarket with an eye on growth often start with a stress test evaluation of current processes to determine if they can scale.It is very common to uncover dozens of manual processes that have been homegrown by scrappy teams over decades that could present risk during a period of high growth.