How we work with ideas and how LANBIX was born

There are many creative employees in LANIT-Integration. Ideas for new products and projects literally hang in the air. It is sometimes very difficult to identify the most interesting ones. Therefore, we jointly developed our own methodology. How to select the best projects and implement them, read 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. Thanks to the increase in computing power and the emergence of server, network and other virtualization technologies, the market has ceased to need a large amount of hardware. Vendors increasingly prefer to work directly with customers. In the IT market, outsourcing is flourishing in all its manifestations, starting with classic outsourcing and ending with the new wave of outsourcers - “cloud providers”. Infrastructure systems and elements are becoming much easier to maintain and configure. The quality of the software is growing every year and the tasks of the integrator are being transformed.

How we work with ideas

Product startup direction in "LANIT-Integration" has been in existence 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 organizing the process of creating products. We have studied many methodologies, from classic to hype. However, none of them met our needs. Then we decided to take the Lean Startup methodology as a basis and adapt it to our tasks. The 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 agile development methodology.

As for the direct approach to product development management: we did not reinvent the wheel, but applied an already existing development methodology SCRUM, adding a creative, 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 full-time technical specialists to work on one project (there are exceptions, but very rarely), since in addition to 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 built the work, smoothly integrating into the existing order of things.
Before entering the market, a product goes through 5 stages: idea, selection, concept, MZHP (more details below) and production.

Idea

At this stage, there is something ephemeral - an idea. Ideally, an idea to solve an existing problem or problem for 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 it? And if not our product, then what?

Source

Selection

As soon as the completed template reaches 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 mentioned in the previous paragraph that, ideally, the idea should solve the problem of the client) and the value of the product are formed. 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 for preliminary confirmation 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 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 management.

Concept

At this stage, about 70% of ideas are eliminated. If the concept is approved, then the idea development stage begins. The functionality of the future product is being formed, ways of implementation and optimal technical solutions are being determined, and the business plan is being updated. The result of this stage is the terms of reference for the development and a detailed business case. If successful, we move on to the MVP or MVP stage.

MVP or MVP

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

Winemaking

And the last step is production. No more than 5% of products reach this stage. This 5% includes only the most important, necessary, viable and functional products.

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

How we made LANBIX

Consider creating a product on a real example - the LANBIX product. This is a “boxed” software and hardware system designed to monitor small IT infrastructures and promptly notify responsible persons and business users about malfunctions with management through 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 live product (that is, it is not final in its development and is on the next round of MVP).

So the first step is the idea. In order for an idea to be born, problems are needed, 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 Moscow region. The staff with a PC is about 15 people. The system administrator is an incoming freelancer (the smart son of one of the caring residents). It would seem that the activities of the management company are weakly dependent on IT, but the peculiarity of this business is monthly reporting to many authorities. On the system disk of the head of the company (as usual, combining many roles) ran out of free space. Naturally, this did not happen suddenly, the warning hung for about 2 months and was constantly ignored. But an update arrived, the OS was updated and, as luck would have it, hung in the middle of the update, complaining about the busy disk before “death”. The computer went into a reboot. While we were dealing with the problem and getting the reports, we missed the reporting deadline. It would seem that a trifling malfunction caused various troubles: from losses to litigation and administrative liability.

Source   

A similar case 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. It was known for a long time that it could break down (the computer was desperately slowing down and warming up), but the hands of the chief accountant did not reach the point of sending a request to technical support. Naturally, it broke down exactly on the day of the salary, and the employees of the department were without money for several days.

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

I myself faced a similar situation when I came to an appointment at a polyclinic and had to get into the VHI registry. They could not send me to the doctor for a banal reason - there was a power surge in the morning, and after the accident, their mail service and a certain service for communication with the insurance did not work. To my question, where are your admins, I was told that their admin comes and visits them once a week. And now (at that time it was already 16:00) he does not pick up the phone. For at least 7 hours, the polyclinic was cut off from the outside world and could not provide paid services.

