There are two ways to define perception. First, knowledge of things obtained with our senses objectively. Second, perception is the way something is interpreted. Latter is subjective and often based on anecdotal opinions.
Case against perception
We released a product in the year of the lord 2001. It was the shinny thing then. Got a bunch of customers excited and onboarded into the service. Then evolution happened, the team which built the product moved onto do something bigger. So our shinny feature remained on the back burner for a while.
We heard bunch of feedback about it, but couldn’t get to it. At its glory, this feature was used by several other features (that’s how we got the customers ;)). Now that this feature was not actively worked upon, product owners of the consuming features had to deal with the pain. That was the beginning of forming opinions about this feature.
Now these opinions come in various flavors. Easiest - the feature is too complex for customers to use. It doesn’t work. Non functionally it slows bunch of other features. It is an overhead. I can totally empathize with the pain of depending on something that was built when you were in diapers. I can understand the helplessness of dealing with issues there. But I don’t understand the interpretation around lack of funding the original feature to functional, performance or scale arbitrarily.
We decided to not invest in the feature. We chose to stick to the UI built for our grandfathers working on 1024x768 resolution on IE 6. Two decades later, we complain that feature is too complex for us! Where’s the surprise?
Coming to the second problem: perceptions are unfortunately more widespread than we would like to see. Even more unfortunate is their priority. They keep coming in the way. As we set out to build a new feature or improve something; everyone questions - Do customers even use it? Isn’t that feature super unreliable? I am definitely not going anywhere nearer.
So as a mark of respect, we now have a new workitem type in our kanban board: Perceptions. Finish off the perceptions before you get on to any bugs and features. Otherwise all the great work you do will not get used because some stakeholders still consider the feature worthless.
Third, everyone who has a perception also comes with a suggestion. Let’s use mongo db as the data store for this feature. That’s the missing ingredient. Almost everytime I hear this, I do add a few more into the mix of options, yeah sure, I hear neo4j is better. Why not model it as a graph? These conversations are almost always one hundred percent fun. We never discuss the real problem and its constraints, only solutions.
Dealing with perception
At this point, I think it is safe to say we care about perceptions within organization more than the actual customer problems ;) In any case, we have to fix these perceptions to enable us to make some progress in solving real customer pain.
First approach may be to try to defend. Confront stakeholders with data showing the actual state of affairs. Let the data speak that our understanding of the system is actually a perception. Quite objective in nature, but bursts a bubble. There is a chance this may work if the opinions are losely held. Or you will walkaway with an ask to consider 20 more data sources :D
I think probably a better approach is to not conclude or take a side. Hear out all the stakeholders, research on the seemingly baseless solutions; present an appraisal of current state of affairs, along with the suggested approaches. Be cautious to get consensus on the requirements first and then evaluation of all approaches.
Remember the perception has been built over years. We can’t fix that. So work on requirements to bring everyone to the same page on reality and projections for the future. Considering the approaches suggested by stakeholders indicates a growth mindset and allows us to objectively evaluate the best path forward!