The importance of a product mindset
Inflexion has been running a series of webinars to help share best practice across our portfolio and from our Network so that the companies we partner with can benefit from hearing about others’ experiences, share ideas and initiatives and support each other. Mike Talbot, seasoned software professional and CTO of Alcumus, talks with the Inflexion Network about thinking like a software company to help avoid tech pitfalls.
There are three rules a software company lives by, according to Mike Talbot, CTO of Alcumus:
“A product is only finished if it’s dead; release early, release often; and build only what you must.”
These rules go to the heart of modern iterative software development, which accepts that – very often, – when starting a new product the requirements aren’t completely known; and that these requirements will also change and evolve over the life of the product.
Most businesses don’t have a shortage of ideas of how to get more from technology, but many service businesses in particular have painful experiences of technology initiatives ending in spiralling delays and mounting costs. “Communication and collaboration is key – a ‘transactional’ relationship where the business sees itself as ‘buying something from IT’ is rarely conducive to building good software”.
This is particularly important given one of the ‘inconvenient truths’ about product development, which is that it’s very hard to be sure what exactly is needed until you try it. Mike comments, “The business might think it’s asked you to build a house, which involves a standard plan where you put bricks upon bricks. But requirements are open to interpretation, and the bigger they are, the harder it gets. The risk is that you end up with tension where some think you’re building a house, others think you’re building something very grand, and in the middle you have a mess!”
As a result, Mike is a strong advocate of the view that perfection is the enemy of good; it’s better to get the product released early, learn what works and confirm what’s wanted, then build on it – rather than aim for perfection at the expense of delaying release. “You have to get things out there and then iterate to improve, but do get it out there because your development isn’t going to stop – that’s not the finish line!” To stay competitive, businesses need to continually innovate and improve their products – the product is only ‘finished’ if it’s dead – and, as Mike says, “if you’re not moving it forward, it’s dead anyway!”
Move fast, learn from mistakes
This ‘moving fast’ culture is critical to a product culture. Attributes of this ethos include being ambitious, a willingness to break things and to embrace trial and error, being disruptive, an aversion to perfection, fast changes in view and direction, and flexibility. These traits are embraced because this culture sees failure as a crucial part of learning.
This can often come to loggerheads with a process culture, which tends to be conservative, risk averse, careful and slower moving, and perfection-oriented. Whilst vital in some areas, these traits can hold back product development. Being ‘critically aware’ of where each culture / ethos is appropriate is crucial to getting the balance right.
“On our product development, we need to fail fast so we can learn and move on. We try things out over here and then see what works and adapt swiftly.”
The process requires trust. “Think like a start-up software company: build on a budget but reach for something that can change the world.”
Think like a start-up software company: build on a budget but reach for something that can change the world.
An important rule is to build only what you must. Mike cautions that every customisation and every line of bespoke code is a risk. “Don’t build what you can, build what you must. If you aren’t uniquely positioned to be the best at something, buy it from someone who is,” he stresses, clearly an advocate of Adam Smith’s theory of specialisation. He shares an anecdote about Alcumus, which had previously insisted on building a CRM in-house – only to find years later that there is “just one person left in the team that has any idea of how it works. What was intended to save money is now being unpicked and done in a more usable way.”