What unites all these cases? Absolutely all problems could have been prevented in advance. With a 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 the problems:

• significant financial and reputational losses due to the low speed of response to malfunctions in the IT infrastructure;
• misinterpretation of early failure symptoms by users.

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

1. take a highly qualified system administrator on staff and make him work conscientiously;
2. outsource IT services to a specialized service company;
3. independently implement a system for monitoring and alerting about malfunctions;
4. conduct training of users/business personnel in the basics of computer literacy.

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 systems for monitoring IT services in the enterprise market have been used for a long time, and their usefulness is not disputed. I talked with representatives of large companies, looked at how the relationship between business and IT is built. The technical director of a large machine-building enterprise has outsourced the maintenance of the IT infrastructure to an external company, but he himself remains in the know. He has a large screen of a monitoring system in his office with indicators of the status of IT services. The most critical ones are brought into the system. At any time, the technical director can find out what state the infrastructure is in, what is happening, in what area the problem is, whether the responsible people have been notified, whether the task 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 in the field of IT. The main objective of the system is simple, as with all systems aimed at increasing continuity and availability - to reduce financial and other losses in the event of unplanned downtime. The device is designed to minimize the time between "something broke" and "the problem is fixed."

Problematic interviews were conducted to confirm the hypotheses. I couldn't imagine how much people are willing to tell if you don't try to sell them. Each conversation lasted at least 1,5 hours, and we received a lot of information useful for further development.

Let's summarize the result of this step:

1. understanding of the problem is
2. understanding of value is
3. idea for a solution is.

The second stage was more detailed. According to its results, we had to present to the management, which essentially plays the role of an investor, a business case (the same Lean Canvas) to decide on the future fate of the product.

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

It turned out the following.

1. There are no ready-made boxed monitoring systems for our segment (small business) on the market, with the exception of a couple of which, for obvious reasons, I will not talk about.
2. Our main competitors, oddly enough, are system administrators with self-written scripts and "finishing" for 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 work and refinement of the system to suit your needs. Of the administrators I interviewed, many admitted that they do not have enough competencies to implement their ideas on their own. And they cannot admit this to the management because of the fear of dismissal. It turns out a vicious circle.

We then moved on to analyzing the needs of our potential customers. We have singled out for ourselves a segment of small organizations that for some reason do not have their own IT service, where either an incoming system administrator, or a freelancer, or a service company is responsible for IT. It was not the IT side that decided to enter, but the business side, offering founders and business owners a tool to improve the quality of IT infrastructure service. A product that should help owners secure their business, but at the same time it will add work to people who are in charge of IT. A product that provides businesses with a tool to control 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;
• easy and fast to install;
• should not require specific knowledge in IT, even an accountant (in no case did not want to offend representatives of this profession) should be able to deploy and configure the system;
• should automatically detect objects for monitoring in the network;
• should automatically (and ideally automatically) install monitoring agents;
• should be able to monitor external services, at least a CRM system and a selling site;
• should notify both the business and the system administrator about problems;
• the degree of depth and "language" of notifications should be different for the admin and business;
• the system must be delivered on its own hardware;
• iron should be as accessible as possible;
• the system should be as independent as possible from external factors.

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

Stage result:

• high-level product backlog;
• a formulated business model or 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 “wish lists” that are decomposed into components/subsystems/features, then they turn into technical specifications/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 chosen methods for their implementation.

Demand
Solution

• It should be an open monitoring system;

We take an open source monitoring system.

• The system should be simple and quick to install;
• should not require specific knowledge in IT. Even an accountant should be able to deploy and customize 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 a router.

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

Let's write our own chat bot for one of the well-known messengers and start all interaction with the system on it.

The system must:

• automatically detect the objects required for monitoring in the network;
• automatically install monitoring agents;
• Be able to monitor external services, at least a CRM system and a selling site.

We write add-ons for the monitoring system for:

