The big secret of small improvements
A small improvement on its own is insignificant, but together they make a huge impact.
Every other Monday, we stop everything we’re doing and devote our day to make our product just a bit better. All startups have more work to do than available resources and having focus is the most important thing. However, this often leads to neglecting the small details of their product.
Torii isn’t different. We have a backlog full of ideas, stories and tasks to last a life time. Every day we see opportunities for small improvements that can be done, but aren’t significant enough to rise above the main feature roadmap and get prioritized. What can we do?
Quick-fix days
Our solution is having a full day dedicated to such small improvements, or quick-fixes, as we call them. We keep a backlog of small UI bugs, mini-additions to features, text updates, making things faster, removing unused features, and more. Each one of us can get to 5–6 tasks and have a small yet big impact on the product.
Why?
I’ve made a list of all the good things that come with a “quick-fix” day:
- Ideas. Everyone have ideas, from the CEO to the junior developer who joined your team just this morning. Adding these ideas as quick-fixes allows everyone to suggest an improvement and actually see it gets done.
- Focus. Since there’s a dedicated day for small fixes, the other days can be used entirely to focus on the most important tasks. Everything that is extra, related or just a good idea on its own — now has a place to live.
- Customers. Say YES to customers when they ask for small improvements. No more, “Good idea, we’ll consider it”. On the end of Monday, you’ll have a list of customers who’ll get an email with the good news.
- Team. Marketing and sales people asking favors from developers is a bad indicator of product management. Now there’s an official way to get things done, without going through a chain of team leaders and managers.
- Debt. Product debt and technical debt can be addressed here instead of letting them pile on.
Why not?
I really can’t see a reason why not.
Tips
Here’s how to conduct your very own “Quick-fix” day:
- Monday. Schedule this day as the first day of the week, otherwise it is easily neglected.
- Always. Never cancel this day even if deadlines are tight. Take these days into account when estimating due dates for features.
- Prioritize. Keep the list prioritized, but allow some degree of freedom when choosing the tasks for that day. Some developers can use this to clean up code, or work on an improvement they’ve suggested.
- Quick. If a task is estimated to be longer than a day, do not start working on it. All tasks must complete by end of day. If a task is longer, prioritize it against the other tasks.
- Small chunks. Each quick fix should have its own branch to ensure changes are deployed. Also be prepared to Code Review a lot of small changes and make time for it during that day or in the last 20%-30% of it.
- Well defined. Only work on tasks that are defined properly. Prefer “Make content scrollable” over “Bug: can’t see content when scrolling”.
- Thanks you. There’s nothing like hearing a customer say “Thank you!”. When a quick-fix was suggested by a customer, let the developer email him and tell him the good news.
Origins
Credit where credit is due. The idea for this came while working at Bizzabo, where we wanted to make the best product but couldn’t find the time. So we came up with this method and it worked amazingly well. I suggest this to every company that wants to win the market on great-product.
If you like this post, clap and spread it around. Follow me on Twitter — @ketacode.
Foot notes
- We actually start our weeks on Sunday and end them on Thursday. So our quick-fix days are on Sunday.
- I always add an Emoji to my name, to test Emoji support across web, emails and mobile.
- The content loads much faster on our web-app, but I slowed it down for the GIF.