How to avoid file development during product development: 10 tips from Rookee

    Product development is a time consuming process. The market constantly needs new solutions, but failures lie in wait for any company on the way of creating innovations. In this article, we have put together our own experience in a high-tech service to try to figure out what problems may arise when developing a new product and how to avoid them.

    1. Forget about the process, work on the result

    Often, companies in the development of a product all the attention and resources are directed to the process of creation and production. Even if each stage of work was performed “strictly according to technology”, the result may not be as rosy as it seemed at the beginning.

    Example from practice

    Three months ago in the Rookee teamA complex system analytics process was introduced. The analyst had to request and collect marketing research, prepare solution options, request financial calculations, design algorithms, set tasks for the UX, determine business requirements, conduct protection of their decisions, track the result after display, transfer to operation, etc. The load on one analyst could reach 15 tasks per day. A specialist cannot physically pass such a number of diverse tasks through himself per day. It is not surprising that with such a volume the work of the analyst was a narrow neck in solving common problems. To improve efficiency, many things have been going around. As a result, the company abandoned such a complex process and radically simplified it, distributing responsibilities among different specialists. Efficiency improved

    How to avoid

    If the product development process is too complex, and the result does not meet expectations, it is necessary to review current processes and become more flexible to changes at each stage of work.

    2. Keep high command sync

    The ability to work in a team is an important skill that not everyone possesses. In practice, situations often arise when the implementation of one task requires the involvement of several specialists at once.

    For example, the task of introducing a promotional code into the system implies the work of both the front-end developer and the backend. If these people can not agree among themselves, the emergence of a variety of problems. For example, from the point of view of the visual, the task will be done, but without an algorithm for developing the mechanics of a promotional code, this task will not give any value.

    Practical example

    When several different products appeared in our service, each product’s development team remained its own. One user, one account, and the products and teams are different. Somehow a client called us and said that we had spammed him. It turned out that all the teams sent him letters when situations arose that required attention (for example, the balance approached zero and the service could be suspended). As a result, the user received about 40 emails from the service per week. An analysis of email newsletters was conducted. Some letters combined. Now in development is an email-strategy, which will finally fix all the flaws.

    How to avoid

    To achieve task synchronization, coordinate the actions of the team / teams working on the same product. For example, conduct a general “demo” of design and development, notify other teams about new features. Share a release history document that clearly describes what, when and by which team was done by adding a link to the task in the task tracker.

    3. Avoid product modifications as requested by the user.

    New products in the process of exploitation reveal problems. It is not a secret that some improvements on the projects were initiated by users who contacted the support service. Nobody argues: products need to be improved, but before rushing to “patch holes” you should look for the root cause of the problems.

    How to avoid

    Collect user requests for a sufficient length of time. Depending on the number of calls to the support service, this segment may be a week or a month or more. Analyze the issues, identify recurring and solve the problems that users complain about most often. If the problem is of a blocking nature, that is, it affects the correctness of the user's work in the system, solve it immediately.

    4. Invite developers to discuss the project and design tasks

    Often, having received the business requirements of customers, the designer proceeds to the description of the logic of the tasks. If this does not take into account the technical features of the system, you may receive a solution that will result in 3 months of development.

    An example from practice

    Once a situation occurred in Rookee . We rendered the interface in which the project creation wizard was in one of the products: in the first step, the user is authorized in another service to get information from it (in Yandex.Direct), in the second step, a list of parameters is selected for operation. Parameters were obtained by performing a query on the token specified in the first step.
    The interface was shown to customers, agreed, sent to developers. When the developers saw this, they said: “There will have to show the movie, because if the user has a lot of data, then he can wait a very long time. Moreover, this interface solution is not user-friendly. ”
    As a result, we had to redo everything, taking into account feedback from programmers.

    How to avoid

    Invite developers to participate in the discussion of projects, drafting requirements, involve them in design. By including developers into the work at the early stages, it is possible to significantly reduce the time to create a project, to avoid unnecessary costs for alteration and to do without extra gray hair due to the breakdown of time.

    5. Simplify. Brilliant, this is when effective.

    From time to time commercial experts attend brilliant ideas when creating new products or refining old ones. Unfortunately, not all ingenious demand and realizable.

    An example from practice

    To increase sales often use copyright email-strategies. There are many ways to implement them: setting up sending events, a third-party email-sending service that sends letters on a signal from your service, implementing a single trigger logic on the side of your service and using a standard or universal template for sending, etc.
    Sometimes companies decide to go their own way and do not like everything. Writing the first letter for users in the team thought it would be the last. And then they sent another last letter. And more ... When there were a lot of letters, the team implemented its template creation service. It was done for 2 months and was not as good as the existing specialized services. As a result, the company came to an optimal solution - integrated third-party mailing service.

    How to avoid

    If the implementation of innovations seems too complicated, discard it.
    Do not waste time on creating services that will obviously lose to existing ones. Answer yourself the question, do you really need a tool that is difficult to maintain, but yours?

    6. Avoid ambiguous interpretation of requirements.

    Ambiguous task creates misunderstandings that can lead to undesirable results. For example, an analyst might ask: "Add five elephants next to the registration field." For different members of a team, there may be different variants of this “side by side”: right, left, top and bottom.

    How to avoid

    If the requirement is not completely clear, it is necessary to ask clarifying questions. Team members should learn to detail each task as much as possible in order to avoid confusion and thought-out. The level of detail requirements is negotiated within the team. You can also develop a TK template that will suit everyone, and prescribe the goal of the task, logic and user interface in as much detail as possible.

    7. Remember your target audience.

    Oddly enough, there are people who believe: it is better to attract as many users as possible, and among them will definitely be the target audience of the product. This is not true. You may have a specific product whose consumers are a certain segment of users.

    Practical example

    The target audience of the product is housewives, but the project wanted to get a lot of traffic. Having spent a significant amount on advertising, the company began to publish ambiguous banners on large business portals in the hope of bringing in paying customers. The traffic has greatly increased, but the sales have not. When we conducted a survey on why users visit the site and do not buy anything, it turned out that most of them are simply not Central Asia. The proposed product simply did not interest them. Changes were made to the advertising campaign, and the problem was resolved over time.

    How to avoid

    Initially, it is better to focus your efforts on attracting targeted traffic and make adjustments in advertising campaigns and positioning, if site visitors are not exactly your potential customers.

    8. Do not allow the intersection of split tests when testing hypotheses.

    Such a problem may occur when hypothesis planning is incorrect or analysts have low qualifications.

    Example from practice

    The company began testing two versions of the registration form on the landing page (50% of users see one version, 50% see the other). Then it became necessary to test another hypothesis on the payment zone, and another test was launched. This complicated the work of analysts, as it took a long time to divide the cohorts in such a way as to assess the impact of the changes on the final actions of the user. It took much longer to collect data than it would take if tests were performed one after another.

    How to avoid

    When conducting A / B tests, do not allow splits to cross. Try to separate users so that one person participates in only one experiment. If suddenly two tests were launched at once, evaluate 4 groups:

    • the first landing variant + the first option in the payment area;
    • the first landing variant + the second option in the payment area;
    • the second version of the landing + the first option on the payment area;
    • second landing option + second option in the payment area.

    9. Do not confuse your opinion with the opinion of the user.

    One of the common mistakes is accepting your opinion for the user's opinion. If you like the product, its design and usability, you understand how to interact with it, not the fact that the user will share your enthusiasm.

    How to avoid

    When developing each separate interface zone, consider the visual of the entire service as a whole. Do not think for the user. Ask him (for example, using the focus group method) how he is more comfortable, more familiar, better what he expects from a new product. Before launching, Yandex conducts face-to-face testing: meets with users, looks at their reaction, asks uncomfortable questions about their hypothesis.
    If you know in advance the user's opinion about the development, you can avoid many problems in the future.

    10. Log events to the maximum

    In the event of a dispute in the operation of a system module, the quickest and easiest way is to access the event logs. Unless, of course, they are. If you are lazy and do not log events, you will have to work hard to find the source of the problem when it occurs.

    How to avoid

    Log events to the maximum. This does not mean that you should start logging every small detail, such as a custom mouse movement, but the basic information that happens to the object should be recorded.


    Any company may encounter problems when developing new products. The main thing is to admit mistakes, draw conclusions and take measures so that they do not recur in the future.
    Did you fail in your development practice and how did you fight them? Tell us about your experiences in the comments.

    By Ekaterina Hindikainen, Lead System Analyst, Rookee Service

    Also popular now: