Dear founder,
A few days ago, over dinner, I found myself deep in conversation about the technological singularity. While that "happy moment" of humanity becoming a machine-augmented brain collective (think Star Trek's Borg) might still be years or decades away, there's something more immediate that keeps me up at night: the unprecedented acceleration of technological advancement and what it means for indie hackers like us.
🎧 Listen to this on my podcast.
Deleting Your Backlog: A Founder's Guide to Feature Pruning
A few weeks ago, I came across an intriguing tweet by Jack Ellis about deleting your backlog. He shared how getting rid of this "mental technical debt" — not even real technical debt, but the illusionary kind — had been one of the most useful things he'd done. The idea resonated with me: a backlog often represents a backward-looking collection of perceived needs that can overshadow what's actually needed in the present.
Jack says so himself in the tweet:
"…if you took away all our planning now, I could name the top 5 things we have to do. And these things change. Customer support 100% has a great vibe on what needs to be done."
While completely deleting my backlog felt too radical, I decided to significantly prune it down. At Podscan, I maintain a Notion Kanban board that categorizes feature ideas into "Not Started," "Possible," "Probable," "Pressing," and "Critical." Most items sit between "Possible" and "Pressing," while "Critical" is reserved for bugs and directly requested features that need immediate attention.
My backlog had ballooned to around 120 items. Some were thoroughly documented with titles, descriptions, and even code samples. Others were just vague ideas jotted down in moments of inspiration. After a thorough pruning session, I managed to whittle it down to just 15 high-impact items. Here's the decision framework I used to achieve this transformation.
The Deletion Rules
I never actually delete data — I just archive tasks and mark them as irrelevant, often with a comment explaining why. This helps me track my thought process and allows for potential revival if circumstances change, like new customer needs or partnership opportunities. Here are my rules for archiving items:
- Delete if Unclear: If I couldn't write it down clearly when the idea was fresh, it's not worth future brain power. I've found many vague notes like "UI redesign" in my backlog. What exactly did I mean? Was it about a specific component, an overall website redesign, or just implementing a nice design I saw somewhere? If I can't remember the context or specifics, it's a clear sign that the idea wasn't well-formed enough to warrant keeping. These ambiguous items get archived immediately.
- Delete if Already Solved: This happens more often than you might think. At Podscan, I had a specific task for "filter alerts by ratings" sitting in my backlog for months. Then, while overhauling the search interface, I ended up implementing a comprehensive filtering system that covered not just ratings, but audience size, review counts, language, and regional filters too. The original task wasn't just solved — it was superseded by a much more robust solution. Sometimes features trickle into existence through adjacent work, making their dedicated backlog items obsolete.
- Delete "I'll Feel Cute" Ideas: These are the random thoughts that seemed brilliant in the moment but lack real purpose. My favorite example was "Add a word cloud for recent podcast topics in the Podscan database." Sure, it would look nice somewhere on the site, but does it really fit? When I dug deeper, I realized no customer had ever expressed a need for this, and none of our competitors saw it as a necessary feature. It was just a "wouldn't it be cool if…" idea that would have consumed development time without adding real value.
- Delete Potential Separate Businesses: This was an eye-opening category for me. I had an extensive feature planned for AI-generated content detection in podcasts. The idea was to analyze transcripts to determine if content was AI-written or even AI-narrated. Technically possible? Sure. But as I thought it through, I realized this would require running every transcript through complex AI detection systems, dealing with stochastic analysis, and building something that even dedicated AI detection tools struggle with. Similarly, I had plans for competitor keyword analysis that would have meant 100x-ing our database size to track potential competitor keywords for each customer's brand. Both these "features" weren't features at all — they were entire businesses masquerading as feature requests. If I ever want to pivot into these areas, that's a future strategic decision, not a backlog item.
- Delete High-Effort, Low-Impact Items: My business runs on profitability, and I'm almost there. I can't afford to build things that don't either make additional money or convince customers to upgrade their plans. A perfect example was my idea to build a 20% faster machine learning system on the backend. Would it be technically impressive? Absolutely. Would it meaningfully improve the customer experience beyond our current 95% accuracy? Probably not. The same goes for complex data ingestion pipeline improvements that sound good on paper but don't produce measurable value for customers.
- Delete Duplicates: Sometimes the same idea appears multiple times in different forms. I found two separate items: "merge duplicate podcasts" and "build a mark as duplicate button in the UI." Both were addressing the same problem — sometimes podcasts get ingested twice because people update their RSS feeds or have multiple feeds for the same podcast. In these cases, I keep the more well-developed idea and archive the other.
The Keeping Rules
After applying all these deletion rules, I was left with very few reasons to actually keep items in the backlog. In fact, just two rules determine if an idea stays:
- Keep if There's Proof of Desire: This is my strongest signal for keeping a feature idea. If I have tangible evidence that someone wants this — whether it's a link to an email, a tweet, or a screenshot from a customer service chat — it stays in the backlog. These aren't just feature requests; they're documented proof of real user needs. This evidence is infinitely more valuable than my own speculation about what might be useful. When a customer takes the time to reach out and explain their needs, that's a signal worth paying attention to.
- Keep if It Requires Data Preparation: Some features need groundwork laid well before they can be implemented. At Podscan, I'm currently working on extending our search capabilities. The search engine we use requires synchronizing data over time across millions of podcasts. For instance, to enable filtering by "last episode release date," I need to start preparing and synchronizing timestamp data now, even though the actual search feature won't be built for weeks. Most podcasts update weekly, so by the time I'm ready to implement the UI and filtering logic, the necessary data will already be in place. These types of features stay in the backlog because they require strategic planning and preparation, even if the end result is still far off.
Making it Work
The real power of a pruned backlog comes from keeping it relevant. I now keep my backlog open during customer conversations, whether they're support chats or exploration calls. But instead of asking if they want specific features (a classic "Mom Test" mistake), I dig into their challenges and processes.
For guidance on these conversations, I highly recommend Rob Fitzpatrick's "The Mom Test" and Michele Hansen's "Deploy Empathy." These books have shaped how I validate feature ideas through customer interactions.
This pruning exercise taught me something valuable: a smaller, focused backlog isn't just about having fewer items — it's about having the right items. It's about building features that solve real customer problems rather than chasing every interesting idea that crosses your mind.
By cutting my backlog from 120 to 15 items, I've created space to focus on what truly matters for Podscan's growth. Each remaining item has earned its place through either customer validation or strategic necessity. And that's exactly how a bootstrapped founder's backlog should look.
If you want to track brand mentions, search millions of transcripts, and keep an eye on chart placements for podcasts, please check out podscan.fm — and tell your friends!
Thank you for reading this week's essay edition of The Bootstrapped Founder. Did you enjoy it? If so, please spread the word and share this issue on Twitter.
If you want to reach tens of thousands of creators, makers, and dreamers, you can apply to sponsor an episode of this newsletter. Or just reply to this email!
No comments:
Post a Comment