«Мы делали стартап два года»: 7 советов молодым стартаперам от украинской команды Flawless App

20813
32

Бета-версия сервиса Flawless App — инструмента для сравнения дизайна с реальным мобильным приложением во время разработки — была запущена в 2015 году. Только спустя более двух лет его создатели, Ахмед Сулейман и Лиза Дзюба, выпустили полноценный продукт. За это время они поучаствовали в двух акселерационных программах, дважды сделали пивот, потеряли 80% сотрудников, но все же смогли провести публичный запуск инструмента. Также сегодня проект запустился на Product Hunt. Ахмед Сулейман по просьбе AIN.UA рассказал об ошибках, которые допустила команда во время работы над инструментом, и дал советы молодым предпринимателям.  

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

Оставить комментарий

Комментарии | 32

  • Дякую, цікава стаття, пишіть ще про ваш досвід.

  • Молодцы. Радует, что честно и с полным осознанием ошибок. На 90% у нс такая же ситуация:)
    Такое ощущение, что статья не закончена
    Ребята, вам удачи, вы молодцы!

  • Отличная статья, спасибо! Хотелось бы в общих чертах узнать о маркетинге — что и на каком этапе лучше всего работало?

    • Спасибо! ?
      Лиза как раз будет вести доклад на эту тему (Как искать первых пользователей, какие канали лучше работали и небольшая статистика с нашего опыта) на ближайшем Cocoaheads Kiev (22 Июля)

      Приходите, будем рады пообщаться ?

      • И снова участие в мероприятиях, медийная активность? Вы же сами предостерегаете.

        • Не так всё однозначно, это смотря какое мероприятие ?
          Cocoaheads для нас крайне важное мероприятие, там мы общаемся с пользователями и ЦА, слушаем их проблемы и получаем релевантный фидбек по продукту и вообще.

          Мы же написали:
          >Мы решили избегать мероприятий, *которые не приносят нам пользу*

          А Cocoaheads приносит очень большую пользу и душевную, и конструктивную.

          • Ну успехов в поиске клиентов там. Просто ИМХО важнее делать доклады о продукте. А доклад «Как искать клиентов» — это больше PR человека, чем проекта. Хотя… в общем удачи.

          • С другой стороны «доклад о продукте» – это PR продукта 🙂
            И чисто PR продукта может и не принести много value для слушающего, а тогда зачем слушать доклад если не ради пользы.
            На самом деле, всё относительно. Нельзя сказать однозначно что «это плохо», а «это хорошо».

            В любом случае, спасибо еще раз за поддержку!)

          • Доклад будет построен на примере продвижения Flawless App без бюджета. Много iOS & macOS инженеров разрабатывают side-projects, которые не знают как продвигать.

            Мы расскажем:
            * как найти первых бета-тестеров для iOS & macOS продуктов
            * как превратить тестеров в лояльных пользователей
            * как работать с комьнити и лидерами мнений
            * где брать релевантный траффик
            * как запустить платный продукт

            ? За два года мы попробовали огромное количество маркетинговых инструментов, которые не требуют денег 🙂 Очень многое из нашего опыта применимо для других dev тулзов. У меня даже есть огромная GitHub коллекция статей по маркетингу для техн. проектов: https://github.com/LisaDziuba/Marketing-for-Engineers

            Посетители CocoaHeads — это наши друзья, юзеры, тестеры или люди, которые помогали нам ?. Теперь мы можем помочь комьюнити, открыто рассказав про наш кейс с реальными цифрами и примерами.

  • Интересный рассказ. А был у вас до начала работы опыт промышленной разработки ПО? Незнание некоторых вещей выглядит несколько странно (изобретение стендап-митингов, приоретизация задач)

    • Спасибо за фидбек!

      Разумеется, опыт был. Но могу сказать однозначно, что это разные вещи:
      1. Когда ты работаешь у кого-то, где процессы налажены хорошо (ты о них не задумываешься особенно)
      2. И когда ты строишь эти процессы сам. Работая с командой, и т.д

      Мы знали о популярных методологиях, знали о «супер Agile», «волшебном Scrum-е» и подобных. Но для нас знания о процессах оказалось мало. Надо было знать как их внедрить и начать использовать, чтобы они приносили пользу.

      Не могу сказать, что это утверждение справедливо для всех, но мы описали наш слуай.

  • Интересная статья, спасибо )
    ЗЫ А среди читателей достаточно целевой аудитории чтобы стоило её писать? ))

    • Спасибо!)

      А эта статья прежде всего для людей, которые, как и мы два года назад загорелись како-то идеей и воплощают её в жизнь. Дело в том, что мы эти ошибки хранили у себя для себя, чтобы не забывать. Теперь статья однозначно поможет помнить о них и дальше 🙂

    • Если честно, то целевой аудитории среди читателей не так уж много 🙂
      Статью мы написали очень быстро, без отрывов от основных задач. Как говорил Ахмед, у нас все эти ошибки были уже записаны.

      Также вчера мы запускались на Product Hunt и на нас поставили линк сверху статьи 🙂

  • Успехов вам, интересная статья!

  • спасибо за статью! Вы пишите что провели 300 интервью с разработчиками, а сколько человек отклонило вашу просьбу пообщаться? И какие каналы связи при этом использовались (соц сети и т.д.)?

    • Спасибо! Рад, что статья понравилась)

      На самом деле, первые 300 людей с которыми мы провели общение, 20- 30% были нашими знакомыми, с остальными мы так или иначе общались на протяжении какого-то времени. Это были не совсем холодные предложения всем подряд с просьбой провести интервью. Мы категоризировали людей на отрасли, страны, уровень человека и т.д. Поэтому очень большое количество согласились участвовать в нашем звонке.

      Для совсем холодных предложений, которые мы делали позже, процент отказов был примерно 60%

      По каналам связи:
      Лучше всего в самом начале для нас работал facebook и релевантные для нас группы. Далее twitter и linkedin. Также хорошо работали закрытые релевантные Слак группы и Реддит.

  • Ощущение, что мысль не закончена, и статья обрывается.
    Давайте продолжение)

  • Я думаю у вас в загашниках осталось еще процентов 90% нераскрытых нюансов(по себе знаю)
    Статья отличная, как и проект и вы ребята. Удачи и успехов)

  • та же ерунда была и у нас с проектом, пока в сикорский-челендж (это акселератор кпи) не встретили ментора (спасибо огромное Егору Шишенку) который за один день мало того что снял с нас розовые очки та еще и помог расписать пошагово что нужно сделать и сколько на это уйдет денег

    • Я знаю про сикорский-челендж 🙂

      Менторы могут помочь расставить приоритеты и указать на неочевидные вещи. Вот нам очень помог Роб с Techstarts Berlin, который усердно говорил про срочный запуск продаж. Наверное, учитель приходит тогда, когда ученик готов )))

  • Спасибо за интересную статью! Знакомые грабли 🙂 Такое ощущение, что про них читать бесполезно — всё равно пока сам шишки не набьёшь — советы других слушать не получается…
    Такие вопросы у меня:
    1) Плучается, вы поступили в акселераторы даже без MVP, я правильно понял?
    2) Раз искали сотрудников в штат, значит у вас был некий бюджет на разработку. Это свои средства?
    Спасибо.

Поиск