Wednesday, October 24, 2012

Users Don't Care About Bug Fixes

We were trained to always write a "what's new" list when we ship a new version of our product. User have come to expect these lists, as you see them even in app stores. Each app update comes with a "release history" that's supposed to tell you why you should bother updating.

This, in itself, is a good thing. Problem is, people who write these lists often confuse "what's new" with "what we've been working on since the last version". Users (and this is a gross generalization, but still) do not care how your team has been spending its time between versions. They care about what's new. Shiny new things.

The worst offense in this respect is including bug fixes as part of the release history. Sure, you've spent 80% of your time fixing bugs and 20% actually adding new functionality - but users don't care. Yes, yes, of course some do, like the ones that reported some of the bugs, but they're really the exception. Your release history is a marketing document aimed at getting more people to upgrade to the latest version and convert inactive users to active ones. Most users could care less about how many bugs you've fixed along the way. In fact, nice going, advertising the fact that you have shipped so many bugs to begin with... Sure, it's reality, but reality isn't the point. You're not logging, you're advertising.

So don't include a list of every single bug you've fixed. For God's sake don't include bug IDs! But most pointless of all is to just write "various bug fixes". O... k... what's the value in that? Why are you sharing this with users? It's not their fault that you only managed to squeeze one new feature into this release. Adding this "but we really worked hard to fix a lot of problems you may not even have noticed" excuse is just silly.

We've done this in the past, I'll admit. No more. If you can spin a bug fix as a positive improvement to functionality (e.g. things run faster), then go ahead - but don't force it.

One exception to this rule is for mega-bugs. Bugs that were so horrible, they caused half your users to flee your product. It makes sense to mention those, but really only those. 

Think of every addition to the release history as adding another line to your product's CV
What goes into a CV? 
Good idea: mention the ways you've grown during your last job.
Bad idea: mention that anger management course they forced you to take. That's the sort of "bug fix" you can keep to yourself.

1 comment:

OhadG said...

Good, enjoyable article! (especially the funny last paragraph).
You indeed see this awful bug-fix list all over (Node.js, Boost), and as a feed subscriber, I care less about those and more about new features.
Interesting how you realized that Gigantt also shouldn't mention bugs fix. It is not that trivial. Way to go.

Post a Comment