"In other words, the ability to write and deploy code is no longer a core value driver" - I do not think it ever was, it is always what that code solves for customer. Ability to write and deliver code is just a way how you can get money out of core value.
Nitpicking, how SaaS stocks could plunge?
I think the good point is:
"The monthly contract value is often far less than the customer acquisition costs (mostly sales and integration)"
You do not price your SaaS based on hosting costs, if yes then those SaaS solutions will simply run out of money.
You cannot run growing SaaS on 1/10 slashed price, you have to fix bugs, add new features and evolve.
I can build clone of some SaaS and run it on Linode with 1/10 of costs but I am not sales person, and not marketing guy.
I would not have money to evolve and it is not fire and forget running on cheap hardware.
So article is not worth reading, nothing exciting.
The article seemed to be worth reading for you as it prompted you to solidify and articulate your thoughts, and to share a good tidbit on SaaS pricing. ;-)
In the same way, it may trigger thoughts/ideas for others, regardless of whether the agree with it or not. I'm glad I read it, as well as the comments.
As Don Quixote should have said to the guy who said there is no book so bad it doesn't have something good in it, opportunity costs are huge these days.
I read it, was disappointed that article does not deliver insights that title is promising and made comment in civic duty so others don't have to read it.
That's a consumer metaphor. The original article is talking about B2B startups.
Consumers and businesses are very different as customers. Every consumer product/service is fundamentally an experience; even the design of Apple's packaging is carefully engineered so that you feel a certain way as you open the box. That's because consumers are buying your product (or sitting through your advertisements, or giving you their personal data) because you gratify some emotional need they have; why else would they use it?
Businesses have only two fundamental needs: save money or make money (where time=money, if you can point to a wage rate). Every B2B business model is based around those. Many failed entrepreneurs have looked at the sucky user-experience of most enterprise software, said "I can do better than that", promptly done better than that...and found out that they didn't make any money, because the person doing the purchasing didn't give a damn what the "experience" is like, the whole reason they pay their employees is so that they'll sit through tasks that they hate. If you can't frame your B2B company's value propositions as "This will save $X" or "This will make $X", you won't sell.
But these days the employees who work in HR, finance, accounts receivable spend their downtime locked into very sophisticated, mobile-friendly apps with user interfaces we could only dream of in past - even while slumped in front of the TV.
They know what good software looks like.
Yes, sometimes the suits making the decisions will just go from form and mandate SAP.
But I can assure you that much of the time, turning up to demo your product will go badly for you if it looks like a drab table-based web site from the 90s.
Conversely a single magnificent d3 animation will move you straight to the short list.
> If you can't frame your B2B company's value propositions as "This will save $X" or "This will make $X", you won't sell.
I've seen multi-million dollar software deals where the "make or break" feature is themeing it to corporate colors. I've also seen some terrible software bought because the sales team takes the manager out to a nice lunch.
I don't think I've ever seen software sold on a purely cost/savings basis.
The mistake those people make is focusing on the user and end result for the enterprise using it. The customer isn't either of these -- it's the exec.
Businesses make lots of emotional decisions... the continued, although diminished, existence of IBM is proof of that. It's just harder to divine whose emotions matter and what moves them. You also need the capital to survive that learning experience.
Businesses don't make purchases, decision makers do. A product/service might succeed if it's really good at operating as you describe but fulfilling the specific needs, often emotional, of the buyer is still very much a part of the sales process in the b2b world.
Sales is a huge industry, and a large portion of it is in squishy things, like meeting in person and sharing a meal, going golfing togeather and whatnot. Businesses don't make choices, people do.
I would say Software as Experience is already here, and has been for a long time.
SaE is when, instead of buying online with a credit card, you are courted by attractive sales people and consultants, get wined and dined, receive beautiful reports to show your boss, get a nice pen and a bottle of wine perhaps, and participate in workshops facilitated by said attractive consultants. This makes you feel like an important person in charge of an important project.
Your SaaE sounds a lot like the "services" that companies like Oracle and IBM offer to older, more established Fortunes 500 companies.
If anything, with the growth of self serve products like AWS and the growing popularity of OSS, we're still in the process of moving away from your "experience-based" service to regular SaaS.
Sorry, coffee snobbery incoming: drip coffee is pretty different from espresso. You're right that there's a "luxury" aspect, but there's also a product difference. Maybe the product difference is only 20% of the cost in total, but it's still there. I don't drink drip coffee anymore, it's gross. :[
Also-- aren't video games already an example of Software as an Experience?
"Espresso" and "drip" aren't types of coffee; they are types of coffee preparation: grind and brew. Drip gets a bad reputation because it's associated with offices, waiting rooms and cheap diners. The espresso method does extract a different profile of substances from the coffee; but it's subjective whether that is better or worse.
Espresso made with poor quality coffee (bad roast, crappy beans, roasted too long ago, incorrect grind, etc) is going to be just as gross as diner drip.
Another thing to consider is: you can make drip manually, whereby you control the drip rate, total quantity, and water temperature. Not all drip is automatic.
It's only fair that I got nitpicked in my nitpicking. :D The quality of beans is definitely a factor, but the difference in acidity from the different preparations is a big factor for me. Especially since I've developed some gastritis, having a less-acidic caffeine delivery system is important.
I watched it happen in the auto industry. You had all these small vendors selling headlights, grills and bumpers. Then someone came along who had bought out some of the little guys and offered the Big 3 a packaged front end of the car. They handled all the engineering post design and had a complete front end of the car that just clipped on.
They were non-union and in a rural area where wages were lower. The price was lower than buying everything individually and the Big 3 saved lots of money on their very high labor costs.
What's to stop people from doing a roll up, buying a bunch of litle SaaS companies and offering a package that is a complete solution? It would be discounted of course like MS Office back in the day which killed off the category leaders like Lotus 123, dBase and WordPerfect.
That is a far more plausible scenario than what this guy proposes.
It may happen, but to to answer your question "what to stop...": probably not to "stop", but make it difficult is the fact that lights, grills, and bumpers are much easier to integrate than software products.
It is much harder to integrate bumpers and lights than software products. There is a whole sales cycle in the auto industry based around new model years. The bumper factory and the grill factory have to bid for the new model. Then the automation supplier helps them re-tool their manufacturing line. The logistics companies set up routes between the new bid winners, etc.
I do find it hilarious how we always defend our illogical likes whenever they are pointed out directly.
There is a very slight product difference in any luxury experience. It adds to the experience after all. However this is meaningless in the overall comparison. You don't drink drip coffee anymore because you love the other experience. It's obviously not "gross" because you were drinking it just fine before you were exposed to espresso. Maybe at some point you'll become disillusioned in being a coffee snob and then go back to drip. It happens.
This isn't unique to you or coffee. You could say pretty much exactly the same thing about whatever brands/hobbies I'm into and I'd feel exactly like you do: that my preference was justified by more than pure emotional connection. In reality, our choices as consumers are 90% emotional, which is why advertising works so well after all.
Nah, drip coffee is gross, and I say this as someone who comes from a country where espresso is the "default" (if you want drip, you'll have to make it yourself, every coffeshop/diner/restaurant sells espresso, and for ~60¢/cup).
Sometimes one just doesn't realize how crappy the previous version was until one tries the new one.
Try a nice Ethiopian blend from a Chemex made by an experienced barista and come back to me.
Espresso is as different to filter coffee as icecream is to milk. They're different products, made with different material mix and different processes, different roasts, different grind size, different bean choice. They're two different things.
An espresso can't be better than filter coffee any more than an apple can be better than an orange.
Beware over-training your ability to discern differences. Such subtlety might give you an advantage in some fields... or it might remove your ability to enjoy basic food and drink.
That's a service provider in that case. You're effectively arguing that outsourcing is the next big thing. Could be a compelling argument to make but I don't agree, if anything I see the opposite happening. Big companies doing everything in house.
Given the economics of SaaS where frequently revenues are dominated by the very big accounts, combined with large companies getting even larger, I can definitely see a world where a company with 10,000 sales people on $2k/yr Salesforce licences might roll out an in-house solution. (though even then, I wonder if $20M/yr is a big enough cost driver for such companies to take the leap)
At some point it makes economic sense to roll out your own data center. At some point it makes economic sense to design and make your own server and networking equipment. The question would be where that breaking point is for SaaS.
"Software as Experience" is a nice way to describe Apple's business model.
Hardware spec wise, the price of a Macbook is probably double that of a regular laptop with equivalent specs (CPU, Memory, GPU, Disk, etc). But people buy those Macs for the experience; not just the specs.
It's incredible how myopic this article is towards web development SaaS products.
There are a whole slew of SaaS products for business applications that have nothing to do with what the author is talking about (think SalesForce, Workday, ServiceNow, etc) that totally eclipse the Segment, mParticle, etc's of the world, in terms of size, complexity and
The "what comes next in SaaS" is predicated on what become before SaaS, which was license software that businesses had to maintain. The next evolution of SaaS, IMHO, is one which requires zero consulting/integration/implementation. I dare say "AI" will change that, but this is the biggest friction to new software production adoption.
I believe that the author's core point is that the SaaS business app space ("SaaS v2") is huge, but it has become a red ocean. He then proposed a viable "SaaS v3" space populated with the likes of Segment.
I don't agree with his v3 vision as I think that AI is a better lever than trying to build an integration platform. The latter is hard, usually involves open source, and has slow adoption.
SaaS isn't a type of software or solution, it's a delivery model. You don't use "SaaS" for sales, you use a CRM that is accessed to you through a SaaS delivery model. So it's "low-code application development platform" is still delivered to you via a SaaS model.
I'm not sure I agree with the listed reasons. From what I understood, the author tries to prove that "SaaS is eating SaaS" and SaaS abundance/switching costs are prohibitive to new SaaS ventures. This doesn't seem like a very good argument for "SaaS is dying." May be, it's better suited for "it's becoming more difficult to enter the SaaS game."
Sounds like SaaS is falling under standard business rules. You have a core product and you have differentiators. A single, great core product was fine for a long time. As more players enter the market, the differentiators matter more.
Much of the value of a SAAS/Cloud service is that the operational costs are so reduced. We talk a lot here about the explosion in complexity in tech (front end stacks, different OSs, security, mobile+desktop etc.) but rarely about how to really manage them.
SAAS services are typically wildly, crazily cheaper than hiring people to either do the services or to support an internally setup and managed application to do the same.
You're so right. Especially at the small-scale end, it's much cheaper to build a buggy and fragile product with a database you can access any time and fix stuff for your users. Instead of hiring a bigger team with the QA discipline to send nearly-perfect releases out into the wild, the hacked-together SaaS can be built with 10x fewer developers and one DBA. That's been true since at least 2005.
A lot of points in this article resonated well with me. Especially this:
> Companies that focus too much on technology without putting it in context of a customer problem will be caught between a rock and a hard place — or as I like to say, “between open source and a cloud place.”
I'm in the second year of a SaaS selling to entreprises. We are doing ok but all of our customers are nearly identical (it's in the public sector). We would love to have lots of different types of customers but we seem to be stuck. Our customers are probably buying our knowledge as much as our product.
I would say unless your tech is groundbreaking and not easy to copy, domain knowledge will likely be your differentiator. But that's harder to scale.
I think the hole in many SAAS products is the assumption that the end-user has a development team, or that every other SAAS company is going to integrate with their API.
At the end of the day, a small business has much larger fish to fry than trying to figure out how to plug product A into product B, though it is a massive problem for every small business. This isn't solved by hiring programmers, but by downloading data and inserting into macro-enabled Excel sheets. You can hire 5 Excel gurus for the same price as you can a Jr Developer (a typical SMB isn't able to figure out if said dev is worth anything).
The fact is, the end-user really doesn't give a care about "who" but "does it work?" Integrating all the pieces and parts is a very complicated and time-consuming thing for small businesses to deal with.
What comes post-SAAS? A fully integrated suite of products that does what the end-user wants. SMBs would be super stoked to have a product that does inventory, label-printing, CRM, market analysis, sales channels, etc, and pay that to one company. I think that there ought to be an in-between layer. If a some companies could offer a solution that integrate all of the SAAS products needed to run a business, packaged in one place, entire industries would end up toppling. The price differential wouldn't even have to be that high. The company would save the end-user months of research and time-wasting presentations.
I just did a SaaS company serving SMB. We were an all-in-one security play. Well-regarded product.
One of the things that we encountered was a vice between "can you add this filter" and "but I don't need this, only that filter."
In a more general sense, my research suggests that "IT in a box for SMB" is a deadly place to operate. They make sense on many levels, but they don't sell.
I believe that SMBs favor point solutions because they are pain-avoiders. If they've been phished, they want a remedy. Firewall? Content filter" Maybe later...
I see a lot of problems here. You are selling to technophobes, for the most part. They don't care one iota what the difference is between a firewall or content filter is. If you have fraud-prevention, ie, making sure they don't get screwed out of money, you are talking their level.
There shouldn't be an vice between option A and option B. You are selling security, not options. They are paying you money for your expertise, which includes both your programming an your knowledge, which mainly means they have to get things done and don't have the time the learn about this stuff, which is why they are paying you.
That repeats my initial point. The end-user really doesn't care at all about the product, who you integrate with, what you use, etc. They feel like they are paying experts to make these decisions. Asking them is friction, which is nothing but wasting their time.
"Fear" doesn't sell in SMB/Owner-operated businesses as well as it does in Enterprise. Most security selling is "Fear" based.
SMB looks at potential post-event loss vs cost of buying a preventive security solution (Reducing losses). Most security solutions are not priced as insurance premium are determined. The ROI of security solutions is not compelling for SMBs. That is why security solutions targeting SMBs don't succeed.
In my opinion, SaaS is being eaten by largest PaaS providers : GOOG, AMZN and MSFT. They built so many free or cheap services that killed a lot of independent service and product providers. You can't compete with them because they own the platform you're on, they can always clone you and make the clone cheaper and more integrated with their platform.
In some places, there's a gap between open-source libraries that I can find, and services that Do One Thing.
Recently, I dived into the available options for online document signing.
I needed one thing (document signing) done well, with a few variations based on the few different integration situations I had.
Almost everyone had the same offering, which wasn't programmatic or flexible, but was drop-in (iframes). I could only do what they'd though to make possible.
On the other hand, I have trouble imaging what, say, a ruby gem for this would look like. Seems like it'd be pretty involved.
Compare this to, say, SendGrid, and other email providers. I get a lot of flexible functionality around one thing (sending emails), but the interaction is very much on my terms (via their API) rather than theirs (dropping in an iframe).
The only exception I found in the document signing world was HelloSign, which has a lot more in common with SendGrid than, say, DocuSign or RightSignature.
I don't think this is quite what he's talking about, but I do think it's indicative of the direction and forces in play.
I took a look. What level of critique do you want?
I think with a decent amount of effort, you can out-compete (as a product) all existing solutions except HelloSign. However, I would expect to run into serious issues convincing companies to switch. You would probably want to specifically target the new company / tech-savvy startup market, which I think are very underserved by the painfully antiquated leaders (DocuSign, RightSignature), who are targeted towards people who feel more comfortable with "enterprise"-style solutions.
Our major issues were:
- We needed to provide our own styling, etc, for integration on a responsive website. Existing iframe solutions used the provider's styling, and did not work well on mobile.
- We expect to send out many more documents than get signed; thus, HelloSign's per-API cost would be to expensive for us.
Many of our SaaS customers hate the utility pricing. It's hard to calculate costs and budget when things change every month. Our flat-rate pricing is what attracts many.
This is is a very important point, especially for larger organizations where budgeting (and closely following budgets) is extremely important.
I co-founded and sold a company that did SaaS/outsourced natural gas and electricity billing for energy retailers in deregulated markets, and cost consistency was a major reason why corporations signed fixed price energy contracts. Even though they might pay more than simply taking the spot market price, having known costs was preferable.
I don't get how flat fee is sustainable long-term if the company is cost-sensitive (which I guess is different than simply wanting a convenient and predictable budget item, which may or may not be the same thing you're talking about)
If I offer a service for a flat fee, I should keep my price higher than if you were to accept a variable budget item. If you start going over the flat fee, I'm eventually going to be taking a loss on the electricity/hardware. So naturally I might have to raise the price more quickly since I'm not likely to be a massive electricity/natural gas company. The price for SaaS/Cloud would not be as sticky as gas/electric and so the contracts would be for a shorter length.
Where-as, had you done some napkin math for cloud costs and tried your best to overestimate, you can add some additional overhead and see if you run over/under that year and adjust. You still treat it like a flat fee, but there's just a re-adjustment if you're over/under at the end of the term.
I agree. It's simpler, but it's also often a lot higher. In the AWS case, you can build an app that costs almost nothing to run, until you have usage.
If you paid $10-$100/month for every component just for simplicity, a lot of things would never get off the ground. One of the big differences is Amazon has also unbundled support from their pricing.
I think between your remark and mine it's evident there's no generic recommendation, just a basket of options and the advice to learn your customer preferences.
It's what I chose instead of monthly fees. For my market this is far more palatable than a recurring subscription. I personally like it because the amount of value we capture scales with the amount we create.
It also means I skip reporting the "traditional" SaaS metrics like MRR and churn, but I don't talk to VCs much anyway.
> Peter was annoyed. An energetic young fellow — he faced a pretty serious problem: people weren’t even willing to try his company’s analytics product. Even though it was (in 2012) a very immature market — and the current offerings lacked a lot of what customers wanted. Why? ... So Peter and his team build middleware to make it easy to switch between SaaS providers (maybe then people might try his system).
This is a gross misrepresentation of the whole situation. It reads as if Peter was a biz guy who was having trouble selling the analytics software because of the involved "switching costs". Peter and his team, in their own admission, were trying too hard to build a product without a focus on what they were solving. Analytics space is too broad and complex to be attacked all at once. It's not wise to build a GA competitor but several analytics companies with a clear focus have succeeded in the past.
Segment wasn't trying to build a "middleware to switch between companies". The product was almost an accident of a building a small library for themselves to avoid mantaining code for multiple APIs.
Is the core argument here is that SaaS enables the success of software companies that have little value and that "post-SaaS" means that those companies die?
That doesn't really ring true to me. That already happens, doesn't it? SaaS as a pricing model or platform strategy in and of itself won't do shit for you if you have a terrible idea, right?
Or is the author trying to argue that SaaS will eventually become a race to the bottom and that the market should shift towards value-based pricing?
Lots of parallels between your take and that of this author.
I'm more skeptical than you guys about the Saas/cloud "plumbing" space. There's lots of open-source software out there and I think that value extraction – largely from PMs and devs – will be tough.
An interesting read but this kind of predictions don't work "in advance". Usually it's needed for some market player that is still unknown to show up first. That player will then serve as an example and solidify the argument. To know/feel what SaaS 2.0 is, in advance, would mean that you are the one driving it. SaaS 2.0 is not here yet.
Maybe hardware as a service? Perhaps specialized chips constructed by software is the next evolution in efficiency?
You could have a data center, chip designer, fabricator, and software service.. all in one. Unlikely, maybe... but the question is pie in the sky anyways.
> Companies that focus too much on technology without putting it in context of a customer problem will be caught between a rock and a hard place — or as I like to say, “between open source and a cloud place.”
Comparing a cloud to a rock, the author needs to work on their metaphors.
Workday (WDAY) and Veeva (VEEV) as great examples of just recently rallied SaaS stocks.
The true value of SaaS is just unfolding, not being stuck on old versions is just now sinking in. The above companies have customers go beyond the 5 year, sometimes 10 year mark - but they're not on some outdated version, figuring out how to patch that shit up. This is a revolution in enterprise that has not fully sunken in, there are still a lot of companies out there only dipping their toes into going SaaS.
Vertical clouds such as Veeva, as in going deep into one specific target industry, are a pretty good model to follow. Customer acquisition costs are super low, there is data out there to confirm this. All a reference sell, as CIOs talk to each other in a specific industry. Build a positive reputation, the sale follows. Product leads the way, not marketing.
The moat here being super deep industry expertise and data accumulation that gets harder and harder to compete with.
There will be something after SaaS, but it will take a while and it is utterly unclear what it will be.
Since the article referenced "Louie"building out his product in a 3 months Ramen-fuelled binge, I don't think he's talking about SaaS like Workday, which is basically a gigantic ERP, just delivered via the interweb.
Nitpicking, how SaaS stocks could plunge?
I think the good point is: "The monthly contract value is often far less than the customer acquisition costs (mostly sales and integration)"
You do not price your SaaS based on hosting costs, if yes then those SaaS solutions will simply run out of money. You cannot run growing SaaS on 1/10 slashed price, you have to fix bugs, add new features and evolve. I can build clone of some SaaS and run it on Linode with 1/10 of costs but I am not sales person, and not marketing guy. I would not have money to evolve and it is not fire and forget running on cheap hardware.
So article is not worth reading, nothing exciting.