The Bootstrapped Founder

Arvid: 00:00

Hey. It's Arvid and this is the bootstrap founder. A few weeks ago, I came across an intriguing tweet by my internet friend Jack Ellis of Fathom Analytics 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 interesting and useful things that he had done recently. And this idea resonated with me because a backlog to me just represents this backward looking collection of these perceived needs that can overshadow what's actually needed in the present.

Arvid: 00:40

And Jack says so himself in the tweet, he says if you took away all our planning now, I could name the top five things that we have to do. And these things change. Customer support 100% has a great vibe on what needs to be done. And while completely deleting my full backlog feels way too radical, I decided to significantly prune it down this week. And at PodScan, I maintain this notion kanban board that categorizes features into a couple categories.

Arvid: 01:09

I have not started possible, probable, pressing, and critical. That's what I came up with after all these years of trying to figure out priorities. I think possible, probable and pressing are very interesting different urgency tiers and those have really helped me see what's important and what's not. And most items sit between possible and pressing somewhere in the middle and critical is reserved for bugs or directly requested features that need immediate attention because people are gonna pay for it. So my backlog had ballooned to around 120 items over the last year or so.

Arvid: 01:42

PodScan is at this point like 10 months old. So I worked through a lot of them that probably have been 350 on the backlog and 120 have been left. Some were thoroughly documented with titles and descriptions and even code samples. Others were just vague ideas jotted down in moments of inspiration. And after a thorough pruning session last week, I managed to whittle it down to just about 15 high impact items spread across all these categories.

Arvid: 02:10

And I wanna share with you the decision framework that I use because it doesn't really make sense to share all the items with you. I will share a couple, but more importantly, how did I go about either deleting something or keeping something and that's what I used to transform my backlog and that's what I wanna share with you today. Let's talk about my deletion rules first because I would rather delete than keep, so deletion comes first. But I never actually delete data. Never.

Arvid: 02:37

Anywhere really in all my businesses. I just archive it. I archive the tasks in my kanban board and I mark them as irrelevant and if I can, if it makes sense at that moment, I often add a comment explaining why I deleted this so that future me can know why this choice was made today. I would love if I had actually added a comment when I wrote it. Why I wrote it because now me has to deal with past me's idea but anyhow any comment helps.

Arvid: 03:05

This helps me track my thought process and allows for potential revival if the circumstances of the business change, like if I get new customer needs, if I find them or if I have partnership opportunities that weren't actually prioritizing something different. So here are my rules for archiving or deleting items. Number 1 is delete if unclear. If I couldn't write down clearly when the idea was fresh what it was about then it's not worth future brainpower either. I found many vague notes like UI redesign in my backlog.

Arvid: 03:37

What did I mean with this? UI redesign, like, the whole thing? Was it a specific component? An overall website redesign for the front end or the dashboard? Or just implementing a nice design thing that I saw somewhere.

Arvid: 03:49

If I cannot remember the context or specifics, if I didn't write them down, it's a clear sign that the idea was not well formed enough to warrant keeping. Those ambiguous items get archived immediately. I don't even spend more than a minute trying to remember what it was about. If it doesn't make sense, I should have put in more effort. So I delete my idea.

Arvid: 04:12

Number 2 is delete if already solved. It's a pretty clear one, pretty obvious and this happens more often than you think. At PodScan, I had this specific task for filter alerts by ratings. Where I wanted the keyword mention alerts that I track via PodScan to be filterable by the number of ratings that a podcast has on Apple Podcasts or Spotify and I had this sitting in my backlog for months. And then while recently overhauling the search interface and adding a couple things, I ended up implementing this comprehensive filtering system in search that not only covered just ratings but audience size and review counts and language and regional filters too.

Arvid: 04:51

And that kind of rolled over into alerts. Right? It happened in search so I kind of did it in alerts at the same time. So the original task wasn't just solved. It was superseded by a much more robust solution that I never really turned into a task to begin with.

Arvid: 05:07

So sometimes features trickle into existence through adjacent work. That's what I call it. And that makes the dedicated backlog items obsolete. So I deleted straight away. Clearly because it's already finished.

Arvid: 05:19

Number 3 rule for deletion is that I will delete these, might feel cute might delete later. Right? Yes. To me these are the random thoughts that seem brilliant in the moment but lack real purpose. My favorite example for this in my recent pruning session was, thing called add a word cloud for recent podcast topics in the PodScan database.

Arvid: 05:42

