Наші граблі у запуску hardware-стартапу — пошук бізнес-моделі і розробка MVP у сфері «інтернет речей»

image

Дисклаймер:
Internet of Things — круто, цікаво і на гребені хвилі світових трендів. Про те, як пройтися по граблях, втопити на проект коштів на придбання маленького парку іномарок, що є MVP і яке він має відношення до залозу, як програміст стає продавцем — під катом.

— Привіт, мене звати Олександр, я стартапер.
— Привіт, Олександре, — безладно відповів зал.

Бачачи явні труднощі, керівник центру анонімних стартаперів запропонував розповісти з самого початку. Напевно так починався мій перший день, якби подібний заклад в дійсності. Я піду раді і дійсно почну з початку.


На початку був проект

Про те, що я стартапер, я дізнався не відразу. Пройшло досить багато часу, перш ніж у інвестора урвався терпець, і він відправив нас у вільне плавання. Саме тоді я і знайшов у собі той душевний порив, щоб встати і сказати «я ж стартап. А ну, панове інвестори...». Ні, відразу скажу — я не сволота, яка займається пошуком інвесторських коштів як способу банального людського буття. Перед цим плаванням я взагалі-то був технічним директором. Тобто на мені був такий простий та звичний процес розробки продуктів. Продуктів різних, смачних і прекрасних. Але, розробляючи щось дійсно нове і цікаве, в процесі важко спостерігати за тим, як це «щось» нищать огидним процесом продажів. Досить сказати, що під дією чарівної сили переконання було розроблено близько 15 продуктів для абсолютно різних ринків, які були складені в стіл. Немає сил дивитися на це не було зовсім, тому догляд у вільне плавання збігся з розставанням, гірким і прекрасним, з людиною, який займався продажами.

Отже, що ми маємо в сухому залишку? Моральні зобов'язання перед людиною, яка це справа спонсорував, — раз. 15 рішень, які так і не знайшли свого покупця — два. Купу ентузіазму, руки і голову. Стартапер, че вже там.

Для початку — аналізуємо що є і вибираємо проект. Скоро казка мовиться, та не скоро клієнти знаходяться. У загальному підсумку було зроблено ще дві спроби почати продажі продуктів, перш ніж ми зупинилися на тому проекті, який маємо зараз. Але в кінцевому підсумку перемогло рішення, яке було розроблено під замовника (він навіть примудрився частина купити). Це було рішення, яке дозволяло контролювати параметри роботи автомобіля і відстежувати його розташування. Ми вирішили доповнити його повноцінної діагностикою, розширити список параметрів, які може отримувати пристрій, і уявити у вигляді комплексу, який допомагає віддалено діагностувати автомобіль в дорозі.

Довідка:
MVP (від англ. minimum viable product — мінімально життєздатний продукт) — найпростіший працюючий прототип продукту, яким тестують попит до повномасштабної розробки. Такий підхід страхує підприємця від незатребуваності кінцевого продукту і втрати витрачених на розробку ресурсів. MVP дозволяє мінімальними зусиллями зібрати інформацію, щоб доопрацювати продукт під запити цільової аудиторії або зовсім від нього відмовитися.
Термін MVP ввів співзасновник консалтингової компанії SyncDev Френк Робінсон у 2001 році. А він поширився завдяки Стіву Бланку і Еріку Райсу — ідеологам методології customer development. Власне, MVP став частиною цієї методики.

Інструмент для оцінки чого-те, чого ще немає на ринку (розробка такого продукту власне і є мета стартапу) — річ більш ніж потрібна і приваблива. І в багатьох книгах розписана, наприклад, у того ж Еріка Рису. Але! Всі приклади, які наводяться там, стосуються софтової частини. Типу фигачим сайтик на вордпрес, обходимо магазини з взуттям, і херакс — у нас вийшов Zappos. Зляпали форум, надрукували купонів на піцу — і заснували Groupon. Суть зводиться до одного — вкладайте менше, робіть ручками, перевіряйте цінність. Потім вже оптимізуйте. У нас рішення для віддаленої діагностики авто і контролю водіїв. Досить слабо клеїться одне з іншим, вірно? Слідуючи філософії в лоб, треба було брати діагностичний комплекс і їздити з водієм. Заодно вирішуючи проблему кислої міни водія, який змушений вести себе добре. Думаю, що за півгодини такого тріпу в світі в принципі не залишилося б небезпечних професій.

Нічого не знаючи про концепції MVP, але маючи багатющий (15 проектів, Карл!) досвід того, як НЕ треба робити, ми інтуїтивно уникли кількох помилок, які потім я мав щастя спостерігати у інших проектів:

