Every founder wants to build more features. Our job is to tell them no.
After launching 50+ products, we've learned: What you DON'T build matters more than what you do. Here are three features we killed—and why the products succeeded because of it.
Feature We Killed #1: Social Login
The ask: "Users should be able to sign in with Google, Facebook, Twitter, LinkedIn, and GitHub."
Why we killed it: Social login adds 2 weeks of development (OAuth flows, token management, account linking). For a B2B SaaS, 90% of users prefer email anyway. We shipped email-only. Post-launch data: 94% used email. 6% requested social login. Added Google only (took 2 days when we actually needed it).
Lesson: Build features when users ask for them, not when you think they might want them.
Feature We Killed #2: Advanced Filtering
The ask: "Users should be able to filter by date range, category, status, tags, custom fields, and save filter presets."
Why we killed it: Complex filtering is a power-user feature. 95% of users use basic search. We shipped: search bar + 2 status filters. That's it. Post-launch: 2% of users requested advanced filtering. We added it 3 months later for paying power users.
Lesson: 80% of users need 20% of features. Ship the 20% first.
Feature We Killed #3: Mobile App
The ask: "We need iOS and Android apps at launch. Users expect mobile."
Why we killed it: Mobile apps take 2-3x longer than web. Most B2B SaaS usage happens on desktop. We shipped: Responsive web app. Post-launch analytics: 89% desktop, 11% mobile. The 11% mobile users were fine with the responsive web app. We added a PWA (1 week) before building native apps.
Lesson: Validate platform usage before building platform-specific features.
The Cost of Feature Bloat
Every feature has hidden costs: Development time. Testing time. Maintenance burden. Cognitive load for users. Delayed launch date.
Example: A "simple" notification system adds 1-2 weeks. Email notifications. Push notifications. In-app notifications. Notification preferences. Mark as read. Do you REALLY need it at launch? Or can users check the app?
We've seen products delayed 3 months because of "must-have" features that nobody used post-launch.
Our Feature Decision Framework
For every feature, we ask: 1) Can the product work without it? 2) Will 80%+ of users use it in the first month? 3) Is it 10x better than the manual alternative?
If any answer is no, the feature gets cut or moved to post-launch.
Saying no is hard. Founders want to build the complete vision. But the complete vision takes 18 months. The minimum lovable product takes 8-12 weeks. Ship the 8-12 week version. Add features based on real usage. This is how you win.
