How we work with ideas and how LANBIX was born

How we work with ideas and how LANBIX was born

There are many creative employees in LANIT-Integration. Ideas of new products and projects literally hang in the air. Identifying the most interesting is sometimes very difficult. Therefore, we jointly developed our own methodology. How to select the best projects and implement them, read in this article.

In Russia, and 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 no longer needs a lot of hardware. Vendors increasingly prefer to work with customers directly. In the IT market, the heyday of outsourcing in all its manifestations, starting with classic outsourcing and ending with outsourcers of the new wave - “cloud providers”. Infrastructure systems and elements become significantly easier to maintain and configure. The quality of software grows every year and the tasks of the integrator are transformed.

How we work with ideas

The product startup direction in LANIT-Integration has been around for over a year. Our main goal is to create new products and bring them to the market. The first thing we started with was the organization of the product creation process. We have studied many methodologies, starting with the classical and ending with the HYIP. However, none of them matched our requests. Then we decided to base the Lean Startup methodology and adapt it to our needs. “Thrifty Startup” is an enterprise theory created by Eric Rees. It is based on the principles, approaches and practices of such concepts as lean manufacturing, customer development and flexible development methodology.

As for the approach to the management of product development: we did not reinvent the wheel, but applied the already existing development methodology SCRUM , 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 (exceptions are, but extremely rare), since, apart from working on products, everyone is busy with current projects. From SCRUM we took the division of work into sprints, daily reporting, retrospectives and roles. We chose Kanban to work with the task flow, and it integrated perfectly into our existing task tracking system. We have built work, seamlessly integrating into the existing order of things.

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


At this stage there is something ephemeral - an idea. Ideally, the idea of ​​solving an existing problem or customer problem. We have no lack of ideas. Initially, they should be generated by technical staff. In order for the idea to be accepted for further development, the author must complete the “Idea Design Template”. There are only four questions: What? For what? Who needs it? And if not our product, then what?



As soon as the decorated template comes 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 (I knowingly in the previous paragraph mentioned that, ideally, the idea should solve the problem of the client) and the value of the product. A scale hypothesis is being formed, i.e. how our business is going to grow and flourish. Problem and expert interviews are conducted with potential customers to pre-confirm that we are going to produce something necessary. 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 amount of investments and the investor's possible earnings are estimated. As a result of this stage, a document called Lean Canvas is born and presented to management.


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


MUP 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 very last stage is production. No more than 5% of products reach this stage. These 5% include only the most important, necessary, viable and functional products.

We have a lot of ideas, a large portfolio has already been assembled. We dismantle each idea and do everything so that it reaches the final stage. It is very pleasant that colleagues have not remained indifferent to our R & amp; D-direction and are actively involved in the development and implementation of products and solutions.

How we did LANBIX

Consider creating a product using a real-world example — a LANBIX product. This is a “boxed” hardware and software system designed for monitoring small IT infrastructures and promptly notifying responsible persons and business users about faults with control via chat bot. In addition to the monitoring function, LANBIX includes Help Desk functionality. This product is exclusive to the market segment that we are targeting. This is our advantage and our pain. But first things first. At once I will say that LANBIX is a living product (that is, it is not final in its development and is on the next round of MVP).

So, the first stage is an idea. In order to have an idea, 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 business.

A small management company serves two houses in the suburbs. The staff with a PC, about 15 people. The system administrator is a visiting freelancer (the clever son of one of the caring tenants). It would seem that the activities of the Criminal Code is weakly dependent on IT, but the peculiarity of this business is the monthly reporting to many instances. The system disk of the head of the company (as usual, combining many roles) has run out of space. 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, it hung in the middle of the update, having complained before the “death” to a busy disk. The computer went into a cyclic reboot. While we dealt with the problem and got reports, we missed the deadline for submitting reports.It would seem that a trifling malfunction caused various troubles: from damages to legal proceedings and administrative liability.


A similar case occurred in a large holding company that brings together 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 he could break was known for a long time (the computer was desperately slowing down and warming himself), but the accountant’s hands didn’t get to send a request for technical support. Naturally, he broke down right on the payday, and the department staff spent several days without money.

