10 biases to be aware of when building products
We can’t “fix” our minds and stop making errors in judgment, but we can become more aware of biases that influence our decision making.
Building products is a cycle — from creating a roadmap and conducting research to execution and post-launch, we almost always repeat the same steps. As we do them over and over again we gain more experience and develop our intuition so each time the outcome is better and requires less mental effort.
But even after repeating the same thing multiple times we are subjected to biases — systematic errors that occur because our mind is overloaded with data and looks for the easiest and shortest way to process all of it. We can’t “fix” our minds and stop making errors in judgment, but we can become more aware of biases that influence our decision making.
Let’s break down the product building process to 3 main stages (the planning stage, the building stage & post launch) and see how we can make better choices concerning our products when identifying these biases.
The Planning Stage
The planning we do before developing a product includes research, definition of the problem and the scope of the solution. But no matter how confident we are in our vision of what needs to be done, we must align it with the management & relevant stake holders. Everyone has their own opinion and making tradeoffs is hard — we need to compromise on certain things and decide which ones to tackle first.
So how do you know you’re not leaving out important features out of your scope, in favour of momentary whims?
Availability Bias
This heuristic refers to our tendency of judging the magnitude of an event based on the ease with which it comes to mind.
When prioritising features and deciding what are the most important ones to do, we’re likely to prefer things that come easily to mind. Things we hear about recently and frequently (“frecently”).
For example, if there’s a feature a user asked for in the past week and was also mentioned to you by a colleague, you might think it’s something you should include because “everyone are asking for it”. But in fact, it‘s the availability bias that makes it seem like so. We need to overcome this assumption and rely on data to make the right decisions.
Affect Heuristic
The affect heuristic is a type of mental shortcut in which people make automatic decisions while influenced by their current emotional state.
Sometime, emotions can cloud our judgment and influence our decisions. This may happen when we are under stress and don’t have time to consider risks vs benefits so we trust our “gut feeling”. We might think a feature’s cost is low and the benefit is high just because we like it. When this happens, we tend to overlook relevant information and act only upon how this feature “makes us feel”.
It’s important to maintain an objective point of view backed up by research and data with clear pros and cons when making decisions.
Optimism Bias
This bias causes us to believe that we are at a lesser risk of experiencing a negative event compared to others.
This causes us to underestimate the costs and the duration of a project we are about to start, failing to take unexpected things that might happen into account. Personally, I can’t remember when a project I was part of went exactly according to plan.
This can also be reflected in a decision to release an unfinished or bad product, hoping your users “will adapt” and use it anyway.
The Building Stage
We build products for people with complex minds (like our own). Let’s look at a few biases our users may have when using our products that we should think of in advance:
Mere Exposure Effect
The mere exposure effect is a psychological phenomenon by which people tend to develop a preference for things merely because they are familiar with them.
The more your product resembles and behaves like something people already know and used to, the easier it will be for them to accept and adapt it. It can be a mobile navigation pattern, or a simple thing like a “pressed” state of a button when you click it (mimicking a behaviour of an actual button) that makes a product feel “familiar”.
Make sure it’s clear what your product does and how to use it. Consider making it similar in a way to the popular ones. I’m not saying you should copy another product, but if you’re breaking a solid convention, you better have a really good reason why.
The Principle of Least Effort
The “principle of least effort “basically states that if there are a few ways to get something done, people will always prefer the one that requires the least amount of work.
Our brain is lazy by nature, and if your product offers several ways to achieve the same goal, people will use the shorter and simpler one. Don’t make it hard for your users with complicated flows, long forms, and exhausting interfaces. They use your product to get a job done, help them do it seamlessly and don’t make them think too much. Don’t be afraid of adding “additional clicks” — sometimes it’s better to break a long flow to bite sized, scannable chunks of information.
The Anchoring Effect
Anchoring is a cognitive bias for when people rely too heavily on an initial piece of information offered (usually a number) when making a decision.
We influence our users’ decision making by providing an initial starting point, next to which, other options seem reasonable. For example, we can see that in premium plan package pickers: when giving a user an “anchor” — the value of highest priced package, the “recommended” package seems reasonably priced, or even too cheap, in relation to it.
Post Launch
After releasing a product we need to see how it performs and collect feedback from users in order to decide how to proceed. We really want our product to succeed so we’re naturally biased towards it being good and are looking for confirmation that we are right in our decisions.
Confirmation Bias
This error makes us automatically embrace information that validates our point of view, while dismissing details and facts that contradict it.
After building and releasing our product to the world we must stay objective to the user feedback it receives. The confirmation bias makes us look only for the good feedback in order to confirm our assumption, making us blind to opinions we don’t agree with and ignore details that cast doubt on our beliefs.
The Law of Small Numbers
This judgmental bias makes us jump to conclusions with just a few data points from a small sample population.
Let’s say you open your feature to 10% of your users which are a 10 people. 8 of them give the same feedback. That’s 80% of the tested group. You might think it’s representative of the user population and it’s safe to make a decision based on this information. But you’re actually looking at only 8% of all of your users. The optimal thing to do would be waiting until you collect a big enough portion of feedback and only then make a decision, and always look on the absolute number next to the percentage presented to get the full picture.
Sunk-Cost Bias
This fallacy makes us continue investing in a loosing cause because of the time / money/ effort we already spent on it.
Sometimes a product does not prove itself profitable or takes too much time and effort to develop, making itself not worth the investment anymore.
Sunk-cost thinking makes us stick with a bad product because of the time and money we have already lost on it. Killing a product is hard, especially if it’s something that you’ve built. And it gets even harder to abandon it over time because we start focusing more on what we’ll lose rather then what we’ll gain. In this case, it’s better to stop before you lose more of your resources, and spend them on a better investment.
Conclusion
These are only some out of the many biases we are subjected to while building our products. I want to finish off with a particular one to keep in mind:
Bias Blind Spot
While we can easily notice flaws in someone else’s judgment, we fail to see the impact of biases on ourselves. Daniel Kahneman summaries it this way:
“We’re blind to our blindness. We have very little idea of how little we know. We’re not designed to know how little we know.”
Thanks for reading!
