How to Report Issues and Bugs to Development Team


As a product owner, I found out that many people have trouble reporting bugs or expressing their issues. I am going to tell you what people maintaining products want to hear when they facing requests. If you are the staff from other departments such as marketing or business development and have chances to communicate with engineers or product managers from the development team, this post is for you.

The core concept is being stupid. No matter reporting bugs or requesting new features, the main purpose is to solve problems. Therefore, it is super important to let ticket owners, normally are product managers, project managers, or product owners, understand your consideration and motivation.

Reporting a Bug

It is essential for developers to reproduce the bug again. Therefore, try to write down how this bug happened step by step. An ideal reproduction might look like this:

  1. I want to submit a document for signature
  2. In page (it’s better to provide URL)
  3. Upload the pdf
  4. Click on “Submit”
  5. “Fail to submit.” (Screenshot if possible)

It looks stupid, but it is easier for engineers to reproduce the bug. The reporters might think that this bug is so obvious why issue owners want such a stupid document? In fact, most of the systems are way more complex beyond the users’ imagination. There are many paths or cases that lead to certain results. Thus, let developers focus on the right direction, without excluding possible cases.

Also, try to provide information as much as you can, like user IDs, environment (browser, operating system), time, URL, screenshot, etc. Most of the systems use logs to trace back. Therefore, the information can help engineers find the record quickly.

Some people might complain that providing so much information is time-consuming, and not all of them are helpful. Yet, the most time-consuming process during the reporting bug process is actually communicating back and forth. To avoid unnecessary transaction costs, report your bug with enough information.

Sometimes, the bugs cannot be fixed right away. If issue owners can tell why reporters want to do such behavior, they can sometimes provide alternative solutions. For instance, the reporter says he or she cannot submit the documents for digital signatures. If this issue cannot be fixed right away, the issue owner might report another solution that he or she can ask the managers to sign manually and then scans inside the system for the record. That’s why telling your purpose is important as well.

Requiring a Feature

Some of the reporters tend to propose final solutions, trying to be thoughtful. Actually it is thoughtful but helpless. There are two reasons.

First, they can never be as familiar with the system as the development team. The proposals can be less efficient. Only by understanding the real need can the developers create the most effective and satisfying features. Take a bakery as an example. Imagine a customer is asking a baker for a chocolate cake. The baker has no time to bake a cake right now. How can the baker satisfy the customer’s needs as soon as possible? If the customer is hungry, the baker can provide apple pies that are already in the bakery; if the customer just wants to taste chocolate, the baker can provide a chocolate candy bar instead. On the other hand, if the baker gave a candy bar for the hungry customer, without asking why, he or she will not be satisfied at all.

Another more serious case is that the proposal cannot really solve the problem. For example, my mom required to rent extra space for her belongings. Since she is a shopaholic, the requirement cannot really solve her problem because the extra space would be full of belongings one day if she kept shopping. That is, the accurate solution is to recycle or sell things out, and to change the habit by buying less frequently. In the world of product development, it is quite common to find out that the released features do not meet the initial requirement (or real need).

Therefore, it is severely essential for issue owners to clarify what reports’ needs and for reports to clearly express their true requirements. Do not hesitate to tell your original incentive; do not try to save time without telling the whole story. After all, as I mentioned before, the most time-consuming and frustrating situation is to work back and forth.

Leave a Comment

Your email address will not be published.

Scroll to Top