Episode #93 of the B2B Market Research Podcast – Is SaaS, Agile and DevOps Leading Us to the Innovator’s Dilemma?
- Is a combination of SaaS, DevOps and Agile causing us to miss opportunities for growth?
- Is a customer-centered focus always a good thing?
- Important questions you need to ask when developing software that leverages a DevOps & Agile mindset.
Subscribe to our newsletter for more B2B technology market research and competitive intelligence news.
Sean Campbell – CEO of Cascade Insights
In this episode we’re going to talk about whether a combination of SaaS, DevOps and Agile is just leading us back to an “Innovator’s Dilemma” moment.
Welcome to another episode of the B2B Market Research podcast. This podcast is brought to you by Cascade Insights. Cascade Insights specializes in competitive intelligence services for B2B technology companies. Our specialization helps us to deliver detailed competitive intelligence insights that other firms simply can’t match.
To learn more about us, visit us at cascadeinsights.com and also check out our free resources there, and don’t forget to sign up for our newsletter.
Is SaaS, DevOps and Agile causing us to miss market opportunities?
This particular podcast actually got its start from a conversation I was having with someone, who is the executive director of a major product management association. One of the things we started chatting about was how this combination, an almost insidious combination, of SaaS apps, DevOps and Agile, might be leading us to develop products and solutions that are missing out on some pretty interesting market opportunities.
In fact, we spent a lot of time talking about how these misfires, of a sort, might be leading us back to things that have been talked about for years in books like “The Innovator’s Dilemma” or in newer books like “Stall Points.” That’s what led me to talk about this today.
Unpacking the definition of Software as a Service (SaaS)
First, let’s define a little bit of terminology. Software as a Service, is something most of our listeners are pretty familiar with, but just to make sure we don’t speed past the basic definition here, let’s unpack SaaS a bit. We’re talking about things like Salesforce, in terms of their sales cloud. We’re talking about software as a service applications, even to some degree, things like Gmail, which is essentially email as a service.
We use these kinds of services all the time. Sometimes we use them with a client-side application that connects to a back-end service. More commonly we think of a web application that we use via our web browser. Importantly, SaaS is now being used to support all kinds of business processes ranging from financials, human resources, marketing, sales, and so on. So that’s software as a service.
SaaS can be contrasted by on-premise software, which was really the default for a number of years, where an organization deployed software inside their organization on physical hardware. They purchased the hardware and the software along with other things such as support contracts and the like. Basically, organizations maintained those on-premise applications and the associated hardware in their own data centers.
SaaS is treated a bit more like a utility in the sense that you’re buying your access to the application on a monthly or yearly basis. The organization providing you the SaaS app is handling the support, you’re interacting with them and you’re not buying hardware, etc.
How Agile Development differs from Waterfall Development
Another definition that’s important to dig into is DevOps and a very aligned term called Agile – Agile Development. First off, Agile Development has been with us a little longer than DevOps has. Agile Development was started, in part, to solve the problems that organizations ran into with something called Waterfall Development. In addition Agile Development is all about valuing individuals and interactions over processes and tools. The focus is on continuous integration, pair programming, all of which are really, really good things.
In contrast to waterfall development, Agile Development provides a lot of benefits, both in terms of better software from an end-user perspective and software that basically just cost less to maintain and support.
Agile also places a pretty big emphasis on customer collaboration. The core idea being that you’re going to deliver functionality every couple weeks, you’re going to interact with your customer regularly, and you’re not going to do this massive requirements-gathering process all up in the front-end of your development process that leads to this massive multi-month or multi-year effort – i.e. Waterfall Development. Hence all these changes brought about by Agile Developer are really good. In a lot of ways, all these changes make a ton of sense.
DevOps is something that has come along more recently. DevOps focuses on the deployment side of the development equation. Overall, you want to produce a complete unit of functionality in a few weeks, in essence, Agile Development, and then get that functionality into production, which is DevOps. All the while generating feedback from the production environment that can influence what you build in future sprints.
These products basically help you instrument your SaaS application, which initially sounds like a great idea, right?
There are also a host of products that target this space, New Relic is one, for example, AppDynamics is another one. These products basically help you instrument your SaaS application, which initially sounds like a great idea, right? And it is for a lot of good reasons.
For example you can figure out what portions of your application are being used. You can figure out what portions of your application are not being used. You can instrument your application in ways that were, let’s just say, very difficult to do with on-premise software. If only because getting that telemetry back to you, as the application developer, might be difficult or face security challenges or network challenges in terms of getting that traffic back to you in a meaningful way.
On the other hand if you’re hosting a SaaS application and it’s on your servers in your data center and you’re providing it to customers, your ability to instrument that app, as long of course, you disclose said instrumentation in your terms of service, is actually pretty awesome.
Is a customer-centric focus always a good thing?
So lets take this all in combination and ask, “Where is it leading us?” Because, on one hand, we have software that’s being developed in two-week sprints, and we have a very continuous integration and deployment model.
In addition, both of these trends are in, a lot of ways, tied to listening to the data we are getting from the customer – both qualitatively and quantitatively. Which leads us to the problem. These processes can help us make great software for current customers. In some ways, these processes help us to make better software than we’ve ever had.
So what does “The Innovator’s Dilemma,” or a book called “Stall Points” that you might not have heard of, say about the kind of customer-centric focus I’ve outlined?
Staying close to your own customers is not always good advice.
For example in “The Innovator’s Dilemma,” one of the core quotes is, “Staying close to your own customers is not always good advice.” Another one of my favorite quotes is, “We need an organization that can get excited about a $50,000 order.” In short, a small order, when orders are typically much larger – from current customers.
What both of those quotes essentially target is that an over-reliance on one’s own current customers to shape the firm or the company’s future investments can cause long term grief. Obviously it is important to listen to current customers to a degree, but what if you want to find new opportunities, new markets, or you want to figure out why certain market segments simply are rejecting your offering, even though it seems like they should be logically accepting it based on features and capabilities as you understand them?
The connection here is this over-reliance on quick sprints coupled with a focus on your current customers. In addition, our ever-increasing ability to instrument our apps gives you powerful telemetry. Unfortunately, because this kind of telemetry is so powerful and so visible, it leads us into believing that we’re seeing everything we need to see. Exactly the kind of thing that leads you into the “Innovator’s Dilemma.”
Another great book, tackles the same theme. The book is called “Stall Points.” In “Stall Points” the authors did some great analysis of how companies essentially fail, or stall out, and therefore they are unable to reach the same revenue growth and revenue targets that they once had.
That authors say that the core problem is that companies essentially fail to realize that “what they know is no longer so.”
That authors say that the core problem is that companies essentially fail to realize that “what they know is no longer so.” The other primary reason companies fail to continue to grow, as the book points out, is what they call premium position captivity. This is the idea of being held captive by one’s current customer base. Again, we have another author pointing to the same challenge.
Important questions to ask…
So when you look back at things like DevOps and SaaS and Agile, I think it’s safe to say that we’re building better software today than we ever have built before. And even though this is true, we still have some real questions to face.
- Is the focus on incremental improvement with a heavy dose of current customer feedback driving us away from understanding what other opportunities we might have?
- Is the focus on short sprints – providing you only a limited time window to gather feedback from people and organizations who are not your customers today – limiting the growth of SaaS-focused organizations?
- Is the focus on features that are easy to build vs. features that are needed, per se, to crack new markets and to create new opportunities in new industries, again, inhibiting the growth of our companies and our software products?
- In the final analysis, is the combination of DevOps, Agile and SaaS leading us back to the future, so to speak, and to an “Innovator’s Dilemma” sequel of sorts? I would say yes, but we’ll have to see.
Thanks for listening to this podcast. Hope to have you along in the next one.