Your shiny new software just launched. The team expertly planned and executed the deployment. Your new product integrates seamlessly with your other systems. New users find the product intuitive and user-friendly. But, as with any new software, a few problems crop up. The Bug vs Feature Request argument begins.
Is it a bug?
A bug means something is broken. The software unexpectedly and suddenly stopped performing as intended.
But what if the software isn’t broken? What if users are asking the software to perform tasks it’s not intended to do? Something customers expected. It’s a feature request.
Enter the Bug vs Feature Request argument. Your customers don’t care or even understand a bug vs feature request. They just know the software isn’t doing what they want it to do.
So, why do you care?
You worked tirelessly to specify, design, build, and deploy a product to deliver a great user experience for your customers. You invested a sizeable amount financially to develop the product. Only to discover that you missed something.
Whether it’s a bug vs feature request, your customers are struggling. You need to triage. You have hard choices to make. Your decisions depend on factors that are difficult to quantify.
- How many customers does this affect?
- What’s the impact? Is there a workaround?
- How difficult is it to fix or update?
- How much more will you invest, and how long will it take to deploy the updated version?
- How will this impact the other products your team is building?
You weigh the impact and assess your options. You may need to de-prioritize some bugs, especially those affecting the fewest users. Or the bugs that are easily skirted. Or the bugs that are costly to fix. You may decide that it is more important to prioritize a new feature. A feature that can attract new customers or delight existing ones.
So what should you do?
Maintenance (bugs) and Evolution (features) are hopelessly intertwined. You only have so many developers and designers. Your support budget is finite. You can’t do everything. You assess and re-assess. Your market is dynamic. Customers are dynamic. Staff availability is dynamic. You must continually adjust priorities.
The team may fix low-priority bugs later—or may never fix them. If the team identifies high-priority bugs, they may delay long-planned features. Or, new and more interesting features may pre-empt long-planned features.
Keep your software product in tip-top shape.
We’ve said it before. Software is Never Done. Software maintenance always includes bugs and features. Have a plan for both.
