Cognitive Errors in Digital Business - Part 1

Unfortunately, the nature of human thinking is not necessarily rational and often thinking errors that we would rather avoid creep in. In the context of software development, there are also a number of thinking errors that can lead to incorrect assumptions and sometimes quite costly decisions. In this article, we provide tips on how to recognize these thinking errors and, in the best case, how to avoid them. 

The idea to write a blog about the topic of thinking errors in software development came to me because of the book by Rolf Dobelli with the title "The Art of Thinking Clearly". In this book there are 52 cognitive errors, which provided me with some exciting insights in an entertaining and understandable way. 

Because there are quite a few such thinking errors in the digital business, we have divided the blog into two parts. Here are the first 6 - part 2 will follow in the near future.

1. The Overconfidence-Bias

Overestimating yourself is a thinking error that we often encounter in app development as well as in everyday life. We use an app or other well-known software and think "I can do that much better! This misconception happens not only to our customers, but also to ourselves, especially when it comes to the exact estimation of project costs, duration or the potential success of digital products and services.

Examples of overconfidence in software projects

Quite often we receive requests for app development with statements like: "I know how to make e.g. Facebook or Instagram much better, you would only have to add this or that and not collect data. Please give me a price on how expensive this better version of Facebook will be".

Many people probably don't realize that Facebook has written more than 60 million lines of code and that a functioning platform requires a very large number of users in order to offer any added value in the context of the community.

Not only our customers overestimate their knowledge and skills, but also we as project managers, software developers and design specialists suffer from this phenomenon from time to time. Especially when it comes to realistically estimating the development time for a new software project, we often fall into the trap of assuming that all work can be done efficiently and effectively, instead of assuming the realistic case that unpredictable challenges arise in virtually every project, which then require more time than expected.

In the case of effort estimation, in addition to the overconfidence effect, there is also the "incentive-superresponse tendency", i.e. the tendency to react to incentive systems and thereby maximize personal benefit. The chances of a new order are perceived to be higher with a tighter estimate than if we include a large reserve for unforeseen events. In the worst case, this can lead to disappointment on both sides. For the development team, it will lead to planning changes and discussions; from the customer's point of view, it can lead to delays and additional costs, i.e. a poor customer experience.

Possibilities to reduce the Overconfidence-Effect: 

• Assume the pessimistic rather than the optimistic scenario.

• Diversity: Different people estimate things differently. The thinking error can often be avoided if one has one's own assumptions validated by other people. In the best case, without communicating one's own conclusion in advance. 

• Make the hypotheses on which the assumptions are based explicit and test them seriously with clear quantitative and qualitative goals and metrics. 

• As a customer, you should not put pressure on a seriously prepared effort estimate of the development team. Why should someone estimate much higher than necessary? The competition in the market is too big for anyone to afford unrealistically high estimates. Our experience shows that heavily negotiated prices/estimates usually end up back at the original price at the end of the project anyway.

• Include a reserve for contingencies in the budget to get a realistic picture of the costs.  

2. Sunk Cost Fallacy 

As unpleasant as it may sound, it would often be best if we could manage to forget the past and consider only the future prospects without all the past effort in our minds. 

We humans want to appear consistent, which is why we behave irrationally when an "outlier" or contradiction presents itself. By behaving consistently, we want to establish credibility and trust. Abandoning a software project in the middle of the effort because you have not met self-imposed goals is a clear contradiction to an otherwise consistent performance. However, continuing a pointless project only delays the pain. So the saying, "Better an end with horror than horror without an end" should definitely be taken to heart. 

All too often, we give value to past costs when deciding on the future of an endeavor. Even though goals were far from achieved, we say to ourselves, "Now we've come so far and invested so much time in this project, we can't just abandon it." In the vast majority of cases, however, failure is only delayed and made more expensive.

Tips for Avoiding the Sunk Cost Fallacy:

• Set clear, realistic and measurable goals from the start and decide on the basis of their achievement.

• It is better to bite the bullet sooner rather than later

• Involve neutral persons who bring objectivity in the decision

• In each case, consider what alternatives would be possible if the planned budget were invested in other projects / products.

3. The Confirmation Bias

A ubiquitous thinking error that we probably all know - and yet are regularly caught by it. 

Example from the public discourse

There are always different opinions and positions, of course. But it is often exciting to see in public discussion how all positions, armed with "evidence" and "facts", are very sure of their own opinion. Each side can find enough material on the web that offers arguments for one side or the other. We love to find videos, blogs and posts that confirm our own opinion and usually ignore the contrary facts and opinions. If there is something that we ourselves can not deny, then we call it special or individual case. 

Example from software development

At all levels of software testing, we aim to fully test the code in order to detect software bugs and thereby improve the quality of the software. However, software developers and testers tend to test positively rather than negatively because a negative test is not a confirmation but precisely a refutation. This is due to the phenomenon known as confirmation bias, which leads people to prefer confirming their own hypotheses rather than trying to disprove them. This is one of the reasons why we place so much emphasis on having a QA team that is as independent as possible.

Example of confirmation bias among apppreneurs

Many apppreneurs who have product or marketing responsibility are much more open to evidence that supports their assumptions, strategies and actions. Disconfirming evidence (things that speak against my assumptions) is usually not sought, or if present, rather ignored. This means that as an app manager, I would much rather collect and widely communicate all possible indications that speak in favor of the success of the app or my measures than all indications that speak against my success. 

