In the first part of this two-part mini-series, we already described 6 thinking errors that can occur when planning, implementing and managing software projects. And we have drawn a first conclusion: Setting and measuring the achievement of goals helps to realistically assess one's own situation, diversity of opinions and people is important in the software industry, and in general, you can easily stumble into thinking errors in digital projects that you also know from everyday life. For those who haven't read the first blog yet: Here's part 1, where we of course also wrote about the reasons and motivation behind these 2 blogs. For all those who have already read part 1, let's start with cognitive errors 7 - 12.
7. Incentive-Superresponse-Tendency
As already briefly touched on in Part 1, this thinking error describes the problem of incentive systems: Whether in politics, society or business, as soon as an incentive is defined for or against something, this has a strong influence on people's thinking and behavior.
In terms of digital product development, this can mean that when incentives are set, such as meeting a delivery date, other important metrics such as test coverage, user experience, attention to detail, or project efficiency suffer just because the incentive is "merely" set on meeting a deadline.
It is very important that we are very aware of what can happen through the definition of incentive systems. It is absolutely central that the team and personal goals of employees are derived from the corporate and business goals to ensure that there is added value for the entire organization.
Too much focus on individual goals with large incentives can become very dangerous. This can be observed, for example, in the financial sector, when bonuses are set as incentives for closing loans and, in doing so, the incentivized employees make as many loans as possible without, however, considering the sustainability of these loans. It is probably true that there were no bad thoughts behind this goal, but at the same time it was forgotten that people react strongly to incentives, but often do not consider the actual intention behind the incentive set.
Burned out battery of a Galaxy Note 7. Image: BBC/Reuters
In 2016 Samsung launched the Galaxy Note 7 in fall as usual: A new flagship product on the market exactly at the planned time. Whether the unconditional adherence to the release schedule was the reason for the poor quality control, exploding batteries and a recall campaign of millions of devices?
8. The Outcome Bias
An outcome bias occurs when a decision is based on the outcome of previous events without taking into account how those previous events unfolded. When an outcome bias occurs, the factors that led to an earlier event are not analyzed. Instead, the events that preceded the outcome are downplayed and the outcome is overrated.
Let's assume that 10 people each receive 1 million francs to develop and market a successful app. After one year, five projects have absolutely no success, four others are doing moderately well, and one app seems to be on its way to becoming a big hit. After two years, five projects are completely down the drain without ever having become successful, two others are just barely keeping their heads above water, two have managed to break even, and a single app project has become so successful that it is bought and used regularly several hundred thousand times worldwide. This is now called the "success app" and the media, as well as many specialists and experts will now try to find out the "recipe for success" of this app and write a report, a blog post or even a book with the title: "The recipe for success in app development".
This story describes the tendency to evaluate decisions based on the outcome rather than the decision-making process at the time. In order to evaluate the quality of the decisions, we have to put ourselves in the original information situation and filter out everything that we only learned about it after the fact. The fact that precisely this app became the most successful should not be included in the evaluation of the decision-making processes. We can only really judge the decisions of the successful app if we understand something about app development, if we closely observe the approach and execution of all activities, and if we thus judge the process and not the result.
Dating apps as an example - one of the most popular app categories: There are millions of users. However, only a few of them are successful, hundreds of such apps are "gathering dust" in the app stores. Although Tinder is obviously very successful, one should not forget the many failed apps.
9. The Control Illusion
As with the pitfall of overconfidence, this thinking error is about believing we have mastered something we simply cannot influence. For example, have you noticed that the general public tends to roll a die stronger when the target is a high number and weaker when a low number is desired? In many cases, this is the case with myself and my kids.
In the app business, we often experience that customers want us to tell them after the first conversation whether their idea for a digital product will be a success or not. What we can offer our customers is simply our subjective assessment of the idea, which should in no way be taken at face value. We can only influence to a small extent whether the intended target group will value the problem that the product is intended to solve and thus use the digital tool regularly. However, in order to be able to assess as early as possible whether an idea will work or not, we recommend to involve potential end users in the concept development in early phases and to validate the hypotheses on which the idea is based with prototypes by means of user research before even writing a line of code. More about prototyping can be found in the following blog post.
How can we escape the illusion of being able to control things over which we have little influence?
Let it flow: We should let things that we cannot influence flow, instead of trying to take artificial control.
Hypothesis testing: Prototyping, user research and a user-centered approach should be used to validate our hypotheses early in the idea and concept phase.
Think Again: Carefully think about whether you can really control something (e.g. the success of a product) or whether this is simply subject to too many unknowns or factors that cannot be influenced.
Focus on things that can be influenced: Rater invest your time in things that you can effectively and to a large extent influence / control.
Iterative approach and user centered design: Co-creation, involvement of target groups from the beginning can prevent us from making wrong assumptions about the needs, problems, interests and feelings of end users.
10. The Cognitive Dissonance
Cognitive dissonance can be explained like this: The weakness to admit mistakes or weaknesses to oneself, as well as the ability of humans to positively influence their own feelings even with small lies, works in such a way that a clearly wrong decision suddenly becomes a plausible OK decision.
Aesop's fable explains the thinking error
The Greek poet Aesop illustrated this widespread thinking error with a fable. A fox, which despite several attempts could not reach the juicy grapes because they are too high up, is content in the end with convincing himself that the grapes are not yet sufficiently ripe for him anyway and therefore sour.
Bust of the fabulist Aesop
Especially as a product manager, sales or marketing manager, this thinking error can happen very quickly.
It is not uncommon for me to agree to a project despite a bad gut feeling and less than ideal conditions. In many cases, the gut feeling is not wrong and the project becomes difficult, many unforeseeable problems arise, misunderstandings exist and thus everyone involved is rather stressed and has a bad experience. During the debriefings, it then happens quite often that I find myself making statements like "it was still good that we did the project because we were able to learn a lot". The original goal was actually that we could implement a successful, educational and sustainable project for the client and for us. Since this result did not materialize, I can now either:
a) try to make the project a success after all
b) admit to myself that it was a mistake to start the project under these circumstances or
c) by adjusting the objectives and a bit of self-deception, still call the project a "success", in that it is enough that we have learned something from it.
Of course, failures and difficult projects are also very important for us, but one should also be able to admit this 100% in order to learn effectively from it.
In my view, it is a great competence when someone can fully admit to mistakes and dedicate him or herself to the learning process in order to avoid the mistake in the future. It should not hurt to make a mistake, but should evoke a good feeling of "Yeah, now I've learned something again!". For this very reason, it is also important to enable a culture in an organization in which failures and wrong decisions can be openly discussed and learned from.
11. The Anchoring Effect
The anchor effect is a term from cognitive psychology and describes the assimilation of a numerical judgment to a given standard of comparison (anchor). The problem is that we are influenced by this given standard of comparison when making decisions without being aware of this influence. The anchor effect, then, is the tendency to rely too heavily on an initial piece of information, called an anchor, when making decisions. On the one hand, I know this effect from my travels to distant countries, where the prices for products are not fixed from the beginning, but rather have to be negotiated. Whether at a market in Morocco or at a bazaar in Turkey, when haggling about the price, the first mentioned price is usually set as an anchor and thus represents the starting point for the negotiations. In many cases, the initially communicated price proposal influences the final outcome of the negotiations.
But this effect is also often encountered in software development. For example, when it comes to calculating a serious estimate for the costs of a new native app, web app or even a backend or interface. If we communicate to the team that the customer has a certain budget before estimating the costs for the existing software requirements, the chance is very high that the estimated price will be based on this set anchor in the end.
A second example in the same context is that, for example, the estimate of iOS (Swift) developers is often influenced if an Android developer has already entered the effort (estimated hours per requirement) in the estimation document.
Some tips to avoid the anchor effect when estimating effort:
Never communicate an existing or desired budget before the estimation work, but let all estimation participants estimate as unencumbered as possible (without an anchor).
Hide hours already estimated for one discipline (e.g. Android development) when estimating the same requirements for the second platform (e.g. iOS development). This should prevent one side from being influenced by the other side's estimate.
Have different people estimate the same requirements in each case without knowing each other's estimate. After several people have estimated independently, the numbers can be compared; if the differences are only small, the mean can be assumed to be a good estimate. In case of larger differences, all those points can be discussed in the team, which show very high differences and are therefore probably afflicted with different assumptions.
12. The Scarcity Fallacy
Rara sunt cara - Rare things are valuable. After I have written so far actually only about problems in connection with thinking errors, it is time to point out also the possibility to draw a use from the omnipresent thinking errors.
The scarcity fallacy addresses the thinking error that we consider things that have limited availability to be more valuable, even though they otherwise contain no other quality features or additional functions. The mere fact that there are not an infinite number of copies / pieces / accesses / invitations of something makes it (supposedly) a more valuable good.
Examples of the scarcity fallacy in game development
Let's assume you want to successfully launch a new mobile game. As usual, you will try to build as large a community as possible in advance. Since you know that people value scarce things more highly, you artificially limit the number of pre-release versions (beta testing community), for example to 50 beta users. A landing page then says, "sign up now to get one of the exclusive 50 pre-release versions." This gives interested people the feeling that they have to register immediately, otherwise the chance to get this exclusive version is lost. Of course, you can reinforce this psychological effect by having a counter that shows how few slots are still available and this counter also gets smaller on a regular basis.
Especially in advertising or e-commerce, this thinking error is very often played with. For example, on booking platforms for hotel rooms. Often it says "only one room left" and "two more people are looking at this offer right now!". This produces an inner stress and a feeling of "now or never." Discounters work in the same way with the daily, weekly special discounts, which are limited in time or quantity ("only while stocks last") and therefore make us mistakenly think that we have found a particularly good offer here.
How to escape the scarcity fallacy
Whether something is in short supply or only available for a certain period of time (e.g. Black Friday, Cyber Monday, etc.) should not play a role in the decision for or against a purchase. What criteria are important to someone when buying something are highly individual. The important thing is to apply those criteria and not invent new ones to it like the product should be rare or the product should have only been offered at that price for one week. I don't think anyone seriously has such buying criteria, unless of course you are an art dealer, collector or similar.
Typical information about the limited availability of hotel rooms on a booking platform
Conclusion: 12 cognitive errors in digital business
Nachfolgend eine Übersicht der in diesen zwei Blogs beschriebenen Denkfallen. Nebst den reinen Bezeichnungen, welche oftmals schwierig sind, sich zu merken, habe ich jeweils eine Frage oder einen Input angefügt, welcher helfen sollte, diesen Denkfehler zu vermeiden.
Part 1:
The Overconfidence-Bias
Obtaining feedback from other people on one's own assessment usually helps to reduce one's own overestimation. In general, modesty also helps, as Socrates already knew: "I know that I know nothing."
Sunk Cost Fallacy
Pay attention to the achievement of set goals rather than considering the investments already made when making decisions for the future
Confirmation Bias
Explicitly look for disconfirming evidence and pay at least as much attention to it as to evidence that supports your theory.
Authority Bias
Before we form a decision or opinion based on the statement of an expert or authority, we should think for ourselves and look for contrary opinions. Diversity and an open feedback culture in decision-making bodies and teams usually helps to prevent bias.
Survivorship Bias
Be sure to look for failures in the big graveyard of failed app or web projects. Soon you will realize that there are probably much more failures than success stories, but the perceived presence of successful digital products is of course much larger.
The Swimmer's Body Illusion
Think and ask yourself the question: what is really the cause and what is the effect.
Part 2:
Incentive-Superresponse-Tendency
Ask yourself if you have created an incentive system through the defined framework in the project, which will have a negative impact on the process, the decisions or the final product.
The Outcome Bias
Never judge a decision already made by its outcome.
The Control Illusion
Is the success or failure of the digital tool really in my control? What factors effectively influence the outcome?
The Cognitive Dissonance
Don't lie to yourself, own up to your mistakes and try to learn from them. If you can identify your mistakes, own up to them and find alternative solutions to your problem, this can reduce cognitive dissonance.
The Anchoring Effect
Reflect on yourself and try to find out if a decision has already been influenced by a previous piece of information (anchor). Get second opinions and make sure that you are not already influencing the person from whom you are getting the second opinion by your own opinion / decision.
The Scarcity Fallacy
Can I increase the perceived value (demand) of supply by artificially shorting it?
Conclusion on Cognitive Errors and Pitfalls in Software Development
Everyone makes thinking errors all the time and I would love to meet all those who claim that this is not the case. Even after I have written this blog post and you have read it, this will not free us from cognitive errors and "systematic" misdirection of our brain. I guess this leads to the question: why bother? Well, there is some hope that because of the knowledge of these thinking errors, our own ability to reflect and thus the chance that we will discover our own thinking errors and introduce tactics to reduce these misconceptions will be increased. Whether this already corresponds to the thinking error of overestimating oneself is of course the next question 😉 From my point of view, self-reflection, obtaining feedback from various people and the active search for contrary opinions and evidence are already good measures to prevent quite a few thinking traps, respectively to reduce their negative influence.
Finally, it is important to mention that in this blog series only a small part of the existing thinking traps have been described and that there are many more possible thinking errors also in software development, which one should pay attention to in order to prevent fatal wrong decisions. We would be happy to hear your ideas, experiences and tips with cognitive errors in software development.