And I love this idea. It would be so cute to have this nice word cloud somewhere in a site where people could see like just what got added recently, but does it really fit? Is it really needed? Because when I dug deeper here I realized that no customer ever had expressed a need for this or even an inclination towards it and none of my competitors saw this as a necessary feature in the past. It was just as wouldn't it be cool if kind of features and I think that would have consumed development time without adding any real measurable value.

Arvid: 06:17

So I archived it. Because it's just a cute idea, but it doesn't really have the impact on the bottom line that I want right now. Number 4, the next rule probably is the one that most indie hackers fall prey to. It's called delete potential separate businesses. And this was an eye opening category for me when I realized that this was what I was trying to kind of archive things into.

Arvid: 06:39

I had this extensive feature planned for AI generated content detection in podcasts. The idea was to analyze transcripts as I already do and then determine if the content was AI written or even AI narrated. I could have checked the audio and see if like an AI voice was in there. And this is just as an additional little flag to put into the interface to show people is this an AI podcast or one by real people. Right?

Arvid: 07:03

And this would be really cool and is it technically possible? Sure. But as I thought it through for just a minute I realized immediately that this would require running every transcript that I'd have in a day which is 50,000 or so through a complex AI detection system which probably involves another AI layer to begin with and I have to deal with stochastic analysis and building something that even dedicated AI detection tools right now struggle with. If you look into academia where they check papers for like AI generated text these things have false positives all the time. Do I really want to build something and then deal with those false positives and having my customers yell at me for their podcast be detected as AI when it's not, when they just sound a little bit robotic?

Arvid: 07:48

I didn't really wanna go there. And similarly, I had plans for competitor keyword analysis inside of PodScan and that would amend probably 10 to 100 x ing our database size just to track potential competitor keywords to each customers brands that they already track mentions for. And it would be so cool to have this and to offer this, but both of these ideas, like AI detection and competitor tracking, those are businesses in itself. They weren't features at all. They were entire businesses masquerading as feature requests.

Arvid: 08:21

I'm running PodScan here. I'm not running PodScan and the AI generation detection thing. Detection thing. Right? So if I ever want to pivot into these ideas, I have things written down and that's a future strategic decision, but it's not a backlog item.

Arvid: 08:35

Archived. Gone. Out of sight. Out of mind. The next rule that I have is to delete high effort low impact items.

Arvid: 08:43

And that kind of sounds like these wishful thinking ideas, but it's from a different angle. My business runs on profitability or hopefully because I'm almost there. So I can't afford to build things that don't either make additional money or convince customers to upgrade their plans through expansion revenue into the business. A perfect example here was my idea to build a 20% faster machine learning system on the back end. Because I had read this article, somebody had used some new kind of tech and made things like 20% faster and I thought, oh, that would be cool.

Arvid: 09:14

That would be technically impressive. And that would be absolutely impressive, but would it meaningfully improve the customer experience beyond the already existing accuracy of, like, 95 to 99% that I have there? Would 20% faster with kind of the same accuracy even make a dent? Probably not. And the same goes for complex data ingestion pipeline improvements that I thought really good on paper, but would not immediately produce measurable value for customers and that's what these features are supposed to do.

Arvid: 09:45

So if I ever find something where the engineer in me wants to build it but the business owner in me thinks this is completely pointless. I tend to archive it because that's what the book the e myth the entrepreneurial myth by Michael e Gerber says. You have to be both the technical person and the manager and the visionary of a business. You have to be all 3 if not more in 1. And if one of those roles really wants to build something but the other 2 think it's a waste of time.

Arvid: 10:14

It probably is a waste of time for your solopreneur business. If you have a team and you can dedicate this work to be done by somebody who's an expert and can really focus on it. Great. But if you are the person that has to juggle all of this, do not do this until you know you have the time for this. Which is why high effort low impact items get archived immediately when I see them.

Arvid: 10:36

And the final rule I have for deletion number 6 is just to delete duplicates. Sometimes the same idea appears multiple times in different forms. It just comes as an idea you phrase it one way and then a week later you have a a similar, if not the same idea, but it comes from a different angle and you phrase it differently all of a sudden you have 2 items in your backlog. My examples, I found 2 separate items. 1 was merge duplicate podcasts.

Arvid: 11:00

The other one was build a mark as duplicate podcast button in the UI. Obviously both of them were addressing the same problem because sometimes podcasts get ingested twice because either people update their RSS feeds because they change hosts or some podcasts have multiple feeds, multiple RSS feeds even because they have maybe a paid version or they forgot that the old version is kind of still linked to this old feed. In any case, both cases, all of these cases, I need to keep a kind of a duplicate detection system. So when this happens, when I have multiple duplicates, I keep the more well developed idea and I archive the other. This really simple rule.