Ми не стали одразу робити айфон
Звичайно, можна спробувати розробити готове рішення. Що ми і робили до цього. В обстановці найсуворішої таємності ми пиляли наші залізяки, проходили всі етапи розробки і віддавали цей продукт сейлзам. На це витрачалися чортова сила-силенна грошей. За час розробок можна було відкрити свій маленький парк таксі на ті кошти, які пішли на розробку продуктів, відірваних від ринку. У поточному рішенні ми вже втомилися від необґрунтованих витрат, тому зліпили рішення з DevKit-ів, приправлених маленькою часткою магії і купою дротів. Нашим рішенням можна було вбити середнього розміру лося, а при монтажі в автомобіль виникала реальна проблема відсутності причепа для його розміщення. Але основне, що нам було цікаво — це взагалі комусь треба?

Залізяка всіляко виправдала наші очікування — китайський компонент справно слідував заповітам Великого Кромчего. Як відомо, вся електроніка працює на чарівному білому димі. Якщо чарівний білий дим виходить з компонента, то він перестає працювати. А запхати дим назад не виходить. Ось і саморобка, через пару тижнів радісно випустивши в нашу сторону хмарка запашного кумара, вирушила до брами Вальгалла. Підвели дивовижні за якістю лінійні стабілізатори. Ми не додумалися взяти з клієнтів гроші, це нас і врятувало. Найважливіше, що ми отримали — це зворотний зв'язок: «Хлопців, круто, нам це треба, от ще б не згорало...»

Ми не стали роздувати штат
Хоча тут, швидше, заслуга обмежених коштів на розробку. Якщо б дозволили бюджетів, ми б напевно точно так само, як і інші, понеслися, радісно повискуючи, наймати фахівців. Різних. І багато. Насправді ж, перша версія після фонтануючих димом китайських блоків обійшлася нам у 15.000 на розробку документації для виробництва і 20.000 — на збірку п'яти прототипів.

Ми не стали працювати з Китаєм
Коли плата спроектована, вкрай важливо швидко зробити пару штук і протестувати. Чи буде вона працювати так, як ти думав? З ймовірністю 99% — ні. Буде потрібно кілька ітерацій по зміні дизайну плати. І тут — о диво! Ми згадуємо про те, що було б круто заощадити грошей (звичайно, цілий штат інженерів — задоволення не з дешевих). Де Мекка економії железячной, країна паяльника бюджетного? Про те, скільки часу займе логістика з Китаю на кожну ітерацію, замислюватися чомусь не прийнято. Нам знову пощастило. Маючи специфічний досвід роботи з Китаєм, у тому числі і колег, з якими ми тісно спілкувалися, а так само досвід роботи з мініатюрними дымомашинами, ми не стали навіть розглядати цей варіант. Крім того, нам важливо було зробити рішення швидко і поставити його на тест.

Ми не стали писати систему для ЦУПа
Рішення для IoT — це не тільки залізо, але і сервер і клієнтське ПЗ. Так само перебуваючи в невіданні щодо практик MVP, ми, тим не менш, розгорнулися тут на повну котушку. Наше рішення в першому наближенні було написано всього за 2 місяці зусиллями однієї людини. І тільки отримавши реальні відгуки, ми почали допрацьовувати систему, закриваючи неефективні блоки і допрацьовує функціонал.
Крім цього, нами відразу була закладена можливість роботи через API. Справа в тому, що ми планували відкрити до нього доступ всім розробникам і побудувати на ньому екосистему з сервісів і ПО. Це допомогло нам надалі активно працювати з повторним використанням коду під час модернізацій продукту.

Вийшло приблизно ось так:
image

Успіх?
Угумс. Фантастичний і прям з порога. Відкатали ми пристрій, прокинулися — ба! А на вулиці вже черга. Компарки по одній лінієчці стоять, Боші з Сименсами у своїй віп-черги щось неспішно обговорюють… насправді, все стало гірше. На порядок. Ми знали, що зробили потрібний продукт. І ця впевненість була продиктована багатьма людьми, з якими ми спілкувалися. Але продавалося все в основному методом молитви. Це як у програмуванні, коли написаний по п'яні код працює (часами), але при цьому немає не те що чіткого розуміння, чому він працює/не працює. Навіть чіткого уявлення про те, як він там всередині себе функціонує, не спостерігається. Причин тому було декілька:

