🥇How We Work with Ideas, and How LANBIX Was Born

At "LANIT-Integration," there are many creative employees. Ideas for new products and projects literally hang in the air. Identifying the most interesting ones can sometimes be very challenging. That's why we developed our methodology through joint efforts. To learn how to select the best projects and implement them, read this article.

In Russia, as well as worldwide, a number of processes are occurring that lead to the transformation of the IT market. Due to the increase in computing power and the emergence of server, network, and other virtualization technologies, the market no longer needs a large amount of hardware. Vendors increasingly prefer to work directly with clients. The IT market is witnessing a flourishing of outsourcing in all its forms, from classic outsourcing to the new wave of outsourcers—"cloud providers." Infrastructure systems and elements are becoming significantly easier to maintain and configure. Software quality improves year after year, and the integrator's tasks evolve.

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 market. The first step we took was to organize the product creation process. We reviewed numerous methodologies, from classic to trendy. However, none of them met our needs. So, we decided to base our approach on the Lean Startup methodology and adapt it to our objectives. The "Lean Startup" is an entrepreneurship theory developed by Eric Ries. Its foundation lies in the principles, approaches, and practices of concepts such as lean manufacturing, customer development, and agile development methodology.

As for the approach to product development management: we didn't reinvent the wheel but applied an existing development methodology SCRUM, adding creativity, and it can now confidently be 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 can understand, a classic 'integration' business does not imply assigning technical specialists full-time to work on a single project (exceptions occur, but very rarely), as everyone is busy with ongoing projects in addition to working on products. From SCRUM, we adopted the division of work into sprints, daily reporting, retrospectives, and roles. For managing the flow of tasks, we chose Kanban, which integrated perfectly into our existing task tracking system. We organized the work, smoothly integrating into the already established order.
Before entering the market, a product goes through 5 stages: idea, selection, concept, MVP (more details below), and production.

Idea

At this stage, there is something ephemeral – the idea. Ideally, it is an idea for solving an existing problem or task of the client. We have no shortage of ideas. Initially, they should be generated by technical staff. In order for an idea to be accepted for further development, the author must fill out the 'Idea Submission Template'. It has just four questions: What? Why? Who needs it? And if it's not our product, then what?

Source

Selection

