When known issues become blindspots

Building hardware and platforms is hard. It takes many people and many years and often by solving many complex problems. Along the way, there are all kinds of issues - some obvious, some rare to reproduce, some inconveniences and others just plain egregious. The reasons include bugs, design choices and hardware limitations. People working on these programs eventually see many of these as “known issues”. What I have observed and learnt (painfully so) through building products are some common behavior patterns where these known issues transform into blind spots. Here are four such patterns and some ways to look for them during product development and dogfooding/beta testing phase and prevent them from reaching customers.

It might be known issue but it is poorly explained and often misunderstood.

This one is very common. A symptom is broadly attributed to a particular issue. Turns out the symptom can mean more than one issue and as a result anytime it is observed, it is mischaracterized to be the same one issue. It is not until much later in the program, usually after the misattributed issue is finally fixed that everyone realizes the problem is not gone - ergo, there is more than one issue at play.?

It’s such a well known issue, we (the product team) stopped thinking about it.

This often occurs in hardware development. Due to various and often very valid and compelling reasons, there are tradeoffs that are made during the hardware design phase. It is understood that these shortcomings will be addressed prior to when the product launches through help guides or messaging. But given the long hardware cycles, some of these plans don’t materialize leading to a “oops” moment during Go-To-Market planning when everyone in the room points the finger at someone else assuming they would have handled it already. This can be mitigated by the Program Manager and Product Manager working on a set of roadmap tasks early in the program to keep track of such known tradeoffs and address it at the right time.

It is such a glaringly obvious issue, the product team likely knows about it. I dont have to take the pains to report it.

This happens when a product is in internal dogfooding/ beta testing for a prolonged period of time. Certain issues are experienced so often by beta testers, it is assumed everyone knows about it and someone is working on it. So at some point, beta testers just stop reporting it. The issue falls through the crack ironically because it was so obvious in the first place.?

I (as the PM) don't experience this issue, so it must not be a common one.

We all have our respective distortion fields and as PMs, it can be both a boon and a bane. We tend to think that we have seen it all - so when someone reports an issue, we tend to sometimes dismiss it just because we haven’t experienced it ourselves. The?thought process here is, “If I haven’t experienced it over dozens of hours of regular dogfooding then it must be an edge case”. It took me a while to come out of this distortion field and instead tell myself, "I am a sample size of one. I am likely missing out on a bunch of issues because I am biased and likely overlooking some obvious things."

These are just four of a bunch of behavior patterns that I have experienced and learned from.?A combination of processes to avoid such behaviors and the ability to look past our own blindspots will go a long way in avoiding confusion and worse, customer pain that can result from it. ?