Interesting! 25 business days for a business is close to 41 calendar days, too. I wonder if there's some sort of common, human constant involved. 25 days of engaging with something to decide whether that something is worth keeping around. Maybe the median relationship length is 25 days, too...
As a software dev I can say this is so true. A 14-day free trial is not free, it costs your time.
It takes a serious block of time to evaluate any product or service, maybe a few days. If I put a few days into an open source product and I like it I can just use it. If it is a paid product I'm going to have to go to my management, it might be easy or it might be hard, but I have to discount the gains from "I found a product I like" by the probability that "we won't buy it anyway" so that makes me all the more hesitant to complete a trial.
My team is responsible for the research, evaluation, approval, integration, and on-going support for each and every single platform that is within our stack. We have a lengthy standardized process for evaluation/scoring/approval and one of our mandates is a minimum of 30 days, no payment, and no Sharewaresque limitation in functionality. If we cannot get 30 days, it's a simple 'no,' and we move on to the next.
Even at 30 days, it's extremely stressful on the team to get the system up and running, ingest our test case data, and run our tests. This is after going through this process >100 times. There's simply no way to get everything that needs to be done with an evaluation of even basic coverage in less than 30. Full stop.
Lack of adequate understanding of the potential challenges an org is going to face during implementation and use is, IMO, the single biggest reason implementations run WAY OVER budget, time, and eventually fail at integration w/the rest of the org. This is entirely ignoring the required change management, which is another beast entirely.
It sounds like you're bragging about a dysfunctional way of working. If what your team is doing is valuable they should get any tools they like without much questions. Just like in any reasonable workplace. Because workers produce more and better when they have better tools.
You can also just buy the software to evaluate it. This way you have unlimited time to see if it fits or not. That's what people do in other industries.
Yeah it is a bit odd to say that the #1 requirement is that the software be free for 30 days, that would disqualify a bunch of critical infrastructure.
Sourcegraph is $99/u/m and has major network effects. For a moderately sized org this is quickly an entire developer salary.
Snyk is similarly priced, unfortunately “just buy” is a really easy way to:
a) pay more than something is woth
b) have multiple products doing the same thing. (for example, I have Miro and figjam and Mural in my company because each do something slightly better and teams have chosen the tools that work best).
That means we often double pay on licenses for ostensibly similar software.
Sourcegraph CEO here. It’s not $99/user/month anymore. It’s great that a lot of companies were willing to pay that, but we and our customers prefer a lower per-user price and a higher % of devs at the company using it (ideally 100%). We reduced prices for our customers (current and future). You can see the posted pricing at https://sourcegraph.com/pricing.
For any other dev tools companies, I’d strongly recommend having lower prices so that every dev at your customer can use it (if that’s relevant for your product). If you start seeing customers be really picky with who gets a license, it’s probably priced too high.
Off-topic, but I see you always responding very quickly whenever Sourcegraph is mentioned.
I was entertained a while back when I saw you getting accused for using sockpuppets, but am I correct in thinking that you're probably just using the API to monitor for name mentions?
Edit: To be clear, I think this is great and that more companies should do this.
Haha, yeah, @jdorfman's sibling comment mentions the tools we use. Any mentions on HN, Reddit, Twitter, YouTube, etc., show up in our team chat. The gold standard, of course, is Sid at GitLab ("GitLab CEO here" :).
Well, maybe a way to let workers try out better tools and not explode the budget /complexity of the tech stack is to give devs $500 / year to spend on whatever they want. It could be monitors, a new IDE, etc.... This way individuals can try out a new tool and if they really see itts value they could "sell" it to management.
$500 per year is a pathetically low amount for a dev who is expected to make his company hundreds of thousands or millions per year. Plumbers and HVAC specialists have tools worth tens of thousands of dollars.
But physical tools wear out when used professionally, so they are an ongoing cost. Not to mention all other material that are simply spent when used by people in physical businesses.
In my experience, I've only looked at new software when the text on the box says that it'll solve an issue we currently have, dramatically improve existing workflows, or specifically asked by someone else. If you're concerned about time, then maybe you (or your company) are doing it wrong. Depending on the size of your company, there should be a team of people assigned time to specifically evaluate theNewShiny whatever. If the product does not do what is advertised on the tin, then drop it and move on. If it does work as advertised, the team then evaluates next steps in how to utilize it. In this way, that research is already "budgeted" into employee's time.
Sounds like you need a first filter, and then only do your evaluation process on a given product if it solves a major pain point and even in that case, just evaluate the best/most common product in that category and only if it clearly doesn't work test another product.
You are not going to win as a startup by using Teams, even if it is cheaper than Slack+Zoom, you are going to win big or not at all and focusing on things that don't matter for the core success just means less time to make something people want.
And the time to evaluate for something you're releasing (vs staying in your control on SaaS) is significantly higher. Things that lock you in, especially between your released software and hosted services -- like authentication, installers/auto-update, and licensing (keygen) -- are even higher than that.
It's just really hard to "undo" these things, both technically and because of the optics (user experience). Requiring your users to re-license their software is friction -- it burns user trust and costs a lot of time in support.
14 days is just too short to evaluate if the product will even meet your needs, let alone evaluate how much lock-in there is and what the path away could look like.
Implementers failing to prioritize doing some legwork during the free trial period also costs time for the sales organization of the selling party.
From the sales side, if we see the prospect the finding a solution is a low enough priority that their engineers can’t spend time in two weeks to simply look at a solution, then they might not be an ideal fit for the product (they don’t enough business pain, don’t have a champion, and/or don’t have an economic buyer to prioritize the purchase of a solution).
This is of course highly dependent on the nature of the software and the ideal customer profile of that solution, but the fact that there’s two sides of this coin is something to keep in mind.
In many orgs, pain points are subtle, product evaluations happen on the back burner, and internal consensus on pulling the trigger might take months. These firms are left on the table by a demo/sales process that can only afford them two weeks.
And a trial need not take many sales resources. We can automate that with a demo download and self serve documentation. If it's an on prem demo, a 2 week or 12 week trial costs us the same - it's just a sign up and download. We don't actually need a sales rep to prod them about buying - the demo countdown does that, for people actually gaining value from the demo.
Let's acknowledge the article's evidence that longer trials can convert customers with lower pain points. Secure customers like to evaluate things without pressure. And they might be the majority of customers.
Let's enable this by building sales resilience, engineering the infrastructure painlessly delivery a longer trial that takes near zero sales or production effort.
The more so as the team is often small (one-person ops teams are probably the norm, at least by number of establishments), and workload is often already overwhelming.
New technology and/or products always come with unanticipated consequences and downsides. Expecting to make a decision on a major, or even minor tool isn't something that can be rushed.
One model I'd noted as innovative at the time was for a SAAS company to offer a free tier of service, in the case in mind, with limited data retention of a monitoring tool. That struck me as an exceedingly good way to balance the power of the tool (all other features were otherwise available), whilst also providing a clear and reasonable upgrade path to a paid subscription. When that company IPO'd and revealed its CoS (cost of sales), I was surprised to see how high it remained (on the order of 40--50% of revenues).
Selling (and buying) complex information goods is hard, whether that's software, services, consulting, news, or anything else. There's a copious literature on the production side addressing the zero marginal cost / high fixed costs predicament. There's less on the buy side, though Akerlof's "Market for Lemons" addresses this in part. Reducing uncertainty, increasing knowledge, and mitigating purchaser risk without needlessly offsetting revenues seem key to the issue.
I wonder if for a larger consumer product this would not work, as word gets around they can stay free for a long time. Though it seems to work for a lot of community software like makeMKV.
Nice write-up! This is a great example of throwing out "best practices" and being truly user/product-centred. Even down to your trial strategy.
It reminds me of YNAB's trial[^1] strategy of offering 34 days. It gives folks just enough time with their app and process. I wish YNAB's trial extended to ~60 days since my "ah ha!" moment was only around then. That's another conversation, though.
I imagine 34 days is so that you have enough to budget around an entire month. Would be shitty to setup a budget and not be able to follow it for a whole month.
Yeah, exactly. Their whole thing is to get ~30 days ahead, too. I think 60–90 days would be a better hook and almost guarantee an "ah ha" moment. Everyone I've spoken to that's had YANB "click" was in that time frame, myself included.
I wish I could see how a trial length change would affect their conversions.
I sell a JS/TS graphing library, so B2B, developer-to-developer.
We decided to just have an indefinite trial period (library has a watermark) and instead offer 30 days of free support. That way we can help people get started and realize their proof of concept, but if they want to start evaluating on their own time they can do so without worrying about any clock. This makes it much easier for customers who are trying to evaluate multiple options at once.
Thank you. I guess I should update that, since GoJS renders to SVG also if that's what you prefer (at a cost to performance of course)
Most of us who make such libraries tend to distinguish charting (time series, lines, bars) from graphing (nodes and links). Charting is, in many aspects, a much smaller problem space. Graphing requires a lot more in terms of layouts and interaction tools, grid snapping, guides, undo/redo, copy/paste, grouping, subgraphs, managing user permissions for interactivity, expand/collapse (both subgraphs and tree sections), updating the backing data when the graph is edited, etc.
It's very surprising to me that there is a market for this. But then again I have spent almost my entire professional programming career writing matlab. How does one even identify such a market? I am so curious, please share your story.
The extremely condensed story of my company (started ~1995 when I was a tiny child, I joined 2010, though now I am part owner) was a bunch of guys in an advanced research division of Digital, trying to make a visual programming language. After Digital went under they kept trying to do this, but no one wanted the language. People however were interested in the graphic tech used to make the language, so they turned that into a library, in the 1990s, called Go++ (Graph Objects for C++).
Then JGo (Java), GoDiagram (C#, WinForms and now Avalonia), GoXam (XAML/WPF C#), and GoJS.
I began GoJS as a greenfield project starting in 2010-2011 as a new grad by working with these guys who had been thinking about diagrams for years. So it had the advantage of being built from scratch (and using the brand new HTML Canvas surface) but with all the accumulated experience of their wisdom at hand any time there were design questions. In some sense I got really lucky to work on such a "brand new, but charted path" project. Not many new grads get that kind of experience...
When we released GoJS I was unsure if anyone would actually pay for JavaScript library. There weren't too many I could find in the space that weren't free (Sencha was one I found while doing research, and funny enough they tried to recruit me, flew me out to CA after I wrote a book about canvas circa 2013). But the problem space really truly is large, and you can save a year or more of development time by buying such a library, so the calculus is very worth it for many companies. Like so many people, what we sell is time, and having thought hard about these problems for so long, from layouts to really mundane undo/redo transactional stuff.
This is a key component for any good low/no code platform, process builders, workflow builders , process documentation and so on. And that is just one area.
It makes tons of sense to buy/use a library like this rather than build your own (unless that is your business).
We use one from antd. Antiquated and hard to automate testing. We are looking for a more modern solution.
How compatible is GoJS with web testing tools? Most seem to have trouble with canvas.
I would say "fairly annoying", alas! I never bothered to make Selenium etc examples, though I know some customers use it. You can switch to the SVG renderer for testing if you really want to inspect the DOM after doing actions, and some customers do this too. And you can mock events if you want to, we give some basic examples: https://gojs.net/latest/samples/Robot.html
But you have to inspect programmatically one way or another. What is easiest really depends on what, exactly, you want to test. Eg testing your permissions (can a user copy a node with these checkboxes in my app selected) can be done by trying to copy and seeing how many Parts exist before and after, etc.
Can I ask how large your library can scale to? We have digraphs in the range of tens to hundreds of thousands of nodes, and every tool I've tried falls over. The layered digraph example from your site seems to hang forever at 10k, but that could just be how the example widget is set up.
we have some niche performance examples like this (WARNING slightly epileptic) https://gojs.net/extras/10000parts.html, but most of those are for internal testing and not too useful for customers.
They're data-dependence graphs for a neural-network scheduling problem. Like this but way bigger to start with and then lowered to more detailed representations several times: https://netron.app/?url=https://github.com/onnx/models/raw/m... My home-grown layout engine can handle the 12k nodes for llama2 in its highest-level form in 20s or so, but its not the most featureful, and they only get bigger from there. So I always have an eye out for potential tools.
You can make it a business to build and license a JavaScript calendar widget. Many companies would rather buy such a library than have their developers pick something FOSS or develop on their own.
Time limited trials are always a feels-bad moment for me, an extra deadline I now have to plan around.
Another option I like is providing some amount of free credit that doesn't expire. So you're not on the hook for providing a "free tier" forever, but users can play around with your service at their own pace.
This is what I am doing (business to consumer) and I am quite happy with it. I am maybe a bit too generous with the free credits (many people can use the service lightly for over a year on the trial) but I like that they get the exact experience as if they were paying and they can pause and resume their trial with no extra complexity on my end. Just sign up and you get some starting credits. Then you can just buy more as you need them. I think it makes things simpler and avoids any sort of pressure.
Sometimes there's a shifting business priority, and guess which wins when the choice is "important customer X is on fire" vs "our developer trial for wizbang component xyz is going to expire in 8 days".
I also don't mind something like '30 days' or '60 days', but it only counts the days when you open the application.
Like a few weeks ago I was motivated to learn some music production software, so I downloaded a few trial versions. I worked on it heavily for a few days, but then got busy with other things, and now that 30 day trial or whatever is coming up to an end, but I still don't feel like I've had a chance to decide if it works for me, because I haven't been actively using it that long yet still. I do plan to go back to it, just maybe not for another week or two.
But if it only counted the days I opened the application, I'd still have like 26 'days' left to evaluate them (they might, I haven't checked), and it'd be no big deal, and I wouldn't have to feel all stressed out because I'm 'wasting' the demo time by actually having a life and maybe badly timing when to trigger the trial period.
This has happened time and time again with B2B systems - I sign up for a trial, begin poking it, and then work happens and by the time I go back the trial is dead.
Time-based free trials are fine for one-time purchases I think. It's basically the equivalent of a return window, without collecting money upfront.
Where they don't make sense is for subscriptions, because subscriptions are by definition something your users will be using for a long time, and it might take them a while to realize all of its value and get hooked.
For this stuff a free tier that funnels customers to the paid tiers usually works best. You can play with limitations by restricting features, or usage, or anything else, but you probably shouldn't restrict them based on how much time has elapsed since they first signed up. Let them get hooked at their own pace.
I get the sense that a 2 month trial would have been a better option (41 days + buffer). It provides clients with the required amount of time to get up and running while also time boxing them and applying some pressure on them to commit.
An unlimited free trial falls into the same trap of customers leaving until they're "ready" to integrate, time boxing it sort of forces them to commit to the integration at some point.
I don't think it would make a considerable difference. Not mentioned in the post, but I have a limited unlimited free trial. Taking into account the usage limits, it's not useful for a production deployment so it applies pressure once integrated. That way I only apply pressure to those that actually integrated.
If I were to do a timed trial again, it'd apply pressure to evaluate and plan the integration right now, and the product may not even be at the stage where they're ready to do that yet i.e. still in dev. This needlessly applies friction, which I want to avoid doing until they're ready.
I could certainly be abnormal, but I'm much more likely to sign up for something that has a real free tier. There's honestly very little difference to me between 60-day free trial and just having to pay from the start, I know that once I do the work to integrate then I'm committing to having to pay. At least for a startup with little revenue and little cash, 60 days is just too soon to commit to having to pay, unless it's like $10/mo.
What's worked better for me is the "startup scholarship" that a lot of companies are doing now. A year is far enough away that we'll either be out of business or have the cash to pay, and I don't need to worry that I'm getting my money's worth by the time the 60-day trial ends.
I'm a big fan of Posthog right now because they have both a generous free tier & a generous startup scholarship. I've moved a ton of stuff to their platform.
A lot of it probably depends on your product though. If you're solving a very targeted problem then you might not be able to create a reasonable free tier. But a lot of B2B tech stuff is like... sure you can charge a bunch of users $5 apiece, but you risk missing the signup of the one user that was going to pay you $10k. Anything with usage-based pricing is going to have Pareto distributed revenue and you need to do everything you can to make sure you're capturing those customers on the tail.
> There's honestly very little difference to me between 60-day free trial and just having to pay from the start, I know that once I do the work to integrate then I'm committing to having to pay.
Yep. That's the problem with timed free trials. It applies pressure to sign up only within your magical goldilocks timeframe, otherwise you'll likely bounce because you're not ready to start your 14/30/41/60/etc. day eval.
It seems obvious that the conversion rate was higher among people who wanted extensions, because the people who don't are the ones who already decided not to use it; rarely are people going to turn down more free time to use something and rush to ask to be allowed to pay for it (though it does happen- I've been part of procurements that were being rushed to use an existing FY budget, for instance).
Another thing you need to work out, imo, is what level of *feature use* in your application best maps to conversions, and from there, how can you improve the likelihood of people seeing the benefits of that feature use.
As an example, my current company's app can be used with or without agent deployments, and we saw that trials that deployed agents- even just one-off ones in lab envs- converted at a far higher rate than non-agent trials.
So we worked to lower the perceived barrier of entry that agent deployments posed, which meant more people seeing the increased usefulness they provided, which meant more conversions.
> It seems obvious that the conversion rate was higher among people who wanted extensions, because the people who don't are the ones who already decided not to
use it
Yeah, exactly! Those two groups are not the same, there's an obvious selection effect there.
I think you misunderstood, or maybe I wasn't clear in my post. This wasn't an experiment on 2 separate groups; this was an experiment on the same group: those that convert from trial to paid. When I did X, conversion rate for the entire group increased, i.e. I made more money. If I stopped X, I'd make less money. That then lead me to the point of the post -- the % difference in conversion rate were the people who weren't actually ready but signed up for a trial anyways, only to run out of time and never come back.
You're assuming that the percentage increase in conversions after you extended or removed the trial timeout period across the board corresponds to users who previously would have been kicked out by the trial expiry before they could see the value in converting.
My comment was referring to the period you mentioned where you were offering people manual extensions, and you noted that you saw more conversions among that group than among users who didn't extend their trials.
That's right. I acknowledged that that increase in that comparison was likely biased since those people would also add a card, which increases conversion rate in itself (but also weeds out those that are uncommitted). But that doesn't change the fact that overall conversion rates were higher when I went out and manually offered extended trials.
Even 30 days is useless for me with my schedule on some items. Some of the optimization solvers are annoying that way if you're trying to get a proof of concept together to get management buy-in, but it'll take a lot of development to get there. You can use one of the generic libraries that abstracts away the solver (where you can plug most vendors in) and start with an open source option, but it's an annoying approach if I think there's a strong chance we'll end up with a particular vendor as I'd want to use their native API and avoid the additional abstraction layer.
I totally understand why it makes sense to the business, it's just hard to work it in to my schedule.
Another thing for these companies to think about is a potential customer is investing their own time in learning your product. They may not act on it right away, but I've been in situations where we had an "oh crap" moment and I was able to say go get product X, I know it works on our data sets and already have example scripts for how we can use it and the vendor indicated a price of Y last year which is like 1/5 the cost this other vendor just quoted you to start implementing this from scratch. Allowing employees some creativity to scratch that itch seems to constantly pay off in my experience as long as they're still being successful at their main job.
a software i paid for 10 years ago recently got bought by another company.
they immediately added bs "features" like dark theme, changed to subscription model with 1 year sub price 3x what i paid to buy it outright, and reduced trial from 30 to 12 days
piracy is the only true form of digital ownership.
They want me to pay a subscription, but as long as Windows will still open CS6, I'll keep using it. It still gets the job done for me, even though I wouldn't mind some of the newer features (some of my annoyances I know they've improved in the new version) and probably would have paid for an upgrade by now if it wasn't all subscription models now.
And hopefully by the time it stops working, another non-subscription option for Illustrator that I don't hate will be available.
I didn't like Affinity or Inkscape when I tried them (I even bought Affinity on a sale in order to try it, so I own it). Affinity also had issues importing my CS6 Illustrator files, IIRC, and since I have hundreds of those for various board game designs of mine that I still go back to and rework when I have a new idea for them, the fact that it couldn't play nice with them made it pretty much a nonstarter.
It's been a while since I've used Inkscape, but I remember it feeling clunky and buggy for me, and I had difficulty getting into the workflow.
I'm sure I could probably force myself to get used to, and probably enjoy alternatives, but the more I invest in these proprietary alternatives, the harder it will be to shift anything back to Illustrator if I need to, especially since I don't think any of them bother to output to a CS6 friendly file format anymore, so I can shift to them, but I can't easily shift out of them.
And at this point Illustrator CS6 is just dead simple for me, I don't have to think about where anything is, I know exactly what I need to do for like 98% of what I want to do on it, and most of it is muscle memory, I can whip up some cards in a few hours while watching TV shows in the background.
It's going to take something significant (like it no longer working) to motivate me enough to upgrade. I know I'm playing with fire a bit, since these files are getting more and more out of date, and may not import nicely into even the subscription Adobe Illustrator at some point, but I already have too much other shit I have to learn all the time for my day job, I don't have much left outside of that (maybe eventually I will. I am starting to learn Logic Pro and Ableton Live for making music finally, and for the longest time I only used FLStudio).
That's a cool graphic though. I'll download it for future reference. Also it'll be easier for me to convert for other Adobe products, like I mostly use Paint.NET instead of Photoshop nowadays, for example. Illustrator is the main one I feel I have to stick with. Also Flash, since it doesn't exist in any newer ones (I used to make Flash games, so if I want to open those FLA files again, I need it).
I'd say this is about correct... my new Toyota came with 3 months of free satelite radio, and it was at about 2 months casual usage that I decided "I'm going to actually sign up" [after having enough time to explore multiple channels].
Had it only been "1 month free" I would not have explored enough to sign up.
Just last week, I abandoned a 7-day trial of some project management software because it was not enough time for me to feel comfy with it. Would have preferred a week or two more, even if features were somehow nerfed (watermarks, etc).
I develop barcode and label design software. My app is immediately usable after download, but it will print a watermark when not licensed. Users can start a 14 day free trial to remove the watermark. Since it’s a desktop app, each trial is locked to that one computer. I can keep track of which computers register for a trial and limit the duration for subsequent re-registrations. It’s all based on JWT.
The author does a really good job of describing the tension between the customer’s readiness and the vendor’s need to move leads through the pipeline as fast as possible:
> What I was really asking potential customers to do was wait.
> Wait until they're ready to start understanding the API.
> Wait until they're ready to go through onboarding.
> Wait until the PoC is planned.
> …
> What ends up happening is that people get busy and they end up seeing that 14 day deadline, determine that they're not ready yet, so they bounce until they are ready, but then they never come back.
> I decided that I needed to remove that friction. I wanted to capture these leads as soon as they decide Keygen may be the solution for them. So ultimately, I can start nurturing these leads.
I’d love to hear more about what “nurturing” looks like.
In B2B sales something that can happen with extension of free trials is that companies doing window shopping, doing competitive analysis, or who aren’t motivated to find a solution to an immediate need (don’t fit the ideal customer profile) and essentially don’t intend to buy will do half-hearted integration and extend trials. It’s a runaround which ends up costing your sales organization valuable time and effort.
Usually it’s just a matter of the implementers on the prospect side not prioritizing the effort.
A free trial should usually be followed by a proof of value where both parties are committed to implementing the solution in a realistic way with the expectation of a signed contract if the proof of value delivers on the customer requirements.
This could be something to be careful of if that applies to you.
Have you read the article? It's not clickbait, it literally goes on to explain it, and it's only a couple paragraphs. I honestly don't see the issue, and the fact that the author acknowledged a potential question is IMO a good thing.
If this were really the justification, there are almost always better ways to do it. ("If you're wondering about X, see section N". Or just link to it.)
Like other dark patterns, there times when this sort of thing can make sense, but in practice it's usually done (consciously or not) to get the reader to read more than they would otherwise.
I don't think so. The author is acknowledging that there is a very obvious question they need to answer and doesn't want to leave the reader in doubt about whether they will answer it, but wants to finish making a different point first.
It's almost the opposite of reader-hostile.
Don’t do limited time trials. Please. A limited trial means I’m going to have a worse dev experience with deadlines, activation or loss of functionality. Having a time limited trial or even a requirement to submit an email in order to try something is a big turnoff when evaluating a product.
Just make the product free for non commercial use (including a trial in a commercial setting). If I need support or want to buy something please let me contact support or sales. I don’t want an automated email from Jeff at Randomcorp asking me how my trial is going. If a trial has to take 30 days or 365, just let me finish.
If I sign up on Monday, I might not even look at the API docs until Friday. Assume the week after that I personally like it, if I'm at a bigger company I'm probably going to spend a month or two just getting approval to expense it.
Agreed. I have usage limits (e.g. 100 active users), as well as a hard limit of 2k API requests a day for the free tier. This provides freedom i.r.t. PoCs but restricts production usage.
And if the user indefinitely uses the service within the free tier, they are not the target customer anyway - so count the infinitesimal usage as evangelization !
Hey SaaS. Here's what I want from you (re: sign-ups):
1. Show me your price, with multiple pricing tiers. The more tiers you have, the more likely I am going to pick one of them, because I will think "well this lower tier is quite the deal compared to the higher tiers!". If I am an Enterprise customer, I will disregard you as an option if I can't see a price. Don't even show me the tier at all if you aren't going to show me your price. I get immediately incensed when I see that "Contact us for pricing!" bullshit, because I know how much bullshit I am in for if I just want to get a quote, so I look for somebody else. I want to use your product right now. But I'm not going to use it if I think it will be painful to work with your company, or that you might have exorbitant pricing, or you're just looking for whales. Don't make me discount you.
2. Let me use your product, immediately. Let me run it from my laptop immediately. Let me spin up a PoC. Show me your complete reference docs immediately. Show me a toy implementation w/source. I want to know if this will [eventually] give me what I want, within 15 minutes. Do that and you will already have gone above and beyond 95% of SaaS (in my mind).
3. Let me have gradient pricing. Let me sign up right away and start using your product for $0, for 5 users. Send me an e-mail when I have 7 users, informing me that I have 30 days to either reduce the number of users to 5, or it will automatically upgrade my account and charge me more (or make me confirm, or whatever). Same for the next tier, etc. (or 'pre-purchase' discounts vs 'on-demand' overage cost, etc) This gives me flexibility: I know our workflows won't just stop working when we hit a limit, and I can acquiesce to the new price or clean up old users.
4. Let me start using your product without a card on file. Sometimes it takes a while to find the right corporate person with the right corp card (if they even let me use a corp card, rather than invoicing). If you really need a card, give me 15-30 days, and then pause my account if you have to. The point is to let me get "hooked" on your product without needing to figure out which card to use first. (It goes without saying that when the card expires or a charge doesn't go through, give me 30 days to resolve it, because usually the corp card has hit its limit)
So it's interesting. Everything you ask for here is something I, personally, as an independent wanna-get-my-hands-dirty nerd, would ask for too. I totally get where you're coming from.
But the thing is - the reason large companies often don't give folks like you and me these things is becuase there are proven reasons to do the contrary that actually end up making them more money. It sucks, but it's reality.
1. "Call us" pricing works because for big enterprise deals (4-7+ figures), there's often some serious negotiation involved and if you just show a sticker price up front, you risk a) scaring the buyer because the price is too high, b) losing the buyer because your competitor will just negotiate a better price than your listed price or b) leave yourself no room to negotiate if you really put your best price on the website.
2. Offering immediate free trials where you can jump in right away is the ideal world for nerds -- again, I love it personally. But software is often complex, and a guided demo/implementation is often the best path to make sure your buyers are actually successful. Otherwise you risk a lot of folks who sign up, jump in, have no idea what they're doing, and then abandon the trial immediately and go to a competitor who held their hand.
3. "Let me sign up right away and start using your product for $0..." If only offering Freemium were so simple. You will immediately have to deal with porn (it's always porn - and often kiddie porn. These people will figure out incredibly creative ways to use your SaaS product to host illegal content one way or another), spam, fraud, customer service issues, etc. There are many valid reasons to offer Freemium. There are many valid reasons not to do so. It's just not so simple.
4. Again, think about the flip side here. Lower friction to sign-ups without a card, but SO much hassle when it comes time to pay -- now you have to nag, bug, etc. to get payment, and then you have to delete accounts that are dormant. And you have much lower buying intent signals, etc. etc. etc.
I wish the world of software catered to folks like us, but I fully and completely understand why it doesn't.
Indeed many of these "complaints" are explicitly designed to filter out high-maintenance, needy, and stingy customers, leaving you with the people who are more than happy to say "shut up and take my money."
> 1. "Call us" pricing works because for big enterprise deals (4-7+ figures), there's often some serious negotiation involved and if you just show a sticker price up front, you risk a) scaring the buyer because the price is too high, b) losing the buyer because your competitor will just negotiate a better price than your listed price or b) leave yourself no room to negotiate if you really put your best price on the website.
I'd disagree and say this can go either way. As an enterprise buyer I know both MY budget and that all numbers are negotiable - to some extent. If you show me that this product costs $100k and my budget is $80k, I'll still talk to you. But if you list $100k and all I've got is $25k for the budget, yes, I'm going elsewhere.
Now you might argue "We can make something work" I'm concerned. You'll do 80% off deal? Clearly you don't think your product is worth what you list so... now I don't think so either. And the "But We've got a tier for that" then list it.
My time is way valuable to me. I do not want to go through 3 screening calls, a shit ton of hoops, and a 2 week wait... just to find out that your product is way too expensive for my budget. Especially when getting into those sales calls where the reps wanna play coy and say "Well whats your budget" or "Well it really depends, we want to get into a POC bla bla bla to understand your useless before providing a pricing". Ain't no one got time for that shit. Give me the MSRP up front (with the understanding that a deal may be reachable if it's a little much) or I'm walking.
Keep in mind that when I'm pricing your product I'm probably pricing 3 to 5 others. There is literally not enough hours left in my life to give each and every vendor a 5 hours of time in order to get a price.
Fortunately the world is shifting. You know who's pricing is available on their website? Salesforce. Okta. OneLogin. Ping. Slack. Github. Gitlab. AWS. Google. Microsoft (for some). Elastic. Tailscale. Adobe. Databricks. Datadog. Cloudflare. Zoom. ... The list goes on. In other words there are a lot of companies out there with their prices available on their website right this second. Sure, almost everyone of them has a "Enterprise call us for pricing" option and that's fine, as long as you've got something for me to start with.
If you're a software vendor and don't have some prices to start with, you're at a major disadvantage. Because your competitors often do. And price is not the only thing buyers are looking for. If it was, Okta would have no business. You can look at their prices and OneLogin and Ping's (and Azure AD and Google). The entire IAM/SSO space has their prices right out front and Okta is... the most expensive. Yet somehow they all still are selling.
To add to this: I have been in the position to push for a 6-7 figure investment in a product, and have passed on companies, because they made it so insanely frustrating just to give them my money, let alone get a quote. Meeting after meeting, powerpoint after powerpoint. Some had literally zero way to pay, even for a lower tier, so there was no way I could try out the product at all. We skipped them all. You know what we did go with? A hodge-podge of AWS services, with on-demand pricing, that definitely was more expensive than the SaaS and took us more time and manpower to get working. It wasn't a niche solution, either.
Often we don't need the whole company to be locked into whatever the Enterprise feature is. Maybe we only need a single feature, and that has a given dollar value for us, and for the provider.
SSO for example costs the provider almost nothing in terms of compute/network, and little in terms of development and support; so why not let people pay a-la-carte for SSO? Cheap enough to be worth it, not so expensive as to be a turn-off. You could have one bulk price for SSO, or even charge per authenticated user! The point is to make it flexible, but still extract some money for that feature that hardly costs you anything to support.
Another example: let them have complex IAM (groups, roles, etc) for one price, and SSO costs extra. OR they can call to negotiate. This way they can pay now a-la-carte, or they can try to get a better price, or they can just settle for not using the feature. But it gets them on your platform, giving you money, in some form or another. Add up all the a-la-carte features and you get a bloated quote, but you can offer discounts for package deals.
You're dead on with all of this. To add to your point, the worst and most regrettable software product my company uses would have been immediately exposed as non-viable had I been allowed to get my hands dirty and run a couple of test cases. As it was, the sales-person "yada-yada'd" my technical questions (more fool me, yes, but I didn't know enough about their internals - the primary cause of our discontent stems from a truly stupid database-design decision) and so I lacked the context to make an informed decision. (I'm more experienced and more suspicious now; I don't think I'd make the same mistake again.) You can add borderline-fraudulent sales practice and avoiding discovery of truly bad products to the list.
What you say is true, but it’s because their pricing is deliberately complex and they’re performing yield maximization. I get that. However, it feels more like a new car negotiation that wastes everyone’s time. If you’re willing to accept X price at Y volume, just say that. If you offer discounts at certain tiers, provide those tiers.
Mutual Fund companies do it, and successfully, even if you’re only signing a letter of intent and aren’t buying at the higher tier today.
The charade involving salespeople, and let-me-talk-to-my-manager isn’t as productive as it seems. I’ve walked from several vendors (or discounted them in an RFP) due to that behavior.
High pressure time offers that are only known after signing up kind of stink too.
I've never used Uber in my life but I'll be traveling internationally next month for the first time so I figured it wouldn't hurt to install Uber now to get a feel for what the UI is like.
As soon as I signed up Uber was like, hey we'll give you 50% off your 4th ride if you complete 3 rides within 14 days. I won't even be traveling by the time the offer runs out. All this does is make me feel like I made a mistake for signing up too early without knowing anything was going to happen.
On the bright side Uber now has the right country set for you. I signed up in Belgium and Uber is now convinced that's where I am based for all of time.
Uber goes nuts with offer notifications until you find the page to turn ALL of them off (quite a few, and broken out by category like Uber Eats vs Uber). The overall app is good enough, it's just a unfortunately spammy.
As a ridiculous example: I took an Uber from an office to the Indianapolis airport then an Uber from the Dallas airport to a hotel for the night. As I'm winding down for the night I get a notification from Uber: "Need a ride back to ${indianapolisOffice}?".
237 comments
[ 2.8 ms ] story [ 241 ms ] threadFor consumer stuff my experience was closer to 25, but for businesses it was 41.
It takes a serious block of time to evaluate any product or service, maybe a few days. If I put a few days into an open source product and I like it I can just use it. If it is a paid product I'm going to have to go to my management, it might be easy or it might be hard, but I have to discount the gains from "I found a product I like" by the probability that "we won't buy it anyway" so that makes me all the more hesitant to complete a trial.
Even at 30 days, it's extremely stressful on the team to get the system up and running, ingest our test case data, and run our tests. This is after going through this process >100 times. There's simply no way to get everything that needs to be done with an evaluation of even basic coverage in less than 30. Full stop.
Lack of adequate understanding of the potential challenges an org is going to face during implementation and use is, IMO, the single biggest reason implementations run WAY OVER budget, time, and eventually fail at integration w/the rest of the org. This is entirely ignoring the required change management, which is another beast entirely.
You can also just buy the software to evaluate it. This way you have unlimited time to see if it fits or not. That's what people do in other industries.
Sourcegraph is $99/u/m and has major network effects. For a moderately sized org this is quickly an entire developer salary.
Snyk is similarly priced, unfortunately “just buy” is a really easy way to:
a) pay more than something is woth
b) have multiple products doing the same thing. (for example, I have Miro and figjam and Mural in my company because each do something slightly better and teams have chosen the tools that work best).
That means we often double pay on licenses for ostensibly similar software.
For any other dev tools companies, I’d strongly recommend having lower prices so that every dev at your customer can use it (if that’s relevant for your product). If you start seeing customers be really picky with who gets a license, it’s probably priced too high.
I was entertained a while back when I saw you getting accused for using sockpuppets, but am I correct in thinking that you're probably just using the API to monitor for name mentions?
Edit: To be clear, I think this is great and that more companies should do this.
B) You can buy software and evaluate and decide not to use it and cancel the license.
> Plumbers and HVAC specialists have tools worth tens of thousands of dollars.
And how many of their tools are annual subscriptions? And do their tools have residual value e.g. sell the business as a whole?
But physical tools wear out when used professionally, so they are an ongoing cost. Not to mention all other material that are simply spent when used by people in physical businesses.
You are not going to win as a startup by using Teams, even if it is cheaper than Slack+Zoom, you are going to win big or not at all and focusing on things that don't matter for the core success just means less time to make something people want.
It's just really hard to "undo" these things, both technically and because of the optics (user experience). Requiring your users to re-license their software is friction -- it burns user trust and costs a lot of time in support.
14 days is just too short to evaluate if the product will even meet your needs, let alone evaluate how much lock-in there is and what the path away could look like.
From the sales side, if we see the prospect the finding a solution is a low enough priority that their engineers can’t spend time in two weeks to simply look at a solution, then they might not be an ideal fit for the product (they don’t enough business pain, don’t have a champion, and/or don’t have an economic buyer to prioritize the purchase of a solution).
This is of course highly dependent on the nature of the software and the ideal customer profile of that solution, but the fact that there’s two sides of this coin is something to keep in mind.
And a trial need not take many sales resources. We can automate that with a demo download and self serve documentation. If it's an on prem demo, a 2 week or 12 week trial costs us the same - it's just a sign up and download. We don't actually need a sales rep to prod them about buying - the demo countdown does that, for people actually gaining value from the demo.
Let's acknowledge the article's evidence that longer trials can convert customers with lower pain points. Secure customers like to evaluate things without pressure. And they might be the majority of customers.
Let's enable this by building sales resilience, engineering the infrastructure painlessly delivery a longer trial that takes near zero sales or production effort.
Even if your sales team spends zero time on them they are the kind of customer that will end up losing money for the company.
This whole thought process is how we get money-losing companies with revenue growth rather than sustainable businesses.
The focus is on closing as many deals as possible rather than selectively engaging with the most profitable customer use cases.
The more so as the team is often small (one-person ops teams are probably the norm, at least by number of establishments), and workload is often already overwhelming.
New technology and/or products always come with unanticipated consequences and downsides. Expecting to make a decision on a major, or even minor tool isn't something that can be rushed.
One model I'd noted as innovative at the time was for a SAAS company to offer a free tier of service, in the case in mind, with limited data retention of a monitoring tool. That struck me as an exceedingly good way to balance the power of the tool (all other features were otherwise available), whilst also providing a clear and reasonable upgrade path to a paid subscription. When that company IPO'd and revealed its CoS (cost of sales), I was surprised to see how high it remained (on the order of 40--50% of revenues).
Selling (and buying) complex information goods is hard, whether that's software, services, consulting, news, or anything else. There's a copious literature on the production side addressing the zero marginal cost / high fixed costs predicament. There's less on the buy side, though Akerlof's "Market for Lemons" addresses this in part. Reducing uncertainty, increasing knowledge, and mitigating purchaser risk without needlessly offsetting revenues seem key to the issue.
It reminds me of YNAB's trial[^1] strategy of offering 34 days. It gives folks just enough time with their app and process. I wish YNAB's trial extended to ~60 days since my "ah ha!" moment was only around then. That's another conversation, though.
^1: https://www.ynab.com/sign-up
I wish I could see how a trial length change would affect their conversions.
We decided to just have an indefinite trial period (library has a watermark) and instead offer 30 days of free support. That way we can help people get started and realize their proof of concept, but if they want to start evaluating on their own time they can do so without worrying about any clock. This makes it much easier for customers who are trying to evaluate multiple options at once.
https://news.ycombinator.com/user?id=simonsarris
which says:
I make GoJS, a powerful canvas-based diagramming library:
http://gojs.net/
Which is not what I think of a graphing (time series, x-y points joined by lines), but otherwise seems relevant to their comment.
Most of us who make such libraries tend to distinguish charting (time series, lines, bars) from graphing (nodes and links). Charting is, in many aspects, a much smaller problem space. Graphing requires a lot more in terms of layouts and interaction tools, grid snapping, guides, undo/redo, copy/paste, grouping, subgraphs, managing user permissions for interactivity, expand/collapse (both subgraphs and tree sections), updating the backing data when the graph is edited, etc.
Then JGo (Java), GoDiagram (C#, WinForms and now Avalonia), GoXam (XAML/WPF C#), and GoJS.
I began GoJS as a greenfield project starting in 2010-2011 as a new grad by working with these guys who had been thinking about diagrams for years. So it had the advantage of being built from scratch (and using the brand new HTML Canvas surface) but with all the accumulated experience of their wisdom at hand any time there were design questions. In some sense I got really lucky to work on such a "brand new, but charted path" project. Not many new grads get that kind of experience...
When we released GoJS I was unsure if anyone would actually pay for JavaScript library. There weren't too many I could find in the space that weren't free (Sencha was one I found while doing research, and funny enough they tried to recruit me, flew me out to CA after I wrote a book about canvas circa 2013). But the problem space really truly is large, and you can save a year or more of development time by buying such a library, so the calculus is very worth it for many companies. Like so many people, what we sell is time, and having thought hard about these problems for so long, from layouts to really mundane undo/redo transactional stuff.
This is a key component for any good low/no code platform, process builders, workflow builders , process documentation and so on. And that is just one area.
It makes tons of sense to buy/use a library like this rather than build your own (unless that is your business). We use one from antd. Antiquated and hard to automate testing. We are looking for a more modern solution.
How compatible is GoJS with web testing tools? Most seem to have trouble with canvas.
But you have to inspect programmatically one way or another. What is easiest really depends on what, exactly, you want to test. Eg testing your permissions (can a user copy a node with these checkboxes in my app selected) can be done by trying to copy and seeing how many Parts exist before and after, etc.
Layered Digraph is by far the slowest layout. In general as you get past ~5k nodes you should consider all of https://gojs.net/latest/intro/performance.html
we have some niche performance examples like this (WARNING slightly epileptic) https://gojs.net/extras/10000parts.html, but most of those are for internal testing and not too useful for customers.
Another option I like is providing some amount of free credit that doesn't expire. So you're not on the hook for providing a "free tier" forever, but users can play around with your service at their own pace.
Sometimes there's a shifting business priority, and guess which wins when the choice is "important customer X is on fire" vs "our developer trial for wizbang component xyz is going to expire in 8 days".
Like a few weeks ago I was motivated to learn some music production software, so I downloaded a few trial versions. I worked on it heavily for a few days, but then got busy with other things, and now that 30 day trial or whatever is coming up to an end, but I still don't feel like I've had a chance to decide if it works for me, because I haven't been actively using it that long yet still. I do plan to go back to it, just maybe not for another week or two.
But if it only counted the days I opened the application, I'd still have like 26 'days' left to evaluate them (they might, I haven't checked), and it'd be no big deal, and I wouldn't have to feel all stressed out because I'm 'wasting' the demo time by actually having a life and maybe badly timing when to trigger the trial period.
Where they don't make sense is for subscriptions, because subscriptions are by definition something your users will be using for a long time, and it might take them a while to realize all of its value and get hooked.
For this stuff a free tier that funnels customers to the paid tiers usually works best. You can play with limitations by restricting features, or usage, or anything else, but you probably shouldn't restrict them based on how much time has elapsed since they first signed up. Let them get hooked at their own pace.
An unlimited free trial falls into the same trap of customers leaving until they're "ready" to integrate, time boxing it sort of forces them to commit to the integration at some point.
If I were to do a timed trial again, it'd apply pressure to evaluate and plan the integration right now, and the product may not even be at the stage where they're ready to do that yet i.e. still in dev. This needlessly applies friction, which I want to avoid doing until they're ready.
What's worked better for me is the "startup scholarship" that a lot of companies are doing now. A year is far enough away that we'll either be out of business or have the cash to pay, and I don't need to worry that I'm getting my money's worth by the time the 60-day trial ends.
I'm a big fan of Posthog right now because they have both a generous free tier & a generous startup scholarship. I've moved a ton of stuff to their platform.
A lot of it probably depends on your product though. If you're solving a very targeted problem then you might not be able to create a reasonable free tier. But a lot of B2B tech stuff is like... sure you can charge a bunch of users $5 apiece, but you risk missing the signup of the one user that was going to pay you $10k. Anything with usage-based pricing is going to have Pareto distributed revenue and you need to do everything you can to make sure you're capturing those customers on the tail.
Yep. That's the problem with timed free trials. It applies pressure to sign up only within your magical goldilocks timeframe, otherwise you'll likely bounce because you're not ready to start your 14/30/41/60/etc. day eval.
Another thing you need to work out, imo, is what level of *feature use* in your application best maps to conversions, and from there, how can you improve the likelihood of people seeing the benefits of that feature use.
As an example, my current company's app can be used with or without agent deployments, and we saw that trials that deployed agents- even just one-off ones in lab envs- converted at a far higher rate than non-agent trials.
So we worked to lower the perceived barrier of entry that agent deployments posed, which meant more people seeing the increased usefulness they provided, which meant more conversions.
Yeah, exactly! Those two groups are not the same, there's an obvious selection effect there.
You're assuming that the percentage increase in conversions after you extended or removed the trial timeout period across the board corresponds to users who previously would have been kicked out by the trial expiry before they could see the value in converting.
My comment was referring to the period you mentioned where you were offering people manual extensions, and you noted that you saw more conversions among that group than among users who didn't extend their trials.
I totally understand why it makes sense to the business, it's just hard to work it in to my schedule.
Another thing for these companies to think about is a potential customer is investing their own time in learning your product. They may not act on it right away, but I've been in situations where we had an "oh crap" moment and I was able to say go get product X, I know it works on our data sets and already have example scripts for how we can use it and the vendor indicated a price of Y last year which is like 1/5 the cost this other vendor just quoted you to start implementing this from scratch. Allowing employees some creativity to scratch that itch seems to constantly pay off in my experience as long as they're still being successful at their main job.
they immediately added bs "features" like dark theme, changed to subscription model with 1 year sub price 3x what i paid to buy it outright, and reduced trial from 30 to 12 days
piracy is the only true form of digital ownership.
They want me to pay a subscription, but as long as Windows will still open CS6, I'll keep using it. It still gets the job done for me, even though I wouldn't mind some of the newer features (some of my annoyances I know they've improved in the new version) and probably would have paid for an upgrade by now if it wasn't all subscription models now.
And hopefully by the time it stops working, another non-subscription option for Illustrator that I don't hate will be available.
I really enjoy the Affinity tools; they more than meet my modest requirements.
https://affinity.serif.com/en-us/press/newsroom/canva-press-...
It's been a while since I've used Inkscape, but I remember it feeling clunky and buggy for me, and I had difficulty getting into the workflow.
I'm sure I could probably force myself to get used to, and probably enjoy alternatives, but the more I invest in these proprietary alternatives, the harder it will be to shift anything back to Illustrator if I need to, especially since I don't think any of them bother to output to a CS6 friendly file format anymore, so I can shift to them, but I can't easily shift out of them.
And at this point Illustrator CS6 is just dead simple for me, I don't have to think about where anything is, I know exactly what I need to do for like 98% of what I want to do on it, and most of it is muscle memory, I can whip up some cards in a few hours while watching TV shows in the background.
It's going to take something significant (like it no longer working) to motivate me enough to upgrade. I know I'm playing with fire a bit, since these files are getting more and more out of date, and may not import nicely into even the subscription Adobe Illustrator at some point, but I already have too much other shit I have to learn all the time for my day job, I don't have much left outside of that (maybe eventually I will. I am starting to learn Logic Pro and Ableton Live for making music finally, and for the longest time I only used FLStudio).
That's a cool graphic though. I'll download it for future reference. Also it'll be easier for me to convert for other Adobe products, like I mostly use Paint.NET instead of Photoshop nowadays, for example. Illustrator is the main one I feel I have to stick with. Also Flash, since it doesn't exist in any newer ones (I used to make Flash games, so if I want to open those FLA files again, I need it).
Had it only been "1 month free" I would not have explored enough to sign up.
Instead of a time-limited trial, we have just one of the plot types (Sankey) freely available indefinitely (https://plotapi.com/page/sankey/).
We tried a time-limited trial, and we just ended up with people re-registering new accounts every 2 weeks.
> What I was really asking potential customers to do was wait.
> Wait until they're ready to start understanding the API.
> Wait until they're ready to go through onboarding.
> Wait until the PoC is planned.
> …
> What ends up happening is that people get busy and they end up seeing that 14 day deadline, determine that they're not ready yet, so they bounce until they are ready, but then they never come back.
> I decided that I needed to remove that friction. I wanted to capture these leads as soon as they decide Keygen may be the solution for them. So ultimately, I can start nurturing these leads.
I’d love to hear more about what “nurturing” looks like.
Usually it’s just a matter of the implementers on the prospect side not prioritizing the effort.
A free trial should usually be followed by a proof of value where both parties are committed to implementing the solution in a realistic way with the expectation of a signed contract if the proof of value delivers on the customer requirements.
This could be something to be careful of if that applies to you.
> We'll get there.
Just FYI, I consider this tease-based writing to be reader-hostile, the prose equivalent of clickbait. It's the surest way to get me to quit reading.
Like other dark patterns, there times when this sort of thing can make sense, but in practice it's usually done (consciously or not) to get the reader to read more than they would otherwise.
Just make the product free for non commercial use (including a trial in a commercial setting). If I need support or want to buy something please let me contact support or sales. I don’t want an automated email from Jeff at Randomcorp asking me how my trial is going. If a trial has to take 30 days or 365, just let me finish.
If I sign up on Monday, I might not even look at the API docs until Friday. Assume the week after that I personally like it, if I'm at a bigger company I'm probably going to spend a month or two just getting approval to expense it.
1. Show me your price, with multiple pricing tiers. The more tiers you have, the more likely I am going to pick one of them, because I will think "well this lower tier is quite the deal compared to the higher tiers!". If I am an Enterprise customer, I will disregard you as an option if I can't see a price. Don't even show me the tier at all if you aren't going to show me your price. I get immediately incensed when I see that "Contact us for pricing!" bullshit, because I know how much bullshit I am in for if I just want to get a quote, so I look for somebody else. I want to use your product right now. But I'm not going to use it if I think it will be painful to work with your company, or that you might have exorbitant pricing, or you're just looking for whales. Don't make me discount you.
2. Let me use your product, immediately. Let me run it from my laptop immediately. Let me spin up a PoC. Show me your complete reference docs immediately. Show me a toy implementation w/source. I want to know if this will [eventually] give me what I want, within 15 minutes. Do that and you will already have gone above and beyond 95% of SaaS (in my mind).
3. Let me have gradient pricing. Let me sign up right away and start using your product for $0, for 5 users. Send me an e-mail when I have 7 users, informing me that I have 30 days to either reduce the number of users to 5, or it will automatically upgrade my account and charge me more (or make me confirm, or whatever). Same for the next tier, etc. (or 'pre-purchase' discounts vs 'on-demand' overage cost, etc) This gives me flexibility: I know our workflows won't just stop working when we hit a limit, and I can acquiesce to the new price or clean up old users.
4. Let me start using your product without a card on file. Sometimes it takes a while to find the right corporate person with the right corp card (if they even let me use a corp card, rather than invoicing). If you really need a card, give me 15-30 days, and then pause my account if you have to. The point is to let me get "hooked" on your product without needing to figure out which card to use first. (It goes without saying that when the card expires or a charge doesn't go through, give me 30 days to resolve it, because usually the corp card has hit its limit)
But the thing is - the reason large companies often don't give folks like you and me these things is becuase there are proven reasons to do the contrary that actually end up making them more money. It sucks, but it's reality.
1. "Call us" pricing works because for big enterprise deals (4-7+ figures), there's often some serious negotiation involved and if you just show a sticker price up front, you risk a) scaring the buyer because the price is too high, b) losing the buyer because your competitor will just negotiate a better price than your listed price or b) leave yourself no room to negotiate if you really put your best price on the website.
2. Offering immediate free trials where you can jump in right away is the ideal world for nerds -- again, I love it personally. But software is often complex, and a guided demo/implementation is often the best path to make sure your buyers are actually successful. Otherwise you risk a lot of folks who sign up, jump in, have no idea what they're doing, and then abandon the trial immediately and go to a competitor who held their hand.
3. "Let me sign up right away and start using your product for $0..." If only offering Freemium were so simple. You will immediately have to deal with porn (it's always porn - and often kiddie porn. These people will figure out incredibly creative ways to use your SaaS product to host illegal content one way or another), spam, fraud, customer service issues, etc. There are many valid reasons to offer Freemium. There are many valid reasons not to do so. It's just not so simple.
4. Again, think about the flip side here. Lower friction to sign-ups without a card, but SO much hassle when it comes time to pay -- now you have to nag, bug, etc. to get payment, and then you have to delete accounts that are dormant. And you have much lower buying intent signals, etc. etc. etc.
I wish the world of software catered to folks like us, but I fully and completely understand why it doesn't.
I'd disagree and say this can go either way. As an enterprise buyer I know both MY budget and that all numbers are negotiable - to some extent. If you show me that this product costs $100k and my budget is $80k, I'll still talk to you. But if you list $100k and all I've got is $25k for the budget, yes, I'm going elsewhere.
Now you might argue "We can make something work" I'm concerned. You'll do 80% off deal? Clearly you don't think your product is worth what you list so... now I don't think so either. And the "But We've got a tier for that" then list it.
My time is way valuable to me. I do not want to go through 3 screening calls, a shit ton of hoops, and a 2 week wait... just to find out that your product is way too expensive for my budget. Especially when getting into those sales calls where the reps wanna play coy and say "Well whats your budget" or "Well it really depends, we want to get into a POC bla bla bla to understand your useless before providing a pricing". Ain't no one got time for that shit. Give me the MSRP up front (with the understanding that a deal may be reachable if it's a little much) or I'm walking.
Keep in mind that when I'm pricing your product I'm probably pricing 3 to 5 others. There is literally not enough hours left in my life to give each and every vendor a 5 hours of time in order to get a price.
Fortunately the world is shifting. You know who's pricing is available on their website? Salesforce. Okta. OneLogin. Ping. Slack. Github. Gitlab. AWS. Google. Microsoft (for some). Elastic. Tailscale. Adobe. Databricks. Datadog. Cloudflare. Zoom. ... The list goes on. In other words there are a lot of companies out there with their prices available on their website right this second. Sure, almost everyone of them has a "Enterprise call us for pricing" option and that's fine, as long as you've got something for me to start with.
If you're a software vendor and don't have some prices to start with, you're at a major disadvantage. Because your competitors often do. And price is not the only thing buyers are looking for. If it was, Okta would have no business. You can look at their prices and OneLogin and Ping's (and Azure AD and Google). The entire IAM/SSO space has their prices right out front and Okta is... the most expensive. Yet somehow they all still are selling.
Often we don't need the whole company to be locked into whatever the Enterprise feature is. Maybe we only need a single feature, and that has a given dollar value for us, and for the provider.
SSO for example costs the provider almost nothing in terms of compute/network, and little in terms of development and support; so why not let people pay a-la-carte for SSO? Cheap enough to be worth it, not so expensive as to be a turn-off. You could have one bulk price for SSO, or even charge per authenticated user! The point is to make it flexible, but still extract some money for that feature that hardly costs you anything to support.
Another example: let them have complex IAM (groups, roles, etc) for one price, and SSO costs extra. OR they can call to negotiate. This way they can pay now a-la-carte, or they can try to get a better price, or they can just settle for not using the feature. But it gets them on your platform, giving you money, in some form or another. Add up all the a-la-carte features and you get a bloated quote, but you can offer discounts for package deals.
Mutual Fund companies do it, and successfully, even if you’re only signing a letter of intent and aren’t buying at the higher tier today.
The charade involving salespeople, and let-me-talk-to-my-manager isn’t as productive as it seems. I’ve walked from several vendors (or discounted them in an RFP) due to that behavior.
I've never used Uber in my life but I'll be traveling internationally next month for the first time so I figured it wouldn't hurt to install Uber now to get a feel for what the UI is like.
As soon as I signed up Uber was like, hey we'll give you 50% off your 4th ride if you complete 3 rides within 14 days. I won't even be traveling by the time the offer runs out. All this does is make me feel like I made a mistake for signing up too early without knowing anything was going to happen.
As a ridiculous example: I took an Uber from an office to the Indianapolis airport then an Uber from the Dallas airport to a hotel for the night. As I'm winding down for the night I get a notification from Uber: "Need a ride back to ${indianapolisOffice}?".