Perception is Reality

Hugo Froes
10 min readSep 30, 2022

Have you ever sat in a meeting and seen two people debating, only to realise they’re saying the same thing, but in different words?

In product teams, this can be exaggerated to a whole new level, especially when we try to compare internal approaches to the ideals set by industry experts on best practices.

In this article, we’ll explore how to identify those differences and how we can mitigate their impact to help our product teams move forward.

What do we mean?

Let’s start at the beginning to make sure we’re all on the same page.

What do we mean when we talk about Reality and perception?

Reality is defined as “the state of things as they actually exist, as opposed to an idealistic or notional idea of them.”

I think that’s pretty straightforward, but to be clear, we’re saying it is exactly and unequivocally what it is. No room for interpretation or opinion… despite many people wanting to add their own spin to reality ;)

On the other hand, when we look at how Perception is defined, we see it is “the way in which something is regarded, understood, or interpreted.”

Which is basically our own specific version of events based on various biases of our own that we’ve added.

Contrary to the title of this article, Perception is categorised as NOT real, or at least that’s how it’s viewed by academics. It’s viewed as a skewed and biassed way of viewing something.

However, for the person experiencing that perception bias? FOR THEM, their perception is their reality. For them it IS what is going on and many of their decisions will be made based on that bias.

To better illustrate my point, let’s look at some simple examples.

There is a story found in ancient Indian texts of the blind men and the elephant.

It is a story of a group of blind men who come across an elephant for the first time and describe the elephant by what their hands feel, although each of them touches a different part of the animal.

As we can see in the example illustration, their descriptions vary immensely and each accuses the others of being liars, clearly showing how they are looking at it all from a very small spectrum of their own interpretation.

In some versions, the blind men even resort to blows.

Moving into modern times, many of you may have seen the following image from Jeff Patton (Writer of User Story Mapping) which shows a classic example:

  1. We are all in agreement and no doubts exist
  2. But when we write it down or discuss in more detail, we realise we aren’t all differing views. Much like when everyone says they work in an Agile organisation, but the actual meaning may differ for each.
  3. We decide to hash it out until we actually are aligned
  4. Now we’re happy, because we’re aligned

In both examples, we can see how easily someone can assume that everyone is saying or seeing the same thing. However, each person’s perception of the situation is different and thus they interpret the situation differently.

What’s interesting is how easily things can evolve in different directions for both parties based on those assumptions. In some cases the divide can grow larger and create extra complications.

In modern Product Orgs, we do our best to reduce assumptions of events, but we are strongly influenced by our interpretation of events every single day and in multiple situations.

I’ve sat down to chat with many people who will play back their interpretation of a situation or a communication that was sent out and their interpretation is sometimes the exact opposite of what truly happened or was trying to be communicated.

But why does this happen? Even acknowledging that it happens doesn’t seem to reduce the probability of it happening again and again.

And then, how can we reduce the impact or even remove it completely?

It’s not an easy question to answer, but in the next part, let’s explore some of these challenges, their cause and how to potentially mitigate them.

Exploring the challenges

Let’s be clear on something, the baseline fact is that our brains are hot-wired to take the easy route.

What do I mean? In his book “Thinking, Fast and Slow”, Daniel Kahneman describes how our brain is divided into two “systems”.

  • System 1 — is lazy and jumps to conclusions quickly. Accepts what is presented without much digging.
  • System 2 — However is more analytical but needs to exert more effort

Basically our brain is lazy and given the option, it wants to jump to the easiest solution, even when it could be completely wrong.

In today’s tech world, that is even more exasperated, because we already have so many distractions and cognitive overload, that our brain wants to jump to those conclusions rather than asking questions or taking time to really understand what is being said.

In today’s tech world, that is even more exasperated, because we already have so many distractions and cognitive overload, that our brain wants to jump to those conclusions rather than asking questions or taking time to really understand what is being said.

Many resources focus on someone recognising their own incorrect interpretation and how they can work to change their perception bias.

But what happens when we see that perception bias in others? Especially when the other person doesn’t recognise their bias?

Battling mixed perceptions

Let’s dig into some of the most common mixed perceptions I’ve seen and how we can mitigate them

Going back to the point on the 2 systems of the brain, the only way to bypass system 1 is by using mental effort and being intentional when thinking through the challenges.

5 simple rules to keep in mind at all times:

  1. Question your initial response to things
  2. Slow down when thinking
  3. Learn and experience new things
  4. Enhance cognitive abilities through practice and repetition
  5. Be mindful and open minded

Now let’s look at some practical example of this in action

Example 1: Listen to the team

This is a tricky one. We want to make the team feel as if they have a voice, but also avoid design by committee, or we’ll never reach a conclusion.

We know we’re going to have people who will disagree strongly. We can’t please everyone.

Below is an example of two interpretations of the same situation from different angles