A good approach by Albert Einstein

Albert Einstein also knew this phenomenon well and had a rather pragmatic recipe for it: He spent as much time as possible to find exactly these "disconfirming evidences" and to take every single one of them very seriously in order to disprove his own theses before someone else could do so. We should think in the same way.

4. The Authority Bias

According to Stanley Milgram's experiment in 1961, people tend to attribute a higher value to the opinion of "experts or specialists" or to a person who is considered "authoritarian". Particularly in digital business or around the digital transformation of society and the economy, there are extremely many so-called "experts and specialists" who then sell their half-knowledge to ignorant market participants in the form of consulting mandates or publications for a lot of money. 

Perhaps someone remembers Mark Zuckerberg's statement in 2016, which predicted the end of native apps and the rapid rise of smart chatbots. Many market participants immediately believed this and started developing chatbots or founded companies that develop such chatbots for others. About six years later, it is safe to say that this scenario did not become reality. The app market is still growing strongly and the number of really useful and widely used chatbots is still very manageable. We also took up the topic in our blog back then and wrote about chatbots 

I believe that we would not have written this blog without Mr. Facebook's statements. 

Authority bias is often exacerbated by the belief that obedience represents correct behavior. To counteract this bias, one should examine one's own assumptions and ask oneself if any of these assumptions were made because of a bias against an authority. This authority may be one's own organization, a recognized player such as Google, or perhaps even one's own former self. In either case, question the authority rather than blindly relying on what may be a biased opinion.

Especially with new trendy and hyped topics, such as blockchain and cryptocurrencies, we often observe this authority bias. In many cases, we base our own opinions on statements and opinions of other, from our point of view, bigger authorities in these topics. Of course, it is important to listen to and read different opinions and views of so-called experts, but it is equally important to always question them and consider for yourself to what extent these statements are really based on facts and figures and have validity in your own context.

5. The Survivorship Bias

Because successful apps get much more exposure, visibility and usage than all the thousands of apps that are less successful, we systematically overestimate our own chances of launching a successful app or digital service ourselves. The amount of failed projects and non-successful apps is unbelievably large, but this "loser list" gets absolutely no attention when the thought of a self-developed, very successful app makes us euphoric. 

Example from the Gaming Industrie: The Rovio Story

Rovio, the world-famous game studio from Finland, may seem like an overnight success to many, but it was anything but. In 2009, Rovio was a small game studio in Finland on the verge of bankruptcy. It had laid off most of its employees and had only 12 employees left. The company was founded in 2003 by students who had won a video game competition and thought it would be fun to start their own studio. They discovered that they were able to develop some cool games, but distribution was difficult. Before Angry Birds, they had developed 51 games, which did not bring the desired success. The fact that today hardly anyone pays attention to the 51 failures, but only looks at the extremely successful example of Angry Birds as inspiration and starting point for their own game projects, is a clear example of survivorship bias. More about the history of Rovio can be found here.

Ways to avoid this thinking error:

• Pay attention not only to successful projects or products, but also analyze failed projects.

• Calculate the probabilities of success as objectively as possible and explicitly formulate your own assumptions that should lead to this success and regularly check them on the way to success.

• It is important to learn from the once promising brands and products that then failed. Especially in the tech industry there are countless of them like Nokia, Blackberry, Microsoft's Windows Phone, MySpace, Xing, 3D TVs and many more.

• Since we notoriously overestimate our own chances of success, it would probably be helpful to assume the worst-case scenario in each case. This would then be more in line with reality.

6. The Swimmer's Body Illusion

We often have trouble interpreting the reason for the success of something and in many cases even confuse the prerequisite for something with the result. For example, we see successful and physically very appealing swimmers, which makes us believe that with enough swimming training we will also look like that. All too often, we forget that this physique may have already been the prerequisite for the swimmer to become so successful: Voilà, the Swimmer's Body Illusion.

In terms of the app market, digital transformation and new technologies, it is important to be very critical whenever someone claims that he or she has found the one recipe for success. There are so many books that describe the means by which an app or digital offering was made successful. À la "seven steps to success" or "the Google principle". The fact that there were already many companies before and definitely also after this success that applied exactly these principles 1:1 themselves and still did not become as successful often goes unnoticed. The fact that one project was able to create a successful product using a very waterfall-like project method and that others created equally successful apps using agile methods is often forgotten. Often there are many other factors that have led a brand or a product to success than those that seem obvious and understandable to everyone. Often it is pure coincidence, an unforeseeable event, external circumstances or pure luck / bad luck that leads someone to success or failure. So beware of advice that promises success with simple recipes. Success is in many cases also simply very hard work.

Summary of Part 1 of our Cognitive Errors Mini Series

• Many thinking errors that we experience in everyday life also occur in the software industry.

• No matter who says or writes what: You should carefully examine statements and future predictions, think for yourself, and also look for contrary opinions.

• Don't be blinded by the success of the best apps and digital products, but go to the graveyard of failures, look behind the scenes and find out why many other projects have not been successful. 

• Assess your own chances of success realistically or even rather pessimistically and base them on real facts and figures through clearly measurable goals and measurements. 

• Diversity in teams and an open error culture as well as 360° feedback loops increase the chance that important decisions and strategies contain fewer thinking errors. 
  
  

Do you have any good examples of yourself or someone else making a thinking error in software development? We are looking forward to any input, criticism or further information on this topic. And then you can look forward to part 2!