How to Handle Small Features & Bugs in a Product Development [4/100]

I’m writing 100 posts about product development and product management. For this challenge I take weekly cadence, so you can expect a new post every week (or less). This is post #4.

We, as product managers, tend to focus on large cool features. We like to think strategically, do major releases, and announce large cool things. This is a very dangerous path. User experience consists of many small things and many fixed bugs. By ignoring small things we may put our products in danger: poor conversion, poor retention, and poor product loveability. These problems are quite hard to discover. When you ask a customer or a lead, you might hear very generic feedback like “it just feels incomplete” or “I feel irritated quite often”. Such replies are a sign that a product manager ignores small improvements and bug fixes.

Google Docs team struggled with the product. Adoption was not great and they heard similar feedback about unpleasant writing experience. Many many small things here and there that were hard to combine into significant features or problems. They decided to improve and fix hundreds of small things with text editing. When they did that, adoption skyrocketed, since writing experience became good enough. New features would not save them, but many small improvements cumulatively did the trick 🌱.

I hope you are persuaded now that small things should be a part of the product development process, but how to handle them? Let’s dig into various approaches, maybe you will find inspiration below.

Small Items Backlog

First, it should be easy to discover small features/improvements/bugs that developers can take and implement/fix. You may have a special field like the “Small Item” checkbox in Features and just filter the usual backlog. If you estimate effort or duration, you may have an agreement that “small” means everything less than 2 days, or less than 3 points (if you still use points).

“Small” will vary from product to product, so it’s your decision and your process to nail what “small” means for you. The end goal is to have a backlog with just small things. It can be prioritized, but I’d not bother with that. OK, you have this backlog, now what?

“In-between” improvements

One strategy that I really like is to take several small things after the large feature release. For example, you have a team that just released a 2-months-long feature. Now it’s a good time to give the team 1-2 weeks and allow them to take any items from Small Backlog.

First, the team should relax a little bit after the serious effort. Small features and bugs are usually easier to do than large features, you have to keep fewer things in mind and cognitive load is lower.

Second, freedom of choice is good for team morale and product involvement. Developers can take features they want to implement, bugs they want to fix, a technical debt they want to pay.

Clean-up Sprints

Maybe you like iterations/sprints and follow the Scrum process. In this case, you might add Clean-up Sprints. This is the usual Sprint with only one additional rule — only items from Small Backlog are accepted. You can’t add anything large in this Sprint. I know that iterations are quite monotonous and it’s good to spice them up with something new.

Subbotnik

What if you’ve accumulated huge piles of small features and bugs? 💩 What to do? You may dedicate more “in-between” time to that or run Clean-up Sprints more often. But you can also have a Subbotnik

All development teams participate in Subbotnik at the same time and implement/fix as many small things as they can. Subbotnik may take 2 days or 1-2 weeks (if you have really huge piles of small items). It should be an unusual event that unites people, improves collaboration, and maybe imposes some kind of competition (like what team will implement more small features or fix more bugs).

The main problem with Subbotnik is synchronization. If you have common sprints for all teams inside a company it will be relatively easy, but if you have kanban-style async development some features may be paused. This is not always a good idea, since context switching is expensive.

We tried Subbotnik twice in my previous company, and it was quite fun. We had a board with all developers’ names and drew how many bugs everyone fixed. As far as I remember, the winner fixed close to 20 bugs in 2 days.

Tiny Wins

Joel Califa wrote a great article about small improvements they did in GitHub (I really recommend reading it). He calls these improvements Tiny Wins. Tiny Win is a very small change that is very impactful (low effort, huge impact). Here are the main traits of Tiny Win:

1. Tiny Wins are standalone.
2. Tiny Wins are low effort.
3. Tiny Wins are high-impact. They affect things that the majority of users interact with on a regular basis.
4. Tiny Wins are often shortcuts. They save a user’s time by getting rid of existing steps — physical or mental — required to perform an action.

Note that not every small feature or bug fix is a Tiny Win. Only high-impact items are. Joel notes that Tiny Wins are hard to discover since users don’t report them. You have to think deeply and analyze frequent usage flows to discover them.

My advice would be to differentiate Small Features and Tiny Wins as well. Tiny Win should have a priority in most cases, since its impact is great, while for any Small Feature it is not the case.

—

Small improvements are important. Don’t ignore them!