Software procurement underwent radical change in the face of “the cloud.” Â The paradigm of purchasing a static piece of software that met your requirements, installing it (or having it installed) locally, and then purchasing updates went out the window over the past decade. Â Some organizations still follow the old model, but there are fewer and fewer of them and they are dying off. Â CTOs who obstinately refuse the cloud out of security concerns are cowboys in a world of interstate highways, and old enterprise software vendors are carriage makers circa 1920.
Software as a Service has been the new model. Â Salesforce and many others have proved that Software is not a static product, it is a continually updating service. Â Buying software is as easy as going to the dry cleaners, dropping off your dirty laundry and picking up clean, pressed sartorial concerns. Â You can sign up for or subscribe to software for $50 bucks a month per user, sometimes basic products are free and additional functionality costs money (the fermium approach), others still are supported by selling information or eyeballs to advertisers.
But in the past three years or so, there’s been an absolute explosion in software companies building tools on the Internet. Â The sheer quantity of .coms .lys .ios . ins will just blow your mind. Â Just read TechCrunch for a few days and your thumb will get tired from hooking up these new services to Facebook Connect or one of your other online identities.
How do you evaluate companies that are three months old? Â How can you prove efficacy to something that launched two weeks ago? Â Why should you write a check to a bunch of people staring at computer screens that jam to techno and have dogs running around their office?
Software as a Service is no longer an accurate description of the paradigm of innovation, of the relationship between customer and service provider. Â We need a more accurate term.
Software as a Mission.
Software can move so fast that customers are not only not buying a static product anymore, they are also not subscribing to a defined service, they are now believers in a mission and hanging on for the ride. Â And the ride is fast enough to be a bullet train, but can also be a roller coaster. Â Companies that seem promising can suddenly get acquired, or go down in flames from premature scaling. Â They can get a strong competitor coming out of left field.
The question is no longer “Do you like the product?” As much as: “Do you believe in the company? Â Do you believe in their direction? Â Do you believe in the team?”
And if you bet on the wrong horse, it’s not as big of a deal as it used to be. Â You just take your credit card to the next one doing the thing you wanted doing. Â No big deal. Â The cost of implementation is usually just people hooking up their identities and choosing a password, at most uploading a spreadsheet.
By the way, this also means you won’t just have one vendor for what your communities or teams need. Â You’ll likely have several, and functionality will overlap. Â We’re going to have to be Zen about that.
So, let me ask you this question: think about your vendors.  Picture them.  Do you believe in the company?  Do you believe in their mission, their direction, their team?  Believing is so important because great teams can ship software really quickly, and what you have next year will not be what you have this year.  Believing is important because small teams of people can now produce software that millions of people use.  (At one point there were almost 2 Million Twitter users for every Twitter employee, same goes for Instagram.)  Designing and developing software is more of a craft than an assembly line.  Old paradigms of product development created McDonalds.  SaaS introduced the Olive Garden.  But let’s face it, we really want our software to come from organizations like the French Laundry.  We want our Software to be produced with great theory and execution, by a small team of people paying infinite attention to detail to provide an excellent experience.
Allison Wood says
Love this post, Michael. As a co-founder of an EdTech co. offering a specialized LMS for healthcare education, we find ourselves hanging on for the ride as we welcome a rush of new customers while maintaining our “infinite attention to detail” and providing an “excellent experience” for our clients. We believe that, in connection with our product, this is what will make us successful – asking, listening and problem-solving, not just shipping them a system.
It’s no surprise to us that in this warp-speed, iterative world we’re spinning through, a commensurate demand has arisen for “old-fashioned”, personal communication, for really listening and solving problems – you know, the stuff that takes time. Our team refuses to let the “scale or be damned” mentality dilute our commitment to our customers; indeed, we believe that we will scale as a *result* of those authentic partnerships, not despite them. Thanks for validating our philosophy and reminding folks what’s great in both the reality and the potential of “software as a mission.”
Jason Rappaport says
This, to me, extends far, far beyond CTO’s and CIO’s looking to purchase software. And, to be honest, it goes beyond software itself. Having a mission – one that you feel in your gut – to me isn’t just something great for a business and the folks that interact with it. It’s a requirement.
It’s one of those things that I can’t believe gets overlooked. When I attended EDUCAUSE last year as a Startup Alley exhibitor, it was absolutely astounding to me how many edtech companies weren’t passionate about their products. And if you’re not passionate about your own product, how the heck do you think you’re going to get other people believing in it as well? The general overtone of the entire industry was one of monotonous indifference.
I kid you not, I received several comments about how I was able to pitch enthusiastically for three days straight, and from representatives of well-established companies. There isn’t some kind of magic secret. It’s because I absolutely love what I make. I wouldn’t pick any other job in the world. And I make sure to extend that to my team that helps me build this thing (okay, they do *most* of the work), and we all make sure to extend that enthusiasm to everyone that gets a good hard look at GoodSemester.
The people we’re talking to? They’re not clients. They’re human beings. They’re not a number, a statistic for us to check off like “how many professors do you have on your service?” These are people who pour their blood, sweat, and tears into helping build the infrastructure to teach people. And we get to help bring that kind of system to everyone. Every single product in edtech has just one purpose: Let’s make education better.
If the company doesn’t believe in that – truly believe that, at all costs, they should make education better – I don’t see the point in getting involved if you’re a CTO or CIO or an “end user” or a “client” or whatever label someone wants to put on you. And if you’re the company making these things, you’d better damn well believe in what you do with all your heart and soul, because you can’t change the world unless you care about it.
Brittany Mullins says
Wonderful post Michael! I think the other two comments have summed up my thoughts, but I’ll just add that we here at SoftChalk we feel the same way. Our founders (Sue Evans and Robert Godwin-Jones) came directly from the public education sector (Jones still teaches currently) and our mission since day one has been about helping educators and improving education.
SoftChalk actually came about as an extension of the early work with learning management systems, when Evans and Jones recognized that although educators desire to create sophisticated, interactive content, they typically do not have the time to learn complicated authoring tools. SoftChalk solves this issue!
This year marks a decade for SoftChalk and we’ve just launched a web-based version of our product called SoftChalk Cloud, so we’re no longer “carriage makers.” 🙂
Michael Staton says
Hi Allison, Jason, Brittany,
I’m glad you agree. So does that mean we agree to use Software as a Mission consistently from here on out?
I wonder what it means that all three comments were from vendors rather than institutions?
Jason, I know you’re particularly passionate about what you do. As am I, but for the record your consistent exuberance was outstanding even amongst the fifty or so entrepreneurs at Startup Alley.
Michael Feldstein says
Regarding the point that the vendors have responded and the institutions haven’t, I think it might be useful to explore what Software as a Mission means for procurement processes. How should this mindset change the ways in which schools evaluate vendors?
Allison Wood says
For vendors like us, software IS our mission, whereas institutions have to plan, strategize, build and execute against their own missions – which are usually at least one triple-club-sandwich layer removed from ours.
But we believe our commitment to SaaM can literally bubble over into our institutional relationships and carry them along on the ride with us. I know because I’ve seen it happen. As a young company, sometimes the highest value we have to offer is our passionate commitment to solving problems for our clients. They just don’t get that from most of their vendors, and it has helped us win over some big institutional clients who hardly ever work with companies as young as ours. They get that we care, and not just about adding their name to the client list.
As far as changing their mindset, I think it’s more about changing their experience and expectations. Mindset will follow as a result. The client with this “new and improved” attitude would do the following:
– Understand that technology can help solve their problems, but that they likely need to make some business process adjustments as well
– Appreciate that robust, efficient technology is worth its weight in gold
– Respect our time as well as their own with efficient communications and requests
– Seek out strategic advice, listen, make the best possible decision and keep moving forward
All this adds up to “agile” in every sense of the word – and that is a word rarely used to describe any entity that qualifies as an “institution.” To get more agile, they’ll have to decentralize their decision-making while retaining a birdseye view of their greater institutional needs. Then it’s up to us, as SaaM disciples, to make sure our technology can serve the individual as well as the institution.
Jason Rappaport says
Michael, I think “vendors” are the ones who’ve responded because, for the most part, companies have one mission (let’s stick to the education sector and ignore multi-department conglomerates for this purpose). That makes it really easy, and often fun, to focus on that one thing.
Schools, particularly large universities, have to focus on a wide array of subjects, each with their own research and mission. It’s honestly a wonder that a single administration could make decisions for an organization that, almost literally, has a department for every job field on the planet. In this sense, interests aren’t just likely to collide – they’re bound to.
The short of it is that I feel like it’s far more complicated for anyone at an institutional level to come out and say “We’re only going to purchase software that believes in itself,” because they’re busy enough fighting the good fight to get their own institution to do the same thing.
Not only that, but how do you make a decision between MULTIPLE pieces of software or MULTIPLE services, each built by an incredibly passionate team? When everyone’s at war, no one’s at war, etc, and we end up back to square one. An institution needs to be evaluating not whether or not a vendor has a mission, but whether or not their two missions intersect. And, as I just expressed, my feeling is that most institutions are spread so thin that they haven’t solidified their own missions to get to the point where they can empathize with the missions of others.
All of things brings me to what I really wanted to say at the beginning of this post: I don’t think vendors having a mission is something optional that is “agreed upon”. I don’t think there’s any other way of doing business. As a rule of thumb, I’d like to think that companies with no mission who don’t care deeply about their product and customers will be forced out of business. Perhaps that’s idealistic, since I’m a youngin.
tl;dr: I don’t think there’s any other way to do business but to have a mission and care about what you do, so if you want to call it software as a mission, I’m all for it! Just no acronyms please. 😉
Allison Wood says
Brilliant, Jason. Totally agree with your insightful comments.
Joel de Bruijn says
Thanks for your article!
But one thing made me wonder: “The cost of implementation is usually just people hooking up their identities and choosing a password, at most uploading a spreadsheet.”
That would be for applications which support fairly common processes (HR, Finance?) I guess? In the cloud I don’t have to install anything, but setting up and configuring software to meet the demands of specific business processes can be as time consuming as ever. I think having my software in the cloud or local doesn’t change this.
Or should I say: when implementation does cost a lot (of time/consultancy) my processes are not standardised enough? Which can be the case if I have a niche market. But like most educational institutions we’re not operating in a niche market …