Think like a tech company: Make software the core of every business model

Over the past decade, traditional businesses have faced stiff competition from new market entrants that are systematically and sneakily poaching existing and prospective customers. In the majority of cases, surviving and innovating is done with a digital-first mindset.

To survive and capture the largest market share, organisations need to look at how they work with software to improve business. This involves small software development cycles and a product-centric mindset for managing the evolution of applications. In fact, in a recent survey of EMEA IT executives, 90% of CIOs and SVPs agreed that improving their application portfolio would improve customer experience, one of the the core drivers of running a business better with software. At the same time, 49% of them agreed that they’re only moderately effective or not at all effective at doing so.

Software is at the centre of how disruptive companies operate their business, how customers interact with them, and most importantly, how these companies innovate. With this closeness to customers, such organisations have a far better chance of catching ‘inflection points’, those shifts in business-as usual that present opportunities to those that notice, and threats to those that don’t.

Tech companies often refer to something called ‘failing fast’. When you meld together software and business development, you can innovate by systematically failing weekly, over and over, until you find the thing people will buy and the best way to work with them – making the most of the inflection point within your sector. That of course sounds like the opposite of what you’d want. What’s really happening is that you’re using the agility of software to innovate, create more optionality, and even manage risk better. Sometimes people refer to all this as ‘digital transformation’: modernising how to think, build, and run custom written software to be more like a tech company. It means treating software like a product instead of a project.

Running software as a product and overcoming the IT bottleneck

Most IT runs as a project. IT is given a set of features a deadline and a budget. They write the software, provision the data centres, create runbooks for how to operate the software in production, and deliver it all as the completion of a project. When projects are complete, the aim is reached, and it’s onto the next one.

A product approach focuses on the full lifetime of the software: is it useful and does it help customers and users, and thus the business? Everything is oriented around gathering customer and market feedback and changing the software accordingly on an ongoing basis. In a project approach, IT is responsible for delivering what was asked for and keeping the software up and running. In a product approach, IT shares responsibility for the business being successful.

In the past, this lack of ownership has led to many bottlenecks: it takes years to deliver on projects, at high cost, and with a whimper of long-ago promised features. Systems go down or perform poorly. Most IT organisations still run this way, but an emerging cohort of high-performing companies have perfected how IT builds and delivers software. They’ve moved software release cycles from years and months to just weeks and sometimes days. They’ve accelerated how they use software to create new business value and keep organisations alive, competitive, and thriving. And the software tends to work better as a bonus side effect.

Getting the most value from software

To achieve expected business outcomes, companies need to change the way they look at agile software development. For most people, software success means delivering on time, on budget, and with the agreed-upon set of features. This makes sense based on real-world analogies. If I ask a plumber to install a toilet, I’d like it done by the day agreed upon, at the cost agreed upon, and I’d like a seat and flushing mechanics – not just a bucket with a hole in it. Software is much more difficult than toilets though and can’t be measured in this way. Following years of research from The Standish Group, my rule of thumb is that about 70% of software projects fail to live up the expectations. But, what if those 70% of were actually the best you could hope for? The ‘successful’ projects were just anomalies that happened when you got lucky. What this second way of looking at software projects shows is that the time and budget it takes to get software right can’t be predicted. In each case, the only hope is rigorously using a system of exploration and refining.

With any product, finding and defining the problem is as big an issue as figuring out how to solve it. And when you think you’ve solved it, you need to constantly iterate and innovate to solve it correctly. Until you actually experiment by putting a product out there, seeing what demand and pricing is, and how competitors respond, you actually know little beyond your hopeful day-dreaming. The same is true for software.

Small-batch cycles

In software, the discovery cycle follows a simple recipe: reduce the release cycle down to a week and use a theory-driven design process to constantly explore and react to customer preferences. Try to find the best way to implement a specific feature in the software, usually to maximise revenue and customer satisfaction. That is, to achieve whatever ‘business value’ you’re after. This can be referred to as the small-batch cycle. It essentially involves doing the smallest amount of coding necessary to test a hypothesis and then deploying it into production for customer feedback. You can then observe how users interact to validate or invalidate your theory and then use the observations to improve.

All small batches add up over time to large pieces of software, but in contrast to a large-batch approach, each small batch of code that survives the loop has been rigorously validated with actual users. Of course, in each cycle you deliver less software than in a big batch: I’m not talking about doing more coding in a smaller amount of time. In fact, doing less coding each cycle is better.

By using this approach, not only can businesses innovate faster with a shorter time to market, they can also reduce the risk of failure along the way. ‘Think like a tech company’ must become central to the business agenda in 2020 for traditional businesses and small disruptors alike.