This is a pretty established distribution model often called "bottom up" approach, and it's particularly relevant to enterprise sales where you allow the users to start using the software without friction [something that was proper to "consumer" applications] and then allow management to pay for that software, or users to pull their corporate credit card and buy what their budget allows.
One turn-off for us for machine learning platforms was going to the website, wanting to try the software, and then finding a button that says "Schedule a demo" or "Schedule a sales call". I want to try the software, not talk with your salespeople. I want to create an account, or request access to a demo account without speaking with someone. Then I want to be able to pay for it without speaking to someone. I have the proverbial, and sometimes literal, credit card in my hand: let me pay.
That weighed on our decision to make our own platform[0], because we simply don't like to buy things this way.
Again, there are differences with low-touch and high-touch software, and situations where the regulatory context or contract amounts require that at some point, people sit down together, but that's for particular cases and clients. We made custom machine learning products for large enterprise, so we sit a lot with clients, but the word "custom" is there.
Some content that goes into this is Slack's CEO discussing this with Yammer's former CEO[1]. Slack's CEO also discussed this in a Pando Monthly[2]: they didn't have a "sales" team, but sometimes needed to 'onboard' a large organization. He also addresses how raising $1B reassured many 'traditional' and 'sensitive' organizations into using Slack for internal communications.
>One turn-off for us for machine learning products was going to the website, wanting to try the software, and then finding a button that says "Schedule a demo" or "Schedule a sales call".
Share the sentiment but both of us are likely not the target audience for these kinds of funnels then. Decision-makers who go down the "talk to our sales team" route are more likely to sign big enterprise-y contracts in the end I guess
>Share the sentiment but both of us are likely not the target audience for these kinds of funnels then.
Except I'm an engineer first who just happens to be able to make that decision, and I made the decision not to buy.
Here's the thing: we've been making bespoke machine learning products for large enterprise for quite long. Not huge contracts, but say mid six-figures on average. We sit down with our clients but the key word here is "bespoke", which warrants these meetings and communications and calls. We build these solutions from scratch to solve their problems with their workflows. Anything that's not bespoke or where we don't have to discuss regulatory matters or where that conversation is not required by law is a roadblock for my purchase.
One reason we're making our platform is to reduce that necessity and be able to deliver that value to companies without ever speaking to us. Heck that "speaking" is also included in the cost of the product, and all those "engineer.days" add up pretty quickly, making our client list exclusively composed of behemoths who sometimes happen to have internal ML teams but just need more help, or because we happen to have expertise on a problem and they're inexperienced despite their size. One of our biggest frustrations is that we could not serve smaller organizations, and I'm not even talking mom & pop's or SMBs, but even some organizations that seem large shy away from this kind of projects even though they want to leverage data.
I find that these companies and products are targeting decision makers who do not consult with their teams and buy products nobody will use. They're targeting dysfunctional organizations which, I'll grant you that, may be a large enough segment to build a business around. Not my ideal to wake up and earn a living, though, but that's another matter.
This might be true but there are many engineers with decision making power. My pet hate (and a virtual guarantee of "no deal") is when I'm forced to talk to a sales person who is all hair-gel and swagger [1] who knows substantially less about their own product than I do.
The interesting thing here is that until I say "go" no one will "Schedule a demo" or "sales call" to them. While I will absolutely not do it for a fishy firm - and by putting something like that on the site they automatically get into "fishy firm position" - you would like to convince me with words instead of facts to buy your products and waste my time. No, thank you.
Show me the facts, and leave my mind to decide what it is, not lie to me what you think will make the sale. It is just a waste of my time.
In my experience the reason this is done is because customer acquisition is manual and the "schedule a demo" button is used for lead generation, and the reason it's all manual is because onboarding/support is high touch and you're not sure who the customers are yet.
Free demos are my nightmare. I really don't have that much time to split between fixing existing issues, adding critical features for paying customers, and supporting or troubleshooting for users that aren't paying anything. That's not to say at a point in the future the organization could have the capacity for a sick free trial, it's just that free trials cost money.
I dont like talking to sales people but I get where they are coming from. It might also be using the opportunity to do some discovery as to what people are using the platform for and who are those people.
But I agree that they should make provisions for people who just want to pay and get to business.
They might also want to massively price segment. Basically they don't want to quote you a price until they've got a feel for where your pain point is. If you're a whale, they want to reserve the right to bleed you dry by not preemptively quoting a lower sticker price way below your budget. But yeah, to me it still just screams "if you have to ask, you can't afford it".
>But yeah, to me it still just screams "if you have to ask, you can't afford it".
We're talking about buying product: I have at least to ensure the product does what I need it to do before even considering buying the product, and I can do that on my own. We're not talking about selling airplanes here, where there might be some setting up required for me to test the specs, neither are we talking about software targeted to governmental agencies or the intelligence community. We're talking about products that claim they do X for the knowledge worker, but fail to provide a way for a knowledge worker to test X.
This can be turned to: "If you have to talk to me before I could use or buy the product, something's fishy".
That's Theranos/Nikola hyping the product with claims it can do things but nobody ever saw it do that thing.
I get the price segmentation argument, though there may be better ways to extract more value by providing tailored services to large clients to solve problems only large clients have.
>It might also be using the opportunity to do some discovery as to what people are using the platform for and who are those people
The way we do that is giving people access to the platform, letting some time go by, then engaging the users and asking questions. We also have Slack channels in case they have problems.
Why we leave them alone: because I don't like it when someone immediately engages us asking us a bunch of questions when we start using something, or try and up-sell right when I'm discovering the product. I also don't like energetic chatbots popping up on different tabs of the same website, making all kinds of sounds wanting to get my attention to help me. Back off, I'll close that site and will not visit it again.
We give people time so we could at least observe what's broken. Did the person not start using the product immediately? Why? Was the user unsuccessful accomplishing a key task with a key feature of the product? Why? Is it a problem of discoverability, or is it just that it is not our target user? How can we improve that either way?
My main point is that this bottom up approach doesn't work as well as it could simply because of the difficulty of navigating purchasing processes. I know my team would have bought easily 5x what we did if we didn't have to invest 4 to 6 months in getting a vendor set up for each SaaS we wanted. It just wasn't worth the hassle.
Not to say this would have worked at your company, and not to say it's perfect, but I think the "HACK" of the bottom-up approach for software like JIRA or others is that it is priced in a way where you can get your team at a company using it and showing demonstrable value from using it on a free or very low-cost (AKA your personal credit card) tier.
Then, when you go to make it official, you have much more power in the negotiation.
If it's working well, making the "shadow IT" SaaS tool an official purchase typically goes:
Team Lead: Everyone is using this tool, we're about to go above the free tier and need to purchase it.
IT/Finance: You should have gone through the process, you need to fill out these forms.
VP/CEO (to IT/Finance, seeing value of tool): Just get it done
I think maybe I wasnt clear. No one tried to keep us from licensing anything. Pretty much any solution was fine with then assuming it wasn't a security nightmare.
> Just get it done
Getting it done is a process heavy, minimum 4 month process because of purchasing rules. That's the problem I'm calling out.
Whether it's IT or Finance (purchasing rules), CEO/VP have the power to force them to make an exception or change their process if there's a clear business benefit.
I'm talking about 10K+ global employee companies. No VP wants to listen to my problem licensing Jira. And prices changes like that happen on the scale of years.
Exactly. Then taking it a step further. GP at VC firm makes the round at their "portfolio" companies and see your product on every screen, or hearing about your product from every team they go to, and then wanting to speak with you because clearly someone is doing something right.
>My main point is that this bottom up approach doesn't work as well as it could simply because of the difficulty of navigating purchasing processes.
I may have been unclear. The "bottom up" approach is precisely designed to circumvent and solve the case where the user is not necessarily the buyer. It emerged to solve the "shrink-wrap software", or when you did not have an army of salespeople.
One way to look at it is "bringing SaaS to enterprise", which was typically the distribution model for consumer applications.
I don't really agree. I've sold software both independently and by hooking into the AWS marketplace to reuse existing billing channels. It really didn't make anything better even though using AWS as a single point of purchase sounds like a good idea. The enterprise software purchasing process is just a slow one and the actual billing mechanics aren't really the issue in my experience.
Plus delegating control of your payment relationship with your customers to a third party is more of a pain than a boon.
My CFO didn't care about the line items inside our $20,000/mo Heroku bill. What he did care about its size. When I told him we could save a lot of money by fostering a direct relationship with companies like Redis Labs, he was very receptive to making that happen.
My engineers could spend money on new pieces of third-party infrastructure pretty easily via Heroku plug-ins. If the spend got big we figured out how to address it.
For this dynamic to work for you as SaaS developer, you need enough runway to wait for your users to adopt your tech and have some fraction organically grow big enough to be real money.
This rhymes with how Intuit won the accounting market. They initially got destroyed in reviews when compared to their more mature yet complicated competition, but everyone starting a business wanted cheap and simple. You just need to be willing to wait for enough of your early garage-based startup customers to become S&P 500 companies. While you're waiting, you're also evolving your product so that it better meets your growing customers' needs.
Yeah, I've done enough fine dining in my professional career to know that "schedule a ..." means a low value product pumped up by dedicated sales.
Even if an actual product value exists after accounting for spin, the gated access means high training cost which in turn means vendor lock-in.
"Schedule a ..." ticks all the wrong boxes. Except for dinner, dinner is often quite good. In fact maybe they would get more traction with "schedule dinner."
If it's an important service it's not a big deal at all to speak to someone, and frankly, even though they do this for price discrimination, the fact is they can incredibly helpful and save you a boat load of time and effort trying to understand the product in many cases.
Yes, some things should 'just be self serve' but many things, not so much.
Well the job they have to do before I waste my time scheduling a meeting with your sales dude is 1) convince me that your product is valuable and 2) convince me that the ballpark pricing is workable for me.
You can really only know a car by test driving it. But that doesn't meant that Toyota doesn't publish photos of its interiors and asks you to schedule a test drive before finding out the price. I can quickly find out what cars might be suitable for my needs given their properties and their pricing, and THEN commit my time to test driving the best candidates. If you just say "Believe me. This is the best car. People are saying what a great car this is. This is a car that you'll come in and you'll test drive, and you'll say that you've never even seen a car this good." Well I'm just going to ignore you.
>the fact is they can incredibly helpful and save you a boat load of time and effort trying to understand the product in many cases.
I take having to explain what our product does to users as a failure on our part. We have the same mentality when we have to personally explain what code does to our colleagues. We take the necessary measures of using better abstractions, writing documentation and Wikis, simplifying code, and making efforts so that "failure demand" does not arise.
In terms of product, it's either our documentation sucks, or a problem of "affordances and signifiers", or a problem of targeting the "wrong" users.
One turn-off for us for machine learning platforms was going to the website, wanting to try the software, and then finding a button that says "Schedule a demo" or "Schedule a sales call". I want to try the software, not talk with your salespeople. I want to create an account, or request access to a demo account without speaking with someone. Then I want to be able to pay for it without speaking to someone. I have the proverbial, and sometimes literal, credit card in my hand: let me pay.
That weighed on our decision to make our own platform[0], because we simply don't like to buy things this way.
Again, there are differences with low-touch and high-touch software, and situations where the regulatory context or contract amounts require that at some point, people sit down together, but that's for particular cases and clients. We made custom machine learning products for large enterprise, so we sit a lot with clients, but the word "custom" is there.
Some content that goes into this is Slack's CEO discussing this with Yammer's former CEO[1]. Slack's CEO also discussed this in a Pando Monthly[2]: they didn't have a "sales" team, but sometimes needed to 'onboard' a large organization. He also addresses how raising $1B reassured many 'traditional' and 'sensitive' organizations into using Slack for internal communications.
- [0]: https://iko.ai
- [1]: https://www.youtube.com/watch?v=4NbXBGjUrA0
- [2]: https://www.youtube.com/watch?v=TbM1iOi33NY