The Direction of Overloaded Products

You've probably read the standard advice by now that says focus on one problem, solve it perfectly, resist the urge to build a long list of features, because a “crowded product confuses people” and a “narrow one earns trust.”

I want to complicate that advice rather than repeat it, because too many features can in fact be a competitive advantage, and the only thing that decides is the direction.

Think about why you'd trust a professor of medicine who also practices as a doctor more than you'd trust a doctor who also happens to be a mechanical engineer and a weekend chef. The professor's second credential deepens the same claim you already believed — more medicine, aimed at the same question you came in with — while the engineer-slash-chef's extra credentials answer questions you never asked, so instead of adding trust they add noise you now have to sort through before you can even evaluate the one credential you actually care about.

Products work the same way, which is why "cut the noise, reduce the offer, focus" is decent advice but also incomplete advice because it's right that unrelated capability confuses people, but it treats all added capability as unrelated, when the split is between capability that drifts outside what the customer hired you for and capability that closes a gap inside it. Add the first kind and you get confusion. Add the second kind and you get something closer to a moat. Both look like "more features" but they produce opposite outcomes, which means the deciding question is which direction you're adding it in, and that direction only makes sense once you know the job your customer hired you to do.

Jobs-to-be-Done theory answers this part better, because it starts from the observation that people don't buy products, they hire them for progress on something specific, the way commuters in the famous milkshake study weren't buying a dairy dessert at eight in the morning, they were hiring something one-handed and slow enough to finish that it would keep them full and occupied through a boring drive to work. The product team have landed on "milkshake" by asking what an eight o'clock commute actually needed, and that's the same question every team should be asking before they decide whether their next feature is drift or depth.

A job is also almost never one clean step — it's a sequence, something closer to noticing the need, deciding what to do about it, preparing, doing it, checking that it worked, and cleaning up afterward — and most products grab one or two links in that chain while leaving the rest for the customer to solve alone, usually by stitching together a second tool, a notebook, and a half workaround to cover whatever the product left out. That stitching costs the customer something even though nobody puts it on an invoice, and once you see that cost, you can see the entire argument that bad overload adds capability that has nothing to do with the job, while good overload closes the gaps still left inside it.

Bad overload is the feature shipped because a competitor has it, or because it demoed well in a meeting, or because one unusually loud customer asked for it once, and every one of those features becomes a small tax on the customer's ability to describe your product in a single sentence, a tax that compounds until they can't describe it at all and eventually stop trying to.

Good overload on the other hand looks identical from the outside — with more surface area, more capability, a longer feature list on the same landing page — but it's aimed entirely at closing the gaps inside the job you already own, so the customer never has to leave, never has to remember a workaround, never has to open a second tool just to finish what the first one started, and that difference in aim is the entire reason one kind of overload becomes a moat while the other becomes a liability.

It's also cheaper than it looks to be the one who closes those gaps, because owning one more step of a job your customer already trusts you with is nearly always less expensive than acquiring a brand-new customer for some narrow, unrelated job — you already have the relationship, the data, the support history, the login, everything a new acquisition would cost you to build from zero. And there's a second cost sitting underneath that one, a coordination cost that is the tax of moving information between tools, re-entering the same data twice, losing a step in some handoff nobody was watching closely enough to catch.

If you sell that then you are selling a removal of a friction the customer had gotten used to living with, and people will pay more for the removal of a friction they'd normalized than they would pay for the feature sitting on its own.

Once a product owns enough of a job from start to finish, it starts being the first choice for users, which is a far higher bar for a competitor to clear than simply undercutting your price, and it's the reason people keep using an all-in-one system even when some standalone tool does one piece of it slightly better in isolation.