Why enterprise software is such a pain in the ass

Buying a big chore

You buy an expensive piece of enterprise software for your growing business. It’s nice and modern: cloud-hosted, SaaS model, fancy web UI with snazzy animations, integrates with Slack and Outlook and a bunch of other software that sounds valuable, and it’s got a nice logo. More importantly, it does something you care about and your business needs (maybe it tracks inventory, or provides some accounting function, or instruments marketing channels—doesn’t matter for this post). Now you have to “implement” it, which more or less means “get it set up and start using it.” Doesn’t seem like it should be too bad, right?

But then it takes, like, 3 months. You’d think it would look like “sign up, give some people access, flip a few switches, and get to work,” but it never is. Even the friendly and helpful implementation team the vendor provides you outlines a multi-phase plan for configuring, testing, and rollout. There’s a dizzying set of permissions and roles to manage, “workflows” to customize, taxonomies to configure, and so on. ChatGPT tells you that the three features you bought the product for will work, but only if you add three custom fields and rig up a Rube Goldberg machine to them. You want it to email you when something important happens, and it presents you with an entire system for defining business rules; don’t worry, the implementation folks can walk you through it. By the time you’re ready to actually use it, it feels like a marathon.

You get that some of this is intrinsic. For example, you really do have a bunch of users who have different roles and you have to set them up right, and perhaps the job the software actually does is complicated on its own. But most of it seems like a bloated system full of configuration and abstractions you don’t need, stuff that has little to do with why you bought the software in the first place. You are hacking through a jungle of complexity, wondering if you bought an accounts payable system or a programming language for describing your requirements. You spend your energy operating the software instead of using it.

The $500k feature

The thing to understand here is that the software was designed for a company bigger than yours, even if you’re right smack in the middle of the vendor’s target bracket. This is just how B2B companies are wired: their biggest customers completely dominate everything about how they work, from their customer solutions teams to their feature set. And really big customers want big, complicated enterprise things.

Here’s how it happens: the vendor builds some software that does [whatever thing the software does] and gets some customers. Then along comes a Fortune 100 prospect. They submit an RFP that asks questions like, “Does your software support restricting which content a user can see based on their current geographic location?” The product managers think, “No, we’ve never thought of that and no one’s asked for it. Is that even a good idea?” But the deal represents about half the vendor’s ARR, so they build it, along with 6 other oddball asks. This keeps happening, so the product gets more complex. To support it, the implementation and solutions teams grow with it.

Worse, now when someone says, “Wait, we’re being asked to implement separate approval chains based on business unit. That’s going to be so hard for customers to understand,” someone else says, “Don’t worry, we’ll just train our solutions team on it and they’ll help.” Once humans can explain the product, the product no longer has to explain itself; the army of consultants becomes part of the system, and you couldn’t self-service it if you tried. And all that lets the vendor target even bigger customers.

It gets worse: when the system gets complicated enough, customers start dedicating full-time staff to administering it. Sometimes this is justified by the business value the tool provides, and sometimes it borders on absurd. But either way, that person becomes a feedback conduit to the vendor. What should they build next? They rarely hear from the end user, who says things like, “Why is this so many clicks? Make this easier.” Instead, they hear from the administrator, whose complaint is, “It needs to automatically reassign document ownership when someone changes departments.” Add in IT demanding elaborate deployment and data-governance options, security asking for ever more granular controls, compliance teams imposing sophisticated consent tracking…you can see how pretty soon it’s hard to even see the business value through the clutter of enterprise mumbo-jumbo.

It’s hard to measure the cost of this kind of bloat, so most companies just don’t. Their customers complain that the system is clunky, slow, and difficult to understand, but if the vendor ever removes any of the complexity, its biggest customers will throw a fit, so that’s not even an option. It’s a trap.

It doesn’t have to be like this

The siren song of really big customers is hard to resist; they can make or break a vendor’s whole business, and their logos look great on the website. But sometimes you can grow your business by leaving money on the table, or by simply being more disciplined about who is and isn’t a customer. Simplicity is a sales strategy, and in our view, an underused one. Those really big customers often really do need all that stuff, and they’re willing to pay for it in money, time, and energy. But you aren’t that big, so you shouldn’t have to.

Staying simple sometimes means saying no to that $500k feature that two companies in the world need. A vendor can add the administrative tooling most of their customers need (every product needs some; this isn’t a screed against configurability), and turn down the big complicated stuff that bog the system down for everyone else. Vendors can build good defaults, make the product easy to self-service, so they don’t need a huge implementation team. Don’t trade the usefulness of your product for the esoteric demands of an RFP.

At Tachline, we’re in a busy market (sales enablement) with a simple pitch: we’re what you need when you’re not a huge company. You just want to get to work. Not chasing that jumbo deal frees us to build the right stuff for a huge class of customers. Our stakeholders are the people who use the product, and so our job is to make the software work better for them, not the administrators and IT departments you don’t even have. This results in a product that’s fast, easy-to-use, and quick to set up. We think this is a winning formula, and we wish more software vendors would try it. Enterprise software shouldn’t be a pain in the ass.