[statictype]

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)

Interested to hear what others think.

[llamaLord]

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.

[hitekker]

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.

[1] If you read this far, check out ChuckMcM's view on layoffs at Google: https://news.ycombinator.com/item?id=38384254

[lelanthran]

> 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?

[llamaLord]

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.

It's more akin to the Chinese concept of Guangxi (https://en.m.wikipedia.org/wiki/Guanxi).

The problem is that where Guangxi ends and corruption begins is a VERY murky question with no clear way of finding an answer.

[whatshisface]

Guess how it works in third world governments!

[vasco]

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.

[backwardation_b]

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.

[verve_rat]

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.

[doctor_eval]

Agree. I used to say that my biggest competitors were my own customers.

[BadHumans]

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.

[doctor_eval]

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.

[23B1]

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!

[Terr_]

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.

[0] https://news.ycombinator.com/item?id=39188090

[wmf]

In my experience this "anti-pattern" is the enterprise software business. If you don't want to do that just don't try to go enterprise.

[pm90]

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.

[23B1]

Unfortunately it's never this simple.

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.

[em-bee]

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.

[23B1]

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.

[Terr_]

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.

While I've seen its historical accuracy questioned, something about this satire from Pentagon Wars still resonates: https://m.youtube.com/watch?v=aXQ2lO3ieBA

[em-bee]

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)

[hiAndrewQuinn]

#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.)

[jjen_abel]

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

[bitwize]

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.

[vasco]

Big customers don't hijack your roadmap. Weak visioned product teams that can't say no to sales are the ones that hijack your roadmap.

You are not forced to say yes.

[doctor_eval]

It’s not remotely that simple.

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.

It’s a balancing act, nothing more or less.