Remaining Agile — Software as a Service
Human beings seem to have a tendency to think backwards (looking for patterns in previous experience) rather than thinking forwards (working out what patterns will form in the future). Obviously you can’t do the latter without doing the former, but if we think backwards too much, it can focus our attention on surface detail — how things appear — rather than on what lies beneath.
If you cast your mind back to elementary physics lessons, you may recall learning about wave interference , or perhaps Young’s double slit experiment.
Where the waveforms generated by the signal interfere constructively, the signal is amplified, but elsewhere, the signal is either faint, or completely eliminated due to destructive interference.
This is very similar to the world of SaaS. But in SaaS, there are at least three signal generators — monetisation, market understanding and technology. To pick a successful SaaS business model is to find a strategy where these three factors tend to interfere with each other constructively. Detecting a strong signal in one or two of these isn’t enough — you have to know how all three will interact with each other.
A SaaS business is in the business of providing software. Unfortunately, in many cases the C-level executive team, or board of directors is almost exclusively focused on financial strategy, sales and marketing. If you’re lucky, there might be a CTO, or perhaps a CPO, but in many cases their responsibility is often seen as implementation of business strategy, rather than formation.
With any software business, but especially with SaaS, what you build into your business strategy will determine the agility of your business for many years to come. Just as you need the right financial plan, and a solid understanding of your market, you need to build agility into your technology. You need to remain vital, to let your product shine, to focus on inner strength, to be sure-footed — you need to care about the technology.
None of these qualities can be achieved merely by implementing Scrum, Lean Development, or Agile Product strategies. These things have value in the right context, but more often than not, they fail because business strategy has failed to account for the technology signal.
What is misunderstood when creating our SaaS business models is that the functionality we choose to provide to our customers is fundamentally coupled to the long term viability of the business. Technology is not a magic bullet which can realise every proposed product idea in a way which results in a viable business model. This ought to be obvious — but I repeatedly find that it is not understood.
Leadership teams tend to retain responsibility where they feel most able, and create silos where they feel they lack understanding. Initial success often brings about, or accentuates this type of failure as business growth funds the development of these silos.
How to start listening to the technology signal
If there’s not much deep technical understanding amongst those of you who are responsible for business strategy — that’s ok. But, you still don’t get to delegate that responsibility to a team of technologists. You are responsible for knowing how your technology strategy will succeed.
If you’re making financial projections without understanding your technology — you’re probably wrong. If you say you know what needs to be built because you understand your customers, but you don’t know your technology — you’re probably wrong.
Conversely, making correct decisions about technology is almost impossible for someone who doesn’t understand the financial model, or go-to-market strategy. This is why you shouldn’t expect to delegate fundamental decisions about technology to your software architect, or your development team. They may play a vital role, but somebody with the ability to determine overall business strategy needs to be making the calls.
Hopefully, your name is Steve Jobs or Larry Page and you’re brilliant at everything. Or, you might adopt the strategy of keeping technology so simple that anyone can understand how it will work.
But, if you can’t or don’t want to stay responsible for the technology strategy, then you need to find a technologist with whom you can share the responsibility for leading the business. You need to find someone who appreciates technology for technology’s sake, but who still understands financial drivers and market context.
How important is the technology signal?
The three signals I mention above — monetisation, market context and technology, have close analogs in the literature about business modelling. For example, in the article The MVP dilemma, the author identifies three aspects — desirability, feasibility and viability, where technology is fundamental to the feasibility category, and contributes to the viability category.
For this reason, I use a figure of 30% as a rough minimum of how much focus technology should receive in a business strategy. However, this is not to say that technology should ever be divorced from financial or market considerations. Rather, this is a measure of how influential technological factors ought to be in all areas of the business.
One way to achieve this ratio is to draw 30% of your executive team from the technology sector.
How do I know if I’m hearing it right?
The measure of a good SaaS product is not (just) how good the software looks, or even if it has the right features. It needs to keep working. It needs to be built in such a way that it can be kept working with exponentially less effort than the initial effort which it took to build.
If you have to spend most of your resources adjusting and fixing bits of the service, if a significant number of your users encounter faults in production, or if you have to run a large support team to help your users, then you probably have a problem.
If you have a business idea, and you’re asking yourself which technology to use, then you’re not listening. If you’re asking yourself which of three database technologies, or cloud providers, you should use to implement your product, stop and reconsider your business idea. You probably started with a financial model, or a product idea, instead of listening to all the signals and picking the point of constructive interference.
A successful SaaS business idea emerges by listening to what the financial, market and technology contexts are telling you, and noting where they concur. If you aren’t hearing the signals, stop and learn. Or, find someone to partner with and listen to them.
When its working, just like the financial model, and the go-to-market strategy, your technology will fade into the background. Like a well tuned engine, it will quietly do its job until you need it to provide the acceleration for overtaking, or to avoid a problem. When your technology is constructively interfering with the other aspects of your business, it will become more and more stable, less demanding, and easier to flex.
We’re struggling, now what?
If you’ve been ignoring the technology signal for years, a well intentioned technologist will immediately rush to fix the worst areas of accumulated debt. But this is the wrong starting point. The first step is to think about your business strategy, and how you bring technology back into the core of what your business does. You probably need people leading the company who care about technology.
Depending on the amount of technical debt accumulated, and presuming your business is still viable, it may take a few years to put things right. But nevertheless, if you are prepared to fix the source of the problem, the effects will be felt immediately. Things will start to move in the right direction, and technologists have an innate sensitivity for changes in the system. Because they’re so good at abstraction, good technologists get motivated by having the right strategy in place. Often, the situation on the ground is less significant to morale than an understanding that efforts are being well invested — and this is particularly true for software product engineers.
In this series of articles, I’ve thought through what agility really means in the context of software products, and SaaS in particular.
I’ve noted that there isn’t just one type of agility we need in a business. Rather like Maslow’s hierarchy of needs, there are “higher-level” and “lower-level” types of agility required.
I’ve discovered that “Agile” doesn’t come about by implementing particular processes, development techniques or product strategies. All of these fail to deliver, or cause damage, if you don’t build agility into your business model.
Agile technologies derive their agility by working hand-in-hand with financial and market drivers to allow a successful business model to emerge.
This is part of a series of articles on agility and software which are linked below:
