Two fallacies of software product design

In recent years, I become more and more involved in software product conceptualizaiton and design. From these experiences, I found there’re some general principles that may be useful in the design of other software products. But these principles are rarely discussed in litterature or are conflicting with some wide-spread opinions, so I want to summarize and explain them in this article.

Customers are not buying softwares to follow a trend, nor because they’re interested in cloud computing or html5 technologies. They buy software to do a job in work or in daily life. The purchased software help them fix some recurring headaches or tasks. That’s the value of software.

To locate these recurring headaches or tasks is not an easy job, it requires the ability to do abstract thinking. This is also the first and most important step in inventing new products and features. Some irrelevant problems and tasks when perceived from a higher level of abstraction may be handled neatly by some simple modelling. Imagine that if there’re no postal codes and postal system, how it would cause various problems in different sectors and daily life? But the postal system solves these problems elegantly. There’re a lot of such good inventions everywhere in the world, such as computers, internet, world wide web, telephone system, money, languages, etc.

The lesson above is natural and obvious, but it’s often overlooked in real world. I find that usually there’re two common causes of aberrancy : (1) fallacy of business; (2) fallacy of ideology.

Fallacy of Business

Customers often participate in the process of building a product. Sometimes, they may ask for very specific features instead of what tasks they want to be done with the product. As the business tenet goes the customer is God, some people(usually the boss) in the software company try to satisfy everything customers asked for.

I call the case above as fallacy of business. The problem is clear, the customer is not an expert, you’re the expert, how can an outsider guide an expert? They may ask for something they don’t really need or not best fit them or in wrong priority order. I’m not objecting that the customer is God, but objecting a superficial interpretation of it. We are not treating customers as God, if we’re not doing the best to them. Usually we are cursing them stupid secretly in mind in such cases.

To avoid the fallacy of business, we should not take the face value of customer’s demand for specific features. We should investigate what prompts them to ask for the feature, what problems they have in work or daily life. Once we get insights to these questions, we can assign an appropriate value to the problem and arrange it in the priority list.

Even the problem is in the priority list, it doesn’t mean it will be satisfied. It will depends on two factors:

The first factor is simple to understand. If customers think it costs too much for a solution, the requirement will not be satisfied. Remember the efforts to fix a problem not only include one-time development efforts, but also development and maintenance efforts of every existing and future features because of the additional complexities incurred.

In practice, I tend to say NO to inessential features that will complicate conceptual model or business logic, unless a good modelling can be achieved or it doesn’t have much impact on conceptual model or business logic, in the name of maintainability.

The second factor says that when a new feature fixes a problem, it may also introduce new problems. For example, a new feature may make a product more complex to use. Another example is that a feature may be useful for 10% of the users, but it’s an overhead for 90% of other users. If the loss outweigh gains, it makes sense to cancel the feature.

Fallacy of Ideology

A lot of product designers have some background in programming(sometimes programmers take the role of product design themselves), where they have been immersed in ideologies of object-oriented programming, domain-driven development, etc. These methodologies have some metrits in software development, but are generally harmful in product design with two wide-spread misconceptions:

I’ve been working on a project where customers need a system to manage contracts online. Each contract has several operation teams working in oil fields. The remote operation teams report various job logs, activities, notes, incidents, tickets to the headquarter everyday. Currently all these are done based on paper, they want a digital solution.

One way to approach the problem would be to first analyse what’s there in the world and their relationships. After some conversations with customers and observation of how they work it’s not difficult to get following list:

Following the approach, the list above will be converted directly to product concepts, software design models, and finally classes and database tables. I call this typical approach fallacy of ideology.

What’s wrong with the approach above? First, it doesn’t analyse customer’s problems or values. For example, how can we know customers really need to manage site status using the system? If we put a high price on a problem and ask if they want a solution, or ask them what headaches it will cause if the problem is unsolved, we’ll get more insights into customers’ values and priorities.

Second, it doesn’t do any abstraction or creative design at all. For example, it’s possible to invent a concept issue as an abstraction of activities, notes, incidents, tickets, etc. The abstraction not only makes the product simpler to use, but also more flexible. For example, it’s possible to use issues for announcements or meeting memos.

From the example above, it’s clear that software product concepts don’t necessarily correspond to real world things. A good example to illustrate this point is video games. In the famous video game Warcraft, the concepts like ‘Night Elves’, ‘Humans’ and ‘Undead’ are referring to things of the product, not things in the world. Software products are more like poker cards or postal systems than mirrors of the world.

Good software products are usually inventions of good concepts, with which users can easily solve their problems. Sometimes, users have to learn these new concepts and do things in a new way. This is very common in the field of ERP(enterprise resource planning) systems. With the introduction of an ERP system, a company may need to change its existing processes or even organizational structures. They can’t just stick to their old processes, as a new product is a new game with different concepts and rules. That’s a non-negligible hindrance of the acceptance of new products, as the users are accustomed to old games. But good new products will prevail eventually.

Naming is essential in inventing good concepts. In a project management system, we have a concept project. It turns out ‘project’ is a bad name, as it forms an obstacle to better understanding and more flexible usage of the product. The cause is that the name ‘project’ makes users and even product designers think that it represents real-world projects. It’s true that it can be used for real-world projects, but it’s more useful than that. For example, it can be used inside an office to manage daily issues. So a better name would be ‘workspace’, which will reduce misunderstanding and encourage more flexible usage of the product. Note that in this case the concept workspace doesn’t correspond to anything beyond the product, it refers to things recognized by users through GUI(graphical user interface) of the product.


The fallacy of business and fallacy of ideology are among the most common mistakes in software product design. Like logical fallacies, it’s part of human nature to err on these matters. Nevertheless, human mind is the finest machinery of God, it’s possible to overcome these fallacies through careful thinking and rigorous analysis.