Getting SaaS-ey

I hope that this comes as a surprise to none of you but building SaaS (Software as a Service) is complicated. Over the years I have worked on different ways to help people understand this with varying amounts of success. One of the biggest problems I keep running into is the need to plan for maintenance. It is easy to want to believe that you can build a service, stand it up, and move on to the next thing. Unfortunately, it is hard to do that reliably.

Part of the problem in creating SaaS is you are often building something new. I have said before that it is a mistake to believe building an API is like making a car on an assembly line. These things are not widgets. The process is generally more like building a widget factory than actually building a widget. I think that this disconnect drives the majority of problems that businesses run into once they are accidentally successful. There is a cascading failure that comes from accidental success because the people responsible believe it is a repeatable success.

The amount that could be said on this topic could fill libraries. I am trying to find the right nuance of warning and inspiration to impart to someone who is about to enter into this kind of machinery. It absolutely has to be both.

Let’s start with the warnings.

One of the mantras of software development is “build it once, sell it many times”. I am pretty sure I have seen that in book, video, and powerpoint format enough times that I believe it. In the world of SaaS the problem is that you do not just build it once. You need to iterate on it through the release and sales cycle. The vast majority of software systems reveal their True Form after you have stood them up and sprayed audiences on them. Many times, what you built is “six beers equal” to what you wanted to build. You often need to make changes based on usage patterns and learnings from your customers. Sometimes this is change in the UI, sometimes this is change in the API, and sometimes this is change in the administration tools. I have seen all flavors of this.

The problem is that if you are building and deploying SaaS features, you are generally on a feature treadmill, and the resources that worked on the feature that needs modification are now unavailable because they are busy working on “Shiny New” other work. It is always most ideal to get the original developers onto making modifications like this. It is almost always nigh impossible. No one wants to leave precious developer resources idle on the “off-chance” that there is work discovered based on what happens to it once it goes live. I put “off-chance” in quotes because while that is the argument against some kind of “hardening sprints” from well intentioned product managers, it is actually the majority of the time that something is stood up on the internet.

It gets even worse. There is generally such drama and frustration around resourcing the updated tasks to improve a live system that it creates some level of trauma on the part of the development teams involved. Shipping software turns from a moment of joy into a moment of reluctance and dread.

Now let’s finish with the inspiration.

The good news with accidentally successful software is that it is successful. I am seeing more and more companies come to accept this as a good thing and to try to figure out how to make accidental successes into repeatable successes.

This is pretty important. Good product leadership will understand the importance of change management from top to bottom, including how an organization itself can change its change management.

I am seeing more and more people thinking and talking about this, and I am grateful that this describes many of the people I am working with.

If you find that you are not in a similarly awesome situation, you should feel free to reach out. I would love to see if I can help you influence your organization to be more successful or, more likely, to help you find a much more forward thinking bunch of people to work with.

Current world events have thrust rapid radical change on the way we work and you should be ready to optimize for long-term career maximums.

We are going to see some interesting stories about amazing successes in thinking about work—mostly for recruiting purposes.

This may or may not be one of them.