Require me to give you my contact information just to download something. Have sales people blow up my phone and/or email and ignore polite brush-offs. Keep reaching out to me periodically with requests to have a meeting about how you product can help me.
I don't have buying power, but I do have bitching power and your product will wind up getting bad-mouthed by the whole team eventually. And when the engineer asks us for recommendations, guess what we tell him?
IT Manager here, and deal with this almost weekly at this point. I'll add to your list of how not to do it - ignore my brush-offs and start email blasting others on my team or within the company to get around me. Quick way to get your domain blocked all together.
Also please don't make me sit through a demo just to get a quote. If I want a full demo I'll ask for it, and I need to know pricing first before even considering going any further. I've probably already researched your product, maybe even did a trial if available - I don't need to sit through any number of sales pitches, just give me the numbers.
I fairly recently got to switch sides on this. I never take sales calls or want to get on demos as a developer ... but I moved roles a bit and needed to join some calls with the reps at my company for a product I now manage. It has no public pricing.
I was surprised by how much the people who show up for demos seemed to like them and have good relationships with their reps. They thank us for saving them a lot of time they would have spent reading docs and marketing materials to learn the specific things that applied to them, or for us talking about roadmap stuff they don't get to see in the public materials.
Sometimes the price is a surprise to them and it needs a bit of context. Customers who are used to buying software this way seem to read between the lines really well and ask suitable questions about discounts or whatever, when they are surprised by pricing. Often we are able to make something work at a different price than the typical quote, or we can connect the dots so that the rationale is more clear, or the value requires some customization to be done.
My reps tell me this sorta thing is difficult over email, that nobody makes $10k+ purchases without talking to somebody, so if we can't get you on a call the deal falls over.
So I dunno. I'm not a big fan of the requirement for calls really, but I can understand why reps don't just throw quotes around without some conversation.
I've come to the opinion now that if something in sales doesn't make sense, you're probably not the target market. Sure _I_ don't want to have a demo with no price guarantees, but I'm not the target market - big companies with dedicated purchasing teams and big lists of requirements are. And those companies write big, ongoing cheques. So in some ways the obscure pricing and convoluted sales process is doing it's job which is qualifying good customers and diverting bad customers (people like me)
The problem is that a lot of companies all want to sell those $10k+ purchases but then forgot that their products are actually useable to the "common man".
So they then lack any easy to see price overview or reasonable models for small dev teams or small companies. Demo's are not worth it for somebody going to spend a few hundreds, so you get often ignored.
What they then forgot that if you tie in a customer at the low end, that customer may grow and become a 10k customer down the line.
This is why companies need to get it in their stick skull, that you NEED fixed pricing for the folks that do not want personalized quotes (or the lovely no-response emails if asking for a quote as a single dev or "small" company).
And getting customers early on, even if they are not mass profit generators on their first purchase, are a good source of future money as people really do not change infrastructure or tooling without a good reason.
Seen a lot of good products, that we ignored because they lacked proper simplified pricing on their website. If its "contact us for pricing", its just like advertising "we do not want to deal with your poor ass" advertisement. So those customers go somewhere else, get a product they like and then grow. But then its too late / difficult as changing that customer to your product is 10x harder.
That presumes that it's worth the cost and headache to even serve you. It's called the long tail of small customers for a reason: you have a huge amount more customers to satisfy when combined they might be worth less than a single big customer.
A surprising amount of services are held together by duct tape and human hands.
Appreciate the other perspective. I'll even admit there's been cases where the demos have been useful and sparked other questions, but in those cases I hadn't heard of the product before or was coming in blind.
Most of my cases now (and I may be an outlier), I'm looking at something because I both have a need and someone I know recommended it or uses it so I'm already familiar, but at that point it's not so much a sales process and more so "I already know I want this, and I already have the budget and approval, let's get this buying process over with as quick as possible."
Related gripe: Requiring people to sign-up--or worse, to already be a customer--just to view API documentation.
Y'all're crazy if you think your API is so awesome that it needs to be a trade secret, and without it I can't get a good idea if you product is something that would actually solve our problems, or whether it seems like something worth integrating-with.
A major change in my field over the last few years is the rise of Ignition, a SCADA suite that's taking over everywhere. And sure, it's got simpler and cheaper licensing than it's rivals. But for our projects, licensing cost isn't generally a factor.
What Inductive Automation did was open up their documentation, offer good online training for free, have an endless demo mode that can be reset indefinitely, and a "maker" version that can be used for free. Oh, and it's scripted with Python instead of some janky BASIC knock-off. All features that appeal to integrators but that don't matter to the end users.
Putting these walls up also makes life harder for actual customers, who now have to prove they are such every time they need to access said docs for whatever reason.
As an individual engineer, if I have to jump through hoops just to login and view docs... yeah. I won't be going out of my way to make sure you get considered in trade studies at my next job.
Adding Auth0/Okta to the list. Funny enough I had buying power and budget for it, and was gonna ask a Senior engineer to look into it, but the calls got so crazy that I just soured on it.
Love the idea of "bitching power"; basically anti-"word of mouth". Even if you make something freely available, your sales/marketing/GTM folks can hurt your company's name by being too aggressive.
You should contact to people how they want to be contacted, not how you'd want to be contacted.
I've seen some insanely obnoxious email saturation bombing from some SaaS marketing teams. One was emailing me every 5-15 minutes.
Sometimes it could just be a rogue sales/marketing person. But other times it looks like it's probably blessed from the top, if not the startup-CEO personally setting the email marketing tool slider controls to maximum trashy level.
Requires a "professional account" just to register. And tend to refuse gmail accounts to create said microsoft professional account.
So the 30 day trial period you could use to check what's possible and see if you can integrate their shit with your IT infrastructure? Not happening. And if it's a bother just to get to try your shit, I can't fathom how bad the rest of the experience can be so you can keep your AI enhanced CRM, ERP, Dataverse etc.
No, I'm the lead integrator at a small-to-medium-sized company. Which means when an engineer brings me in on a project, I have a decent amount of influence on the software and controls hardware we use.
The customer may specify a PLC manufacturer or a particular SCADA system, but unless we're expanding an existing system we usually have a lot of leeway. I know this stuff better than the engineer does (that's my job, after all), so my recommendations are usually accepted.
In this case, corporate management holding the purse strings but their workers (devs) using the actual tools. The solution they offer to founders is to make the user your champion and have them sell your product for you.
"The meta point here is that you're not going to talk to the credit card holder; the user/dev is going to do that for you.
Give them the best possible chance at convincing the leadership. Make them look awesome for even bothering the leadership with a choice like this. Make it obviously awesome for them to decide “yes”. These users/devs are your sales people."
Maybe that works for dev tools with freemium models, but in many industries where this problem arises its just not possible to even get your product in front of the users. Take hospital systems and EHR purchasing where Doctors and Nurses are the users of the EHR day in and day out but it is the hospital administration that ultimately gets to decide which EHR is deployed. How do you get users to be champions of your product if you can't even get it in front of them?
Too often we get the reverse. Slick salesman targets the person with budgetary discretion while avoiding letting the users in in the transaction, so by the time they can complain about how terrible the product is, the check has already cleared.
Speaking as software developer and company co-founder for a product for use by other developers, the company employing those salesmen is very possibly overall losing money on these deals.
In our early days we had on occasion managed to directly convince non-developer decision makers in an organization to use our product (even though it wasn't an intentional strategy) and this invariably failed unless we also managed to get full buy-in from the developers who will actually use it.
These days we have an explicit rule that we don't go ahead with any customer engagement until we can see that a project's lead developer is fully sold on our product, otherwise we waste loads of time (which is essentially money) on ultimately fruitless retention attempts instead of using the time more productively on ideal customer opportunities.
Now it does depend on the nature of the product though. For a product used by only a small subset of a company (like our product), it's probably a bad strategy to sell to the execs instead of the users. But for a product like an ERP (think SAP, or Oracle ERP), these are deals worth USD millions (sometimes 10s of, or more) and convincing the execs is a highly (or possibly the only) effective strategy.
Yup, then the technical people have to deal with the bullshit and nightmare that is implementing the shitty thing that was purchased. Hard to get around this in large enterprises, someone just decides they're going to use some shitty tool (like that cloud provider no one uses but has great sales folks) and you just get a notice you have to migrate all your apps to the new thing in 3 months cos they got a better contract there.
The school district my kids are changes the parent app almost every year, its always a nightmare for everyone involved, I can't imagine what it is like to work IT in such a place.
I believe open source is approximately an order of magnitude larger than it would be if developers controlled their own purchasing. What FOSS introduced was the ability to use software without someone with a little power saying no, you can’t, because we won’t pay for it.
Jetbrains threaded this needle for years by having professional licenses tied to an individual with clauses for time and location shifting. So you could use their software at home, drive to work and also use the same license there.
And they priced it at around the cost of three tech books per year, which it is at least that useful for productivity. I suspect we would be in better shape now if others had copied their model. Rather than the (defunct) Microsoft model of ignoring home piracy and demanding commercial licenses from any company large enough to make it economical to fire off a cease and desist to them and demand back pay.
> Jetbrains threaded this needle for years by having professional licenses tied to an individual with clauses for time and location shifting. So you could use their software at home, drive to work and also use the same license there.
It's a very, er, "enlightened self-interest" model, because it makes me "sticky" as a customer, since I'm less likely to learn a completely different IDE for work and then use that one for my own projects and eventually ditch theirs.
It sounds like a trivial question to answer, but it just exposes the level of detachment that exists between who makes the purchase decisions and its users in SME context.
Because you want to control who uses it (offboard separated employees, onboard new employees automatically), integrate into your auth systems to make it easier for employees to access, get an SLA if something goes wrong, connect to your data auditing systems, etc, etc. Companies have a lot of needs outside of just the core functionality of a product.
You might want to understand the politics and business dynamics before you go too far down that route. You could just end up getting your product blocked and/or replaced with a competitor instead.
"Well we have Bob from purchasing on the phone and he says we have to put this out for a bid first. And Alice from compliance wants to know, do you have [insert esoteric certification]?"
You really have to know who you are talking to and their motivations before you know what the right sales angle is.
I knew at one point some engineers who added RFC2549 to see if the salespeople were just being yesmen. A few years later I had similar problems with HSM salesman lying about Java support in their products so I can sympathize. Buying a product you cannot use without extreme effort is the pits.
One of them put in a bid to Cisco and got a reply back saying something like they were working on it but having some issues with the birds.
That used to be the case much more strongly in the past. At least dominant players now much more often expect institutions to buy bulk licenses for their students, because if they don't, the students won't have practical knowledge for the job market in the industry standard tools.
Except for that whole every company that tries it ends up either not making money money on it, get Amazoned (where Amazon offers a hosted version and makes money), or ends up seeing the error of their ways and using a more restricted license and still struggles.
Agreed. There are better models to commercial open source that align better with business sustainability, like fair source. I was mainly referring to bottom-up adoption, not sustainability.
Amazon already has a relationship with your corporation, it's easy to buy their hosted elastic search
Even if the original elastic company offers it cheaper, or better, that's a massive hill to climb. Corporations don't care about costs, they care about pieces of paper, or less charitably nice dinners with the sales team.
For every AWS offering aside from maybe MySQL/Postgres Aurora and DynamoDB, there are better cheaper alternatives. You choose the AWS alternative because they are 80%-90% “good enough” and you have one pain of glass, one IAC implementation, one set of permissions, one point of governance, one account manager, one TAM etc.
That by itself is worth the extra cost for some organizations. While I’m a big fan of AWS as a technology provider and have been heavily in the ecosystem for 8 years, I’m no fan of the company or the organization as a former employee.
You consider PostgreSQL more scalable than dynamodb ? This is certainly a novel take. Since dynamo is hosted are you talking about a hosted pg as well or how even are we comparing this?
And even with Postgres, I doubt their definition is “multi AZ with a shared storage layer between data centers that is also fault tolerant and replicated across multiple data centers”. Meaning that if your database server goes down, your backup servers are immediately up to date because of the shared storage engine in the same region but the underlying storage was also replicated across multiple AZs.
Not if you need multiple databases for failover or read replicas. Aurora’s storage engine is head and shoulders above what you are going to get for $10
I specifically said commercial open source, which is different -- one hopefully has a business model and the other does not need/want one. Working on open source outside of a commercial context has never promised compensation, and expecting compensation for it ends in pain.
this happens all the time at large companies with small teams, plus if there's a security team they hate it so that's always an angle to lean on "hey 400 people are using 12 different slack workspaces, wouldn't it be nice to manage them all from one corporate account?"
Heya, I work for a commercial auth provider but we provide a free version with unlimited SSO connections. (Details in profile if you are interested.) So I have a bias.
There's a number of ways for open source software stacks to make money, but I agree that finding features that companies with money will pay for is a great one.
I think Patio11 said it once, but SSO feels now like HTTPS felt in 2015. Used to be super expensive, but now should be "table stakes".
Other ways open source companies can make money:
- hosting (offers that sweet sweet recurring revenue)
- support (especially SLAs, which pair nicely with hosting)
- other enterprisey features, such as integrating with enterprisey tools (DataDog, SIEM tools)
- other auth features like fine grained authorization (RBAC, ABAC, PBAC) and provisioning (SCIM)
- control planes (I see this with tools like Cerbos and Permit which both offer fine grained authorization execution engines that are free, but charge for the control plane)
- certifications (SOC2, FIPS, HIPAA, PCI). this might not make sense in all cases, it does depend on the tool
- custom feature development (better if this is pulling forward planned development rather than something unplanned)
It's not easy, though.
I wrote more on my personal blog about freemium[0] and open-source[1] business models.
The problem is there's a huge gap between "We are a small company, and don't care about SSO" and Enterprise.
The company I work for is in the middle - anything where SSO is gated behind "Enterprise" is not even considered by us. We don't need 90% of the other "features" under the Enterprise plans, and most aren't willing to custom quote us for Basic+SSO.
Withhold it from free versions, sure - but definitely don't lock SSO only behind the most expensive option.
Companies of that size are common. It would in isolation even be profitable to serve them. The problem is if you introduce a middle tier that includes SSO, many enterprises will go for that instead of the expensive enterprise tier you want them to buy. Basically, you sacrifice medium companies as customers in order to chase after that sweet enterprise money.
Companies of that size are served by the "enterprise call a salesperson" offering. If you really don't need all of the other features you can probably negotiate a discount.
That makes sense, but I still think there are other features that can be gated behind enterprise to help make sure that doesn't happen while still providing SSO for smaller companies.
You can have user limits on the non-enterprise plans (Microsoft does this, for example, with Business Premium locked at 300 users or less), or gate other features behind enterprise: Have MFA across the board, but lock conditional access behind enterprise, lock more advanced audit logs & reporting behind enterprise, lock RBAC behind enterprise, or data residency, custom security policies, API limits, etc.
There are numerous other features that are non-negotiable for enterprises to help funnel them into the enterprise plan, while still being able to service medium companies with SSO.
I'd hardly call a business with between 150-300 employees, that cares about SSO but doesn't need the full suite of enterprise features an outlier, I'd imagine that's fairly common nowadays.
Maybe in 2015 it was an outlier, but SSO is now a non-negotiable and with many of these businesses on M365 business premium, which includes EntraID P2, SSO is now accessible to a large number of companies where it wasn't before. It's no longer some niche enterprise only functionality, it's a bare minimum for business SaaS.
The fact you’re unwilling to even consider a product with SSO behind the enterprise license is what makes you an outlier, and frankly probably a bad customer.
And if you’re trying to negotiate custom, non standard licensing when you’ve only got 300 employees you will likely be a noisy customer in perpetuity.
No offense, that’s just how I’m betting 99% of folks read your response.
> There’s a reason they all do it, and it’s because SSO is one of the few features enterprises are almost universally willing to pay for.
Also, anyone who's dealt with SAML knows it's like licking lead-based paint. It's the knowledge equivalent of antimatter, every line of code you write costing you a point of IQ.
SSO has to bring in monthly recurring revenue, to cover the monthly recurring disability payments to the many people who've lost the ability to feed and dress themselves after reading too much of the xml-dsig spec.
withholding enterprise features from free versions isn't the problem, the problem is charging extortionate rates for an important security feature.
> "Decouple your security features from your value-added services...If your SSO support is a 10% price hike, you’re not on this list. But these percentage increases are not maintenance costs, they’re revenue generation because you know your customers have no good options."
Problem is lots of SSO implementation will be dealing with some arrogant architects claiming you know nothing and their semi broken SAML is something you should implement for them for free - repeat for 100 times for each customer having their own way of breaking the spec or using something crooked.
It is getting better with Entra P2 or Okta as it is couple of minutes to configure if you use good framework in your projects.
But the tax was because of what I wrote about in first place.
This is why at work, we're encouraging and recommending to use some kind of SSO, but we're basing our cost off of the customers IDP.
Some "green" IDP like O365 OIDC, Okta, Entra and such are usually included without extra cost (and will be self-service soon, too). Some "yellow" - usually SAML - IDPs come at a fixed fee. We know them, we know they are weird, but we can deal with it.
Other things are flagged as red and call in hourly billed projects and recurring maintenance fees. Like, one customer has an in-house developed SAML IDP written in PHP a decade ago or so. I want our customers to use SSO, but that's a level of jank I'm not supporting for free.
Some of these seem iffy. Looking at one at random with a seemingly excessive increase:
Coursera: $399 per u/y -> $49875 per year [7], 12400%
So, I check out the footnote:
[7] Coursera requires a minimum of 125 users to access SSO pricing. As they do not have an Enterprise price listed, this price just scales their lower cost tier up to 125 seats.
Dividing by 125 shows the SSO pricing is $399, so exactly the same as the non-SSO pricing. I fail to see how this is an SSO tax.
It might be that there is an SSO tax as the Enterprise price wasn't available to them, but listing it as 12400% increase seems like a deliberate attempt at deception.
I've used to work in small startup with ~10 people. The owner was always happy to pay for tools to developer productivity. We did not subscribe to Coursera, but in the theoretical case we'd all want to, the pricing would be:
10 users, no SSO: $3999/year
10 users, with SSO: $49875/year
It's an SSO tax, and a super hefty too. We'd probably balk at it and chose the less-secure option instead. And the fact that we'd get extra 116 licenses we had no need for is absolutely irrelevant, there is nothing we can do with it at all.
Even in your example, and assuming that the only feature that the enterprise plan offers is SSO, that's not even close to a 12400% increase, that's a 1147% increase.
My point was that saying the minimum order is 125 seats for enterprise, and so claiming that the price for a single seat is increase by 12400% is being deceptive.
If you buy a six-pack of beer, you don't say "This is terrible! I only wanted one beer and this six-pack is a 500% increase in price!". If you only want one beer, you just buy the single beer and leave the six-pack on the shelf.
If there is an option to buy a single beer on the shelf, sure. But in this case there is no such option.
Imagine you _really_ wanted to try Foobar beer. So you get to beer distributor, and you find out that while each bottle is just $5, the minimum order is a crate of 144 bottles and they give no samples.
In this case, you might say: "Yeah, I really wanted to try that beer but there is no way I am paying $720 for that". It's exactly the same here.
(re 1147% vs 12400% - sure, maybe you could argue you should not look at a single license, but rather at a pack of 5 or 10 licenses... but this does not change numbers much for Coursera, it's still huge increase.)
The company I founded previous faced this problem - we were selling to a part of the development team that often had no clout in making financial decisions. We were able to sell to smaller companies and larger ones that happened to have people who had enough power to purchase. But the majority of companies had super long sales cycles where we had to work with them to prove out the cost savings to people higher up. Most of the time this went nowhere and cost us a ton of time. It wasn't the only reason the company failed, but a major contributing factor. Glad to see people talking about it because it's something a lot of small b2b companies face and there's surprisingly little advice on it.
This works if the users are able to use the product (in this case on their personal device maybe) first, and are part of the same organisation.
But what about cases where the user isn't directly related to the decision maker? Doubly so when it's a hard to justify purchase? (I.e. you're not selling bread or IBM machines.)
For example, say, a keyless entry fob for a car. The driver benefits immensely. The CTO of Ford may probably not even entertain a meeting ("Huh, what does he think, locks are bad or something?! What's wrong with a secure lock?")
Does anyone have any suggestions for how to approach such a situation if you developed the fob and now want to sell it?
In your scenario, you're looking at a bottom up approach. Instead of going to Ford, you start at the bottom of the food chain. Used car dealerships, auto body shops, and other places that sell/install accessories for your car.
A great example is remote starters. Same idea. Great for the user, not so much for say Ford. The first places I saw these being installed? Stereo shops would use it as a cross selling feature whenever they were selling something else to a customer. I could be wrong, but it took a few years for the manufacturers to start including remote starters as an add-on. Before then, it was all kinds of other shops selling and installing them.
But its a trench warfare type of deal. You have to get into the hands of the people who can install them, then work your way up to approaching dealerships and larger clients.
I've done this with an anti-theft device. Start small, then build your client base and use that as a springboard to get interest from larger clients.
Interestingly I'm currently doing a version of that except with top-bottom and bottom-up approach.
I.e. like you describe I the younger sales rep on the team am going bottom-up after the smallest guys. And my boss, the CEO is going after the top management. We're both selling the same thing but with different argumentation.
The idea is that the buzz of excitement will turn into consensus when everyone in the middle sees approval from the top and positive feedback from the bottom.
Just be sure your product actually works. Third party/aftermarket remote starters and car alarms are (were) nortorious for causing a varity of intermittent, obscure electrical issues. Not sure if it was the devices themselves, or the installation, or both.
B2B2C marketplaces - especially ones that don't charge the "B2B" users, but take a cut of each transaction, and empower users to encourage transactions through a customized instance of the platform - are a fascinating "final boss level" for this mindset.
Your user is not your buyer, but they can be a distributed salesforce. You need to growth-hack not only for your penetration at the B2B level, but to give them the tools they need to growth-hack their own B2C client bases, with your product at the forefront.
That's a lot to build as a founding team, and occasionally it can be like herding cats - but it can be incredibly lucrative, because you have an incredibly low barrier to entry at the B2B level, but every account naturally scales with value delivered to the end customer.
For enterprises its not usually as simple as sell to the CTO. Some things you need that, if you are AWS or Azure, the CTO and some principle engineer are who you have to convince to move the whole 20k person org over. But for a lot of software its the Line manager or director who is calling the shots, or a division head since division A may use different software than division B.
This hits home. We're building business intelligence APIs around entity resolution, and the buyer/user split gets messy when you have engineering, product, and data science teams all involved.
Engineers immediately understand why matching messy company data is a nightmare, but executives just see delayed projects without grasping the technical complexity.
We're seeing more success lately with "your team burned N months on data matching that should've taken weeks" rather than explaining what entity resolution even is. We're talking to one company right now that's spent 10 years building their own entity resolution system and it still doesn't work well.
But even then, it depends on the company and what they're trying to do.
To be frank, that's the challenge we're working on now. To start, my partner and I were mostly tapping into our network for initial customers. Both of us have been in the Bay Area for 10+ years.
Now, we're working on more of an inbound strategy and have a bunch of ideas. We're debating on cold emailing, but as an engineer myself, I hate getting cold emails.
This is a bit of a simplification of how enterprise sales works. A few extra dimensions are sometimes required. For "decision makers" their own personal view of reality may not in fact be accurate. You sometimes must vet that what they tell you (and may in fact believe) actually reflects the actual power dynamics of a big enterprise. There are extra dimensions to consider; The first is: are they in a cost center or are they generating revenue. The second is: are you trying to get new technology adopted or is this considered "standardized". The third is: who might perceive your product as a risk, or a threat to their power? These data points inform your sales strategy both in who you sell to, who you avoid, and when you might choose to engage a particular persona, when to go small and when to go big.
Employees, by and large, all share three common desires:
* How do I get promoted?
* How do I get a raise?
* How do I not get fired?
Beyond those common desires are a constellation of more personalized that is specific for each salesperson and the cohort they target (I'm somewhat of an idealist in that I believe people are quite often strongly driven by meaningful non-capitalist, non-realist desires).
In any case, when you're working in enterprise sales, what you have to realize is that, regardless of what the desire is, what your corporate champion is "buying" is a way for them to achieve their goals and only incidentally what is good for the company, where your product is merely a proxy to accomplishing this.
Of course, companies also know this and anyone who has owned a P&L immediately recognizes that the sum of all things everyone wants far exceeds the resources of the balance sheet, thus, some selection process needs to be put in place to allocate scarce resources.
Your corporate champion is ideally far more aligned with you against the company than they are with the company against you and your job is to figure out how to win this selection battle together.
The core insight though, is that people are actually astonishingly bad at performing on this and it's actually quite easy for an outside sales person to become a subject matter expert for 3 core reasons:
1. Any employee usually only ever has a sample size of 1 whereas you have a broader peek into how this has happened across a range of companies industry wide.
2. Any employee, only a minor part of their job involves interfacing with outside parts of the firm responsible for allocating resources whereas you treat this as a core competency.
3. For any person, it's always easier to advise a 3rd party on what to do than to practice the same actions yourself.
What this means though, is that, as an enterprise salesperson, you should understand that your core value comes from developing subject matter expertise in how to help people in your industry get promotions, get raises and avoid getting fired and the product you're representing at the moment is merely the avenue through which you enable that to happen.
The best salespeople I've ever met always share a common core value that they deeply care about making sure everyone around them is getting rich with the faith that some of that money eventually reflects onto them but that's not what drives them. That's why so many immigrants and children of immigrants make such great salespeople, they've seen the material difference wealth has made on their circumstances and they want to spread that opportunity to others.
This is what I advise Founders who start Enterprise focused businesses. Fundamentally, you should be thinking about how do I get someone to VP/Director/Line Manager/Tech Lead 2/3/5 years earlier than if my product doesn't exist and how do you breathe this passion day in day out.
Agreed, with the modest addition of “How do I avoid unexpected hassles?” It shares a corner with not getting fired but is more about comfort than risk.
I'll tell you how not to do it.
Require me to give you my contact information just to download something. Have sales people blow up my phone and/or email and ignore polite brush-offs. Keep reaching out to me periodically with requests to have a meeting about how you product can help me.
I don't have buying power, but I do have bitching power and your product will wind up getting bad-mouthed by the whole team eventually. And when the engineer asks us for recommendations, guess what we tell him?
Lookin' at you, Veeam, AWS, and Keyence.
IT Manager here, and deal with this almost weekly at this point. I'll add to your list of how not to do it - ignore my brush-offs and start email blasting others on my team or within the company to get around me. Quick way to get your domain blocked all together.
Also please don't make me sit through a demo just to get a quote. If I want a full demo I'll ask for it, and I need to know pricing first before even considering going any further. I've probably already researched your product, maybe even did a trial if available - I don't need to sit through any number of sales pitches, just give me the numbers.
I fairly recently got to switch sides on this. I never take sales calls or want to get on demos as a developer ... but I moved roles a bit and needed to join some calls with the reps at my company for a product I now manage. It has no public pricing.
I was surprised by how much the people who show up for demos seemed to like them and have good relationships with their reps. They thank us for saving them a lot of time they would have spent reading docs and marketing materials to learn the specific things that applied to them, or for us talking about roadmap stuff they don't get to see in the public materials.
Sometimes the price is a surprise to them and it needs a bit of context. Customers who are used to buying software this way seem to read between the lines really well and ask suitable questions about discounts or whatever, when they are surprised by pricing. Often we are able to make something work at a different price than the typical quote, or we can connect the dots so that the rationale is more clear, or the value requires some customization to be done.
My reps tell me this sorta thing is difficult over email, that nobody makes $10k+ purchases without talking to somebody, so if we can't get you on a call the deal falls over.
So I dunno. I'm not a big fan of the requirement for calls really, but I can understand why reps don't just throw quotes around without some conversation.
I've come to the opinion now that if something in sales doesn't make sense, you're probably not the target market. Sure _I_ don't want to have a demo with no price guarantees, but I'm not the target market - big companies with dedicated purchasing teams and big lists of requirements are. And those companies write big, ongoing cheques. So in some ways the obscure pricing and convoluted sales process is doing it's job which is qualifying good customers and diverting bad customers (people like me)
The goal in sales is to flatter people (with attention) whose job is to spend other people's money.
The problem is that a lot of companies all want to sell those $10k+ purchases but then forgot that their products are actually useable to the "common man".
So they then lack any easy to see price overview or reasonable models for small dev teams or small companies. Demo's are not worth it for somebody going to spend a few hundreds, so you get often ignored.
What they then forgot that if you tie in a customer at the low end, that customer may grow and become a 10k customer down the line.
This is why companies need to get it in their stick skull, that you NEED fixed pricing for the folks that do not want personalized quotes (or the lovely no-response emails if asking for a quote as a single dev or "small" company).
And getting customers early on, even if they are not mass profit generators on their first purchase, are a good source of future money as people really do not change infrastructure or tooling without a good reason.
Seen a lot of good products, that we ignored because they lacked proper simplified pricing on their website. If its "contact us for pricing", its just like advertising "we do not want to deal with your poor ass" advertisement. So those customers go somewhere else, get a product they like and then grow. But then its too late / difficult as changing that customer to your product is 10x harder.
That presumes that it's worth the cost and headache to even serve you. It's called the long tail of small customers for a reason: you have a huge amount more customers to satisfy when combined they might be worth less than a single big customer. A surprising amount of services are held together by duct tape and human hands.
Appreciate the other perspective. I'll even admit there's been cases where the demos have been useful and sparked other questions, but in those cases I hadn't heard of the product before or was coming in blind.
Most of my cases now (and I may be an outlier), I'm looking at something because I both have a need and someone I know recommended it or uses it so I'm already familiar, but at that point it's not so much a sales process and more so "I already know I want this, and I already have the budget and approval, let's get this buying process over with as quick as possible."
Are you selling to developers?
In my experience, non developer audiences like demos. Developers tend to like to try things out on their own, maybe with a little tech support.
Related gripe: Requiring people to sign-up--or worse, to already be a customer--just to view API documentation.
Y'all're crazy if you think your API is so awesome that it needs to be a trade secret, and without it I can't get a good idea if you product is something that would actually solve our problems, or whether it seems like something worth integrating-with.
I totally agree.
A major change in my field over the last few years is the rise of Ignition, a SCADA suite that's taking over everywhere. And sure, it's got simpler and cheaper licensing than it's rivals. But for our projects, licensing cost isn't generally a factor.
What Inductive Automation did was open up their documentation, offer good online training for free, have an endless demo mode that can be reset indefinitely, and a "maker" version that can be used for free. Oh, and it's scripted with Python instead of some janky BASIC knock-off. All features that appeal to integrators but that don't matter to the end users.
I don't think it's a coincidence.
So much this.
Putting these walls up also makes life harder for actual customers, who now have to prove they are such every time they need to access said docs for whatever reason.
As an individual engineer, if I have to jump through hoops just to login and view docs... yeah. I won't be going out of my way to make sure you get considered in trade studies at my next job.
And now they call from cell phones instead of company phones so it comes up as a plausible real call.
Salespeople are the devil.
Adding Auth0/Okta to the list. Funny enough I had buying power and budget for it, and was gonna ask a Senior engineer to look into it, but the calls got so crazy that I just soured on it.
Same experience
Same. Very annoying and manipulative.
Love the idea of "bitching power"; basically anti-"word of mouth". Even if you make something freely available, your sales/marketing/GTM folks can hurt your company's name by being too aggressive.
You should contact to people how they want to be contacted, not how you'd want to be contacted.
It's a difficult incentive design problem though.
I've seen some insanely obnoxious email saturation bombing from some SaaS marketing teams. One was emailing me every 5-15 minutes.
Sometimes it could just be a rogue sales/marketing person. But other times it looks like it's probably blessed from the top, if not the startup-CEO personally setting the email marketing tool slider controls to maximum trashy level.
Add Microsoft products to the list.
Requires a "professional account" just to register. And tend to refuse gmail accounts to create said microsoft professional account.
So the 30 day trial period you could use to check what's possible and see if you can integrate their shit with your IT infrastructure? Not happening. And if it's a bother just to get to try your shit, I can't fathom how bad the rest of the experience can be so you can keep your AI enhanced CRM, ERP, Dataverse etc.
You're clearly not the type of person who makes buying decisions at a large company.
Found the Keyence sales rep!
No, I'm the lead integrator at a small-to-medium-sized company. Which means when an engineer brings me in on a project, I have a decent amount of influence on the software and controls hardware we use.
The customer may specify a PLC manufacturer or a particular SCADA system, but unless we're expanding an existing system we usually have a lot of leeway. I know this stuff better than the engineer does (that's my job, after all), so my recommendations are usually accepted.
Situations like this are instances of the https://en.wikipedia.org/wiki/Principal%E2%80%93agent_proble...
In this case, corporate management holding the purse strings but their workers (devs) using the actual tools. The solution they offer to founders is to make the user your champion and have them sell your product for you.
"The meta point here is that you're not going to talk to the credit card holder; the user/dev is going to do that for you.
Give them the best possible chance at convincing the leadership. Make them look awesome for even bothering the leadership with a choice like this. Make it obviously awesome for them to decide “yes”. These users/devs are your sales people."
Maybe that works for dev tools with freemium models, but in many industries where this problem arises its just not possible to even get your product in front of the users. Take hospital systems and EHR purchasing where Doctors and Nurses are the users of the EHR day in and day out but it is the hospital administration that ultimately gets to decide which EHR is deployed. How do you get users to be champions of your product if you can't even get it in front of them?
Too often we get the reverse. Slick salesman targets the person with budgetary discretion while avoiding letting the users in in the transaction, so by the time they can complain about how terrible the product is, the check has already cleared.
Speaking as software developer and company co-founder for a product for use by other developers, the company employing those salesmen is very possibly overall losing money on these deals.
In our early days we had on occasion managed to directly convince non-developer decision makers in an organization to use our product (even though it wasn't an intentional strategy) and this invariably failed unless we also managed to get full buy-in from the developers who will actually use it.
These days we have an explicit rule that we don't go ahead with any customer engagement until we can see that a project's lead developer is fully sold on our product, otherwise we waste loads of time (which is essentially money) on ultimately fruitless retention attempts instead of using the time more productively on ideal customer opportunities.
Now it does depend on the nature of the product though. For a product used by only a small subset of a company (like our product), it's probably a bad strategy to sell to the execs instead of the users. But for a product like an ERP (think SAP, or Oracle ERP), these are deals worth USD millions (sometimes 10s of, or more) and convincing the execs is a highly (or possibly the only) effective strategy.
Yup, then the technical people have to deal with the bullshit and nightmare that is implementing the shitty thing that was purchased. Hard to get around this in large enterprises, someone just decides they're going to use some shitty tool (like that cloud provider no one uses but has great sales folks) and you just get a notice you have to migrate all your apps to the new thing in 3 months cos they got a better contract there.
The school district my kids are changes the parent app almost every year, its always a nightmare for everyone involved, I can't imagine what it is like to work IT in such a place.
I believe open source is approximately an order of magnitude larger than it would be if developers controlled their own purchasing. What FOSS introduced was the ability to use software without someone with a little power saying no, you can’t, because we won’t pay for it.
Jetbrains threaded this needle for years by having professional licenses tied to an individual with clauses for time and location shifting. So you could use their software at home, drive to work and also use the same license there.
And they priced it at around the cost of three tech books per year, which it is at least that useful for productivity. I suspect we would be in better shape now if others had copied their model. Rather than the (defunct) Microsoft model of ignoring home piracy and demanding commercial licenses from any company large enough to make it economical to fire off a cease and desist to them and demand back pay.
> Jetbrains threaded this needle for years by having professional licenses tied to an individual with clauses for time and location shifting. So you could use their software at home, drive to work and also use the same license there.
It's a very, er, "enlightened self-interest" model, because it makes me "sticky" as a customer, since I'm less likely to learn a completely different IDE for work and then use that one for my own projects and eventually ditch theirs.
My company gives each employee $500 per year for anything tangentially related to improving their job - training, subscriptions, etc.
We also get 40 hours a year that we can take off for skill development. It can be to learn something new or conferences.
Nice. We got told we should "have some pride" and clean the office on our own time.
I’d like to also see a group fund where the dev team collectively parcels out donations to open source projects the company relies upon.
"Give them the best possible chance at convincing the leadership. Make them look awesome for even bothering the leadership with a choice like this."
We made a "CEO Page" for this purpose:
https://www.rsync.net/products/ceopage.html
Is the link to the CEO Page under More Information meant as a trap to catch pinheads in or just a mistake? https://www.rsync.net/products/ceopage.html#:~:text=may%20fi...
This is how the likes of Slack, Postman sells, “Hey, 96% of your developers/team are already using it. It makes sense to buy it.”
"If they already use it, why should I buy it?"
It sounds like a trivial question to answer, but it just exposes the level of detachment that exists between who makes the purchase decisions and its users in SME context.
Because you want to control who uses it (offboard separated employees, onboard new employees automatically), integrate into your auth systems to make it easier for employees to access, get an SLA if something goes wrong, connect to your data auditing systems, etc, etc. Companies have a lot of needs outside of just the core functionality of a product.
You might want to understand the politics and business dynamics before you go too far down that route. You could just end up getting your product blocked and/or replaced with a competitor instead.
Exactly, you're selling inconvenience. Management usually has to work hard all day long to annoy the employees under them.
"Don't you want them to use it more securely, and with enterprise AI features?"
Wait - it’s not secure now? We’ll be banning it immediately!
"No, it's more secure! We have encryption, which means intermediaries can't snoop, but don't you want to be able to monitor what data goes out?"
etc. There's a laundry list of features enterprises care about, better spelled out in the sibling post.
"Well we have Bob from purchasing on the phone and he says we have to put this out for a bid first. And Alice from compliance wants to know, do you have [insert esoteric certification]?"
You really have to know who you are talking to and their motivations before you know what the right sales angle is.
I knew at one point some engineers who added RFC2549 to see if the salespeople were just being yesmen. A few years later I had similar problems with HSM salesman lying about Java support in their products so I can sympathize. Buying a product you cannot use without extreme effort is the pits.
One of them put in a bid to Cisco and got a reply back saying something like they were working on it but having some issues with the birds.
Somehow I knew what RFC2549 was without knowing what it was.
I used to be able to recite it from memory, but it’s starting to get mixed in my head with others, like 1918 which is the NAT RFC, and thus serious.
It why students get so much free software too.
That used to be the case much more strongly in the past. At least dominant players now much more often expect institutions to buy bulk licenses for their students, because if they don't, the students won't have practical knowledge for the job market in the industry standard tools.
I think this is also one of the hidden benefits of commercial open source and similar models: individual adoption grows corporate adoption.
Except for that whole every company that tries it ends up either not making money money on it, get Amazoned (where Amazon offers a hosted version and makes money), or ends up seeing the error of their ways and using a more restricted license and still struggles.
Agreed. There are better models to commercial open source that align better with business sustainability, like fair source. I was mainly referring to bottom-up adoption, not sustainability.
Amazon already has a relationship with your corporation, it's easy to buy their hosted elastic search
Even if the original elastic company offers it cheaper, or better, that's a massive hill to climb. Corporations don't care about costs, they care about pieces of paper, or less charitably nice dinners with the sales team.
For every AWS offering aside from maybe MySQL/Postgres Aurora and DynamoDB, there are better cheaper alternatives. You choose the AWS alternative because they are 80%-90% “good enough” and you have one pain of glass, one IAC implementation, one set of permissions, one point of governance, one account manager, one TAM etc.
That by itself is worth the extra cost for some organizations. While I’m a big fan of AWS as a technology provider and have been heavily in the ecosystem for 8 years, I’m no fan of the company or the organization as a former employee.
DynamoDB is actually an anti-product, and MySQL/PostgreSQL costs $10/month for a faster, more scalable version.
You consider PostgreSQL more scalable than dynamodb ? This is certainly a novel take. Since dynamo is hosted are you talking about a hosted pg as well or how even are we comparing this?
And even with Postgres, I doubt their definition is “multi AZ with a shared storage layer between data centers that is also fault tolerant and replicated across multiple data centers”. Meaning that if your database server goes down, your backup servers are immediately up to date because of the shared storage engine in the same region but the underlying storage was also replicated across multiple AZs.
Not if you need multiple databases for failover or read replicas. Aurora’s storage engine is head and shoulders above what you are going to get for $10
Clearly, yet many open source contributors just work for free..
I specifically said commercial open source, which is different -- one hopefully has a business model and the other does not need/want one. Working on open source outside of a commercial context has never promised compensation, and expecting compensation for it ends in pain.
this happens all the time at large companies with small teams, plus if there's a security team they hate it so that's always an angle to lean on "hey 400 people are using 12 different slack workspaces, wouldn't it be nice to manage them all from one corporate account?"
Obligatory mention of the SSO tax: https://sso.tax/
So how exactly are open source software stacks supposed to make money if not by withholding enterprise features from the free version?
There’s a reason they all do it, and it’s because SSO is one of the few features enterprises are almost universally willing to pay for.
Heya, I work for a commercial auth provider but we provide a free version with unlimited SSO connections. (Details in profile if you are interested.) So I have a bias.
There's a number of ways for open source software stacks to make money, but I agree that finding features that companies with money will pay for is a great one.
I think Patio11 said it once, but SSO feels now like HTTPS felt in 2015. Used to be super expensive, but now should be "table stakes".
Other ways open source companies can make money:
- hosting (offers that sweet sweet recurring revenue)
- support (especially SLAs, which pair nicely with hosting)
- other enterprisey features, such as integrating with enterprisey tools (DataDog, SIEM tools)
- other auth features like fine grained authorization (RBAC, ABAC, PBAC) and provisioning (SCIM)
- control planes (I see this with tools like Cerbos and Permit which both offer fine grained authorization execution engines that are free, but charge for the control plane)
- certifications (SOC2, FIPS, HIPAA, PCI). this might not make sense in all cases, it does depend on the tool
- custom feature development (better if this is pulling forward planned development rather than something unplanned)
It's not easy, though.
I wrote more on my personal blog about freemium[0] and open-source[1] business models.
0: https://www.mooreds.com/wordpress/archives/3621
1: https://www.mooreds.com/wordpress/archives/3438
The problem is there's a huge gap between "We are a small company, and don't care about SSO" and Enterprise.
The company I work for is in the middle - anything where SSO is gated behind "Enterprise" is not even considered by us. We don't need 90% of the other "features" under the Enterprise plans, and most aren't willing to custom quote us for Basic+SSO.
Withhold it from free versions, sure - but definitely don't lock SSO only behind the most expensive option.
Locking SSO behind the Enterprise option works. Your company is an outlier that can be ignored.
Companies of that size are common. It would in isolation even be profitable to serve them. The problem is if you introduce a middle tier that includes SSO, many enterprises will go for that instead of the expensive enterprise tier you want them to buy. Basically, you sacrifice medium companies as customers in order to chase after that sweet enterprise money.
Companies of that size are served by the "enterprise call a salesperson" offering. If you really don't need all of the other features you can probably negotiate a discount.
That makes sense, but I still think there are other features that can be gated behind enterprise to help make sure that doesn't happen while still providing SSO for smaller companies.
You can have user limits on the non-enterprise plans (Microsoft does this, for example, with Business Premium locked at 300 users or less), or gate other features behind enterprise: Have MFA across the board, but lock conditional access behind enterprise, lock more advanced audit logs & reporting behind enterprise, lock RBAC behind enterprise, or data residency, custom security policies, API limits, etc.
There are numerous other features that are non-negotiable for enterprises to help funnel them into the enterprise plan, while still being able to service medium companies with SSO.
I'd hardly call a business with between 150-300 employees, that cares about SSO but doesn't need the full suite of enterprise features an outlier, I'd imagine that's fairly common nowadays.
Maybe in 2015 it was an outlier, but SSO is now a non-negotiable and with many of these businesses on M365 business premium, which includes EntraID P2, SSO is now accessible to a large number of companies where it wasn't before. It's no longer some niche enterprise only functionality, it's a bare minimum for business SaaS.
The fact you’re unwilling to even consider a product with SSO behind the enterprise license is what makes you an outlier, and frankly probably a bad customer.
And if you’re trying to negotiate custom, non standard licensing when you’ve only got 300 employees you will likely be a noisy customer in perpetuity.
No offense, that’s just how I’m betting 99% of folks read your response.
> There’s a reason they all do it, and it’s because SSO is one of the few features enterprises are almost universally willing to pay for.
Also, anyone who's dealt with SAML knows it's like licking lead-based paint. It's the knowledge equivalent of antimatter, every line of code you write costing you a point of IQ.
SSO has to bring in monthly recurring revenue, to cover the monthly recurring disability payments to the many people who've lost the ability to feed and dress themselves after reading too much of the xml-dsig spec.
withholding enterprise features from free versions isn't the problem, the problem is charging extortionate rates for an important security feature.
> "Decouple your security features from your value-added services...If your SSO support is a 10% price hike, you’re not on this list. But these percentage increases are not maintenance costs, they’re revenue generation because you know your customers have no good options."
Problem is lots of SSO implementation will be dealing with some arrogant architects claiming you know nothing and their semi broken SAML is something you should implement for them for free - repeat for 100 times for each customer having their own way of breaking the spec or using something crooked.
It is getting better with Entra P2 or Okta as it is couple of minutes to configure if you use good framework in your projects.
But the tax was because of what I wrote about in first place.
This is why at work, we're encouraging and recommending to use some kind of SSO, but we're basing our cost off of the customers IDP.
Some "green" IDP like O365 OIDC, Okta, Entra and such are usually included without extra cost (and will be self-service soon, too). Some "yellow" - usually SAML - IDPs come at a fixed fee. We know them, we know they are weird, but we can deal with it.
Other things are flagged as red and call in hourly billed projects and recurring maintenance fees. Like, one customer has an in-house developed SAML IDP written in PHP a decade ago or so. I want our customers to use SSO, but that's a level of jank I'm not supporting for free.
Some of these seem iffy. Looking at one at random with a seemingly excessive increase:
Coursera: $399 per u/y -> $49875 per year [7], 12400%
So, I check out the footnote:
[7] Coursera requires a minimum of 125 users to access SSO pricing. As they do not have an Enterprise price listed, this price just scales their lower cost tier up to 125 seats.
Dividing by 125 shows the SSO pricing is $399, so exactly the same as the non-SSO pricing. I fail to see how this is an SSO tax.
It might be that there is an SSO tax as the Enterprise price wasn't available to them, but listing it as 12400% increase seems like a deliberate attempt at deception.
looks legit to me.
I've used to work in small startup with ~10 people. The owner was always happy to pay for tools to developer productivity. We did not subscribe to Coursera, but in the theoretical case we'd all want to, the pricing would be:
10 users, no SSO: $3999/year
10 users, with SSO: $49875/year
It's an SSO tax, and a super hefty too. We'd probably balk at it and chose the less-secure option instead. And the fact that we'd get extra 116 licenses we had no need for is absolutely irrelevant, there is nothing we can do with it at all.
Even in your example, and assuming that the only feature that the enterprise plan offers is SSO, that's not even close to a 12400% increase, that's a 1147% increase.
My point was that saying the minimum order is 125 seats for enterprise, and so claiming that the price for a single seat is increase by 12400% is being deceptive.
If you buy a six-pack of beer, you don't say "This is terrible! I only wanted one beer and this six-pack is a 500% increase in price!". If you only want one beer, you just buy the single beer and leave the six-pack on the shelf.
If there is an option to buy a single beer on the shelf, sure. But in this case there is no such option.
Imagine you _really_ wanted to try Foobar beer. So you get to beer distributor, and you find out that while each bottle is just $5, the minimum order is a crate of 144 bottles and they give no samples.
In this case, you might say: "Yeah, I really wanted to try that beer but there is no way I am paying $720 for that". It's exactly the same here.
(re 1147% vs 12400% - sure, maybe you could argue you should not look at a single license, but rather at a pack of 5 or 10 licenses... but this does not change numbers much for Coursera, it's still huge increase.)
The company I founded previous faced this problem - we were selling to a part of the development team that often had no clout in making financial decisions. We were able to sell to smaller companies and larger ones that happened to have people who had enough power to purchase. But the majority of companies had super long sales cycles where we had to work with them to prove out the cost savings to people higher up. Most of the time this went nowhere and cost us a ton of time. It wasn't the only reason the company failed, but a major contributing factor. Glad to see people talking about it because it's something a lot of small b2b companies face and there's surprisingly little advice on it.
This works if the users are able to use the product (in this case on their personal device maybe) first, and are part of the same organisation.
But what about cases where the user isn't directly related to the decision maker? Doubly so when it's a hard to justify purchase? (I.e. you're not selling bread or IBM machines.)
For example, say, a keyless entry fob for a car. The driver benefits immensely. The CTO of Ford may probably not even entertain a meeting ("Huh, what does he think, locks are bad or something?! What's wrong with a secure lock?")
Does anyone have any suggestions for how to approach such a situation if you developed the fob and now want to sell it?
In your scenario, you're looking at a bottom up approach. Instead of going to Ford, you start at the bottom of the food chain. Used car dealerships, auto body shops, and other places that sell/install accessories for your car.
A great example is remote starters. Same idea. Great for the user, not so much for say Ford. The first places I saw these being installed? Stereo shops would use it as a cross selling feature whenever they were selling something else to a customer. I could be wrong, but it took a few years for the manufacturers to start including remote starters as an add-on. Before then, it was all kinds of other shops selling and installing them.
But its a trench warfare type of deal. You have to get into the hands of the people who can install them, then work your way up to approaching dealerships and larger clients.
I've done this with an anti-theft device. Start small, then build your client base and use that as a springboard to get interest from larger clients.
Interestingly I'm currently doing a version of that except with top-bottom and bottom-up approach.
I.e. like you describe I the younger sales rep on the team am going bottom-up after the smallest guys. And my boss, the CEO is going after the top management. We're both selling the same thing but with different argumentation.
The idea is that the buzz of excitement will turn into consensus when everyone in the middle sees approval from the top and positive feedback from the bottom.
Just be sure your product actually works. Third party/aftermarket remote starters and car alarms are (were) nortorious for causing a varity of intermittent, obscure electrical issues. Not sure if it was the devices themselves, or the installation, or both.
Demonstrate that competitors are adopting fobs and try to build FOMO.
B2B2C marketplaces - especially ones that don't charge the "B2B" users, but take a cut of each transaction, and empower users to encourage transactions through a customized instance of the platform - are a fascinating "final boss level" for this mindset.
Your user is not your buyer, but they can be a distributed salesforce. You need to growth-hack not only for your penetration at the B2B level, but to give them the tools they need to growth-hack their own B2C client bases, with your product at the forefront.
That's a lot to build as a founding team, and occasionally it can be like herding cats - but it can be incredibly lucrative, because you have an incredibly low barrier to entry at the B2B level, but every account naturally scales with value delivered to the end customer.
For enterprises its not usually as simple as sell to the CTO. Some things you need that, if you are AWS or Azure, the CTO and some principle engineer are who you have to convince to move the whole 20k person org over. But for a lot of software its the Line manager or director who is calling the shots, or a division head since division A may use different software than division B.
This hits home. We're building business intelligence APIs around entity resolution, and the buyer/user split gets messy when you have engineering, product, and data science teams all involved.
Engineers immediately understand why matching messy company data is a nightmare, but executives just see delayed projects without grasping the technical complexity.
We're seeing more success lately with "your team burned N months on data matching that should've taken weeks" rather than explaining what entity resolution even is. We're talking to one company right now that's spent 10 years building their own entity resolution system and it still doesn't work well.
But even then, it depends on the company and what they're trying to do.
How are you guys reaching users with such a technical value proposition? Cold emailing engineers first and then expanding the conversation from there?
To be frank, that's the challenge we're working on now. To start, my partner and I were mostly tapping into our network for initial customers. Both of us have been in the Bay Area for 10+ years.
Now, we're working on more of an inbound strategy and have a bunch of ideas. We're debating on cold emailing, but as an engineer myself, I hate getting cold emails.
Be a middle man, charge a percentage like tiktok per sale.
This is a bit of a simplification of how enterprise sales works. A few extra dimensions are sometimes required. For "decision makers" their own personal view of reality may not in fact be accurate. You sometimes must vet that what they tell you (and may in fact believe) actually reflects the actual power dynamics of a big enterprise. There are extra dimensions to consider; The first is: are they in a cost center or are they generating revenue. The second is: are you trying to get new technology adopted or is this considered "standardized". The third is: who might perceive your product as a risk, or a threat to their power? These data points inform your sales strategy both in who you sell to, who you avoid, and when you might choose to engage a particular persona, when to go small and when to go big.
isn't the elephant in the room when the buyer wants you to collect data on the user?
best course: don't. they have a shitty structure so don't bother. find users who are also buyers.
Do what big companies do: sell your users!
This problem is why so many organizations will do an SSO tax.
Employees, by and large, all share three common desires:
* How do I get promoted?
* How do I get a raise?
* How do I not get fired?
Beyond those common desires are a constellation of more personalized that is specific for each salesperson and the cohort they target (I'm somewhat of an idealist in that I believe people are quite often strongly driven by meaningful non-capitalist, non-realist desires).
In any case, when you're working in enterprise sales, what you have to realize is that, regardless of what the desire is, what your corporate champion is "buying" is a way for them to achieve their goals and only incidentally what is good for the company, where your product is merely a proxy to accomplishing this.
Of course, companies also know this and anyone who has owned a P&L immediately recognizes that the sum of all things everyone wants far exceeds the resources of the balance sheet, thus, some selection process needs to be put in place to allocate scarce resources.
Your corporate champion is ideally far more aligned with you against the company than they are with the company against you and your job is to figure out how to win this selection battle together.
The core insight though, is that people are actually astonishingly bad at performing on this and it's actually quite easy for an outside sales person to become a subject matter expert for 3 core reasons:
1. Any employee usually only ever has a sample size of 1 whereas you have a broader peek into how this has happened across a range of companies industry wide.
2. Any employee, only a minor part of their job involves interfacing with outside parts of the firm responsible for allocating resources whereas you treat this as a core competency.
3. For any person, it's always easier to advise a 3rd party on what to do than to practice the same actions yourself.
What this means though, is that, as an enterprise salesperson, you should understand that your core value comes from developing subject matter expertise in how to help people in your industry get promotions, get raises and avoid getting fired and the product you're representing at the moment is merely the avenue through which you enable that to happen.
The best salespeople I've ever met always share a common core value that they deeply care about making sure everyone around them is getting rich with the faith that some of that money eventually reflects onto them but that's not what drives them. That's why so many immigrants and children of immigrants make such great salespeople, they've seen the material difference wealth has made on their circumstances and they want to spread that opportunity to others.
This is what I advise Founders who start Enterprise focused businesses. Fundamentally, you should be thinking about how do I get someone to VP/Director/Line Manager/Tech Lead 2/3/5 years earlier than if my product doesn't exist and how do you breathe this passion day in day out.
Agreed, with the modest addition of “How do I avoid unexpected hassles?” It shares a corner with not getting fired but is more about comfort than risk.
[flagged]