I’ve recently been thinking a lot about the role perception plays in how we respond to life and how we receive the various inputs the world has to offer. One particular thought has been around the role confidence plays in shaping our perception.
Dictionary.com defines “confidence” in several ways. In the context of perception, I believe the definition which best matches is;
certitude; assurance:
He described the situation with such confidence that the audience believed him completely.
Within the context of my day to day (software product management and team lead), I notice confidence play a role in one of the core interactions of a developer; customer and team member interaction.
Dissecting bug reports with confidence
When receiving bug reports from customers, there are several approaches one can take. The polar approaches here are either to assume the user is correct (and thus, that a bug exists) or to assume that there is no bug and that this report is in fact a user error, edge case or related, fundamentally, to how the software is being used.
While the user is 100% correct every time in that they have found something, refuting that there is a bug in the code changes how the report is interpreted and resolved. This often boils down to confidence in the code base of the product.
Fostering your desired outcome
Being heavily involved in various products at Woo, I’ve seen first hand how knowing the code of a product can help to answer user queries and reports with more confidence and how this confidence shapes my very perception of the report. I’ve seen the converse as well, how not knowing a particular code base can shape one’s confidence and perception in the opposite manner.
With the aim of resolving bug reports more swiftly and boosting everyone’s confidence in the product, I’d recommend the following assumptions be made for each bug report:
- The code base is fine. The use of the product is most likely incorrect.
- If the product usage is all above board, check for conflicting products.
- If no conflicting products, check the code base.
This approach shows confidence to the user, while also bolstering confidence from within, shaping the perceptions of all involved in the discussion to ultimately encourage better resolution of the report. Making the converse assumptions shows the user that the team isn’t confident in their product, encouraging further reports and a hostile approach towards the product from the user side.
Encourage everyone on the team to spend some time with the product they support, play with it, try to break it and learn the ins and outs of it. The distance between the product developer and the customer support for the product should be a hop and a skip, rather than a rickety bridge over troubled water.
Leave a Reply