Магія брендів
Ми з самого початку не стали розмінюватися на дрібниці. Ми пішли по виставкам, так бадьоро так подружилися з виробниками. Особливо нам сподобався діалог з Христиною Дубініної, куратором проекту «Веста» (забігаючи вперед — рік присідань навколо заводу з дуже навіть не такими намірами не приніс нічого. Взагалі нічого. Краще б наміри були такими.) — і рішення подобається, і статистику збирати треба, і підвищувати якість, і взагалі. Все вперлося в узгодження з відділом допоборудования… Далі — більше. КамАЗ (який благополучно реалізував те ж саме у своєму ИТИСе. Начебто), ГАЗ, УАЗ. Рольф. Дженсер. Треш, угар і содомія. Ми раділи цим іменам як діти. Безмозкі діти. Які і пальці в розетку засунуть. І навіть досвід кількох успішних продажів невеликим паркам не вправляв нам мізки. Ідіоти.

Технарі продавали технарям
Класика жанру. Стопятьсот параметрів, та ми і так можемо, і сяк. Якщо скоротити до суті — до нескінченності горді собою програмісти продавали технарям (які жодного разу не приймають рішення про покупку) власну винятковість. У цій винятковості нас запевняв ще й те, що один з конкурентів під час квартального викликів почав нам продавати нас. Наше ЧСВ злетіла до небес. Ідіоти.

Відсутність фокусу
Ще однією проблемою стало те, що у нас вийшло, за фактом, універсальне рішення. Лада Калина або пятисоттонник Лібхер — нам було однаково добре. Як ми думали. Ні, ну те, що ми могли з ними працювати, було справді чудово. До цих пір чудово. Наш ринок не усічений. Але! Ми металися по всій лінійці. Трохи спробуємо там. Потім трошки тут. Спробуємо зробити ось так. Не вийшло? Ну підемо в сусідній сегмент. Ідіоти.

Акселератор — для перевірки бізнес-моделі, але не для розробки прототипу

Щоб перестати кидатися між ринками, структурувати продажу і добігти до робочої бізнес-моделі перш, ніж ми відкинемо копита, ми пішли в Акселератор ФРИИ. Ставлення до майданчику — неоднозначне, можна порівняти, мабуть, з програмуванням на плюсах. Є купа народу, який палко відстоює ванильность цього мови програмування всупереч злісним і уїдливим нападкам. Навколо ФРИИ в цих ваших інтернетах, в околостартаперской тусовці, фон розвивається приблизно за таким же сценарієм. На мій суто особистий погляд ФРИИ треба просто правильно застосовувати. Якщо ж використовувати акселератор як затичку до будь-якій бочці і без розбору, то ефект буде абсолютно протилежним.

Для початку — наша історія, в кінці — про правильність застосування та дозування. Отже, ми потрапили під ФРИИ у 8-й набір. Потрапили як портфельний стартап — це означає, що нам не тільки видали пачку цінних рекомендацій і чарівних пенделей, але і відсипали від щедрот російських на розвиток коштів на рахунок компанії.

У перший місяць було відверто важко. По-перше, акселератор змушує працювати. Зараз я розумію, що це норма. Чи стало нормою — не знаю. Але в перший місяць рівень навантаження був подібний до зустрічі з шлагбаумом в темряві — настільки ж оглушителен, як і дієвий. По-друге, було реальне нерозуміння, чому вернуть носа від наших «потенційних» клієнтів. «АвтоВАЗ. Не, ну АвтоВАЗ ж!».

Протягом першого місяця ми, тиждень попыжившись з гучними іменами і не знайшовши такого очікуваного захоплення в очах трекерів ФРИИ, почали нарешті робити те, що у нас і просили — тестувати бізнес-моделі. У цей перший місяць ми пробіглися по моделям B2C, B2B, B2B2C, B2G, виділяючи на кожну не більше тижня. А потім, з довгими суперечками, зробили поворот нашої початкової концепції бізнесу.

По-перше, ми перестали продавати трекер. Ми почали пропонувати по моделі підписки скорочення витрат. По-друге, ми повикидали до монахів всі сегменти, крім одного — LCV (легкі комерційні вантажівки). В ньому ми прописали ще 14 подсегментов і зупинилися на піщевке — у них найбільш яскраво виражена біль, а цикл угоди не такий довгий. У підсумку на другому місяці акселерації ми отримали перший прибуток, а на поточний момент — збільшили продажі в 4 рази. План на червень — в 6 разів.

