We routinely sell mostly to large enterprises. Yes, its not proportionally more difficult than selling to SMEs.
However the problem with enterprise accounts are:
1. They hijack your roadmap. You go into danger of building one-off features and bespoke software
2. Your risk is concentrated into fewer accounts. When you lose an enterprise customer you risk disrupting your cashflow and quarterly targets
3. If you dont yet have product market fit it becomes more difficult to achieve it (related to point 1)
There's also the element of what I call "structural corruption". This isn't "money in brown paper bags" style corruption, as much as it is key stakeholders at customers having existing relationships with certain vendors, and having built their position at the company they work at based on being subject matter experts in that vendors tools.
Try breaking in to an established market as a new product, even if you have a distinctly better value proposition.
You will face a near impenetrable brick wall of critical customer stakeholders who are using the incumbent product and have very strong vested interests in NOT changing solution, no matter how much better your solution may be.
Another word for the corruption you speak of is friendship.
The key stakeholders and their vendors are friends. They know each other, they get along, they get the product, and like you said, they've built their clout on the know-how of people and product. To choose another vendor, is to disrupt that friendship, and its ancillary benefits, e.g., a ring of trust and a status quo.
I wrote this comment because I've been on the inside. It doesn't feel like corruption when you're in it. It feels like you're getting work done with people you like, just ignoring silly process and distractions that make you think too hard and feel weird. Seeing things differently requires an outside power to intervene, or for the few key insiders to have an ethic that forces them to question their good time and each other.
Most groups of people, not just businesses, punish ethics in pursuit of collective self-interest. That is indeed corruption but it exists so systemically and so personally that I would first call it human nature.
> The key stakeholders and their vendors are friends. They know each other, they get along, they get the product, and like you said, they've built their clout on the know-how of people and product.
It's not even a friendship in many cases: This is how CEOs fail upwards, after all. It's better to take on a CEO/vendor with a known incompetence level than take a risk on an unknown.
Look at it from this point of view: you're the customer, you have an existing supplier, who frequently fucks up. Due to the frequency, you already have controls in place to mitigate the fuck ups. Do you really want to try someone new with different fuckups that will get past your existing controls?
To be clear, I 100% agree. That's why I refer to it as "structural". No individual or even group of individuals is actively doing anything corrupt, but the overall structure creates an environment where self-interested individuals create an outcome that is VERY difficult to distinguish vs the outcome you would get from more obtuse corruption.
More often than not the whippersnappers that do sales and think they have a better product we should replace, 1) don't actually have a better product and 2) assume there's no cost to migrate and re-train.
And even if your thing is 5% better at some core functionality, if it misses important integrations or security controls and will take a year to replace, it makes no sense to switch.
This may be relevant to a space with a large(r) amount of mature competitors, but I am not sure it exists in smaller (less mature) markets to the extent it impacts your ability to sell.
You need a considerable amount of internal political power to push away a new “competitor”, which generally requires time (maturity).
This is not to say it does not happen, but I think the markets where this is a key element of friction in selling possess enough capital to win-over entrenched “rent-seekers” if needed.
This is all true, but it misses one nuance, your "competitors" might not be other products/services. In an untried space they are at likely as not to be manual processes emailing spreadsheets around.
Enterprise hijacking your roadmap is undeniably true. We had an enterprise client that would regularly say "perhaps your company is not fit to support an organization of our size" whenever they didn't get the feature they wanted pushed to the top.
This is 100% true, and what’s worse is that in many cases, due to the flawed internal processes that got the customer to request the feature in the first place, it will most often be poorly considered, break all kinds of valid assumptions (ie, be hard to implement), and will often not be used. I don’t know how many features I shipped for UAT only to never get feedback, but it happened so often that I ended up making it part of my services contract that if they don’t UAT within a specific time then I get paid regardless.
And while you’re working on this useless feature, you’re distracted from your own road map, which is (hopefully) well considered and likely to lead to new clients. So it’s a triple whammy - tech debt, wasted time, restricted progress.
This is why I’m not interested in enterprise any more. I want to do quality work that helps my customers. That attitude alone makes it easier to sell to midrange clients.
Yep. Healthy businesses should have a diversified revenue stream.
The hardest thing for me in the CRO role has been getting product to understand this, which pisses them off – but if we don't, the only way to survive will be to change the roadmap at every shift in the market, which will piss them off even more!
With respect to "highjacking roadmaps", recycling a comment from a few days ago [0]...
____
> > So many vendors are focused on charging money for customer specific features or adding new features to win new tenders.
> In turn, this enterprisey anti-pattern creates unfocused products which can be configured to sort-of-solve every niche customer requirement that might block the sale.
> The result is a massive ball of muddy configurations and feature-flags, so that learning isn't very portable and backend integrations are very painful.
Well it’s possible to support enterprise features as part of your product roadmap without it being “hijacked” but this requires building an understanding with the client that they can’t get everything that they’re asking for right away, that they should be open to a back and forth when it comes to new product features.
Often the account managers have a Golden Goose attitude and don’t want to say no. But it’s possible to build healthy relationships that allow this to work.
PMF is a bit of a lie in that sense; there's no such thing as perfect fit, and sometimes we might have to solve for one or two major customers before we have enough runway to built the perfectly-focused roadmap product desires.
that's my thought. first customer: build anything they want. second customer: add everything they want, and pay attention to what they don't want. third customer: ok, now we are starting to see a pattern. see if we can satisfy them without any custom features. fourth: ok, this is our product, take it or leave it. new features only if more than half of all customers want it. fifth: by now the first customer may be the odd one out. need to find a strategy to deal with that.
I mean I hate to say this but it's the stuff they teach in CS and PMI: modularity, abstraction, loose coupling, thorough documentation, version control, and design-for-change.
It's 2023 and there's a long ton of off-the-shelf tooling that makes all of this much easier than it was ten years ago.
Modularity and abstraction come up against some limits when different customers have incompatible domain models, and thus different ideas of what your product ought to be.
not in the undergrad courses that i have taken. but that was a few decades ago when computer science covered anything related, and the degrees have diversified since then.
the problem with modularity and abstraction is that in order to make that work you need to step back and be able to build tools and frameworks that are completely independent of customer requirements.
ruby on rails is a successful example of doing that, and other frameworks that came out of some industry need. but a startup who is just getting their first customers doesn't have the resources for that, but also in my opinion are 5 customers not enough to make that move. maybe after 10, or after a few years of working you have accumulated enough experience that you are able to create something like ruby on rails that is modular and abstract enough to really be able to handle every need a potential customer might have.
(basecamp was founded 1999, RoR was released 2004. basecamp as a product came out in 2005. so it took roughly 5 years of consulting work for RoR to emerge)
#1 put my current employer through a lot of pain about a decade ago, and we're still digging ourselves out from that quagmire in a few ways. Despite that pain, I still give them a lot of credit for not prematurely optimizing and building a fully mature product before confirming market viability.
#2 you can live with if you don't let it get out of hand. Watch out for one enterprise customer dominating 80 or more % of your revenue though - monopsonists are as big jerks as monopolists are. (Monopoly = 1 seller / ∞ buyers, monopsony = ∞ sellers / 1 buyer.)
1. customer/market should never dictate product roadmap -- important to say no OR show why it's coming in next year or so
2. true for anything, there is always risk -- easier to mitigate by ensure healthy pipeline -- down-market churn is so much more rampant
3. i actually think it's opposite, you can be further away from product/market fit in enterprise as services add value outside product AND far more forgiving -- they'll give you time to sort
There's also the fact that enterprise purchasing decisions are often made on the golf course. My coworkers were lamenting that they had to deal with Oracle on a previous job and I explained it to them thus: why is Donald Trump orange? Donald Trump is orange because his buddy owns a company which makes a line of fake tan products. The products don't have to be any good; Trump uses them because his buddy makes them. His buddy gets promoted or at least attracts attention, and Trump gets someone powerful he can call in a favor from if needed. And that's how purchasing decisions for big-ticket enterprise software like Oracle get made: the head of sales of Oracle becomes buddies with our CTO on the golf course and convinces him to use the database his buddy represents. Not for any technical reasons... to help your buddy and your buddy will help you.
If you’re relatively small and you have a significant enterprise client, they have multiple ways to make your life a misery.
Are there times I wished I’d stood my ground? Yes, absolutely. But, worst case, it would have meant sacking people, and potentially a long period of time struggling while we made that revenue back.
Then there’s the reputations damage it can cause, and (at least in my case) the potential loss of referrals, and loss of a top tier referee.
This touches very very briefly on it, but the support load of enterprises is very different from that of small businesses.
If you're targeting small/mid-market then you want to invest a lot in docs and self-service support options, have a many-hands approach to triaging support, and implement a well-oiled, human-driven escalation process to more hands-on technical support paired with clear limits or dis/incentives for those escalations in the support contract or product terms.
The more small businesses you serve, the more people you'll be interacting with who have a low level of understanding of your product paired with a lack of time to focus on drilling into issues. You can't scale account services or customization as easily, but you still want to listen to and serve smaller customers when many of them ask for the same thing or communicate the same product deficiencies.
If you're targeting enterprise then you want that investment tilted on the account management and senior live support sides. They're more likely to need customized solutions, and support and documentation for those solutions will focus more on them than anyone else.
They're also more likely to show up with their entire department (or org) on fire and demand a senior on-site presence or similar level of sustained round-the-clock commitment, including handoffs across time zones and geos, until the fire's out.
They're both hard, but if you aren't careful and proactive in having good self-service content then you'll hit scaling issues very quickly with small businesses. Like, when an enterprise customer calls support there's a very good chance the customer calling knows what a web browser is, and a pretty good chance that they've had some onboarding on what the product itself is. Neither is nearly as likely on the small business side, and they'll all ring the phone and drain time and resources just the same. Pair that with needing more SMB logos to drive the same revenue as enterprise and your support channels will be overwhelmed if you don't have the means to helpfully deflect.
The weakness of SMB is always going to be the high touch stuff, and they’re ruthless cost cutters mostly, it’s harder to drive loyalty as easily as you can with enterprise.
It’s the mid market that I think however is more lucrative long term, because businesses with between 50 million and a billion in revenue are a bit of a sweet spot, as they are likely to have some experts but they’re also growing, which means as their business grows you can grow with them, ideally.
That said, sometimes with SMBs you snag a rocket ship that grows by 100x or more and they sudden become a very top tier customer
I agree with you about self service. I wouldn’t even consider building a SaaS today without it being 100% self service. As much as possible, any time you spend with the customer needs to be adding value to the relationship, not repeating what you did before.
That said, another side of this is that the sales cycle is typically much, much longer in enterprise, and can take significant effort - especially if you have to go through an RFI and RFP process, internal onboarding, secops audit, etc. And there’s really no guarantee you’ll win. You could sink 6 months into it for nothing. You might just be the stalking horse for some other vendor.
An enterprise sale can easily take 6 months. So one needs to consider, how many mid- or low- tier customer could you get in that time? What is the value of that over time?
> They're also more likely to show up with their entire department (or org) on fire and demand a senior on-site presence or similar level of sustained round-the-clock commitment, including handoffs across time zones and geos, until the fire's out.
This is a great example of “doing things that don’t scale”.
When you’re a scrappy startup servicing a big time enterprise client, you get to a be star when shit hits the fan. Rather than getting a pre canned “we’ll get back to in $SLA_DURATION” response, you craft an answer and solution that actually addresses their issue. And you do it off hours, researching things that aren’t even directly your problem.
Yeah isn’t that the small vendor life? When you are the big fish everyone gets the f-off response but when you are small you have to help even if it’s not your fault or problem
> The more small businesses you serve, the more people you'll be interacting with who have a low level of understanding of your product paired with a lack of time to focus on drilling into issues
Even assuming the customer resource understands the technical aspects of the software, there's a time commitment on the customer side that's more difficult in SMB.
A large enterprise can assign >= 1 FTE to an important project.
At an SMB, you're usually working with someone who's wearing 5 other hats, and they're still the most responsible resource for your product on the customer side.
Small business practices used to work for small enterprise sales, e.g. a manager or individual can buy if the sale is within the limits of their credit card or discretionary budget.
But now software sales to enterprise has to run through a lot of security and audit and configuration management approval, the days where an individual or group within a larger enterprise can just buy and use software are pretty much over.
I sort of assume that when you aren't a SaaS and you aren't phoning home, the old rules still basically apply. However, making SaaS the normal model of business closes this off for many companies.
That only works for companies that are small enough not to have stringent security requirements, and that aren’t covered by any regulations about things like data residency.
Here’s a rule of thumb: if the saas company is much bigger than your company, chances are you can easily use them, because they’ll have all the necessary compliance boxes checked, documented, and certified. If they’re much smaller than your company, it may be a different story.
At least for our product, we only go for the largest corporations (think top 1000 companies in the world).
IMO it’s way easier in many respects to network and build the product — At least for us.
Simple way I think about it - I have max 1000 people to make happy. If I can get 10 to be super happy, the other 1000 will follow. If I can get 3-5 happy we’re a $100m company, 30-50 a $1B company; etc.
It helps for us because I know a lot of these folks already, so it’s basically just making a product my friends love.
> It helps for us because I know a lot of these folks already
I'm not in sales, so to me this sounds a bit like that "how to draw an owl" meme.
Would this strategy work if you didn't have lots of friends high up in those companies?
I'm just recalling one of my colleagues at sales who had just been in the second 1 hour meeting with multiple regional directors of some big company, trying to sell our SaaS product for $50/month for use in one of their local departments...
I found a cofounder who knew the space super well (one of these folks). It’s a niche market, for people who manage massive budgets. We can probably save millions per year right out of the gate, so it’s an easy pitch.
“Hey, we designed this for you. Here’s how we save you $X per year. Plus here’s some references. We want $Y and you’ll save $Z net.”
Now, I chose this field because I had tried other side projects and businesses.
Worst one I had was a website called easy-a.net - we FOIA requested universities for the grades for every class for 5-10 years. We could then predict people’s grades & how much effort it’d take for a given semester based on a small sample of real data from that user.
Anyway, we had idk 250k students using it across 10-12 universities. Was crazy to see my whole campus try it out and I basically tossed it together in a night. That said, made no money. Trying to charge was pointless — college students don’t pay. Loved the product; no real net revenue (broke even)
I’ve done that a few times with problems I’ve had. And simply put, I didn’t want to do sales this go around (though it’s still necessary). This time I just picked super high value customer & figure out how to maximize value to them.
I started with who I wanted to help, then figured out their biggest issues.
My startup sells to news organizations. Several mentors have suggested that we don't bother with mid-market organizations and just focus on the biggest ones. The reason is that the biggest organizations are more capable of doing integrations, whereas midsize outlets are (to a surprising degree) held together by duct tape and baling wire. They are loath to integrate any new tech that might cause or reveal brokenness in their systems.
We have had some success with small/midsize organizations, but it does seem like the value-for-effort is perhaps best with large publishers (partly because the little guys pay very little in comparison).
I disagreed with the premise of the headline but agree with the conclusion:
> Success is not about finding an 'easier' path but mastering the distinct games and deciding which is best for you, your market skills, and the product you’ve built.
1. They hijack your roadmap. You go into danger of building one-off features and bespoke software
2. Your risk is concentrated into fewer accounts. When you lose an enterprise customer you risk disrupting your cashflow and quarterly targets
3. If you dont yet have product market fit it becomes more difficult to achieve it (related to point 1)
Interested to hear what others think.