Why Your Product Has Too Many Features (Ex-Atlassian Engineer Explains)
What if the biggest threat to your product isn’t what you haven’t built yet, but everything you already have?
I sat down with Rich—early at Atlassian, who spent years in the trenches building products used by millions—and we went deep on something most founders don’t want to hear. Your users don’t want more features. They want clarity. They want tools that solve real problems without drowning them in options they’ll never touch.
This conversation hit me hard because I’m building Clarity right now, and Rich’s insights forced me to question everything. Are we building for users, or are we building to feel productive? Are we creating value, or are we creating noise?
If you’re a founder, product leader, or engineer who’s ever felt the pressure to “just ship one more thing,” this is your intervention. Let’s get into it.
1. The Feature Bloat Trap: How Success Becomes Your Burden
Every product team faces this paradox. You build something people love. They start using it. Then come the requests: “Can you add this? What about that?” Before you know it, your elegant solution has morphed into a Swiss Army knife that nobody knows how to use anymore.
Rich lived this at Atlassian.
“You’re not building for your existing customers anymore. You’re building for the imagined customer that might come in the future,” he told me. “And that’s when you lose focus.
The psychology here is brutal, and I think about it every single day while building. Adding features feels like progress. It feels like growth. It gives your team something to do, your sales team something to pitch, and your investors something to point to in their decks. But here’s the truth: each new feature is a cognitive tax on every user who has to navigate around it just to get to what they actually need.
I keep asking myself: Are we building this because users need it, or because we need to feel like we’re moving forward?
Application for builders: Before adding your next feature, pause. Ask yourself that question. The best product decisions often involve saying no, not yes. And saying no is f*****g hard when everyone around you is screaming for more.
2. The Oracle Years: When Engineering Excellence Meets Corporate Bloat
Rich spent fourteen years at Oracle and PeopleSoft. Fourteen years watching what happens when feature accumulation becomes institutional religion. Large enterprise software companies don’t just add features—they acquire them, bolt them on, create labyrinths of functionality that require armies of consultants to navigate.
What struck me most was this moment of reflection:
“I tended to be in the back seat most of the time,” Rich said. “I would probably suggest moving up to the front, maybe even getting towards the driver’s seat and figuring out how to control and do something more meaningful with your career.”
This wasn’t just career advice. This was about ownership. When you’re deep in a large organization, it’s easy to become a feature factory worker—executing someone else’s roadmap, optimizing someone else’s metrics, building toward someone else’s vision. You lose sight of the why behind what you’re building.
And here’s the irony that kills me: many of these organizations are drowning in talented engineers who know exactly what needs to be cut, simplified, and reimagined. But the incentive structures reward addition, not subtraction.
Application for builders: If you find yourself building features you don’t believe in, it’s time to either influence the roadmap or find a different seat. Your best work happens when you care about the outcome, not just the output. I learned this the hard way at my first startup in crypto gaming when I was just executing without conviction. Never again.
3. The Clarity Insight: What Journaling Teaches Us About Product Design
One of the most validating moments in our conversation came when Rich reflected on what I’m building with Clarity—my tool for personal performance management through journaling and self-reflection.
“The thing that appealed to me when you were talking about it is like, it’s really like a personal performance management app,” Rich said. “If you write in a journal, the only time a journal is really useful is if you’re deliberate about it. You have discipline in writing in it regularly, and then your mind will clarify.”
But here’s the brutal truth about most journals: they become write-only systems. You pour your thoughts onto pages, close the book, and never look back. All that valuable reflection becomes historical noise. Gone. Useless.
Rich compared Clarity to using Granola for meeting notes—having the ability to search through past conversations, find patterns, extract insights months or years later. That transforms raw data into actionable knowledge. That’s the whole f*****g point.
This is the opposite of feature bloat. Instead of adding more ways to capture information, we’re focused on making existing information more valuable. Instead of building forty different input methods, we’re building one great way to retrieve insight when you need it most.
Application for builders: Before you write a single line of code for that next feature, stop. Ask yourself one question: “Does this help users find clarity, or does it add to their cognitive burden?”
The best products reduce mental overhead. They don’t increase it. And if we’re honest with ourselves, most features we ship increase it. We add complexity in the name of capability, and our users pay the price in confusion.
4. The Jobs-to-be-Done Lens: What Are You Really Solving?
Midway through our conversation, I pushed Rich to articulate the core job that Clarity is solving. I love using Bob Moesta and Teresa Torres’s frameworks for this. What’s the fundamental outcome users are hiring the product to deliver?
His answer stopped me in my tracks:
“The promise of AI is about truly being your assistant over your life. Things fail—our memories are going to fail. We forget things over time. We’re not perfect. If you have some history of everything you’ve done or things you’ve talked about, and if you could make use of that somehow... it’s like a living autobiography.”
A living autobiography. Holy s**t.
This is what great product thinking looks like. Not “we’re building a journaling app” or “we’re adding AI features.” But rather: “We’re solving the fundamental problem that human memory is unreliable, and valuable experiences disappear into the void unless we have systems to preserve and surface them.”
When you understand the job at this level, feature decisions become obvious. Does this help create a living autobiography? Does it surface forgotten insights? Does it reduce the burden of remembering? If not, it doesn’t belong in the product.
What I’m taking from this: I wrote down our one job on a sticky note and put it above my desk: Create a living autobiography of who you’re becoming. Every feature request now gets evaluated against that job. If it doesn’t serve that core purpose, it’s noise. It’s a distraction.
5. The Experience Over Output Paradox: Why We Build the Wrong Things
The most philosophical moment came when Rich talked about his relationship with hobbies, particularly photography. He confessed something I deeply relate to: he often feels the need to see progress, validation, recognition for the things he creates—even when he knows he should just enjoy the process.
“I feel like I’m wired that way where like, I need to see some sort of progress, some validation, some recognition for the things that you do,” he admitted. “I know every human wants to feel confident. They want to feel like they belong.”
F**k, I felt that. This is the trap that destroys products. We build for validation—from users, investors, the market, ourselves—rather than building for genuine utility. We add features because we want to show progress. We complicate interfaces because simplicity doesn’t feel like enough work.
But the best products respect that value comes from experience, not from feature count. A journal is valuable because of the clarity you gain while writing, not because of the pages you fill. A camera is valuable because of how it changes what you see, not because of megapixel counts.
Rich’s self-awareness here is the mark of a mature product thinker: recognizing the impulse to optimize for the wrong metrics and constantly pulling yourself back to what actually matters.
I’ve been thinking about this a lot lately. How much of what I build is for me to feel like I’m making progress versus what actually serves the user? How often do I add complexity because I need external validation that I’m “doing something”?
Application for builders: We need to build cultures where “we decided not to build that” is celebrated as much as “we shipped this new feature.” The best product teams are disciplined about what they say no to. That’s the real flex.
Key Takeaways: The Anti-Feature Manifesto
Your product doesn’t need more features. It needs more focus.
1. Question Every Feature Request
Most come from imagined future customers, not actual needs. Ask: “Who is this really for?”
2. Value Subtraction Over Addition
Removing confusion beats adding functionality. Every feature taxes user attention.
3. Design for Retrieval, Not Capture
Information without insight is noise. Make the past useful, not just stored.
4. Understand the Core Job
If you can’t say it in one sentence, you’re building on shaky ground. Ours: living autobiography.
5. Build for Experience, Not Validation
Stop building for your ego. Build for user value.
6. Take the Driver’s Seat
Own the direction. Don’t be a passenger in your own life.
The pressure to add more never stops. The market always demands more features. Competitors always tout expanding capabilities.
Resist.
The products that endure stay focused on solving one problem extraordinarily well. Rich’s journey from Oracle to Atlassian to entrepreneurship proves it: clarity beats complexity every single time.
Maybe the best thing we can build isn’t more. Maybe it’s better.
🎧 Resources and Further Listening
* Jobs to be Done Framework by Bob Moesta [https://jtbd.info/]
* Continuous Discovery Habits by Teresa Torres [https://www.producttalk.org/continuous-discovery-habits/]
* The Lean Product Playbook by Dan Olsen [https://leanproductplaybook.com/]
* Atlassian Product Development Philosophy [https://www.atlassian.com/blog/product-management]
* Granola - AI Meeting Notes Tool [https://www.granola.so/]
Get full access to ABCs for Building The Future at abcsforbuildingthefuture.substack.com/subscribe [https://abcsforbuildingthefuture.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4]
