Picture the scene: it’s 2008, and the team at 37signals is staring at a support queue full of feature requests. Power users want more granular permissions. Agency clients want invoice management baked in. A handful of vocal customers want Basecamp to become a full project management suite with resource allocation, time tracking, Gantt charts, the works.
So the team built some of it. Not all at once, but incrementally, the way you do when you’re trying to make customers happy. Each feature shipped felt like a win. The complaints slowed down. The power users sent thank-you emails.
Then Jason Fried and David Heinemeier Hansson looked at who was actually paying them, and realized they had been building for the wrong people.
The Setup
Basecamp had a problem that most founders would kill for: it was genuinely popular. But popularity created a specific trap. The customers who complained the loudest, who sent the most detailed feedback, who showed up in the forums and wrote long emails, were disproportionately the most sophisticated users. Agencies running ten simultaneous client projects. Freelancers who used every feature and wanted twice as many. Consultants who had opinions about everything.
These customers were articulate, engaged, and totally unrepresentative of the people actually generating the bulk of Basecamp’s revenue.
The silent majority, the ones who weren’t filling out feedback forms, were small business owners, solo operators, and teams of five who just needed a place to put stuff and keep track of who was doing what. They weren’t complaining because the product worked for them. They didn’t need Gantt charts. They needed something that didn’t require a manual.
What Happened
The tension came to a head around 2012, when 37signals (later renamed Basecamp) started unpicking some of the complexity they had layered in. DHH and Fried have been candid about this in their writing and interviews. The company eventually rebuilt Basecamp from scratch, launching Basecamp 3 in 2015 and then a ground-up redesign in 2019 with Basecamp 3’s successor, all oriented around simplicity for the non-power-user.
They removed features. They simplified permissions. They made opinionated defaults instead of giving everyone a settings panel. Predictably, the power users complained again. Some left.
The business got healthier.
This is the part that doesn’t fit neatly into startup mythology. The story we tell is that you should obsess over customer feedback, respond to every complaint, build what your users ask for. And if your users are representative of your target market, that’s reasonable advice. But the customers who complain the most are almost never a representative sample.
Why Vocal Customers Are a Biased Signal
Think about who actually files support tickets and feature requests. They have to care enough to write it down. They have to be frustrated enough to invest the time. They tend to be heavy users because light users who hit a wall usually just leave quietly instead of asking for a fix.
This creates a systematic distortion. You end up optimizing for retention of your most engaged users while slowly degrading the experience for everyone else. The product gets more powerful and more complicated simultaneously. The onboarding gets worse. The value proposition blurs.
There’s a related trap in B2B, where the person complaining is often not the person paying. An IT administrator filing tickets about integration requirements is not the CFO who signed the contract and not the frontline employee who uses the tool for twenty minutes a day. Build for the administrator and you might win their approval while losing the renewal.
This is exactly what happened to a generation of enterprise software companies before Salesforce simplified CRM. The products kept getting more capable because power users kept asking for capabilities. They got too complex for the people who were supposed to use them daily. Adoption cratered. Implementations failed. Companies blamed change management. The real problem was that the product had been co-designed by the loudest voices in the room, who were never the primary users.
What You Should Be Building For Instead
The corrective instinct is to say: ignore feedback. That’s wrong too.
The right move is to segment your feedback ruthlessly. Not just by customer tier or contract value, but by how representative that customer is of the person you’re actually trying to serve at scale.
When Basecamp stripped out complexity, they weren’t ignoring their users. They were making an explicit bet about which users mattered most for the long-term health of the product. The silent satisfied customer who renews every year without a single support ticket is worth as much to your business as the power user writing detailed bug reports, probably more, and they have needs too. Those needs are just harder to hear.
Finding them requires work that doesn’t feel like product management. You have to look at behavioral data: where do people drop off during onboarding? Which features do most users never touch? What does the median session look like, not the power user session? You have to talk to customers who aren’t complaining, which means reaching out to people who have no reason to respond to you.
It also means being honest about who your best customer actually is. Sometimes the customer generating the most noise is also generating the most revenue and complexity simultaneously, and letting them drag the product roadmap is a choice worth making explicitly rather than by default.
The Lesson Worth Keeping
Basecamp is not a perfect company and this isn’t a hagiography. They’ve made their share of other mistakes, some of them publicly. But their approach to product simplicity is one of the clearest examples in the industry of a team that figured out the vocal-customer trap and built a systematic response to it.
The lesson is not that complainers are wrong. Complainers often identify real problems. The lesson is that the distribution of complaints does not map to the distribution of your users’ actual needs, and building a roadmap from that distribution is like navigating by the loudest passenger instead of the destination.
Your most important product decisions should be grounded in who you are fundamentally building for, and that person is probably quieter, less technically sophisticated, and more satisfied with simplicity than the people currently filling your inbox. Serve them well and they will never say a word. That silence is not apathy. It’s the sound of a product that works.