• automatic object detection;
• automatic installation of agents;
• monitoring the availability of external services.

The system must:

• notify both the business and the system administrator about problems;
• be able to monitor external services, at least 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 knowledge in IT, even an accountant should be able to deploy and configure the system.

• Let's add different types of notifications for different types of users. They differ in pitch and depth. The business user will receive notifications like "everything is fine, but Ivanov's computer will die soon." The administrator will receive a full error message, with whom, how and what happened or could happen.
• Let's add the ability to use the mail of an additional responsible person, so that in the event of a breakdown, he would receive a message.
• Let's add interaction with external service providers based on sending email with pre-prepared text, because it is the e-mail that gives the basis for the institution of the incident.
• All interaction with the system will be closed to the chatbot, communication is conducted in a dialogue style.

Supplement:

• Let's add the functionality of "chat with the administrator" so that the user can send a message to the administrator describing the problem directly.

• The system must be delivered on its own hardware.
• Iron must be available.
• The system should be maximally independent of the environment.

• Take a ready-made and cheap Raspberry PI computer.
• We will design an uninterruptible power supply board.
• Let's add a modem for independence from the state of the local network.
• We will design a beautiful building.

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

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

For the hardware subsystem, we developed a draft design. Yes Yes! Having violated all the rules of agileization, we have developed a document, because manufacturing plants work with documents. For the remaining subsystems, we identified users (personas), prepared user stories, and wrote tasks for development.

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

• project on a hardware platform;
• formulated vision in the form of user stories for the other two subsystems;
• prototype of the software part, implemented as a virtual machine;
• a prototype of the hardware implemented in the form of a stand, where the hardware solutions were actually tested for strength;
• 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 figure out what and how to sell, and quite another to face a ruthless legal machine: patents, development assignments, balance sheet, EULA and many other things that we, as creative people, did not initially take into account.

There was not yet a problem, but rather a difficulty with the design of the hulls. There are only engineers in our team, so the first version of the case was “piled” from plexiglass by our electronics specialist.

The case 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 case aroused nostalgic feelings in them. It was decided to make and design the case again, since the old one, in addition to aesthetic flaws, also had structural ones - plexiglass did not tolerate assembly and disassembly of the device and strove to crack. About the production of the case, I will tell further.

And now we are close to the finish line - MVP. Of course, this is not yet the final serial product, but it is already useful and valuable. The main goal of this stage is to launch the create-assess-learn cycle. It is at this stage that LANBIX is.

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 transforming our device from nostalgic to modern. First, I scoured 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 prohibitive, about 1 million rubles.

Our marketing department was asked for a design, the young designer was ready for creative experiments. We outlined our vision of the hull (having previously studied the best examples of hull building), and he, in turn, turned it into a work of art. It remains only to produce. We, proud of our design, turned to partners. Their CEO instantly ruined our fantasies by pointing out, for free, things that could not be produced in the way we chose. The case can be produced, and it 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 have designed a hull that can be produced. Yes, not as beautiful as we planned, but perfect for achieving current goals.

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

And now the most difficult part is the “evaluate” stage, and with our product we are just at this point. We can only evaluate the results of use by real customers and no assumptions work here. We need those “early adopters” 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: a landing page 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 expected. It would be foolish to ignore the new introductions, and based on the results of the interviews, it was decided to launch a parallel line of LANBIX called LANBIX Enterprise. We have added support for distributed infrastructures, monitoring Wi-Fi networks with troubleshooting and localization, monitoring the quality of communication channels. Service companies expressed the greatest interest in the solution. At the same time, the devices already developed by us play an important role in the work of solutions.

What will happen next

What will happen next with the original LANBIX will become clear from the results of the campaign. In case of non-confirmation of our hypotheses, 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 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, on which we are actively working. If successful, LANBIX will move from the MVP stage to the final stage and will develop according to the understandable classical laws of product marketing.

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

Source

Source: habr.com