You want bugs in your app

How to find out what features you don't need

I have to be honest, the title is a bit misleading. You really want bug reports in your app, though honestly they are kind of one in the same. What I’m really saying is that bug reports are a good thing. Don’t get me wrong, they can be highly stressful when discovered during an important demo with a client, or when it is a major security flaw. Those aren’t really the ones I’m talking about. I’m talking about ones from your customers and prospects. When they initially report a bug, you don’t actually know if it is a bug yet. It could be that is something that is FAD (functioning as designed), or just a nuance of the application that isn’t well documented. Arguably either of those are still bugs, but more on that later.

Bugs are always seen as bad things, and as I mentioned with the security and demo cases, they can be. But software is not so black and white. A ton of bugs is a bad user experience, but no bugs is an impossible promise, especially if you are pushing the boundaries of innovation or feature development speed. A few bugs though, that lets you know that people are using your application. This is particularly clear whenever you know about them, but haven’t had the chance to fix them. If your users aren’t reporting that bug, then that feature of the application is not being used (well maybe, as I’ll explore below). If people aren’t reporting any bugs at all, even if it is FAD or not well documented, then they are probably not using that feature either. Remove it. See what happens. If people complain, then ask them what they want to do, because it didn’t seem like they were using it before. There’s always the chance that feature is bug free and clean, so obviously you don’t just go around removing features willy nilly. But if you notice a new bug in something that hasn’t yet been reported, and the code hasn’t been touched in awhile, instead of fixing it, you might evaluate if it is even necessary in the first place.

I say all of this from experience. It was a previous company I worked for. We had an older feature that hadn’t had any updates in a few months (or maybe it was over a year). I knew there was a bug in it that hadn’t been reported. Instead of rapidly pushing to fix it, I asked if anyone was using it. I was told this one particular customer was, which I knew wasn’t true. Even if it was once true, it couldn’t be anymore. Because what I didn’t tell you about that bug is that it was feature breaking. The feature didn’t work. We hadn’t touched that code in months, meaning it had been there for awhile (though there’s always a chance we touched some other code that caused the bug and didn’t realize it, as it was a complex codebase). No one reported it. That’s when I knew we should just remove it. We hadn’t made any improvements in a long time, there was a long standing bug, and no one cared. All the criteria for feature removal in my mind. That’s what happens when you build rapidly and iteratively. You build things that you learn from and then throw away. Validate an idea with a customer and move forward. This is just one example, and I could give you a handful more from that company and others. Maybe it’s a startup thing, as that’s where I’ve been for awhile, but I think it’s more universal.

Just a note, if you aren’t talking to your customers enough to get the “this is weird” bug reports they don’t officially report, you are missing out on some really valuable insights.

— Me

So there is also the darker side of this. Your users may not care. They don’t care enough to report them. I’m a software engineer, and even I won’t always report bugs I find because I may not care enough about the application I’m using. I know how frustrating it is, and yet I still do it. Humans can be surprisingly lazy (is it surprising?), particularly when they don’t care enough. New users usually don’t care, so that’s where this entire idea can really break down.

So let’s talk about the non-bug bugs I mentioned earlier. The FAD bugs and the lack of documentation ones. Those are immensely important. Your users are going to do things you didn’t expect, even if you have a sophisticated testing team. They won’t catch everything (and if they tell you they can, they are lying or naive). But these types of bugs are fantastic. The FAD ones tell you where your app might be a bit clunky, even though that’s how you designed it. Maybe your should reconsider how that works. Maybe it is similar enough to other software applications that your users are expecting it to work the way those do, but it works differently. You might need to think more about how important that difference is. The documentation ones should be obvious, they tell you where you need better onboarding and support documentation. Or maybe you could just make that part more intuitive. Or even add a tutorial in the application that walks the user through it. These are all still bugs in a way. Maybe not in the product, but in your processes and business.

Don’t get me wrong, lots of bugs will mean no one will come back to your application. But shouldn’t you see some bugs? I’ve never written a bug free feature in my career. I’ve written good features that function well and were surprisingly high quality (I say surprising because I’ve been at startups for a while where you are usually trading off quality for speed, so given the time constraints, they worked really well). However, they were never completely bug free. There was always some edge case I didn’t consider, and that’s usually where most bugs come into play (well and browser nuances, but that’s a whole separate topic). Customers will always find a way to do something weird you didn’t anticipate. There are just a much larger volume of them, and each of them brings a different context and expectation for the way software should work and function. So they will inevitably try to do things that will break your app, or reveal that you have a clunky feature. You can’t really avoid that (if you want to ship software somewhat frequently or consistently), but at least avoiding the egregious bugs will keep people coming back. If you don’t see bugs, all I’m really trying to say is that you should seriously consider how important that feature is. Maybe it isn’t as big of a deal to your customers as you originally thought. Or maybe your ICP (ideal customer profile) has shifted. In the words of my father, “just think a little bit”. Not quite the right context from when he always said it to me (usually when I was doing something stupid), but I think it works.