A small business in the wholesale trade lay down selling site, which was hosted on the external site. We learned about its inaccessibility by telephone from a permanent customer. At the time of the call site was already about three hours. It took another couple of hours to find the person responsible for the site, two more to troubleshoot. Accordingly, the site was virtually unavailable for the entire working day. According to the company's commercial director, this simple 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 couldn’t 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 a certain insurance service did not work. When I asked, where are your admins, I was told that the admin is coming and visiting them once a week. And now (at that time it was already 16:00) he does not pick 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 the problems could have been prevented in advance. With timely response from the 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 monetary and reputational losses due to the low speed of reaction to malfunctions in the IT infrastructure;
  • misinterpretation of early user failure symptoms.

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

  1. take a highly qualified system administrator to the state and make it work conscientiously;
  2. give IT service to a specialized service company;
  3. independently implement a monitoring and fault reporting system;
  4. Conduct computer literacy training for users/business personnel.

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

Lyrical digression. Various IT service monitoring systems have been used in the enterprise market for a long time, and their benefits are not disputed. I spoke with representatives of large companies, looked at how business and IT relationships were built. The technical director of a large machine-building enterprise gave service to the IT infrastructure of an external company, but he himself remains aware of all the cases. In his office hangs a large screen monitoring system with indicators of the status of IT services. The system brought the most critical.At any time, the technical director can find out in what condition the infrastructure is, what is happening, in which part of the problem, whether the responsible people are notified, 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 IT knowledge. The main objective of the system is simple, as with all systems aimed at increasing continuity and availability - reducing monetary and other losses in case of unplanned downtime. The device is designed to minimize the time between “something broke,” and “problem 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 got a lot of information useful for further development.

Summarizing the result of this stage:

  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. According to its results, we had to submit to the management, which essentially plays the role of an investor, a business case (the same Lean Canvas) to make a decision about the future fate of the product.

We started with market research and competitive analysis 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 boxed monitoring systems for our segment (small business) in the market, with the exception of a couple or three, for which I will not speak for obvious reasons.
  2. Our main competitors, oddly enough, are system administrators with self-written scripts and “dopils” to open source monitoring systems.
  3. There is a clear problem with using open source monitoring systems. There is a system, there is a huge amount of information on the operation and refinement of the system to fit your needs. Of the administrators I interviewed, many have admitted that they lack the competencies to implement the ideas on their own. And they cannot admit to the leadership of this because of the fear of dismissal. It’s a vicious circle.

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

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

  • The monitoring system should be based on an open source solution and therefore cheap;
  • is simple and quick to install;
  • should not require specific knowledge in IT, even an accountant (in no way wanted to offend members of this profession) should be able to deploy and configure the system;
  • should automatically detect objects to be monitored on the network;
  • should automatically (and ideally automatically) install monitoring agents;
  • should be able to monitor external services, at a minimum, a CRM system and a marketing site;
  • Must notify both the business and the system administrator about problems;
  • the degree of depth and the "language" of alerts should be different for the admin and business;
  • the system must be supplied on its own hardware;
  • iron should be as accessible as possible;
  • the system should be as independent as possible from external factors.

Further, investment in product development was calculated (including the labor costs of the technical department staff). A sketch of the business model has been prepared and the unit-economy of the product has been calculated.

Result of the stage:

  • high-level backlog of the product;
  • a formulated business model or a scale hypothesis that has yet to be tested in practice.

Let's move on to the next stage - the concept. Here we, as engineers, fall into our native element. There are “Wishbones” 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, let's go straight to the requirements and the methods chosen for their implementation.

Requirement Solution
  • This 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 IT knowledge. 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 little, by analogy with the router.

Let's close the interaction with the device to something simple and clear to everyone.

Let's write your chat bot for one of the famous messengers and get all the interaction with the system on it.
System must:

  • 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 write additions for the monitoring system by:

  • automatic object detection;
  • unattended agent installation;
  • monitoring the availability of external services.