Arvid: 11:39

And that those are my deletion rules. That's what I check every single item in my backlog for just to see if it can be and should be deleted. And just like with idea validation, which does not really work you can only really ever invalidate an idea because the counter example for your validation strategy or for your validation assumption might be out there you just haven't found it yet so you can't really ever validate anything. But you certainly can invalidate it by figuring out that if you ask 10 people and nobody wants it, it's likely that it's not a good idea. And it's the same for these backlog items that I have.

Arvid: 12:13

I want to invalidate them as much as possible first and only then do I ask myself why should I keep it. So after applying all of these deletion rules I was left with very few reasons to actually keep items in the backlog. So I have two rules that determines if an idea stays, like if all the deletion rules are kind of ineffective. Number 1 is keep it if there's proof of desire and this is the strongest signal for keeping any feature idea for any business. If I have tangible evidence that somebody wants this that could be that they wrote about it in an email.

Arvid: 12:46

So I find the link to an email put it in the in the feature box. It was a tweet. So I put that link in there or I have a screenshot from a customer service chat. Put that in there. It stays in the backlog.

Arvid: 12:55

With this proof of desire. These aren't just feature requests at this point. They're documented proof of real user needs and I have the evidence. And 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 is a signal worth paying attention to anytime.

Arvid: 13:16

And number 2, the rules for keeping a thing is keep it if it requires data preparation. That's something that I've just found is important for me at PodScan in particular, but has always been important for any software business that I've run. Some features need groundwork laid well before they can be implemented. And at PodScan I'm currently working on extending the search capabilities, search engine that we use for synchronizing data over time and across millions of podcasts. So it takes a while for things to sync.

Arvid: 13:47

For instance, I wanted to enable filtering by the last episode release date on podcasts and that was not yet in the search engine database. So I need to start preparing and synchronizing time stamped data for this information now. Even though the actual search feature probably won't be built for weeks but I already need to kind of let it siphon into the database so that when the features are then implemented the data is already there. And most podcasts update weekly so by the time that I'm ready to implement the UI and filtering logic in a couple weeks all the necessary data will already be in place and slowly synchronized over the weeks if podcast update I do the sync, right? So then data will already in there and these types of features stay in my backlog because they require strategic planning and preparation even if the end result is still far off.

Arvid: 14:36

Data prep is very important. So those are my rules and the real power of a pruned backlog comes from keeping it relevant. That's what I found. And I like it. I like it to be absolutely trimmed down to just a couple of handful of dozen items.

Arvid: 14:53

I now keep my backlog open whenever I have a conversation with my customers and whether that's support chat or exploration call doesn't really matter. I always have it on a screen. But instead of asking them if they want specific features because I'm looking for this proof of desire, right? I would rather avoid the mom test mistake. I dig into challenges and processes and ask people about the underlying problems.

Arvid: 15:16

And for guidance on these conversations I highly recommend Rob Fitzpatrick's book the MOM test. And also Michelle Hansen's Deploy empathy. Both of these books have shaped how I validate feature ideas through customer interactions and Deploy empathy in particular gives you scripts, if you are having these conversations on how to get information out of people. Like, Michelle wrote a wonderful book here and it's really really helpful if you don't know how to have these conversations. Highly recommended Deploy empathy and the mom test.

Arvid: 15:46

And this pruning exercise this week taught me something valuable. Like, a smaller focused backlog isn't just about having fewer items. It's about having the right items in there. The ones that actually hit your bottom line in a positive way. It's about building features that solve real customer problems, validated, shown desire rather than chasing every interesting idea that crosses your mind.

Arvid: 16:09

Because as a founder you gotta have all of these really cool ideas what could be done, but the things you should do often come from a place of need that you might not understand just as well as your customers do. So, by cutting my backlog from 120 to 15 items, I've just created a lot of space to focus on what truly matters for PodScan's growth, and each remaining item has earned its place through either customer validation or strategic necessity. And that's exactly how Bootship Founders backlog should look. And that's it for today. Thank you so much for listening to the Bootship Founder.

Arvid: 16:45

You can find me on Twitter at Avidkar, a r v I d k a h l. If you wanna support me in the show, please share podscan dot f m with your professional peers and those who you think will benefit from tracking mentions of their brands, their businesses, and names on podcasts out there. PodScan is a near real time podcast database with a stellar API. I just added like 4 new API routes this week. So it's growing.

Arvid: 17:07

It's getting more effective and more resilient. So please share the word with those who need to stay on top of the podcast ecosystem for their businesses. Thank you so much for listening. Have a wonderful day, and bye bye.