As soon as the filled-out template gets to us, the processing and selection procedure begins. The selection stage is the most labor-intensive. At this stage, the formation of problem hypotheses occurs (I mentioned in the previous paragraph that ideally, the idea should solve the client's problem) and the product's value. A hypothesis of scale is formed, i.e., how our business intends to grow and thrive. Problem and expert interviews are conducted with potential clients for preliminary confirmation that we are going to produce something necessary. It requires at least 10-15 interviews to draw a conclusion about the product's necessity.

If the hypotheses are confirmed, a preliminary financial analysis is conducted, assessing the estimated volume of investments and potential earnings for the investor. As a result of this stage, a document called Lean Canvas is created and presented to the management.

Concept

At this stage, around 70% of ideas are filtered out. If the concept is approved, we proceed to the idea development phase. The functional capabilities of the future product are outlined, implementation paths and optimal technical solutions are defined, and the business plan is updated. The result of this stage is the technical assignment for development and a detailed business case. If successful, we move on to the MVP stage.

MVP

MVP is a minimum viable product. It means a product that is not fully developed but already provides value and performs its function. At this stage of development, we actively gather feedback from real users and make necessary changes.

Production

The final stage is production. Only about 5% of products reach this stage. These 5% include only the most important, necessary, viable, and functional products.

We have many ideas and a substantial portfolio is already gathered. We analyze each idea and do everything we can to bring it to the final stage. It is very gratifying that colleagues have shown interest in our R&D direction and are actively participating in product and solution development.

How We Developed LANBIX

Let’s consider the creation of a product using a real example — the LANBIX product. It is a box-based software-hardware complex designed for monitoring small IT infrastructures and promptly alerting responsible parties and business users about malfunctions, with management via a chat bot. In addition to monitoring, LANBIX includes Help Desk functionality. This product is exclusive to the market segment we are targeting. This is both our advantage and our challenge. But let's take it step by step. I should mention right away that LANBIX is a living product (i.e. it is not final in its development and is currently on another MVP iteration).

So, the first stage is the idea. For an idea to be born, there need to be problems, and we certainly had them, or rather, our acquaintances did. Below, we will discuss several real situations that occurred in various business sectors.

A small management company serves two buildings in the Moscow region. The staff, who have PCs, number about 15 people. The system administrator is a freelance contractor (a clever son of one of the concerned residents). It might seem that the activities of the management company are weakly dependent on IT, but a peculiarity of this business is the monthly reporting to numerous instances. The system disk of the company's head (which, as usual, combines many roles) ran out of free space. Naturally, this did not happen suddenly; a warning had been displayed for about 2 months and was constantly ignored. But an update rolled in, the OS updated, and unfortunately, it got stuck halfway through the update, complaining before its

Source

A similar case occurred in a large holding company, which unites many small businesses, with a single technical support service for the entire office. In one of the departments, the computer of the chief accountant broke down. It had been known for a long time that it could break (the computer was desperately slow and overheating), but the chief accountant had not gotten around to submitting a support request. Naturally, it broke down right on payday, and the department staff went several days without their salaries.

A small wholesale trading business had its selling website go down, which was hosted on an external platform. They learned of its inaccessibility via phone from a regular customer. At the time of the call, the site had already been down for about three hours. It took another couple of hours to locate the person responsible for the site, and another two hours to resolve the issue. Consequently, the site was inaccessible for nearly the entire working day. According to the company's commercial director, this downtime cost them about 1 million rubles.

I faced a similar situation when I went to an appointment at the clinic and had to reach the DMS registration desk. They couldn't send me to the doctor for a simple reason – there was a power surge in the morning, and after the outage, their email service and the communication service with the insurance company were not functioning. When I asked, where are your admins, I was told that they have a visiting admin who comes in once a week. And at that moment (it was already 4:00 PM), he wasn't answering his phone. For at least 7 hours, the clinic was cut off from the outside world and couldn't provide paid services.

What connects all these cases? Absolutely all problems could have been prevented in advance. With timely responses from the IT staff, the resulting damage could have been minimized. This would have been possible with the proper interpretation of early symptoms by users.

We identified the problem hypotheses:

significant monetary and reputational losses due to the slow response to failures in the IT infrastructure;
incorrect interpretation of early malfunction symptoms by users.

What can the client do about this, and how can similar situations be avoided in the future? There are not many options:

hire a highly qualified system administrator to work full time and ensure he is diligent;
outsourcing IT maintenance to a specialized service company;
implement a monitoring and fault alert system independently;
provide training for users/business personnel on the basics of computer literacy.

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

A lyrical digression. Various IT service monitoring systems have been in use in the enterprise market for a long time, and their benefits are undisputed. I spoke with representatives of large companies, observing how business and IT relationships are structured. The technical director of a large machine-building enterprise outsourced the maintenance of the IT infrastructure to an external company, but he remains up to date with all matters. In his office, a large screen displays the monitoring system with indicators of IT service status. The most critical services are recorded in the system. At any moment, the technical director can find out the condition of the infrastructure, what is happening, where the problem lies, whether the responsible people have been notified, and whether the issue is being resolved.

The stories mentioned prompted our team to think about how to create an optimal monitoring system for small companies. As a result, LANBIX was born — a monitoring system that absolutely anyone can deploy without IT knowledge. The main task of the system is as simple as that of all systems aimed at increasing continuity and availability — to reduce financial and other losses in the event of unexpected downtime. The device aims to minimize the time between "something is broken" and "the problem is solved."

To validate the hypothesis, we conducted problem interviews. I couldn't imagine how much people are willing to share when not being sold to. Each conversation lasted at least 1.5 hours, and we gathered a wealth of information useful for further development.

Let's summarize the result of this stage:

an understanding of the problem — check,
an understanding of value — check,
an idea for a solution — check.

The second stage was more detailed. As a result, we had to present a business case (the Lean Canvas itself) to management, which essentially serves as the investor for decision-making regarding the product's future.

We began with market research and competitive analysis to find out who does what, and, most importantly, how they are operating in this market.

The following became clear.

There are no ready-made boxed monitoring systems for our segment (small business) in the market, except for a couple of them, which I won't mention for obvious reasons.
Our main competitors, surprisingly, are system administrators with custom scripts and modifications to open-source monitoring systems.
There is a clear problem with the use of open-source monitoring systems. There is a system in place, along with a wealth of information on how to work with and modify the system to meet their needs. Among the administrators I surveyed, many confessed that they lack the skills to implement their ideas on their own. They are also unable to admit this to management due to fear of being fired. This creates a vicious cycle.

We then moved on to analyzing the needs of our potential clients. We identified a segment of small organizations that, for various reasons, do not have their own IT department, where IT is managed either by a freelance system administrator, a contractor, or a service company. We decided to approach this not from the IT side, but from the business perspective, offering business founders and owners a tool to improve the quality of IT infrastructure services. The product is designed to help owners secure their business, but at the same time, it will increase the workload for those responsible for IT. It provides businesses with a tool to control the quality of IT support.

As a result of processing the data gathered, we created the first list of requirements (a rough backlog) for the future product:

the monitoring system must be based on an open-source solution and therefore be inexpensive;
it should be easy and fast to install;
it must not require specific IT knowledge; even an accountant (by no means intending to offend representatives of this profession) should be able to deploy and configure the system;
it should automatically discover monitoring objects on the network;
it should automate (ideally fully) the installation of monitoring agents;
it should have the capability to monitor external services, including at least a CRM system and a sales website;
it must notify both the business and the system administrator about malfunctions;
the depth and 'language' of notifications should be different for the admin and the business;
the system must be delivered on its own hardware;
the hardware should be as accessible as possible;
The system should be as independent as possible from external factors.

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

Stage result:

high-level product backlog;
a formulated business model or scalability hypothesis that still needs to be validated in practice.

Let's move on to the next stage—the concept. Here, as engineers, we enter our element. There are "wants" that are decomposed into components/subsystems/features, which then turn into technical specifications/user stories, then into projects, and so on. I won’t go into detail about the process of preparing a set of alternative options; let’s move directly to the requirements and the chosen methods for their implementation.

Requirement
Solution

It must be an open monitoring system;

We take an open-source monitoring system.

The system should be easy and quick to install;
it should not require specialized IT knowledge. Even an accountant should be able to deploy and configure the system.

We suggest a pre-installed system so that the user only needs to turn on the device and make a few adjustments, similar to setting up a router.

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

We will create our own chatbot for one of the popular messengers and direct all interactions with the system to it.

The system should:

automatically discover objects that need monitoring on the network;
automatically install monitoring agents;
Have the capability to monitor external services, at least CRM systems and the sales website.

We are writing add-ons for the monitoring system for:

automatic object discovery;
automatic agent installation;
monitoring the availability of external services.

The system should:

notify both the business and the system administrator about issues;
have the capability to monitor external services, at least CRM systems and the sales website. The depth and "language" of notifications should vary for admins and businesses.
The system should not require specialized IT knowledge; even an accountant should be able to deploy and configure the system.

We will add different types of notifications for different user types. They vary in presentation and depth. The business user will receive notifications like 'everything is fine, but Ivanov's computer is about to fail.' The administrator will receive a complete error message detailing who, how, and what happened or may happen.
We will add the option to use the email of an additional responsible person so that in case of a failure, they receive a notification.
We will establish interaction with external service providers based on sending emails with pre-prepared text, as it is the email that provides the basis for incident management.
All interaction with the system will be centralized around a chat-bot, with communication conducted in a conversational style.

The vulnerability is confirmed in many official Docker images, including images for Couchbase, Elasticsearch, Flink, Solr, Storm, etc.

We will add a 'chat with administrator' feature so that users can send messages directly to the administrator describing their issues.

The system must be supplied on dedicated hardware.
The hardware must be accessible.
The system should be as independent as possible from its environment.

We will use a ready-made and inexpensive Raspberry PI computer.
We will design a power supply uninterruptible board.
We will add a modem for independence from the local network's condition.
We will design an attractive casing.

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

the hardware subsystem;
the monitoring subsystem;
the user interaction subsystem.

For the hardware subsystem, we developed a draft project. Yes, indeed! Breaking all the rules of agile development, we created a document, as manufacturers work specifically with documents. For the other subsystems, we identified users (personas), prepared user stories, and wrote tasks for development.

At this point, the concept phase ends, resulting in:

a project for the hardware platform;
a formulated vision in the form of user stories for the remaining two subsystems;
a software prototype implemented as a virtual machine;
a hardware prototype implemented as a setup, where the hardware solutions were tested for durability;
testing conducted by our administrators.

The challenges at this stage were mainly organizational, related to the inadequate knowledge of the engineering team in the legal and accounting aspects of sales. In other words, it’s one thing to come up with ideas on what and how to sell, and quite another to confront the ruthless legal machinery: patents, development assignments, inventory accounting, EULA, and much more that we, as creative individuals, initially overlooked.

There was not really a problem but rather a difficulty related to the design of the chassis. Our team consists entirely of engineers, so our electronics specialist 'sculpted' the first version of the chassis out of acrylic.

The chassis looked, to put it mildly, debatable, especially for an audience spoiled by modern technology. Of course, there were enthusiasts among the 'craftsmen' of the older generation — the chassis evoked nostalgic feelings in them. It was decided to create and design the chassis anew, since the old one had not only aesthetic shortcomings but also structural issues — the acrylic poorly endured assembly and disassembly of the device and tended to crack. I’ll talk more about the chassis production later.

And now we are close to the finish line — the MVP. Of course, this is not the final serial product yet, but it already brings benefits and presents value. The main goal of this stage is to launch the 'create-evaluate-learn' cycle. This is where LANBIX currently stands.

At the 'create' stage, we developed a device that performs the declared functionality. Yes, it is still not perfect, and we continue to work on it.

Returning to the production of the chassis, i.e., the task of transforming our device from one that evokes nostalgic feelings into a modern one. Initially, I scoured the market for chassis manufacturers and industrial design services. Firstly, there are very few companies producing chassis in the Russian market, and secondly, the cost of industrial design at this stage is exorbitantly high, around 1 million rubles.

The design was handled by our marketing department, and a young designer was ready for creative experiments. We expressed our vision for the case (after studying the best examples of case design), and he, in turn, transformed it into a work of art. All that was left was to produce it. Proud of our design, we turned to our partners. Their CEO immediately shattered our fantasies by pointing out things that could not be produced in the way we had chosen, completely free of charge. The case can be produced, and it would be no worse than Apple’s, but the cost of the case would be three to four times higher than the entire electronic filling. After a series of operations and approvals, we designed a case that can be manufactured. Yes, it’s no longer as beautiful as we planned, but it's ideal for achieving current goals.

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

And now comes the most difficult part – the ‘assessment’ stage, and with our product, we are exactly at this point. We can only assess based on the results of usage by real customers, and no assumptions work here. We need those ‘early adopters’ to provide feedback and make the necessary changes to the product. The question arises: where to find customers and how to convince them to participate in the experiment?

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

The process has already started, but it's still too early to talk about results, although feedback has already started coming in, and we have confirmed many of our hypotheses. A pleasant surprise was the reaction of representatives from entirely different business segments, much larger than we initially anticipated. It would be foolish to ignore new inputs, and based on the results of the interviews conducted, a decision was made to launch a parallel line called LANBIX Enterprise. We added support for distributed infrastructures, Wi-Fi network monitoring with fault detection and localization, and monitoring of communication channel quality. The greatest interest in the solution was expressed by service companies. Meanwhile, our already developed devices play a significant role in the solutions.

What happens next

What will happen next with the original LANBIX will become clear based on the results of the campaign. If our hypotheses are not confirmed, according to Lean methodology, we will ruthlessly eliminate it or it will transform into something new, as there is nothing worse than creating a product that no one needs. However, it can already be said that the work done is not in vain, and thanks to it, a whole branch of parallel products has emerged, which we are actively working on. If successful, LANBIX will move from the MVP stage to the final stage and will develop according to the well-known classic laws of product marketing.

I reiterate, we currently want to find early adopters, companies that can install our product to collect feedback. If you're interested in testing LANBIX, please write in the comments or direct messages.

Source

Source: habr.com

How we work with ideas and how LANBIX was born.