How we work with ideas and how LANBIX was born

    LANIT Integration has a lot of creative employees. Ideas for new products and projects literally hang in the air. Revealing the most interesting is sometimes very difficult. Therefore, we have jointly developed our own methodology. How to select the best projects and implement them, read in this article.

    In Russia, and indeed in the world as a whole, a number of processes are taking place that lead to the transformation of the IT market. Due to the increase in computing power and the advent of server, network and other virtualization technologies, the market has ceased to need a lot of hardware. Vendors increasingly prefer to work with customers directly. On the IT market, the flourishing of outsourcing in all its manifestations, from classic outsourcing to outsourcers of a new wave - “cloud providers”. Infrastructure systems and elements become much easier to maintain and configure. The quality of software is growing every year and the tasks of the integrator are being transformed.

    How we work with ideas

    The product start-up area in LANIT-Integration has existed for more than a year. Our main goal is to create new products and bring them to the market. The first thing we started with was organizing the product creation process itself. We studied a lot of methodologies, starting with classical and ending with hype ones. However, none of them matched our requests. Then we decided to take the Lean Startup methodology as a basis and adapt it to our tasks. Lean Startup is a theory of entrepreneurship created by Eric Rees. It is based on the principles, approaches and practices of such concepts as lean manufacturing, customer development and a flexible development methodology.

    As for the approach to product development management directly: we did not invent a bicycle, but applied the existing SCRUM development methodology, adding creativity, and now it can be safely called SCRUM-WATERFALL-BAN. SCRUM, despite its flexibility, is a very rigid system and is suitable for managing a team responsible for only one product / project. As you understand, the classic “integrator” business does not involve the allocation of technical specialists for full time to work on one project (there are exceptions, but very rarely), since in addition to working on products, everyone is engaged in ongoing projects. From SCRUM we took the division of work into sprints, daily reporting, retrospectives and roles. For working with the task flow, we chose Kanban, and it integrates perfectly into our existing task tracking system. We built the work, seamlessly integrating into the existing order of things.

    Before entering the market, the product goes through 5 stages: idea, selection, concept, MJP (more - below) and production.


    At this stage, there is something ephemeral - an idea. Ideally, the idea is to solve an existing problem or task of the client. We have no shortage of ideas. According to the initial idea, they should be generated by employees of technical areas. In order for the idea to be accepted for further development, the author must fill out the “Idea Design Template”. There are only four questions: What? For what? Who needs this? And if not our product, then what?

    A source


    As soon as the designed template gets to us, the processing and selection procedure starts. The selection stage is the most time-consuming. At this stage, the formation of hypotheses of problems occurs (it was not for nothing that I mentioned in the previous paragraph that, ideally, an idea should solve a client’s problem) and product values. The scale hypothesis is formed, i.e. how our business is going to grow and prosper. Problematic and expert interviews are conducted with potential customers to preliminarily confirm that we are going to produce something we need. It takes at least 10-15 interviews to conclude that the product is needed.

    If the hypotheses are confirmed, a preliminary financial analysis is carried out, the approximate volume of investments and the possible earnings of the investor are estimated. As a result of this stage, a document called Lean Canvas is born and presented to the leadership.


    At this stage, about 70% of ideas are screened out. If the concept is approved, then the stage of developing the idea begins. The functional capabilities of the future product are formed, the implementation paths and optimal technical solutions are determined, the business plan is updated. The result of this stage is the terms of reference for development and a detailed business case. If successful, go to the stage of MJP or MVP.

    MJP or MVP

    MJP is a minimally viable product. Those. a product that is not fully developed, but can already bring value and performs its functionality. Be sure at this stage of development we collect feedback from real users and make changes.


    And the last stage is production. Up to this stage gets no more than 5% of the products. These 5% include only the most important, necessary, viable and functional products.

    We have a lot of ideas, a voluminous portfolio has already been collected. We analyze each idea and do everything so that it reaches the final stage. It is very pleasant that our colleagues did not remain indifferent to our R&D direction and take an active part in the development, implementation of products and solutions.

    How did we do LANBIX

    Consider creating a product using a real-life example - the LANBIX product. This is a “boxed” hardware and software system designed to monitor small IT infrastructures and promptly alert decision makers and business users about malfunctions controlled via a chat bot. In addition to the monitoring function, LANBIX includes the Help Desk functionality. This product is exclusive to the market segment we are targeting. This is both our advantage and our pain. But first things first. I must say right away that LANBIX is a living product (that is, it is not final in its development and is at the next round of MVP).

    So, the first stage is an idea. For an idea to be born, we need problems, and we had them, or rather, not with us, but with our friends. Below we consider several real situations that have occurred in different areas of the business.

    A small management company serves two houses in the suburbs. The staff with PC, about 15 people. The system administrator is an incoming freelancer (the smartest son of one of the concerned residents). It would seem that the activities of the management company are weakly dependent on IT, but the peculiarity of this business is the monthly reporting to many instances. On the system disk of the head of the company (as usual, combining many roles), free space has run out. Naturally, this did not happen suddenly, the warning hung for about 2 months and was constantly ignored. But the update arrived, the OS was updated and, as luck would have it, hung in the middle of the update, complaining before the "death" to the busy disk. Comp went into a cyclic reboot. While we sorted out the problem and got reports, we missed the deadline for reporting. It would seem that,

    Source A   

    similar incident occurred in a large holding uniting many small companies with a single technical support service for the entire office. In one of the departments, the computer of the chief accountant broke down. That it could break, it was known for a long time (the computer was desperately slowing down and warming up), but the hands of the chief accountant did not reach the point to send a request for technical support. Naturally, he broke down exactly on the day of the salary, and the department employees sat without money for several days.

    A small wholesale business has a selling website that is hosted on an external site. We learned about its inaccessibility by phone from a regular customer. At the time of the call, the site lay for about three hours. It took another couple hours to find the person responsible for the site, and two more to fix the malfunction. Accordingly, almost the entire working day the site was unavailable. According to the company's commercial director, this downtime cost them about 1 million rubles.

    I myself faced a similar situation when I came to the clinic and had to go to the VHI registry. They could not send me to the doctor for a banal reason - in the morning there was a power surge, and after the accident their postal service and some service in connection with the insurance did not work. To my question, where are your admins, I was told that the admin comes with them and visits them once a week. And now (at that time it was already 4:00 p.m.) he was not picking up the phone. At least 7 hours, the clinic was cut off from the outside world and could not provide paid services.

    What unites all these cases? Absolutely all problems could be prevented in advance. With a timely response from people serving IT, it was possible to reduce the damage caused. This would be possible with the correct interpretation of early symptoms by users.

    We identified hypotheses of problems:

    • Significant cash and reputation losses due to the low speed of response to malfunctions in the IT infrastructure;
    • misinterpretation of early symptoms of malfunction by users.

    What can the customer do with them, and how to avoid similar situations in the future? There are not many options:

    1. take a highly qualified system administrator to the staff and make him work in good faith;
    2. give IT service to a specialized service company;
    3. independently introduce a monitoring and warning system;
    4. provide training for users / business personnel on the basics of computer literacy.

    We dwell on the third option. Let's offer a monitoring system to those who do not use it for various reasons.

    Lyrical digression. Various systems for monitoring IT services in the enterprise market have been used for a long time, and their benefits are not disputed. I talked with representatives of large companies, watched how the relationship between business and IT was built. The technical director of a large machine-building enterprise has given service to the IT infrastructure of an external company, but he himself remains in the know. He has in his office a large screen monitoring system with indicators of the status of IT services. The most critical are entered into the system. At any time, the technical director can find out in what condition the infrastructure is, what is happening, in which area the problem is, whether responsible people are notified, and whether the problem is being solved.

    These stories made our team think about how to make an optimal monitoring system for small companies. As a result, LANBIX was born - a monitoring system that can be deployed by absolutely anyone without knowledge of IT. The main task of the system is simple, as with all systems aimed at increasing continuity and availability - reducing cash and other losses in case of unplanned downtime. The device is designed to minimize the time between "something is broken for me" and "the problem is fixed."

    Problem interviews were conducted to confirm the hypotheses. I could not imagine how many people are willing to tell, if not try to sell them. Each conversation lasted at least 1.5 hours, and we received a lot of information useful for further development.

    Summarize the result of this step:

    1. understanding of the problem - is,
    2. understanding of value - is,
    3. there is an idea for a solution.

    The second stage was more detailed. Based on its results, we should have presented to the leadership, which essentially plays the role of investor, a business case (the same Lean Canvas) to decide on the future of the product.

    We started with market research and competitive analysis in order to find out who, what and, most importantly, how it does in this market.

    It turned out the following.

    1. There are no ready-made box-based monitoring systems for our segment (small business) on the market, with the exception of a couple or three, which I will not speak about for obvious reasons.
    2. Oddly enough, our main competitors are system administrators with self-written scripts and “dopilki” to open-source monitoring systems.
    3. There is a clear problem with the use of open source monitoring systems. There is a system, there is a huge amount of information on the operation and completion of the system to your needs. Of the administrators I interviewed, many admitted that they lacked the competencies to implement their ideas on their own. And they can’t admit to the leadership because of the fear of dismissal. It turns out a vicious circle.

    Then we went on to analyze the needs of our potential customers. We have selected for ourselves a segment of small organizations that for some reason do not have their own IT services, where either the incoming system administrator, the freelancer, or the service company are responsible for IT. They decided not to go in from the IT side, but from the business side, offering the founders and business owners a tool to improve the quality of IT infrastructure services. A product that should help owners secure their business, however, at the same time, it will add work to people who are responsible for IT. A product that provides business with a tool for monitoring the quality of IT support.

    As a result of processing the received data, the first list of requirements (a kind of rough backlog) for the future product was born:

    • the monitoring system should be based on an open source solution and, as a result, cheap;
    • simple and quick to install;
    • should not require specific knowledge in IT, even an accountant (in no way wanted to offend the representatives of this profession) should be able to deploy and configure the system;
    • should automatically detect objects for monitoring on the network;
    • It should automatically (and ideally automatically) install monitoring agents;
    • must be able to monitor external services, at least a CRM system and a selling site;
    • Must report problems to both the business and the system administrator;
    • the depth and “language” of alerts should be different for the admin and business;
    • the system must be supplied on its own hardware;
    • iron should be as affordable as possible;
    • the system should be as independent as possible from external factors.

    Next, investments in product development were calculated (including the labor costs of employees of the technical department). A sketch of a business model was prepared and the unit economy of the product was calculated.

    Stage Result:

    • High level product backlog
    • formulated business model or scale hypothesis, which remains to be tested in practice.

    Let's move on to the next stage - the concept. Here we, as engineers, fall into our own element. There are Wishlists that are decomposed into components / subsystems / features, then they turn into TK / user stories, then into a project, etc. I will not dwell on the process of preparing an array of alternative options, we will go straight to the requirements and the chosen methods for their implementation.

    • It should be an open monitoring system;
    Take an open source monitoring system.
    • The system should be simple and quick to install;
    • should not require specific knowledge of IT. Even an accountant should be able to deploy and configure the system.
    We offer an installed system so that the user only needs to turn on the device and configure it a bit, by analogy with a router.

    We close the interaction with the device to something simple and understandable to everyone.

    We will write our chat bot for one of the well-known messengers and start all the interaction with the system on it.
    The system should:

    • automatically detect the objects required for monitoring in the network;
    • Automatically install monitoring agents
    • Have the ability to monitor external services, at least a CRM system and a selling site.
    We are writing additions to the monitoring system by:

    • automatic detection of objects;
    • automatic installation of agents;
    • monitoring the availability of external services.
    The system should:

    • Report problems to both the business and the system administrator;
    • be able to monitor external services, at least a CRM system and a selling site. The degree of depth and the "language" of alerts should be different for the admin and business.
    • The system should not require specific knowledge in IT, even an accountant should be able to deploy and configure the system.
    • Add different types of notifications for different types of users. They differ in pitch and depth. A business user will receive notifications like “everything is fine, but Ivanov’s computer will die soon”. The administrator will receive a full error message about who, how and what happened or can happen.
    • We add the ability to use the mail of an additional responsible person, so that in case of a breakdown he will receive a message.
    • Add interaction with external service providers based on sending email with pre-prepared text, because it is the email that gives rise to the incident.
    • All interaction with the system is closed to the chat bot, communication is carried out in a dialogue style.

    • add the “chat with administrator” functionality so that the user can send an administrator a message describing the problem directly.
    • The system must be supplied on its own hardware.
    • Iron should be affordable.
    • The system should be maximally independent of the environment.
    • Take the ready-made and cheap Raspberry PI computer.
    • We are designing an uninterrupted power supply board.
    • Add a modem to be independent of the state of the local network.
    • We will design a beautiful building.

    We have three subsystems with their own requirements and a vision for their implementation:

    • hardware subsystem;
    • monitoring subsystem;
    • user interaction subsystem.

    For the hardware subsystem, we developed a conceptual design. Yes Yes! Having violated all the rules of agglomeration, we developed a document, because manufacturers are working with documents. For the remaining subsystems, we allocated users (persons), prepared user stories, and wrote tasks for development.

    At this stage, the concept ends, and its result was:

    • hardware platform project;
    • formulated vision in the form of user stories on the other two subsystems;
    • prototype software part implemented as a virtual machine;
    • prototype hardware, implemented in the form of a stand, where actually hardware solutions were tested for strength;
    • testing conducted by our admins.

    The problems at this stage were mostly organizational and related to the lack of technical knowledge in the legal and accounting aspects of sales. Those. It’s one thing to figure out what and how to sell, and it’s quite another to face a ruthless legal machine: patents, development tasks, balancing, EULA and many other things, which we, as creative people, did not take into account initially.

    There was still not a problem, but rather, the difficulty associated with the design of the buildings. Our team has only engineers, so our electronics specialist “piled” plexiglass from plexiglass.

    The case looked, to put it mildly, controversial, especially for the public, spoiled by modern technology. Of course, connoisseurs were found among the “Kulibins” of the older generation - the corps aroused nostalgic feelings in them. It was decided to make and design the case again, since the old one, in addition to aesthetic defects, also had structural ones - plexiglass did not tolerate assembly and disassembly of the device and strove to crack. On the production of the case, I will tell further.

    And now we are close to the finish line - MVP. Of course, this is not the final serial product, but it is already beneficial and of value. The main goal of this stage is to launch the “create-evaluate-learn” cycle. It is at this point that LANBIX is located.

    At the “create” stage, we created a device that performs the declared functionality. Yes, it is not perfect yet, and we continued to work on it.

    We return to the manufacture of the case, i.e. to the task of transforming our device from a nostalgic feeling into a modern one. In the beginning, I went through the market for case manufacturers and industrial design services. Firstly, there are not many companies producing cases on the Russian market, and secondly, the cost of industrial design at this stage is prohibitively high, about 1 million rubles.

    We turned to our marketing department for design, a young designer was ready for creative experiments. We set out our vision of the corps (having previously studied the best examples of corps building), and he, in turn, turned it into a work of art. It remains only to produce. We, proud of our design, turned to our partners. Their CEO instantly destroyed our fantasies, pointing out for free things that cannot be done in the way we have chosen. The case can be made, and it will be no worse than Apple’s, but the cost of the case will be three to four times more expensive than the entire electronic filling. After a series of operations and approvals, we designed the enclosure that can be manufactured. Yes, it’s not as beautiful as we planned, but ideal for achieving current goals.

    Stage result: the first batch of devices ready for battle and testing.

    And now the most difficult part is the “evaluate” stage, and with our product we are right at this point. We can only evaluate by the results of use by real customers and no assumptions work here. We need those very "early followers" to provide feedback and make those changes to the product that are really needed. The question arises: where to get customers and how to convince them to take part in the experiment?

    Of all the possible options, we chose the classic set of digital tools: landing and advertising campaign in social networks.

    The process has already been launched, but it is too early to talk about the results, although there are already responses and we have received confirmation of many of our hypotheses. A pleasant surprise was the reaction of representatives of completely different segments of the business, much larger than those we were counting on. It would be foolish to ignore the new introductory ones, and based on the results of the interviews, it was decided to launch a parallel LANBIX line called LANBIX Enterprise. We have added support for distributed infrastructures, monitoring Wi-Fi networks with troubleshooting and localization of faults, monitoring the quality of communication channels. The greatest interest in the solution was expressed by service companies. At the same time, devices already developed by us play a significant role in the work of solutions.

    What will happen next

    What will happen next with the original LANBIX - it will become clear from the results of the campaign. If our hypotheses are not confirmed, according to the Lean methodology, we mercilessly get rid of it or it transforms into something new, because there is nothing worse than creating a product that no one needs. But already now we can say that the work done is not in vain and thanks to it a whole branch of parallel products has appeared that we are actively working on. If successful, LANBIX will move from the MVP stage to the final stage and will develop according to the understandable classic laws of product marketing.

    I repeat, now we want to find early followers, companies to whom we can install our product in order to collect feedback. If you are interested in testing LANBIX, write in the comments or private messages.

    A source

    Also popular now: