DEV Community

Cover image for 7 biases of dev-tool product teams
Asmit Malakannawar
Asmit Malakannawar

Posted on • Updated on

7 biases of dev-tool product teams

In software development, cognitive bias has a negative impact on quality. Virtually every team member, including developers, testers, and product owners, has biases that influence how they design and test software. As they construct, train, and test products, software developers even transfer their prejudices to AI systems. Users experience poor application information or performance as a result of cognitive bias in software development.

Here are 7 biases that dev-tool product team has to face:

1. The Fallacy of Execution Orientation

Product teams base their judgements on what they know they can readily accomplish at that time. This in turn creates poor product strategies and make suboptimal product decisions. This mistake is usually caused by lack of foresight and lack of agency. The software development is not properly planned according to the product goals.

2. The Building Bias Fallacy

The product teams feel forced to be in continual motion, therefore they don't invest time to completely grasp the problem, domain, competitors and other factors of product success. They convince themselves that they must start constructing and then make changes while developing, based on the input they receive.

3. For items, the IKEA Effect

The developers base their current product decisions on past product execution, because they are too committed to the effort they have already put in and don't want it to go in waste or "all this for nothing". This is usually the case where the existing product is failing.

4. For goods, the Focusing Illusion

The product teams overestimate severity of the problem their product solves when they speak to consumers about it. They get startled when consumers don't use their product. It is like finding a solution for a problem that doesn't exist.

5. Maslow's Hammer

Sometimes, in development, the developers use tools, framework, or a proxy that they are comfortable with (or what their organization approves). This might lead to lengthier and complex codebases, difficult to solve easier problems.
For example, Facebook employs analytics as a hammer for its products, and a number of its previous and current problems may be linked back to this hammer's indiscriminate application.

6. Bias in Authority Approval

Dev teams create product strategies, design product features, and propose product plans based on what they believe would either reinforce the opinions of individuals in positions of power at the organization or make it easier for them to proceed.

7. Products' Russian Roulette

Developers don't plan adequately for scenarios that, under certain circumstances, may result in a disastrous consequence for our product or a public relations nightmare for their organization. This is typically prevalent in workspace where "obeying commands" or "getting things done" are praised.

What can be done to combat these biases and fallacies?

Product teams working on developer tools often develop biases which are very specific to their niche.

To begin, acknowledge that these biases exist and that we are all susceptible to them. If we notice ourselves succumbing to one of them, it doesn't mean we're foolish; rather, this recognition is the first step toward greater communal wisdom.

Bring these prejudices to the attention of your team by naming them. Add these terms to your team's shared lexicon to foster mutual understanding and accountability while also assuring everyone's psychological safety.

Got these valuable information from the event conducted by Prabhat Sahu, founder OF SAWO Labs in collaboration with Tom Hacohen, founder and CEO of Svix.

Discussion (0)