As human beings, we’re all prone to biases — confirmation bias being one of the most notable. It affects communication with clients and can deeply impact product development, especially in the early stages when startups are striving for product-market fit.

When clients listen, they often filter information, retaining only what aligns with their existing beliefs and dismissing the rest. It’s a self-defense mechanism. If they don’t like what users are saying, they simply ignore it.

During conversations with the customers, they try to learn more about their needs and motivations, they pick up bits and pieces, but may shape the narrative completely wrong.

No matter how many user interviews they conduct, confirmation bias leads them to believe they’re right because they only hear what they want to. The bigger the sample size, the more convinced they are of their accuracy, making the interviews pointless.

Instead of being open to new perspectives and adapting accordingly, they stubbornly hold on to their beliefs, especially if the leadership is autocratic and resistant to others’ opinions.

Sometimes, psychology serves product development better than business logic. Futhermore, they’re building the producing using an established route.

Even if clients engage with users to achieve product-market fit, they often don’t make testing a regular habit. They perceive it as expensive, time-consuming, and low-priority, not realizing that building something no one will use, is far costlier.

I’ve seen solid products turn into cute little Frankensteins because assumptions were made, and user feedback was ignored. The room may be full of stakeholders, product owners, project managers, and developers, but the most important person — the user — is absent.

Nevertheless, right after discussing a request, teams quickly move on to execution, deciding who will do it and by when. It may look like efficient work, but without considering whether the feature is needed or whether time and resources could be better spent elsewhere, they risk wasting valuable effort.

Yes, we can quickly mockup dirty prototype and test it with a few users. Sometimes even thoughtful user interview could be enough to decide. Or even, if we strongly believe that’s the right thing to do, we can do the usability testing afterward.

Before building any significant feature, it’s essential to loop users in for a feedback. If we would ingrain this practice in our workflow, it could significantly improve the quality of the outcome.

Ignoring their voice is like ignoring an odd sound from your car’s engine — you’re asking for trouble. When a good driver is driving, he’s not only listening to his passenger or the music from the radio, but he’s aware of any dissonance in the engine sound.

Doing your job the same way for years will build velocity, but without experimentation, you’re unlikely to move the needle. No matter if it’s just slightly updating the process or trying out a completely new things.

Some clients resist changing processes that “work well enough.” They view experiment as risky and rather unnecessary.

If you consider how rapidly technology is changing, and how industry becomes more complex and specialized, sticking to the same old path could mean getting left behind. Just because something works today doesn’t mean it will bring the results tomorrow.

From that perspective, the main value of playing with the different approaches — would be staying afloat.

And I think it’s pretty valid reason to take small, risky steps from time to time. It’s not easy to compromise delivery for an exercise that may not yield results, but when communicated upfront, the potential for innovation is worth it.

The question to always ask is: Is there a better way to get shit done?

Whether it’s tweaking processes or replacing some painful work with still-not-perfect AI tool, it’s worth a shot. Afterwards, if it doesn’t improve things, you can always revert back. Failed experiments still offer valuable lessons.

I’ve worked with guys who are in the process of transitioning from physical to digital landscape. They were very experienced, with extensive knowledge and a list of achievements in their industry.

They wanted to keep up with the times, so they bravely entered the digital landscape, eager to find out how it works. With an extensive research about their future operation, they built the team, set up an infrastructure, same as many times before in their careers. Well, almost the same. The only difference was that before, it was within their own field, where things had remained unchanged for a long time.

One by one, questions started to pop up. There was an overwhelming amount of complex information to process. They discussed technologies, roles, and deliverables with the team, only to be surprised by how much time certain things took. With so many topics raised, the only familiar thing they knew was — their own profession. Suddenly, this new ground felt shaky. They realized they lacked a few skills, but the one they were missing most was knowing how to serve their online customers.

Like overlooking the fact that cramming way too many items into their web shop window only overwhelmed and frustrated already impatient users. Or trying to impress them with a fancy hover effect that takes longer to load, leaving them dissatisfied.

If you don’t provide a pleasant digital shopping experience, users won’t complain — they’ll simply leave without a word. So you’ll not be able to fix the problem by giving them a free voucher. And they might not come back, leaving you with bad reviews for others to see.

They learned all these lessons (and many others) the hard way. On surface levels, entering the digital world seems like it’s about the technology or tools, but when you delve deeper, you see that it is about how people act and behave.