Person A: “We have a few people who don’t agree or don’t understand. All I need to do is set up some time to explain to them better and remove their doubts. But the overall plan just doesn’t change.”

Person B: “I’ve understood what you’re telling me, but I don’t think you understand all the complexities because you’re not in the day-to-day. This just seems like a mess and you’re being stubborn and keep pushing despite us clearly identifying big challenges.”

The balance is paying attention to the general sentiment.

If it’s one or two voices, they can be heard calmly without a huge disruption, but the influence is residual.

The issue is when there are many voices speaking up or disagreeing. No matter how wrong you think those voices might be, they will influence the sentiment of the group.

Equally, the group may seem on-board at first, but as the months go by and they don’t see the “light at the end of the tunnel”, the sentiment may go into a negative spiral.

In both cases, decisions made by leadership and even their qualifications will be questioned.

The important thing is to make sure that you don’t just double down and keep ploughing through when the general sentiment is negative.

Be sure to set checkpoints throughout the process. If need be, stop the process to adjust. Admit to both yourself and the team when it fails, but also make it clear what was learnt and how you now have a new plan that takes that into consideration.

If however you believe strongly in the change and you see what it will do for the team or organisation, you’ll have to accept the second guessing of your decisions. You’ll have to accept a strong rotation of people.

Ultimately the decision is yours, but you can work to mitigate it.

Example 2: The Right level of Transparency

In today’s product world, many product leaders want to create transparency and open forums for sharing. They want the team to be aware of everything.

The challenge arises when something is shared that hasn’t been properly hashed out yet or will be happening months in the future.

Person A: “Our leadership style is super transparent and people have an open window to the whole change process we’re going to implement. That provides them with confidence and security. They now know when things are going to happen and when it will affect them.”

Person B: “Okay, I’ve now seen a six month plan with so much to do. I’m going to get a jump on some of the things right away… but it seems all the resources aren’t ready yet. I also didn’t understand how this part is going to work. If I want to start that a month early, how do I do it?”

Although at first, we feel we’re being open and transparent, for the team it may create stress and insecurity.

Stress, because they may start assuming the whole change process as a whole and have difficulty understanding that certain phases will only impact them in months or years.

Insecurity, because as much as people say they want transparency and to be involved throughout the process, for them, they expect a big change will already be properly defined and set out. Lack of definition on something makes them doubt that all aspects have been properly thought out before making a decision. We all want iterations when building products but fear it when going through an organisational change.

I’ve found that what works best is to break the process down into small workable parts, much like a roadmap. What is going to happen in the next 3 months is clear. What is happening afterwards? We’ll define that during the next 3 months.

Be clear on what has been defined. Be clear on any needs or requests you have from the team to help define the next 3 months.

Again, it’s the internal product or organisation you’re working on. Treat it as such.

Example 3: The dwindling light

In the beginning, you may even have staunch supporters of the change and everybody seems on board, but like I discussed in the first example, as time goes by, the team may begin to doubt everything about the change.

Questions will arise and the team may reach a point where they only see darkness and no longer are able to see beyond that towards the goals we set out together.

Person A: “We know it’s a tough challenge for the teams but we also know the rewards will be incredible. All change takes time and we have to go through the uncertainty to obtain great results in the long run. If they aren’t resilient enough, then it’s not our fault.”

Person B: “We started this change months ago. We’ve made so many ‘improvements’ and changed so much, but I just feel we have more to take on and I’m not really seeing any results. I feel it’s just becoming a bigger mess.”

To work through, we need to keep the team’s hope up. We need to help them see the light at the end of the tunnel.

By defining milestones and celebrating the wins, we give them stepping stones throughout the process.

Show & tell with concrete examples how things are moving forward or how we’re closer to achieving our goals. Qualitative feedback may seem like it’s enough, but in most cases it isn’t tangible enough.

And finally, don’t ignore their concerns. They’re very real to the people on the team going through the change and downplaying them will seem as if you aren’t giving them importance.

Final Thoughts

As a final wrap up, I want to leave you with a small summary of everything we’ve gone through in this article to help you navigate mixed perceptions.

  1. We need to understand that for the individual, their perception of the situation is their reality. We can’t pretend it isn’t
  2. Our brains are naturally hot-wired to jump to conclusions
  3. We need to make a conscious effort to recognise and mitigate those biases
  4. We discussed 5 simple rules to help with that
  5. It’s up to us in our role of product operations to help the organisation navigate perception bias as we are well positioned to do so

And at the end of the day, much like building a bad product we need to avoid implementing bad changes and adding to the already confusing world of digital product.

If it doesn’t make the world better. Don’t do it!

Please feel free to reach out to me with any questions or comments.

(This is a write up of a talk I gave recently at the Product Operations Festival run by the Product-led alliance.)

--

--

Hugo Froes
Hugo Froes

Written by Hugo Froes

// Leading Product Operations at OLX Motors EU // Helping to make better products — Co-founder of @uxdiscuss with @whitingx

No responses yet