Our rake in launching a hardware startup is to search for a business model and develop MVP in the field of “Internet of things”
Internet of Things - cool, fun and on the crest of a wave of global trends. About how to walk the rake, to drown on the project funds for the purchase of a small fleet of foreign cars, what is MVP and what it has to do with hardware, as a programmer becomes a seller - under the cut.
- Hi, my name is Alexander, and I'm a startup.
“Hi, Alexander,” the audience said uneasily.
Seeing obvious difficulties, the head of the center of anonymous startupers suggested telling from the very beginning. Probably so my first day would have begun, had there been such an institution in reality. I will follow the advice and really start from the beginning.
In the beginning was a project
The fact that I am a startup, I did not find out right away. Quite a lot of time passed before the investor ran out of patience, and he sent us on a free swim. It was then that I found that emotional impulse in me to get up and say, “I'm a startup. Well, gentlemen, investors ... ". No, I’ll say right away that I’m not a bastard who is looking for investor funds as a way of banal mortal being. Before this voyage, I was actually the technical director. That is, I had such a simple and familiar product development process. The products are different, delicious and beautiful. But, while developing something really new and interesting, in the process it’s hard to watch how this “something” is being ruined by the disgusting sales process. It’s enough to say that under the influence of the magical power of persuasion, about 15 products were developed for completely different markets, which were folded into the table. No, I didn’t have the strength to look at it at all, so leaving for free swimming coincided with parting, bitter and wonderful, with a person who was engaged in sales.
So what do we have in the bottom line? Moral obligations to the person who sponsored this business - time. 15 solutions that have not found their buyer - two. A bunch of enthusiasm, hands and head. Startup, what's there.
To begin with, we analyze what we have and select a project. Soon the fairy tale affects, but not soon the customers are. In general, two more attempts were made to start selling products before we settled on the project that we have now. But in the end, the solution that was developed for the customer won (he even managed to buy a part). This was a solution that allowed you to control the parameters of the car and track its location. We decided to supplement it with a full-fledged diagnosis, expand the list of parameters that the device can receive, and present it in the form of a complex that helps to remotely diagnose a car on the road.
MVP (from the English. Minimum viable product - the minimum viable product) - the simplest working prototype of the product, which is tested demand before full-scale development. This approach insures the entrepreneur from the lack of demand for the final product and the loss of resources spent on the development. MVP allows you to gather information with minimal effort to modify the product to the needs of the target audience or completely abandon it.
The term MVP was coined by Frank Robinson, co-founder of SyncDev Consulting, in 2001. And it spread thanks to Steve Blank and Eric Rice - ideologists of customer development methodology. Actually, MVP has become part of this technique.
A tool for evaluating something that is not yet on the market (and developing such a product is actually the goal of a startup) is more than necessary and attractive. And in many books painted, for example, by the same Eric Rees. But! All the examples that are given there relate to the software part. Like a fig site on WordPress, we go around shops with shoes, and Herax - we got Zappos. They slurped a forum, printed pizza coupons - and founded Groupon. The bottom line is one - invest less, do with pens, check the value. Then optimize. We have a solution for remote car diagnostics and driver control. One weakly glues one with the other, right? Following the philosophy in the forehead, it was necessary to take a diagnostic complex and ride with a driver. At the same time solving the problem of a sour mine driver who is forced to behave well. I think
Knowing nothing about the MVP concept, but having rich (15 projects, Karl!) Experience on how NOT to be done, we intuitively avoided several mistakes that I later had the good fortune to observe with other projects:
We did not immediately make an iPhone
Of course, you can immediately try to develop a turnkey solution. What we did before that. In an atmosphere of strict secrecy, we sawed our pieces of iron, went through all stages of development and gave this product to sales. A damn lot of money was spent on this. During the development, it was possible to open a small taxi fleet with the funds that went into the development of products torn from the market. In the current solution, we are already tired of unreasonable expenses, therefore we blinded the solution from DevKits, seasoned with a small fraction of magic and a heap of wires. Our solution could kill the medium-sized moose, and when mounted in a car, the real problem was the lack of a trailer for its placement. But the main thing that was interesting to us was that anyone really needed it?
The piece of iron in every way met our expectations - the Chinese component regularly followed the precepts of the Great One. As you know, all electronics work on magical white smoke. If magical white smoke leaves the component, then it stops working. But it’s impossible to push the smoke back. So the craft, after a couple of weeks joyfully releasing a cloud of fragrant Kumar in our direction, went to the gates of Valhalla. Amazing in quality linear stabilizers. We did not think of taking money from customers, this saved us. The most important thing that we got is the feedback: "Guys, cool, we need it, it still would not burn out ..."
We did not inflate the staff
Although here, rather, the merit of limited development funds. If budgets allowed, we would probably, just like the rest, rush, happily screeching, hire specialists. Different. And more. In reality, the first version after the smoke-blown Chinese blocks cost us 15,000 to develop documentation for production and 20,000 to assemble five prototypes.
We did not work with China
When the board is designed, it is imperative to quickly produce a couple of pieces and test it. Will it work as you expected? With a probability of 99% - no. It will take several iterations to change the design of the board. And then - oh, a miracle! We recall that it would be cool to save money (of course, a whole staff of engineers is not cheap pleasure). Where is the Mecca of saving iron, the country of the budget soldering iron? For some reason, it’s not accepted to think about how much time logistics from China will take at each iteration. We were lucky again. Having specific experience working with China, including colleagues with whom we closely communicated, as well as experience working with miniature smoke machines, we did not even consider this option for ourselves. In addition, it was important for us to make a decision quickly and put it to the test.
We did not write a system for MCC
A solution for IoT is not only hardware, but also a server and client software. Still unaware of the MVP practices, we nonetheless turned around to the fullest. As a first approximation, our solution was written in just 2 months by the efforts of one person. And only after receiving real reviews, we began to refine the system, closing ineffective blocks and modifying the functionality.
In addition, we immediately laid the possibility of working through the API. The fact is that we planned to open access to it for all developers and build an ecosystem of services and software on it. This helped us to continue to actively work with code reuse during product upgrades.
It turned out something like this:
Ugums. Fantastic and straight from the doorway. We rolled back the device, woke up - bah! And on the street it’s already the turn. Komparks are on the same ruler, Boshes and Siemens are slowly discussing something in their VIP queue ... In fact, things got worse. An order of magnitude. We knew we made the right product. And this confidence was dictated by many people with whom we spoke. But everything was sold mainly by the method of prayer. It’s like in programming, when the code drunk works (at times), but there isn’t a clear understanding of why it works / doesn’t work. Even a clear idea of how it functions there within itself is not observed. There were several reasons for this:
From the very beginning, we did not begin to exchange ourselves on trifles. We went to exhibitions, but cheerfully made friends with manufacturers. We especially liked the dialogue with Kristina Dubinina, the curator of the Vesta project (looking ahead - a year of squats around the plant with very unhappy intentions didn’t bring anything. Nothing at all. It would be better if the intentions were disgusting.) - we like the decision and we need to collect statistics , and improve the quality, and in general. Everything rested in coordination with the department of additional equipment ... Further - finer. KamAZ (which successfully implemented the same in its ITIS. It seems to be), GAZ, UAZ. Rolf. Jenser. Thresh, fumes and sodomy. We rejoiced at these names as children. Brainless kids. Which fingers and thrust into the outlet. And even the experience of several successful sales to small parks did not set our brains. Idiots.
Techies sold to techies
Classics of the genre. Five hundred parameters, yes, we can, and so on. If to reduce to the point - to infinity, proud programmers sold technicians (who never make purchasing decisions) their own exclusiveness. We were assured of this exceptionality by the fact that one of the competitors, during the quarterly call, began to sell us to us. Our ChSV soared to heaven. Idiots.
Lack of focus
Another problem was that we got, in fact, a universal solution. Lada Kalina or five hundredth Liebher - we were equally good. As we thought. No, well, the fact that we could work with them was really wonderful. It’s still great. Our market is not truncated. But! We rushed along the entire line. We’ll try a little there. Then a little bit here. Let's try to do like this. Didn’t work out? Well, let's go to the next segment. Idiots.
Accelerator - to test a business model, but not to develop a prototype
In order to stop rushing between markets, structure sales, and reach a working business model before we put down our hooves, we went to the IIDF Accelerator. The attitude to the site is ambiguous, comparable, perhaps, with programming on the pluses. There are a lot of people who vehemently defend the vanilla of this programming language in spite of malicious and venomous attacks. Around the IIDF on these internet of yours, in a near-start-up party, the background develops in approximately the same scenario. In my purely personal opinion, IIDF just needs to be applied correctly. If you use the accelerator as a plug to any barrel and indiscriminately, then the effect will be exactly the opposite.
For a start - our story, in the end - about the correct application and dosage. So, we ended up in the IIDF in the 8th set. We got it like a portfolio startup, which means that we were not only given a bundle of valuable recommendations and magic pendels, but also dumped from the Russian bounty on the development of funds at the company's expense.
The first month was frankly hard. Firstly, the accelerator makes it work. Now I understand that this is the norm. Or it became the norm - I don’t know. But in the first month, the load level was similar to meeting a barrier in the dark - as deafening as it was effective. Secondly, there was a real misunderstanding why the nose is turned off from our "potential" customers. AvtoVAZ. No, well, AvtoVAZ! ”
During the first month, we puffed up for a week with big names and did not find such expected admiration in the eyes of the IIDF trackers, and finally began to do what we were asked to do - to test business models. In this first month, we went over the B2C, B2B, B2B2C, B2G models, allocating no more than a week for each. And then, with long debates, they made a turn of our original business concept.
Firstly, we stopped selling the tracker. We began to offer cost-saving subscription models. Secondly, we threw to the monks all segments except one - LCV (light commercial trucks). In it, we prescribed another 14 sub-segments and settled on the esophagus - they have the most pronounced pain, and the transaction cycle is not so long. As a result, in the second month of acceleration, we received the first income, and at the moment - we have increased sales by 4 times. The plan for June is 6 times.
Now about who the accelerator will be useful for. First of all, for teams that have some kind of product, there are unstructured transactions and who generally don’t know what to do next. The accelerator helps such companies to isolate and clearly prescribe value, find their niche, and provide a multiple increase in sales. Accelerator can help not only to turn a swan neck to an entrepreneur by highlighting a completely new approach to assessing product and value, but also quickly find contacts to test ideas, pack a project and check the economy. In addition, to stop massively hallucinating on current, often unconfirmed results. Accelerator helps launch first sales. Take them to a constant level and develop further. All this from the point of view of the lean manufacturing methodology. It seems to me pointless to try to apply the same approaches to a business that has become on the rails (excluding the situation when it comes to testing new business models, or when the business is faced with growth problems). Other laws and methodologies will apply. Axel's task is to work with the project at an early growth stage.
Also, an accelerator will be less useful to startups with a deep R&D component at the development stage. There are very few projects for which this is true, but they are. For example, related to algorithms based on artificial intelligence. If the project is under development, then the focus on sales can only do much harm, forcing to sell a product that needs to be finalized for another year. Yes, the value will be confirmed, but nothing will be transferred to the client, as well as closing this functionality with pens.
Apply correctly, and then only the warmest memories and thanks to the whole team that worked with your brainchild for three months will remain from the process.
And finally, there are three more things that, looking back, are mandatory for an IoT startup:
1.In an online startup without the “iron part”, crashes are easy to fix - the program will be updated at once for all users. In the "iron" startup, if our gadget is covered by the client, we are going to change / repair it. If the client is in Vladivostok - we board the plane and fly to Vladivostok. Therefore, IoT startups are better off running the first devices in their location, rather than immediately looking for customers around the world.
2.The main question when testing IoT startups: how can you compare testing MVP, assembled on the knee, and the finished device? There is no need to develop a board for MVP - to assemble a device from different modules, devkits, or ready-made blocks to close the functionality. The finished device is a completely different product according to the logic of work and the composition of the components. And even if MVP worked by some miracle for a month instead of the prescribed week, it is not a fact that the final device will be just as stable. To do this, having confirmed the demand using MVP, we drop everything and implement the finished device. It is important to start the test as early as possible. And do everything so that it does not interrupt. The sooner the device stops “putting on diapers” and requires a reboot for food every half hour, the more time you will have. If it burns out on the table or freezes due to an error in the code and a stack overflow, then at least you will clearly know how much time you have left before the call of an angry client)). For example, our piece of iron traveled more than one and a half million kilometers in tests, and this happened in parallel with the sales process before we gave it a green light.
3. It is very easy to pour millions of rubles into production, office and bloated staff by drawing a beautiful business plan, but these costs are far from always paid off. In my radical view, it is necessary to take away all the money from the founders and put it on a deposit - leave them a minimum budget for food and experiments, while demanding a product from them in three months. A team that is not able to collect MVP during this time is either developing an autopilot system (although in 3 months the “child” should already distinguish dad from mom and blow bubbles with his nose), or wasting time. In the event of a lack of funds, the team begins to think about how to test demand with a minimum budget, and finds a solution.
Announcement: Until June 23, IIDF accepts applications for the industry accelerator for projects from the Internet of Things sphere. This is an opportunity to work with large industry customers and accelerate the development of your business. Partners include Khanty-Mansiyskiy Otkrytie, GS Group, the Ministry of Emergencies (APK Safe City), the Ministry of Industry and Trade, and the Ministry of Construction.