Less app features please and more speed-driven development
When we founded our SaaS platform, our aim was to disrupt how “work” was done. Let’s be honest, customers just want to have instant solutions to their needs, and most employees would love to automate their current day job away to be able to focus on the real value they could be adding to their role.
We wanted to invert the “inside-out” model where companies dictate the process and pay employees to manage that process, and instead enable “outside-in” where customers self-served their needs and the machine managed the process. To paraphrase Henry Ford we weren’t looking to create enterprise software that would create ‘faster horses’. We were developing a stack that meant ‘zero horses’ where most if not all of what we currently think of as work was fully automated through the invisible orchestration of data, business rules, business process and integrations across applications and companies. The vision was to also simultaneously make business more “human”. By automating the mundane, customers could converse at any time, employees would no longer be human resources but human artificers, and enterprises in the new data economy could become creative, data-driven, intelligent and scalable.
Our platform would always default to open (open data dictionary, open APIs) and if we abstracted everything extraneous away from what we have already built, our platform would at its core be a highly-engineered, serverless, API-first, re-usable set of components that would enable any enterprise to automate anything, anywhere. That’s not easy for a sales team to demo or sell, so we had to add some pretty cool conversational user interfaces for customers (way beyond the MVP), and portal interfaces for employees and supply chain partners (MVP) which brought the vision to life. Our SaaS platform was now broad, complex and (our customers said) slick.
Over time (and it doesn’t take long!), we felt our ability to deploy change was starting to slow. As a start-up we were still way, way faster than our clients but internally there was an awareness that by adding more and more features across so many apps, across multiple environments and with the odd monkey-patch here and there, that we had already created enough technical debt that we couldn’t move fast enough. This was compounded by the fact that as a business we made the importance of conversation a core cultural value. By prioritising conversations amongst creatives (and pair working for everyone on the team) over individuals working in isolation at desks, we were coming up with better ideas, faster. Our speed of thought will always outpace our ability to change.
When I think about the companies I admire the most, the words Google, Amazon and Uber immediately come to mind. Whether it’s Google’s single input field for search, Amazon’s single click to purchase, or 2 taps on Uber to book a car, it’s not just the asymmetry between the simplicity of the user experience against the underlying engineering complexity that is striking, but how those companies have maintained the purity of their original vision over time. Google’s vision was to provide you the most relevant results, Amazon’s was always to deliver faster. No feature creep here, just ever more relevant results and ever faster deliveries. Which got me thinking, what if everyone, everywhere has always been approaching Product Development upside-down? What if instead of defaulting to adding more and more features we defaulted to zero additional features instead?
Speed-driven development is a paradigm shift for product teams
This is what I refer to as ‘Speed-Driven Development’ and its a paradigm shift from how we all approach software development today. Instead of adding features, we focus only on changes that a) make our product faster for customers or b) make our ability to build our product faster.
Instead of a business-facing Product Owner prioritising new features which a cross-functional scrum team then goes about building, we would instead turn this upside-down and default to an IT-facing architect developing a list of suggested changes, whilst our Product Owner would remain responsible for prioritising this list in line with client needs. Whilst this may sound like the proverbial IT dog wagging the business tail, it isn’t. It’s about business and IT being equal first-class citizens.
Achieve engineering excellence by design
The advantage of a speed-driven development approach is that we escape the inevitable slowdown over time that comes with greater complexity, by both reducing complexity (eliminating unnecessary features) and by focussing on the engineering excellence of those SaaS platform features that are truly core. It gives us a way to actively reduce, rather than accumulate technical debt in a way that goes beyond the incremental improvements of agile and re-factoring code as part of our ‘definition of done’.
Be paid to think collectively, not code individually
What’s more, it meshes perfectly with our cultural value around the importance of conversation. Einstein famously said “If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.” What prevents us lesser minds (although Einstein also said genius is 1% talent and 99% hard work) from actually following his advice is our fear we may not develop a solution in time. In our rush to do something (anything) we badly mis-calculate risk, swapping a low-risk strategy (thinking things through) for a high-risk strategy (just do anything). Speed-driven development avoids this natural human instinct because it frees us of the perceived need that we need to do more. We don’t. We need to maintain our vision as to who we are truly meant to be and the value we add to the world, and focus on the important, not the urgent. In so doing, we allow our automation hackers (business analysts and software developers) to stop being paid to code and to instead be paid for conversing and thinking as long as they need.