Тепер про те, для кого буде корисний акселератор. Перш за все — для команд, у яких є якась подоба продукту, є неструктуровані угоди і які взагалі не знають, що робити далі. Акселератор допомагає таким компаніям вичленувати і чітко прописати цінність, знайти свою нішу, забезпечити кратний зростання продажів. Акселератор може допомогти не тільки згорнути лебяжью шийку підприємцю, висвітливши абсолютно новий підхід до оцінки продукту і цінності, але і швидко знайти контакти для перевірки ідеї, упакувати проект і перевірити економіку. Крім цього — перестати масово галлюцинировать на поточні, часто нічим не підтверджені результати. Акселератор допомагає запустити перші продажі. Вивести їх на постійний рівень і розвиватися далі. Все це — з точки зору методології бережливого виробництва. Мені здається безглуздим намагатися застосовувати ті ж підходи до який став на рейки бізнесу (виключаючи ситуацію, коли мова йде про тестування нових бізнес-моделей, або коли бізнес зіткнувся з проблемами росту). Там будуть діяти інші закони та методології. Завдання акселя — працювати з проектом на стадії раннього зростання.

Також акселератор буде менш корисний стартапам з глибокої R&D складової на стадії розробки. Проектів, для яких це справедливо, дуже мало, але вони є. Наприклад, пов'язаних з алгоритмами на основі штучного інтелекту. Якщо проект в стадії розробки, то фокус на продажу може тільки нашкодити, змусивши продати продукт, який потрібно допрацьовувати ще рік. Так, цінність буде підтверджена, але передати клієнтові нічого не вийде, так само як і закрити ручками цей функціонал.

Застосовуйте правильно, і тоді від процесу залишаться тільки найтепліші спогади і подяку всій команді, яка працювала з твоїм дитям протягом трьох місяців.

І наостанок — ще три речі, які, озираючись назад, обов'язкові для IoT-стартапу:

1. В інтернет-стартап без «залізної частини» збої легко поправити — програма оновиться разом у всіх користувачів. У «залізному» стартапі якщо наш гаджет у клієнта накрився — ми їдемо змінювати/лагодити його. Якщо клієнт у Владивостоці — ми сідаємо в літак і летимо у Владивосток. Тому IoT-стартапам краще обкатувати перші пристрої у своїй локації, а не шукати відразу клієнтів по всьому світу.

2. Основне питання при тестуванні IoT-стартапів: як можна порівнювати тестування MVP, зібраного на коліні, і готового пристрою? Для MVP можна не розробляти плату — зібрати пристрій з різних модулів, devkit'ів або готових блоків, щоб закрити функціональність. Готове пристрій — абсолютно інший продукт за логікою роботи і складом компонентів. І навіть якщо MVP пропрацював якимось дивом місяць замість покладеної тижня, не факт, що фінальне пристрій буде настільки ж стабільним. Для цього, підтвердивши попит з допомогою MVP, ми кидаємо все і реалізуємо готове пристрій. Важливо якомога раніше почати тест. І зробити все, щоб він не переривався. Чим раніше пристрій перестане «одягати підгузники» і вимагати ребут по харчуванню кожні півгодини, тим більше у вас буде часу. Якщо воно згорить на столі або зависне через помилки в коді і переповнення стека, то ви, принаймні, будете чітко знати, скільки часу у вас залишилося до дзвінка розсердженого клієнта)). Наприклад, наша залізка проїхала на тестах більше півтора мільйонів кілометрів, причому це відбувалося паралельно процесу продажів, перш ніж ми дали їй зелене світло.

3. Дуже легко злити мільйони рублів на виробництво, офіс і роздутий штат, намалювавши гарний бізнес-план, але далеко не завжди ці витрати окупаються. На мій радикальний погляд, треба відбирати у засновників всі гроші і класти їх на депозит — залишити їм мінімальний бюджет на їжу та експерименти, при цьому вимагати з них продукт через три місяці. Команда, яка не здатна за цей час зібрати MVP, або розробляє систему автопилотирования (хоча за 3 місяці «дитя» має вже відрізняти тата від мами і пускати бульки носом), або даремно витрачає час. У разі нестачі коштів команда починає думати, як протестувати попит з мінімальним бюджетом, і знаходить рішення.

___________________________________________________________________________

Анонс: До 23 червня ФРИИ приймає заявки галузевої акселератор для проектів зі сфери «інтернет речей». Це можливість попрацювати з великими галузевими замовниками та прискорити розвиток свого бізнесу. У числі партнерів — «ХМБ Відкриття», GS Group, МНС (АПК «Безпечне місто»), Мінпромторг, Мінбуд.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.