795 дней. Столько потребовалось нам, чтобы снять розовые очки и перестать играться в стартапы. В апреле 2015 года мы пошли на хакатон. Мы выиграли, получили $5 от первого клиента (все верно — 5 долларов от первого клиента — ред.) и решили, что теперь будем строить свою компанию. Наслушавшись рассказов про единорогов и методологии lean startups, мы решили, что через 3 месяца запустим первый MVP.
Создатели Flawless App — Ахмед Сулейман и Лиза Дзюба
Качественный платный продукт был запущен через 2 года. После пивота, двух инкубационных программ, полной смены команды, депрессий, разочарований и огромного количества работы. Сейчас Flawless App — это macOS-инструмент для сравнения дизайна с реальным мобильным приложением во время разработки. Продукт покупают без пробной версии, весь маркетинг — без бюджета, а поддержка и дальнейшая разработка продукта — без инвестиций.
Мы зафейлили все дедлайны и допустили неисчисляемое количество ошибок. Зато теперь нам есть что рассказать будущим поколениям ребят в розовых очках.
Не нужно посещать все стартап-ивенты подряд
Когда мы только начинали Flawless, то были воодушевлены практически всеми стартап-ивентами в Украине. Нам было важно попасть на каждый из них и обязательно показать себя. Разумеется, это требовало силы и время на подготовку. И часто это время затягивалось на недели, чтобы:
- узнать ФОКУС и специфику мероприятия;
- пообщаться с бывшими участниками;
- правильно написать питч;
- правильно сделать презентацию для определенного мероприятия;
- тренировать выступление;
- до мероприятия посетить парочку тренировочных встреч от организаторов;
- подготовиться к нетворкингу: собрать список интересных посетителей, компаний, других участников и так далее
Спустя какое-то время, когда мы посетили приличное количество таких мероприятий, стало понятно, что это было не так уж и полезно. Не потому что мероприятия были плохие, а потому что там не было нашей целевой аудитории. Усилия, которые были затраченные на подготовку, можно было направить на общение с потенциальными пользователями. Это принесло бы нам больше пользы, но разумеется меньше медийности и публичности.
Мы решили избегать мероприятий, которые не приносят нам пользу.
Много посетителей, много вопросов, но ни одной регистрации на продукт
Нанимай быстро – увольняй быстро
В какой-то момент нам понадобилось искать нового человека в команду. Очевидно, что это задача не из легких, особенно для молодого стартапа с удаленной командой. Мы выделили около трех месяцев на всю задачу целиком.
Как и всегда, мы подошли к поиску нужного человека крайне серьезно. Перед тем как начинать сам процесс поиска, мы долго решали функциональные обязанности, прописывали требования, готовили тестовые задания.
Мы разместили вакансию на топовых площадках и начали принимать заявки. С каждым из кандидатов мы проводили личные звонки-интервью. Спустя 1,5 месяца звонков, мы все-таки определились с теми несколькими претендентами, с которыми мы бы хотели работать. И выслали им тестовые задания. На тестовые задание мы выделили еще две недели. Потом столько же времени на проверку результатов и обратную связь всем кандидатам. И снова интервью.
Вакансия была довольно популярная. Мы продолжали получать заявки от сильных инженеров и все так же общались с новыми кандидатами.
В конечном итоге поиск сотрудника занял 4 месяца. И мы нашли идеального кандидата. Однако спустя пару недель он абсолютно честно сказал нам, что у него нет возможности продолжать с нами работу. Причина банальна: ему предложили лучшие условия. И безусловно, это вина не кандидата. Это первоначально наша вина, как основателей.
Если бы мы не тратили так много времени на уровни проверки (первое интервью, тестовое задание, второе интервью и так далее) в погоне за идеальным человеком, мы бы быстрее закрыли эту задачу. И в случае, если нас или кандидата что-то не устраивало, мы бы точно так же быстро разошлись.
Нет приоритетов – нет результата
На протяжении трех недель после хакатона мы занимались лишь общением с потенциальными пользователями. Чтобы подтвердить, что продукт, который мы намереваемся делать, кому-то нужен и мы решаем реальную проблему.
Сразу после этого мы начали определять задачи и прорабатывать план действий. Мы прописали подробные задачи на ближайший месяц и высокоуровневое видение задач на 4 месяца вперед.
На тот момент для их ведения мы использовали Wunderlist. И вовсе не задумывались о том, что необходимо просчитать, какая задача сколько времени займет и на когда ее надо сделать. Подход был такой: «Задача поставлена – задачу надо сделать как можно раньше. Критично! На вчера!».
В конечном итоге это вылилось в неприятную ситуацию. Ребята старались в поте лица за ночь закрыть какую-то «важную» задачу. На следующий день выяснилось, что на нее есть еще как минимум неделя и она совсем не критична. Это очень демотивирует и не способствует работе.
Если бы мы сразу приоритезировали задачи и потратили время на оценку времени их выполнения, то этого случая можно было бы избежать.
Офис не критично – процессы критичны
Первым офисом для нас стала квартира Лизы (Лиза Дзюба — одна из создателей Flawless App), где мы обосновались на 2 месяца. Там мы полностью провели валидацию рынка и продумали план дальнейших действий. Но дальше нам пришлось работать длительное время удаленно.
На тот моменту у нас не было никаких процессов работы и все происходило достаточно хаотично. Вроде бы все знали что делать, но не было информирования в реальном времени о том, кто и что уже сделал и какие возникали сложности на пути. Это существенно замедляло работу, поскольку постоянно приходилось запрашивать информацию лично у человека.
Поэтому мы ввели вечерние статус-звонки на 5 минут. Ежедневно вся команда созванивалась и каждый отвечали на три простых вопроса:
- Что сделал/сделала сегодня?
- Что буду делать завтра?
- Что помешало, какие сложности?
Теперь стало понятно кто и что сделал за день. Если возникали проблемы, мы могли их оперативно решать вместе. Дальше мы улучшали эту систему, начали записывать все статусы и смотреть какая динамика работы у каждого в команде — эдакий командный KPI.
Пользователи должны участвовать в продуктовых решениях
Как приличные стартаперы, мы провели валидацию рынка перед тем как приступать к разработке. Около трех недель мы уделили только на общение с потенциальными пользователями. И по специфике нашего продукта собрали всех знакомых (и незнакомых) нам людей из этих трех категорий:
- Продуктовые компании (большие и маленькие),
- Outsource-компании (большие и маленькие),
- Фрилансеры.
Также в этой выборке мы учитывали разные страны. В фокусе были Европа и США, но и с азиатскими разработчиками мы тоже общались. Суммарно мы провели интервью с более чем 300 разработчиками из всех категорий и стран, которые нам были интересны. Неделя ушла на анализ этой информации. Еще неделя — на составление продуктового плана и пару дней, чтобы отбросить лишнее. И вот у нас готовы задачи для первой версии продукта.
Звучит хорошо, верно? Очень хорошо! Но мы забыли учесть, что такие интервью с пользователями надо проводить параллельно с разработкой, а не единожды в начале.
Когда первая итерация продукта была готова, мы запустили закрытую бету среди наших первых подписчиков. Спустя пару месяцев активного общения и сбора фидбека стало ясно, что что-то не так. Люди указывали нам на очевидные недостатки продукта, которые мы упустили. И почему он не вяжется в текущие рабочие процессы разработчика.
Жаль только, что это озарение снизошло к нам, когда продукт уже был готов. Мы увязли в разработке сразу после первой валидации.
Если бы мы продолжили проводить интервью хотя бы каждую неделю, то мы бы заметили раньше, что первая итерация – проблемная.
Встреча с нашими пользователями на самом релевантном для нас мероприятии — CocoaHeads Kyiv.
Первое MVP не делается 10 месяцев
Продолжая предыдущую историю. Первая итерация продукта была крайне массивной и требовала навыков многих людей. На тот момент сервис состоял из:
- плагина для среды разработки Xcode;
- плагина для графического редактора Sketch;
- плагина для iOS-симулятора;
- веб-приложения;
- API, чтобы соединить все составляющие.
Мы принялись искать нужных нам разработчиков. Какая-то часть сервиса при этом была уже готова.
Где-то в этот момент мы прошли одновременно в две equity-free акселерационные программы: Lisbon Challenge и Startup Sauna. На 3 и 1 месяца соответственно. Я отправился в Португалию, а Лиза – в Финляндию. Командная работа стала в разы сложнее из-за разницы во времени и отсутствия налаженных коммуникаций.
День за днем мы понимали: еще немного и продукт будет готов. Но, как это всегда бывает, это «немного» затягивается на неопределенный срок. Вследствие бесконечных правок и доработок, первую итерацию продукта мы делали около 10 месяцев.
Основная идея MVP – быстро сделать продукт, готовый к продажам. Чтобы постепенно, версия за версией, улучшать его. Но у нас MVP заняло почти год. Справедливости ради, стоит упомянуть, что следующую итерацию продукта мы переделали за 14 дней!
Подпись: Flawless App в Startup Sauna
Метрики надо использовать
На момент запуска первой закрытой беты у нас была настроена аналитика. Не только на сайте, но во всех составляющих сервиса.
Сразу после запуска все графики роста пошли вверх. Но спустя какое-то время активность использования продукта начала стремительно падать. У нас не было проанализированных сведений активности за прошлые недели. Не было данных кто какую версию продукта использует и в какой момент возникают сложности. Без прямого контакта с пользователями выяснить причину этого спада было невозможно.
Мы добавили аналитику, но совершенно упустили момент, как с этой аналитикой работать дальше. Как показатели трафика могут нам указать, какие каналы работают хорошо, а какие – нет. Или где в самом приложении проблемные и непонятные места, которые требуют внимания.
Если бы мы настроили аналитику учитывая действительные показатели, то сэкономили бы себе много времени. В частности, раньше осознали бы почему продукт не решает проблему и как это исправить.
В конечном итоге, мы выяснили ту же информацию посредством личных интервью с пользователями. Но такой подход, разумеется, требовал большего времени.
Автор: Ахмед Сулейман, сооснователь Flawless App