What should you Build next?
feature / improvement / bugfix / refactor
After finishing the first version or MVP (Minimum Viable Product) of your product/service, and get run real customers using it. What should you build next?
Type of tasks after MVP
Most of the work in a software product can be separated into 4 types: feature; improvement; bugfix; and refactor.
A new feature is adding new capability to your software that didn't exist before.
An improvement is to enhance an existing feature, making a feature faster, providing a better UX for the feature, and related.
A bugfix is when you fix some bad behavior that lets your app crash or causes unexpected behavior.
A refactoring is to improve the codebase without changing the current of their behavior.
Cost of delay
One of the best books about product development is The Principles of Product Development Flow. It gives us a mathematical view, using queue theory, of how to make sure we are delivering the best value to our customers.
One of the concepts of this book is the cost of delaying something.
The cost of delay is how much impact would you have in your existing customers and new sales if you delay this task.
The best way to decide if you want to work in a feature, or improvement or bugfix or refactoring is putting these tasks in the same queue and decide which one would cause more impact if delayed.
I will provide some basic questions that can be a heuristic to estimate the cost of delaying of each of these types of tasks.
Delay of a Feature
How many users are waiting for this feature?
How this new feature helps the sales team to sell more?
Is this feature for most users or part of them?
Will this feature improve usage and engagement?
These questions help you answer if this is a feature that will deliver value for most of your current users and also for your new users. It will also answer if this will make your product more useful and bring user activity up.
Delay of an Improvement
How many users will perceive this improvement?
How many users use the feature that will be improved?
Would this improvement make the feature fast and simpler for users?
Will this improvement makes sales easier?
These questions let you know if this improvement is meaningful. It will let you know if your customer will be happy if this improvement.
Delay of a bugfix
How many users are affected by this bug?
Is this bug generating inconsistent data?
Is this bug part of core user workflows?
Can the user use the product even with this bug?
How many customers support ticket will be open because of this bug?
These question let you understand how urgent and important is this bug and its fix.
If the bug is causing a lot of support tickets to be open, you should make them a priority and release the fix as soon as possible. If a bug only happens in a very hard to reproduce situation, you can delay this fix to next week or so.
Delay of a Refactor
How many more hours developers will spend before this refactor?
How long will it take this refactor?
How this refactor affect the other devs?
What are the risks of this refactor?
Can this refactor be done incrementally?
These questions let you know if this refactor makes sense, how much energy and time we going to spend on it, and how much value it will produce in the long term. Refactor is always about thinking in the long term, you only improve the current codebase to make your move fast and safe in the long run.
Build Less
My advice for who is deciding what work on, it is to build less.
Every new feature that you build in your product will increase complexity. Each new feature will have first and second order effects in other existing features. For each new feature, you are going to have more tasks of improvements, bug fixes, and refactors.
Choose wisely feature you build, prefer features that solve a group of problems your customer has.
Shape Up is a great base by Basecamp company that is built around this idea that you can build less and still make your customer happy.
If you like rants, read this The Nonesuch Beast that describes how a set of simple features can make an impossible product to build.
Good stuff. How would you apply these ideas to practical team management routines and client acquisition in a software house?