FounderQuest
FounderQuest
Should You Blow Up Your Backlog?
Links:
Justin Jackson
Intercom
Help Scout
Trello
Clubhouse
Jira
GitHub
Jason Fried
Local Editor
VS Code
Sublime
Full Transcript:
Starr: So how was your trip, Ben?
Ben: My trip was good. Yeah. I went down to Mobile, visited my parents for a few days, and I actually went over to Louisiana as well and saw my brother and sister. So, good time. Got a lot of reading in. It's a kind of a long trip and so I got some books done. You know Kindle, makes everything wonderful.
Ben: So yeah. Had a good relaxing few days. Nice little vacation.
Starr: Good. Did you eat some crawfish?
Ben: No, but I did have some fried catfish.
Starr: Okay. That counts.
Ben: Yeah, that counts.
Josh: I love fried catfish.
Starr: Yeah. It's the only way to eat catfish.
Ben: It's been a long time since I had some.
Josh: That is true.
Josh: Do people eat catfish any other way?
Ben: Oh, of course.
Starr: Really?
Ben: It's kind of like Forrest Gump. Boiled shrimp, fried shrimp.
Josh: Oh, yeah, yeah. Boiled catfish, though. I don't know. I think I'll stick with fried.
Ben: Yeah. It's the best way. For sure.
Starr: Yeah. So today we're going to be talking about backlogs. We're kind of late to the party. This was on Twitter a long time ago, and then we all went on vacation.
Josh: A long time ago.
Starr: And then I think we're trying to hit the sort of rebound cycle where everything old becomes new again, and people are sort of into vintage tweets. So yeah. So we're going to talk about this. So could somebody explain to me this whole thing about backlogs and why everybody was talking about it?
Ben: Yeah, I think there was... Well the issue of backlogs is when you have a whole bunch of stuff that you've thought about doing at some point. And so you kind of log it, right? We use get GitHub for that. But you can use whatever like Trello or Clubhouse or something. Basically, any idea that you have, people like to throw those in a big bucket and say, yeah, we'll get to that someday. Right? And so you create this big backlog of work that you want to do, or that you think at some point was worth doing. And the conversation on Twitter was, there was some anxiety about this issue, oh I've got this big backlog and I feel like, oh, I've got all this work to do and I'll never get it all done. And woe is me kind of thing.
Ben: And then someone said, "Oh I'll start a service, I will charge you $10,000 and I'll come in and just delete your backlog, and you'll feel so much better." So we've got a request from Justin. He said, "Yeah, the FounderQuest guys should definitely talk about this." Because opinions, and of course we have opinion. So here we are.
Josh: So remind me, did we hire that guy to come in?
Ben: No. And because my opinion is I like backlogs. We can talk about that.
Starr: Well, can I read the quote? There's a quote and it's sweet, and it's from Jason Fried, who seems like a decent guy. I don't know, I'm not going to go into a big tangent about hero worship and the sort of small bootstrap, whatever. But yeah. So he says, "We don't believe in backlogs. Backlogs and make you feel guilty." So I don't like feeling guilty.
Ben: I would say backlogs give you the opportunity to choose to feel guilty. They don't make you feel guilty. Right? But maybe that's splitting semantic care.
Starr: I like it, it's a very stoic quote from you.
Josh: That's what I was going to say. Yeah. It's like I'm-
Josh: Everything is in your perception, right Ben?
Ben: Exactly.
Starr: Well, I mean, yeah, a backlog can't make me feel a certain way. I'm the owner of my emotions.
Ben: Exactly.
Starr: Right? I say that so much. That's my little mantra throughout the day. It's like I'm the owner of my emotions.
Josh: Yeah, say it through my tears.
Starr: Yeah.
Ben: I could see how you might want to say that pretty frequently when you have a three year old in the house.
Starr: Oh yeah. Yeah. Well she is... Ah, I don't know. Maybe I'm the owner of my emotions, but I feel like she's definitely subletting them, to a certain degree. So.
Ben: We could start a new acronym. OME. Owner of My Emotions.
Starr: Oh yeah. And have little yellow wristbands that we sew on.
Ben: There you go.
Starr: Yeah.
Starr: Great idea.
Starr: So how big is our backlog? We've got...
Ben: We've got a couple hundred things in there.
Starr: A couple hundred things? And where does this come from?
Ben: Oh, a lot of them are feature requests. So we'll get someone say, "Oh, it'd be nice if..." Fill in the blank. And so we'll say, "Oh, that's a good idea. We'll think about that." And so we toss it into GitHub, and basically go on our way. We don't really jump on most feature requests. We just kind of file them away and keep them and let them percolate. And if it bubbles up, if a lot of people start wanting that or some day we feel like, hey that's interesting, let's think about that some more, then we'll come back to that. So, that's a good chunk of our backlog. But also we have things like internal, I guess, feature requests, like, oh, it'd be great if, from our point of view, if we did X, Y, or Z. So one that's that we've had for about a year now is dark mode. Right? When iOS 13 was first announced and they talked about dark mode, I was like, "Oh, it'd be really cool if we had dark mode." And Safari was going to support it and it showed up in a technology preview. And so I filed an issue in GitHub saying, Hey, let's look at implementing dark mode. And then we did basically nothing on it for 10 months, but that's-
Starr: Are we going to do that now? I thought I saw Kevin looking at that or something.
Josh: He's working on it right now.
Starr: Oh cool.
Ben: So, but over those 10 months, people would post blog posts about, "Here's how I did dark mode support, and detected Safari in dark mode" and blah blah blah. And so I would add those as comments to the issue. Right? And so kind of paving the way for it to get done, should we ever decide to get around and doing it. And then, Kevin's one day like, "Oh, it'd be kind of nice if we had dark mode." And I'm like "Well, here's the issue. Take it." And that's the idea.
Starr: Yeah. That's kind of handy. It's like, what's the difference between a backlog and then sort of a crude customer research?
Josh: I would say that our approach to backlogs is not... I don't know if we take the standard approach either because the other place you see a backlog is in the agile tracker, Kanban style thing where you have your backlog doing and done type set up, and you basically pull stuff off the backlog when you're done working on what you're... When you finished something, you pull something off the backlog, basically, and it's like a stack. But we don't do that. We don't actually look at our backlog very often which might be why we can tolerate it like we can.
Ben: Yeah, I think you're right. I think a lot of people might look at that, a strict definition of the backlog is something that is going to be done next, after you're done doing whatever you're doing now. And yeah, like you said, we don't do that. We just... I like it because we keep it around as if you're kind of bored one day and you're looking for something to do, you can try troll through the backlog and find something interesting.
Josh: It's like an idea list or something.
Ben: Well I think one thing that's been really helpful about it is, like I said, we file stuff. If someone requests something and we file it away, and then someone else does and then someone else does, well we track that, right? We go back to that same issue and we link to that new person that's asking for it. And then when you see something come up four or five times, hey, there's something here. Right? And then the other thing that's nice about that is actually if you do that, then you know exactly who to go back to you and say, "Hey, we've done it." We've had one time, I think, where we went back, someone had requested something three years before and we finally got around to doing that thing, and so we contacted him. He's like, "Hey, great, thanks for letting me know".
Starr: Oh yeah, I've done that before. And it always feels really good. It's like, "Hey, I noticed that you suggested this thing 18 months ago. Well here you go." They're always like, "What? Huh?"
Josh: They don't even remember."
Josh: Yeah. We try to link up our tickets to any issues that result from them. So we cross post with Intercom, we used to... They had a feature that was pretty handy that kind of took care of that for you. But Help Scout needs to get on that.
Ben: I guess we could make some sort of, I don't know, client-side widget that could do that. But-
Josh: Yeah, yeah, I've seen services as well that are made for that purpose but we just use... GitHub issues has been pretty good for our purposes, since it's really just a bucket we dump stuff in and then just never revisit.
Starr: So do you fellas ever go through the bucket and go throw stuff away? I've never really gone through and just deleted stuff because I don't know what y'all are planning on using. But I have... If I've been working on a feature and then I see an old ticket in the backlog relating to something that maybe is no longer necessary because of the work I did, I'll delete that. But do we ever sort of go through the whole thing and clean it up?
Ben: I think I've done that once or twice. I'll go through maybe and say, "Oh, I've done that." For sure. So I'll talk about, oh that's not necessary anymore. Or that technology doesn't exist anymore. We've had integration requests for third parties. We have integrations for Clubhouse or for a JIRA or whatever. And we've had integration requests for things you have may not have heard of. And so we just file those away. And in some cases, those SaaS providers went away. So it's like, oh, well we don't need to worry about that issue anymore, and close that. But yeah, I've gone through a few times and it's like, oh, we're never going to do this, so we're just going to delete that. Or we've gone in the direction that this doesn't make sense anymore. So just delete that.
Josh: Yeah. Personally I tend to... I think I lean towards Jason's opinion on this more than Ben does. I'm not a huge fan of backlogs. They do stress me out if I think about them too much which is why I kind of try to just basically dump stuff in there but ignore it most of the time. And I like the idea of when you're looking for something new to do, don't just go look at what's on the list and just pick something. But the idea of focusing on what's the most relevant, and what makes sense for the moment, for your users, for your customers, in the moment. If you just go and pick the next thing off the backlog, I don't like that approach. I like the idea of working for whatever's happening right now. So I think I'm more of a blend.
Josh: I don't see a problem in just having somewhere to store ideas longterm, it makes sense. Assuming it's not controlling what you do 100%, it's useful to know what people have asked for in the past. But yeah, at the same time, if, if it's okay to just go and delete your whole backlog, then it's okay to just have the backlog but assume if it went away someday, it wouldn't be the end of the world for us. It wouldn't stop, it wouldn't change anything in what we do today or next week or even this year, probably. So it's really not that consequential for us.
Starr: Yeah. So what if we just rename the backlog, and we just renamed it to Ideas? Or maybe every year we take it and we take all... It's like people who put a bunch of junk on their desktop, on their computer, and then every year you create a new folder, like 2019, and then you to just throw all the junk in there and at the end of the year-
Starr: Yeah, I do that with my files.
Starr: Yeah. So what was it? Somebody posted a tweet or something. It was every year they create a directory called Files, and they put all their desktop stuff up in that. And then the next year they create another one called files and they put everything in that. So it ends up just being this sort of recursive, Files, Files, Files.
Josh: Oh, that's the recursive. That sounds good. Man, my file storage strategy doesn't have recursion.
Starr: I know. I know. We really need to get with the times, Josh. We started this company what, seven years ago? Things were just different back then.
Ben: You should add that to your backlog, Josh.
Josh: That's a good idea.
Ben: So, but one thing that's also been nice about having that backlog is when we have requests that come in that aren't the same but are similar, one thing that's on my mind here is people who have asked for customizations to JIRA or GitHub, and the message that we send, the thing that we post to their GitHub issue, or the title that we use, and we had, I don't know, five or six different requests over time around these same kinds of things, but they were all slightly different. It's like one person wanted, "Oh I want my title to be customized." Or I want X, Y or Z.
Ben: And over time, being able to track these, it's like, oh, this person wanted that and this person wanted that. And if we actually took some time and built something that addressed all those things, that would be useful. Right? So I think that was really helpful. And now we have this nicer system than those minor things. If we just did a Wednesday, Tuesday kind of thing as they came in. So that helps.
Josh: That's a good example.
Starr: Yeah. And I think this points to a way that our use of GitHub issues and our backlog is kind of different than a lot of companies in that when we create something, when we create an issue because the customer requested a feature or whatever, that doesn't mean that we expect it to get done. That just means that we're logging that somebody wanted this. And maybe we'll decide to do it in the future. Maybe we won't. So it's not really a backlog of work that has to get done. Because I mean, we do have some, we do put our bugs in there and we do have more urgent stuff in there, too. But-
Josh: Yeah. And for that reason, I've thought about actually splitting them up because that might help us kind of differentiate between those. But that's another topic, maybe.
Ben: Yeah. Well, I mean, so far we've used labels in GitHub for that, right?
Josh: Yeah, we use labels.
Ben: So we have a feature request label, right? And we have a bug label and a security label. And so the bug and security things get addressed pretty quickly. But those feature requests ones hang out forever. But yeah, maybe it makes sense to separate them.
Josh: Yeah. Just have a separate repo or something.
Ben: But I like what you were saying, Josh, about how, even with all those issues in there, it doesn't really affect our choices day to day, and what am I going to work on this morning. Because we have a more proactive approach to our work, right? We think, what would be most beneficial for us right now as a company and for our customers right now? As opposed to, what's all the things that we've ever thought about doing?
Josh: Right.
Ben: Yeah. I think the way that we've structured the... How we build Honeybadger, we just... Whatever you feel like doing, and with the intent that we want to grow the business, we want to make our customers happy. So whatever features or changes we think that will increase customer happiness, increase retention or increase acquisition, those are always our focus areas. And so we always had that goal in mind.
Ben: I think that's one of the things I've been great about hiring Ben and hiring Keven, is that they were people who we could say, here's the longterm goal. Here's where we're trying to get. Here's our main focus, our emphasis is retention and acquisition. So whatever you do, whatever you decide to do on a daily basis should forward those goals, further those goals. And they've been great in being able to latch onto that. Not everyone has that drive or that initiative. So it's been great that we've been able to have a couple of people join us who are similar to us in that way, that can work that way.
Starr: So I don't want to delete our backlog, but I've got to tell you, there's something about the idea of just going in and deleting all of the GitHub issues that just appeals to me on a deep, cellular level. Just clean slate, just wipe out all the issues, wipe out all of our logs, all of our... I don't know, financial performance data. Just start fresh day one.
Ben: Oh yeah, totally. I know how you feel. There are days I'd like to delete all of our infrastructure and start over.
Starr: Yeah. I mean, well, I mean that's.
Josh: Delete the company.
Starr: Yeah, that's-
Ben: Can we just shut down all the servers and we'll start again tomorrow?
Josh: Build from scratch
Ben: Build from scratch.
Josh: We could always do V2.
Ben: Yes. The V2 that we've always wanted to do.
Starr: The V2.
Starr: Yeah, that's... Oh boy. You want to give me nightmares, don't you?
Josh: One of my favorite things about our backlog from our customer support or customer feature requests is it's kind of a last straw effect where if we have a couple customers request something and we punt on it a few times, and then finally one person will request it and, and it's like, that's it. Okay, we're doing it. And then we'll just build it and ship it, maybe even that day. But yeah, that's kind of how it works. If we get enough requests and we actually happen to feel like doing it, maybe at that given moment, then we'll just do it. Otherwise it'll sit for however long until someone feels like doing it.
Ben: Yeah. So we have three responses, basically, when a request comes in from a customer. So the first response is the first time we hear of a feature request and we our response typically is, "Oh that's a good idea. We'll think about that." And so that means what we do in the back end is we go create a GitHub issue, and we might talk about it amongst ourselves for a bit, and then we just kind of let it sit there and rest and see what happens. The request type number two is, "Oh yeah, thanks for suggesting that, we've had other people request that. We'll consider this a plus one for that." And so we'll go to our GitHub issue and we'll link to that support conversation and say "Hey, such and such also wants this thing" right? So there's the plus one. And then Josh, you described the third response. "Yes, we should totally do this." And it's shipped. We finally built it.
Starr: Yeah, you're forgetting response type zero, though. Which is some of them it's just like, "Thank you so much for giving us your feedback. But honestly, I just can't see us doing this anytime soon."
Ben: Oh, that's true. We do have that. That's more rare, but yeah.
Starr: I mean, my favorite... Sometimes people write in and it's just like, Oh geez, do you... They're like, "okay, so I think this... It makes more sense to call, I don't know, makes more sense to call errors, faults and to have this group under this, so just move this page, make it a sub tab of this other page." And it's just, well, maybe if we were starting from scratch, that would be a good idea. But you want me to make all of our users mad and angry by arbitrarily moving around things in the user interface just because you want it? So I'm sorry.
Josh: Most people don't like change unless they were the ones that asked for it.
Starr: Yeah.
Ben: Unfortunately we don't have-
Ben: Sometimes-
Starr: I mean occasionally, occasionally, not too often.
Ben: Not too often. Yeah. But then there are those things that never even show up in the backlog because it's just some random idea that one of us has and we just do it, right? And then all of a sudden you wake up and oh, there's a new thing there. I mean, we did that, I think more in the past and we do now, but still it happens from time to time.
Josh: I think local editor was that, I think.
Starr: What's local editor?
Josh: Local editor is where you can configure in Honeybadger for each project, you can configure the path of the project on your local file system. So you got your user directory slash code or something where you keep your GitHub projects to work on. If you configure that in Honeybadger then we can show them links. We can basically give you links in your back trace to open the code on your local editor in your computer. Either use GVim or whatever, VS Code, Sublime. We can open it directly from the web app into your local editor to fix the bug, edit the file and fix the bug.
Starr: Well that sounds incredibly convenient.
Josh: Right?
Starr: Yeah. I should check out that Honeybadger product.
Ben: So I guess the moral of the story is if you want to try DDoS Honeybadger, you can send in your feature requests and we will add them to our GitHub issues thing. And that some point, Starr will declare backlog bankruptcy and we'll start over.
Starr: Yeah, I'm not going to do that.
Ben: Oh, all right.
Starr: I don't know. I don't have the courage to live my convictions, I guess.
Ben: It would be a fun experiment, though. I think you're right, Josh. I think that there wouldn't be anything of huge loss if we wiped it clean. And I guess that gives me the, I don't choose to be made anxious by our backlog because that is true. We'd just go on doing what we're doing if we didn't have-
Josh: Yeah. Yeah. So maybe one of these days it'll just mysteriously disappear and you guys won't ask too many questions.
Ben: Okay, got to admit, that does make me a little bit anxious.
Josh: It would be.
Starr: You'll never know when the moment will strike.
Starr: So Ben, that's a nice backlog you've got there. It'd be shame if something happened to it, you know?
Starr: All right. I think maybe we've beaten this horse as much as she will take. What do y'all think? Do you have anything more to add about backlogs or should we call it wrapped?
Josh: I think that's a wrap.
Ben: Yeah, I think we're good.
Starr: All right, everybody, thank you for listening to FounderQuest. If you liked this show, please review us on Apple podcast, or whatever they're calling it this year, and Google Play store or whatever that is. Whatever the podcast thing you use, just review us, please.
Starr: And yeah, we'll catch you next week. Bye.
