Often the development of an Internet project is to create a good solution that fully satisfies the customer and makes it easier for him to part with the money. A technical task is being prepared, the customer makes his wishes and corrections, a beautiful design is made, etc.
And then often turns out to be not very satisfied. Because end users (users) are not very happy with this decision, and at times they refuse to use it at all.
But the main goal is to create an effective (convenient, stable, better than the competitors in certain parameters, etc.) to solve the problem of end customers (users). This is especially important for non-standard, integrated Internet solutions.
You can improve the situation if you begin to use the word “hypothesis” more often, i.e. a set of assumptions that you first need to qualitatively form, then effectively check. And then be ready, on the basis of the results of the test, to correct the old one in the necessary way or to formulate a new hypothesis. And repeat the check again
And most importantly, this magic word “hypothesis” allows the developer to stop pretending (although at times the developer even begins to believe it), that he definitely knows how to make a good, right decision the first time.
First, let's start with the problem. Yes, you first need to correctly formulate the essence of the problem to be solved. Do not rush to answer, often the real problem of end customers that you have to solve is something a little different than it seems at first glance.
Here you need to take a broader look at existing solutions, study direct and indirect competitors, communicate live with the clients themselves. And only then to formulate the problem. And be ready to change the wording of the problem in the process.
Secondly, it is necessary to form a hypothesis. There are many approaches here, but I want to highlight the discussion of user stories. This is when several team members are next to each other discussing how end customers (users) will interact with a future decision.
The discussion process (and here I am very helpful in various ways of visualizing the details discussed in the form of boards, stickers and other elements) is very important. And it’s not good when it turns out to be replaced immediately by drafting requirements from one person (the customer or his manager) to the performers (employees who will implement the project). And here, too, you need to be ready to change the hypothesis, if during the verification process it turns out to be not completely (or not at all) correct.
Thirdly, as we have already understood, the hypothesis put forward (that is why it is a hypothesis) needs to be checked. And it is important to do this as quickly as possible with the lowest possible cost of resources.
This item is sometimes the most difficult. Because instead of “testing the hypothesis” it begins to be implied to “confirm the hypothesis”. After all, the resources have already been spent, people have already worked, the customer has confirmed that everything is going fine. And in general, why redo it if everything looks good enough? But we know that if the solution found is not effective, it will not make the customer satisfied in the future.
In general, it was for this purpose that several techniques were invented, such as Lean Startup (a thrifty startup), which allow testing hypotheses on real end-users (users) with the lowest possible costs. And to be morally ready not only to confirm, but also to refute the hypotheses with minimal losses.
Fourthly, after testing and testing, some corrections need to be made in our hypothesis. At times it will be quite small. Perhaps the hypothesis will have to radically change.
And as I already wrote, they are not afraid to review and challenge the formulated problem. After all, after the verification process, you know much more about the problem itself than at the very beginning.
And how to prepare, customize the customer to understand and accept this approach with hypotheses and the right to mistakes is a topic for another text.