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