Дисклаймер:
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. Дело в том, что мы планировали открыть к нему доступ всем разработчикам и построить на нем экосистему из сервисов и ПО. Это помогло нам в дальнейшем активно работать с повторным использованием кода во время модернизаций продукта.

Получилось примерно вот так:

Успех?

Угумс. Фантастический и прям с порога. Откатали мы устройство, проснулись — ба! А на улице то уже очередь. Компарки по одной линеечке стоят, Боши с Сименсами в своей вип-очереди что-то неспешно обсуждают… На самом деле, все стало хуже. На порядок. Мы знали, что сделали нужный продукт. И эта уверенность была продиктована многими людьми, с которыми мы общались. Но продавалось все в основном методом молитвы. Это как в программировании, когда написанный по пьяни код работает (временами), но при этом нет не то что четкого понимания, почему он работает/не работает,. Даже внятного представления о том, как он там внутри себя функционирует, не наблюдается. Причин тому было несколько:

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

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

Отсутствие фокуса
Еще одной проблемой стало то, что у нас получилось, по факту, универсальное решение. Лада Калина или пятисоттонник Либхер — нам было одинаково хорошо. Как мы думали. Нет, ну то, что мы могли с ними работать, было действительно прекрасно. До сих пор прекрасно. Наш рынок не усечен. Но! Мы-то метались по всей линейке. Чуть-чуть попробуем там. Потом немножко тут. Попытаемся сделать вот так. Не вышло? Ну пойдем в соседний сегмент. Идиоты.

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

Чтобы перестать метаться между рынками, структурировать продажи и добежать до рабочей бизнес-модели прежде, чем мы откинем копыта, мы пошли в Акселератор ФРИИ. Отношение к площадке — неоднозначное, сравнимо, пожалуй, с программированием на плюсах. Есть куча народу, который яро отстаивает ванильность этого языка программирования вопреки злобным и язвительным нападкам. Вокруг ФРИИ в этих ваших интернетах, в околостартаперской тусовке, фон развивается примерно по такому же сценарию. На мой сугубо персональный взгляд ФРИИ надо просто правильно применять. Если же использовать акселератор как затычку к любой бочке и без разбору, то эффект будет абсолютно противоположным.

Для начала — наша история, в конце — о правильности применения и дозировке. Итак, мы попали во ФРИИ в 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, МЧС (АПК «Безопасный город»), Минпромторг, Минстрой.