Stewart Butterfield has told the story of Slack’s origin enough times that it’s become startup folklore. The product wasn’t meant to be Slack. It was meant to be a gaming platform called Glitch. The team built an internal communication tool to coordinate their own work, realized nobody wanted Glitch, and pivoted to selling the tool. But here’s the part that gets glossed over in the retelling: in the early days, Slack almost became enterprise groupware. Big companies came calling with big budgets and big feature requests. Compliance tools. Admin dashboards. SSO integrations before the core product had found its rhythm. The team had to make a deliberate choice about whose problems they were actually solving.
That choice, more than the pivot itself, is what determined Slack’s trajectory. And it’s a choice every startup faces, usually without realizing it’s even happening.
1. The High-Budget Customer Who Wants the Wrong Product
YouTube launched in 2005 as a video dating site. That’s not a joke. The original tagline was “Tune In, Hook Up.” When that didn’t take off, the founders opened it to all video. What they found was that users were uploading everything, including clips of copyrighted TV shows and music videos, which created an immediate legal nightmare. But the real inflection point came when they noticed a specific kind of customer circling: media companies who wanted to license the platform as a private video hosting service for their own content.
This was real money from credible buyers. It would have turned YouTube into enterprise software for media distribution. Instead, the team bet on the messy, copyright-infringing, user-generated chaos. Google bought them for $1.65 billion in October 2006, barely 18 months after launch. The media companies who wanted to license the platform are now YouTube’s suppliers.
The lesson isn’t “ignore enterprise customers.” It’s that early enterprise interest often signals that incumbents recognize a threat and would rather co-opt it than compete with it. Taking that money means building their product, not yours.
2. The Power User Who Represents Nobody Else
Spotify’s early growth in Europe was driven heavily by music obsessives: people who wanted lossless audio, obscure catalog, and deep control over their listening experience. These users were vocal, they were engaged, and they were completely unrepresentative of the mass market Spotify needed to reach.
The power user trap is insidious because these customers are the easiest to talk to. They show up at your office. They write long emails. They join your beta programs. They feel like signal because they’re so loud, but they’re often noise. Spotify could have built an audiophile product with high-fidelity streaming, advanced equalizers, and complex library management. Instead, they built a product that a person who had never thought much about music could use in thirty seconds. The Discover Weekly algorithm, which launched in 2015 and became one of Spotify’s most celebrated features, was explicitly designed for passive listeners, not curators.
Building for your most engaged early users is comfortable. It’s also how you build a product that only your most engaged early users will ever use.
3. The Customer Whose Problem You Can Solve But Shouldn’t
Slack’s near-miss with enterprise groupware wasn’t just about feature complexity. It was about whose workflow would define the product’s DNA. Enterprise IT departments in 2014 wanted a product that looked like a regulated communication tool with audit trails and admin controls front and center. That’s a legitimate need. It’s just not a need that produces great software.
When you build for compliance officers before you’ve built for the person sending messages, you get a product that’s technically capable and spiritually exhausting to use. Butterfield’s instinct was to build something people genuinely wanted to open, and then add the enterprise features on top of that foundation rather than building the foundation around them. Slack did eventually build robust enterprise capabilities, but by then the product’s character was set.
The principle holds broadly: there’s a category of customer whose problem you are technically positioned to solve, but whose requirements would reshape your product in ways that make it worse for everyone else. Identifying that customer early, and consciously deciding not to optimize for them, is one of the harder strategic calls you’ll make.
4. The Validator Who Becomes a Ceiling
Many startups in B2B software land one large, prestigious customer early and spend the next two years building that customer’s roadmap. This feels like success. The logo is impressive. The contract covers runway. The team feels validated.
What’s actually happening is that the startup is becoming a custom software shop for one client. The features they’re building are too specific to generalize. The sales process they’re learning is calibrated to one buyer’s procurement cycle. The product increasingly reflects one company’s internal politics rather than a real market need. When that customer eventually churns, or gets acquired, or changes their internal champion, the startup discovers it has spent two years optimizing for a segment of one.
The tell is usually in the feature requests. If every request from your anchor customer starts with “we specifically need,” rather than describing a problem, that’s a customer who is directing your engineering team rather than informing your product thinking. There’s a difference between a customer who helps you understand a problem more deeply and a customer who is effectively outsourcing their internal development to you at a discount.
5. The Customer You’re Afraid to Lose
The most dangerous wrong customer isn’t the one who wastes your time. It’s the one who pays enough that you’re afraid to tell them no.
This is where most of the real damage happens. A customer who represents thirty percent of your revenue has thirty percent leverage over your roadmap whether or not anyone acknowledges it out loud. Decisions get made, or not made, based on whether they’ll upset that customer. Hiring gets shaped around their technical requirements. The product vision slowly bends toward keeping one relationship intact.
The practical answer, which is easier to say than to execute, is to treat revenue concentration as a risk metric the same way you treat technical debt. A customer who represents more than fifteen or twenty percent of your revenue is a structural vulnerability, not a success story. The goal isn’t to fire them. The goal is to grow fast enough that their share of your business shrinks, which means consciously prioritizing the customers who represent your actual market, even when those customers are less immediately lucrative.
Slack, Spotify, and YouTube all survived their wrong customers by making explicit choices about who they were building for. None of those choices were obvious at the time. The money was real, the customers were credible, and the path of least resistance led straight toward the trap. The companies that didn’t make those choices are the ones you’ve never heard of, because they became bespoke solutions for somebody else’s problem instead of products for everyone.