System must:

  • notify about failures of both the business and the system administrator;
  • be able to monitor external services, at a minimum, a CRM system and a selling site. The degree of depth and "language" of alerts should be different for the admin and business.
  • The system should not require specific IT knowledge, 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 feed and depth. A business user will receive notifications of the type “everything is fine, but Ivanov’s computer will soon die”. The administrator will receive a complete error message, from whom, how and what happened or may happen.
  • Add the ability to use the mail of an additional responsible person so that in case of a breakdown he receives a message.
  • Add interaction with external service providers based on sending email with pre-prepared text, because it is an e-mail that gives rise to the institution of the incident.
  • All interaction with the system will be closed on the chat bot, communication is conducted in a dialogue style.

  • add the “chat with administrator” functionality so that the user can send the administrator a message describing the problem directly.
  • The system should be supplied on its own hardware.
  • Iron should be available.
  • The system should be as independent of the environment as possible.
  • Take a ready and cheap computer Raspberry PI.
  • Design an uninterrupted power supply board.
  • Add a modem to be independent of the local network state.
  • Let's design a beautiful case.

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

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

For the hardware subsystem, we have developed a draft design. Yes Yes! Violating all the rules of adjayment, we developed a document, because the manufacturers work with documents. For the remaining subsystems, we have identified users (persons), prepared user stories, wrote assignments for development.

At this stage of the concept ends, and the result is:

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

The problems at this stage were mostly organizational and related to the lack of knowledge of the engineering staff in the legal and accounting aspects of sales. Those. it's one thing to think of what and how to sell, and quite another to face a ruthless legal machine: patents, development tasks, balance sheet, EULA and many others, which we, as creative people, initially did not take into account.

There was still no problem, but rather, the difficulty associated with the design of buildings. There are only engineers in our team, so the first version of the case was “piled” out of plexiglass by our expert in electronics.

The body looked, to put it mildly, debatable, especially for the public, spoiled by modern technology. There were, of course, connoisseurs among the "Kulibins" of the older generation - the corps caused nostalgic feelings in them. It was decided to manufacture and design the case anew, since in addition to the aesthetic flaws, the old one also had constructive ones - plexiglas did not tolerate the assembly and disassembly of the device and was trying to crack. On the production of the case, I will tell further.

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

At the “create” stage, we have 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 turning our device from causing nostalgic feelings to modern.In the beginning, I went through the market for hull manufacturers and industrial design services. Firstly, there are very few companies producing cases on the Russian market, and secondly, the cost of industrial design at this stage is exorbitantly high, about 1 million rubles.

Applied for design to our marketing department, the young designer was ready for creative experiments. We set out our vision of the hull (after having studied the best examples of the body 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 completely free of charge to things that are impossible to produce in our chosen way. The case can be produced, and will be no worse than that of Apple, 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 a hull that can be manufactured. Yes, not as beautiful as we had planned, but ideal for achieving current goals.

The result of the stage: the first batch of devices ready for battle and trials.

And now the most difficult is the “evaluate” stage, and with our product we are right at this point. We can evaluate only by the results of use by real customers and no assumptions work here. We need the very "early followers" to provide feedback and make the 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 a classic set of digital tools: landing and an 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 business segments, much larger than those we had hoped for. It would be foolish to ignore the new introductory, and based on the results of the interviews, it was decided to launch a parallel LANBIX line called LANBIX Enterprise. We added support for distributed infrastructures, monitoring Wi-Fi networks with troubleshooting and localization, monitoring the quality of communication channels. The greatest interest in the decision was expressed by service companies. In this case, the devices we have already developed in the work of solutions play a significant role.

What's next

What will happen next with the initial LANBIX will become clear by the results of the campaign. If our hypotheses are not confirmed, according to the Lean methodology, we will ruthlessly get rid of it or it will be transformed into something new, because there is nothing worse than making a product that nobody needs. But now we can say that the work done is not in vain, and thanks to it a whole branch of parallel products appeared, on which we are actively working. If successful, LANBIX will move from the MVP stage to the final stage and will evolve according to the clear classical laws of product marketing.

Again, now we want to find early followers, companies that can install our product in order to collect feedback. If you are interested in testing LANBIX, write in comments or personal messages.


Source text: How we work with ideas and how LANBIX was born