image source: perfectdigital.com

You know this picture, right?

I think it shows very well that big discrepancies and a lack of vision may appear in software development projects between all participants and people involved. Problems often arise from the very beginning, when the client comes with a (theoretically) final product vision and presents it to the team. Then come further misunderstandings, misinterpretations and, eventually, the project quickly goes down the wrong path of development.

While analyzing the graph above, I will present in a step-by-step manner all possible threats and suggest how to fight them. Let’s get right to it!

1. How did the customer explain the idea?

There will be discrepancies in the product vision from the very beginning. Why? The reason is very simple - everyone interprets reality in their own way, has an idea of something in the mind and may not accurately present this vision to the other party. If you describe in words a product that you would like to build, there is a high probability that the development team will understand your vision in a different way than you intended.

Of course, it is possible to avoid this. You should start visualizing as soon as possible and discuss individual elements of product functionalities based on sketches. Interestingly, the first sketches usually have nothing in common with the final product. At this stage, however, the most important thing is to make the vision coherent.

2. How did the project leader understand it?

Wondering why the first and second picture is so different? The project leader will always take a closer look at the product vision. However, it is important that such a person, essentially responsible for the entire software development process, fully understands the problem and the needs related to the product. The project leader must have a clear "bigger picture." As you can see, both images do not differ in terms of functionality. They just look different. To better understand this point, let’s return to the picture number one. At the beginning of the project, there were no sketches and that already led to a misunderstanding. The functionality of the product is correct, but the design is completely different.

3. How did the analyst design it? and 4. How did the programmer write it?

Sometimes, analysts and developers do not know the needs of users or established business goals. They see only the small piece of the entire project, which captures their main focus. They are not able to look from a broader perspective, and this is particularly the case for large projects, where a lot of developers work at the same time.

We can also use another example. It may happen that the problem to be solved is incorrectly described, for example, by the product owner. This involves providing incomplete information upon which the developer or designer create their own interpretations, and the product deviates from the intended development path more and more.

How to change that? I think that a good solution is to make sure that the people who are key to the project have detailed knowledge about it – the so-called "bigger picture." In case of misunderstandings, it will be easier for them to bring the software development process back on the right track. Therefore, remember - if everyone sees only their tiny fragment of the developed functionality, the misunderstandings in the vision become a likely threat.

5. How did the business consultant describe it?

Here, the matter is simple. The product must sell. You have to stand out somehow, so, for instance, a simple swing for your garden attains extraordinary elements. The idea is to convince a potential buyer. The marketing and sales department will certainly do everything to show that the product is unique.

6. How was the project documented?

Missing documentation is a very common problem. Sometimes, creating documentation during product development seems like an unnecessary waste of time. This is a mistake. I say very often that changes are made faster on paper than in the code, and there is something to it. In addition, it is easier to refer to the documentation to track any changes. Believe me, a project without documentation is at a very high risk of missing the vision.

7. Which operations were installed?

This stage refers to placing the environment on the server. As in the point about programmers and analysts, without full data and with communication gaps, it may turn out that only a part of the necessary environment has been created.

8. How was the customer billed?

It's the result of poor communication, lack of UX and so on. The appearance of errors increases the development time. And time is money, right? My hint is to run the project in accordance with Agile, maintain the highest communication standards and keep clear budget guidelines. I have no doubt that by doing so you will avoid such problems.

9. How was it supported?

Customers frequently focus only on building a product and finish at that. However, we live a time of many changes and technological innovations, which is why it is necessary to maintain constant tech support. The idea is to avoid a situation in which something suddenly stops working as it becomes outdated and the product loses its value. This aspect should not be forgotten either.

10. What did the customer really need?

We have reached the last point. Look at the discrepancy between the first and last graphs. After all, both relate to the client's perspective. Why is this happening? Everybody lies it as simple as that :) Survey results always differ from your respondents’ actual needs. While answering the researcher's question, users want to show their best side. Therefore, THEY OFTEN DO NOT RESPOND TRUTHFULLY, but rather in a way they think they should answer. Basically, they do not want to be exposed to the negative assessment of others. Here is a small hint for you – mention in the instructions that there are neither good nor bad answers.

Where else do the differences appear? People often don't know what they really want. Quite often, users initially say need 10 functionalities in the product, and later they actually use only, say, 3.

So how do you solve this problem? In addition to asking the users what they want and need, allow them to test to the product, preferably on authentic items to maintain credibility. The more tests during the creation of products, the greater the chance that the result will be accurate.

Summary

If you ever become a member of a software development project, remember my examples and draw conclusions so as not to copy the above errors. And remember, these concepts are very important in building a product (application) from scratch:

- good UX and tests, so you can learn what your users really need,

- communication within the project, so a deep understanding of the problem and needs is available for key people in the project,

- develop the product in accordance with Agile,

- don't forget about tech support.

Read more:

- How to effectively manage remote developers? The guide for CTOs

- Python vs. Ruby? Which technology should you use for product development?

- A quick guide to building and developing your own marketplace. What is worth to know?