In an industry obsessed with velocity metrics, sprint burndowns, and shipping cadences, there’s a radical idea that’s often overlooked: slowing down. While most companies are racing to release feature upon feature, some of the most successful software products have been built by teams that deliberately chose to move more thoughtfully.
The Feature Factory Trap
The modern software development landscape is littered with products that have fallen into what I call the “feature factory” trap. Teams measure success by the number of features shipped per quarter, the velocity of story points completed, and the frequency of releases. Product managers create elaborate roadmaps packed with functionality, and development teams sprint from one feature to the next without pausing to ask the fundamental question: Does this actually make our product better?
This relentless pace creates a cascade of problems:
- Feature bloat that confuses users and complicates the codebase
- Technical debt that accumulates faster than it can be addressed
- Burnout among team members who never have time to reflect or improve
- Lost focus on the core value proposition that made the product successful
The 37signals Philosophy: Less Is More
Few companies have demonstrated the power of slowing down as effectively as 37signals (now Basecamp). Founded by Jason Fried and David Heinemeier Hansson, the company has built a multi-million dollar business by deliberately choosing to do less, not more.
Getting Real: The Foundation
In their seminal book “Getting Real,” Fried and Hansson laid out a philosophy that flies in the face of conventional software wisdom:
“Less software, less code, less features, less options, less stuff. The key is to redefine the problem in terms of what you can do with less.”
Rather than building comprehensive project management suites packed with every conceivable feature, they created Basecamp—a simple, focused tool that did a few things exceptionally well. They resisted the temptation to add advanced reporting, complex workflow engines, or elaborate customization options. Instead, they perfected the core experience of organizing projects and communicating with teams.
Rework: Challenging the Growth Imperative
“Rework” takes this philosophy further, challenging the fundamental assumptions about how businesses should operate. The book argues that the relentless pursuit of growth and feature expansion often destroys the very qualities that made a product valuable in the first place.
Key principles from “Rework” that apply to feature development:
- “Good enough is fine” - Perfect features shipped next year are less valuable than good features shipped this month
- “Start at the epicenter” - Build the core functionality that provides the most value, then carefully consider each addition
- “Say no by default” - Every feature request should be met with skepticism, not enthusiasm
It Doesn’t Have to Be Crazy at Work: Sustainable Pace
Their more recent book, “It Doesn’t Have to Be Crazy at Work,” extends this philosophy to team dynamics and company culture. The authors argue that the “always-on,” feature-churning culture prevalent in tech is not just unsustainable—it’s counterproductive.
When teams slow down, they gain:
- Clarity of thought about what truly matters
- Time for reflection on whether recent changes are actually improvements
- Space for creativity that emerges when you’re not constantly firefighting
- Deeper understanding of user needs through observation rather than assumption
The Power of Subtraction
One of the most counterintuitive aspects of slowing down is that it often leads to removing features rather than adding them. This requires a different kind of courage—the willingness to disappoint some users in service of a better experience for the majority.
Consider some examples of successful products that became better through subtraction:
- Google’s search page remained famously sparse while competitors added more and more widgets
- Instagram started as Burbn, a complex app with many features, but found success by focusing solely on photo sharing
- Twitter’s character limit forced creativity and clarity, even as users demanded more space
Practical Steps to Slow Down
Implementing a “slow down” philosophy doesn’t mean abandoning progress. Instead, it means being more intentional about how you define and measure progress:
1. Change Your Success Metrics
Instead of measuring features shipped, track:
- User satisfaction with existing features
- Time to value for new users
- Code quality and maintainability metrics
- Team satisfaction and sustainable pace indicators
2. Implement Feature Cooling-Off Periods
Before building any new feature:
- Wait 30 days after the initial request
- Gather usage data on similar existing features
- Interview users who specifically requested the feature
- Consider alternatives that might solve the problem without adding complexity
3. Regular Subtraction Reviews
Monthly or quarterly, ask:
- What features are rarely used? Consider removing them
- What configurations create confusion? Simplify the options
- What workflows are overly complex? Streamline the core paths
4. Embrace Constraints
Set artificial limits that force creative solutions:
- Maximum number of features per product area
- Complexity budgets for new functionality
- UI element limits to prevent interface bloat
The Compound Benefits
When teams embrace a slower, more thoughtful approach to feature development, the benefits compound over time:
Technical Benefits:
- Cleaner, more maintainable codebases
- Fewer bugs due to less complexity
- Easier onboarding for new team members
- More predictable performance characteristics
User Experience Benefits:
- Clearer value propositions
- Lower cognitive load for users
- More reliable core functionality
- Easier customer support
Business Benefits:
- Lower development costs
- Reduced support burden
- Stronger competitive positioning
- More sustainable growth
Swimming Against the Current
Choosing to slow down in a fast-paced industry requires conviction. You’ll face pressure from:
- Competitors who appear to be moving faster
- Stakeholders who equate activity with progress
- Team members who measure their value by output
- Industry trends that celebrate rapid iteration
But as 37signals has demonstrated over more than two decades, there’s tremendous value in swimming against this current. Their products remain successful not despite their restraint, but because of it.
Conclusion: The Wisdom of Intentional Pace
The next time you’re tempted to add “just one more feature” or respond to competitive pressure with a flurry of new functionality, remember the wisdom embedded in the 37signals approach: sometimes the most valuable thing you can do is resist the urge to do more.
In a world where everyone is racing to ship faster, there’s a competitive advantage in taking the time to ship better. The companies that learn to embrace this paradox—that slowing down can actually help you win—will build products that don’t just capture attention, but sustain it over time.
As Jason Fried and DHH have proven, sometimes the best way forward is to slow down, look around, and make sure you’re heading in the right direction before you take the next step.
