Rules to Better Bug Management and Product Feedback

Effectively managing product feedback is key to improving your product. While platforms like UserVoice and UserEcho have been popular, GitHub emerges as a superior choice for modern software development.

When reporting bugs or providing product feedback, it’s important to include as much relevant detail as possible. Make sure it reaches the right people through the right channel - ideally the product backlog, or email if needed. A well-written report saves time and avoids frustration for both you and the developers.

The answer to this question can make or break contracts. We think that it's such a fundamental issue it has to be captured clearly. This is how we strictly define a bug.

Imagine this scenario... A designer notices a small typo on an intranet page. As a good employee, they open up the backlog and create a PBI to fix the spelling error. Then send a "to myself" to action.

Meanwhile they are thinking... "That took more time to report the error than it would have taken me to fix it".

It's common to add a TODO comment to some code you're working on, either because there's more work to be done here or because you've spotted a problem that will need to be fixed later. But how do you ensure these are tracked and followed up?

A new version of your software is deployed. How do you tell users important information on older versions?

You shouldn't need to check for updates to be notified of valuable information.

Software is often deployed without any mechanism to insert a message into older versions.

A/B Testing is the process of testing different versions of an application on different users to gather empirical evidence to learn which version is better.

Using A/B Testing enables you to get features tested and when used effectively means that a bug will never be deployed to 100% of users. Generally, new features should be tested on 20% of users and rolled out to others once they are reliable.