Software is more than just features

Software is more than just features

Over the last 10 years, I have seen a shift in SaaS start-ups and scale-ups in their software development approach.

20 years ago, waterfall methodologies were king, and a lot of time and effort was spent on analysis and on understanding how a software product was built, brick by brick.

Possibly due to the rise of Agile, a number of software companies have shifted from building coherent software to just building features. This is especially true in environments where business leadership is more vocal than technical leadership. This isn't an issue with Agile itself, but with how it is often implemented in these organisations.

Why is that wrong?

The problem is that software is so much more than a set of features. Those features need to work well together, form part of the user experience, and follow a coherent path. Without a plan, everything starts to quickly fall apart.

Some businesses also like experimentation and might set aside funding for a proof of concept or a quick trial product. There too, a plan is critical, so that you can bring that POC or trial back into the core product - or at least the concepts they were trying to demonstrate. Too often, those experiments are left unattended, and 6 months later, no one remembers them in detail. The core product has evolved too much, and there are no options but to restart those projects from scratch.

Building revenue-generating features quickly, without a plan to address technical debt, can be tempting, especially in environments where the business pressure to deliver quickly is high. But remember, your product needs to scale in line with your business goals. There is no point in having spent all that time, effort and money on building a product if it fails as soon as you land that large deal. Not only will you have to rebuild a lot, but you'll also have to recover from the reputational impact.

Finding the right balance is very difficult, and that is where we help our customers understand the compromise and make the decisions which are right for their specific business circumstances.

The straw bridge

Pictures speak louder than words, so to use an analogy: Imagine you're a SaaS founder and asking your tech team to keep building features. They built you an amazing-looking bridge. Your current volume is low, but the couple of cars using that bridge every month love it! Your sales team worked hard on building momentum, and you have a highway full of cars ready to start using the bridge. You feel you are ready to open the flood gates, except... the bridge is built of straws!!! It does perform very well for the couple of cars using it currently, but it will come crashing down very quickly as more cars start entering the bridge.

This is the situation I have seen time and time again in a number of businesses we have been helping. Usually, the first answer from founders is: "I don't mind the bridge being improved; for now, I need to focus my limited funds on building an extra lane so I can charge more and generate more revenue!" Obviously, this isn't the correct answer for the business, and that is why understanding the situation and the return on investment on each 'feature request' is critical.

If you need help digging into this in more details your business today, we’d be very happy to help. Click here to contact us.