What If We’re Wrong About This?

There is one question I think product teams should ask more often: what if we’re wrong about this?

It sounds simple, but it can feel uncomfortable. In product work, ideas can quickly become personal. A design is not just a design. It can be weeks of thinking, meetings, pressure, and small decisions nobody else has seen. A product direction is not just a direction. It can be tied to a roadmap, a stakeholder, a client request, or someone’s confidence in their role.

So when someone challenges an idea, it does not always feel like curiosity. Sometimes it feels like a threat. That is where confirmation bias can quietly appear.

Confirmation bias is when we look for information that supports what we already believe. In product work, it shows up when a team protects an assumption before they have tested it. It can sound like:

None of these phrases are always wrong. Gut feeling and experience can help. But when they become the only evidence, the team builds on ground that has not been checked.

Early in my career, I did not always notice when I was trying to confirm my own thinking. What helped was being around people who questioned things properly. At the time, that was difficult. I often felt defensive. I felt like I had to prove I knew what I was doing.

That is a normal reaction. Most people want to feel capable at work. We want to belong in the room. We want our ideas to make sense. So when someone asks, “What do you mean by that?” or “What evidence do we have?”, it can feel like they are questioning our ability.

But looking back, those questions helped me grow. A good manager once helped me slow down. Instead of jumping from one idea to the next, he helped me focus on what had actually been said, what had been found, and what was still an assumption. Reducing confirmation bias is not about having no ideas. It is about knowing the difference between what you discovered and what you filled in yourself.

Confirmation bias is not just in one person’s head. It can become part of team culture. It shows up when teams stop letting new information in. Research gets avoided. External views get ignored. Feedback gets dismissed because it does not match the plan. It shows up when leadership tells the team what to design instead of opening up the problem, or when the loudest person in the room becomes the direction.

It can also show up when a client asks for something and the team simply builds it without questioning the need underneath. That might feel efficient, but it does not always create value. A product team is not there just to build what was requested. A good team helps uncover whether the request solves the right problem.

Reducing confirmation bias helps teams move from “how do we prove this idea works?” to “how do we find out what is true?” Those are very different questions. One protects the answer. The other opens the door.

One of the best ways to reduce confirmation bias is to listen when someone challenges an idea. That sounds obvious, but it is hard when you feel uncomfortable.

A useful model for this is LEAPS: listen deeply, empathise, ask clarifying questions, paraphrase, and summarise. The important part is not just repeating words back. It is trying to reflect the other person’s point in a way they actually recognise.

If someone gives feedback, the goal is not to bend their words into a shape that is easier to argue with. The goal is to understand what they are really trying to say. A good test: could you explain their concern in a way that makes them feel understood? If not, you probably are not ready to defend your point yet.

Sometimes the most useful thing you can say in a meeting is, “So what I think you’re saying is…” That one sentence can lower the temperature. It gives the other person a chance to correct you, and it gives you a moment to stop reacting and start listening.

Another thing that helps is changing how we talk about ownership. There is a big difference between “I created this design” and “We are shaping this product.” The first can make every challenge feel personal. The second makes challenge feel like part of the work.

That does not mean designers should avoid responsibility. The product is not created through one person’s lens. It needs input from design, product, development, research, support, sales, leadership, and the people using it. When the work becomes shared, the pressure changes. You are not defending your idea alone. The team is testing whether the idea is strong enough to help users.

That shift makes it easier to hear feedback, change direction, and say, “Maybe we need to look at this again.”

Design reviews can help, but they can also amplify bias if they are not handled carefully. Sometimes the loudest person speaks first, and the room bends around their opinion. Quieter people hold back. People agree too quickly. The team may leave thinking there was alignment when really there was just volume.

One way to reduce this is to gather feedback individually before the group review. Speak to a few people separately, ask them to walk through the design, and let them respond without the room influencing them. Then compare the themes. This gives quieter voices more space, and it helps you see whether feedback is a pattern or just one strong opinion.

A cognitive walkthrough can help too. Instead of asking, “Do you like this?”, walk through the flow and ask, “Would the user continue at this point?” That moves the conversation away from taste and back towards behaviour.

Research should help teams escape assumptions, but only if it is set up carefully. A usability test can still be biased. If the participant feels like they are being tested, they may try to please you. If you over-explain the prototype, you may teach them what to do. If you rescue them too quickly, you may lose the moment where the real problem appears.

Before a session starts, make one thing clear: we are testing the product, not the person. If they struggle, that is useful. If they get confused, that is useful. If they cannot find something, other people might struggle too.

During the session, let silence do some work. If someone gets stuck, you do not need to jump in straight away. Ask gentle questions like “What are you trying to do here?”, “What are you looking for?”, or “What would you expect to happen next?” What people say matters, but what they do often tells you more. If they say something is clear but hesitate for ten seconds, that hesitation is part of the evidence.

The danger is teaching the happy path too early. Once you show someone where to go, you may affect the rest of the test. Good research protects the truth from our need to be right.

This might sound strange, but reducing confirmation bias can make teams more confident. Not loud confidence before the evidence arrives, but a steadier kind. The kind that comes from knowing you listened properly, tested carefully, and made space for different views.

When teams reduce confirmation bias, they understand users better. They understand each other better. They communicate more clearly. They become less defensive because the goal is no longer to prove one person right. The goal is to learn enough to build something better.

That is why the question matters. What if we’re wrong about this? It is not a weak question. It is one of the strongest questions a product team can ask. The team that can ask it can also learn, adapt, and grow. Better products usually start there. Not with certainty, but with the courage to question it.