Как сделать стартап и не cойти с ума: 25 инсайтов за два года

В декабре Checkaso исполнилось 2 года. Параллельно с развитием нашей ASO-платформы, мы многое поняли про стартапы и готовы поделиться опытом. Инсайтов случилось много больше, но расскажем самое важное. Главный, конечно же, прост – никогда не начинайте стартап. Шутка. А теперь серьезно.

Важно заранее выбрать подходящий стек технологий. Проверить, насколько он будет масштабируем, легко ли будет найти специалиста для его поддержки в будущем. Когда вы начнете расти, а специалисты будут меняться, могут возникнуть проблемы.

В первое время нужно фокусироваться на команде. Это самое главное. Сначала ты вкладываешься в команду, потом она приносит результаты. Нужно не бояться отказывать тем, в ком сомневаешься, ждать нужных специалистов. Берите только тех, кто влюблен в свое дело. Эта любовь будет транслироваться и конечному потребителю.

Дорожите своей репутацией с самого начала. Ее нужно взращивать и лелеять. Это важнейшее вложение. Если она будет плохой, ее будет сложно отмыть. У нас такого опыта нет, но я знаю проекты, которые с этим сталкивались. Такое бывает, если забывать про пользователей и думать в моменте лишь про деньги. В первую очередь нужно фокусироваться на пользователях, которые тебе эти деньги приносят.

Первые 2-3 года жизни проекта – самые напряженные. Это как с ребенком. Сначала ты совсем не спишь. А потом команда начинает втягиваться, ты больше делегируешь и появляется свободное время. Но и на самом старте нужно заботиться о себе, чтобы не выгореть.

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

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

Важно как можно раньше внедрять аналитику. Так вы сразу поймете, где теряете пользователей и насколько новые фичи соответствуют вашим ожиданиям (количество привлеченных пользователей и денег).

Если есть спад продаж, не стоит бросаться снижать цены. Нужно думать, как увеличить ценность продукта для пользователей.

Если вы чего-то не знаете, есть три пути. Первый – можно ждать специалиста, который знает. Не факт, что быстро найдется. Второй – самим погружаться в проблему, но можно закопаться. Третий – обратиться к посредникам. Это страшно и сложно в плане юридических согласований, но в итоге может оправдать все ожидания.

Нужно четко расставлять приоритеты. С одной стороны, от пользователей будут лететь баги. С другой стороны, нужно быстро релизить фичи. Мы берем сразу в работу только критические баги. Если пользователь может решить свою проблему иначе, подсказываем ему как. Может казаться, что задача с багом на 5 минут, но она сбивает фокус внимания.

Определите, что сейчас важно в первую очередь: чтобы все работало идеально или чтобы потребности пользователей были удовлетворены? Ведь когда вы делаете продукт вам нужно догнать конкурентов, отстраниться от них и предоставить пользователям основную функциональность.

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

Рассчитывайте стоимость фичей с самого начала. На этапе проектирования могут возникать споры, расширять или ограничивать какую-то фичу. А на этапе ретро может оказаться, что затраты были огромными, а нужного выхлопа вы не получили. Можно было сделать функциональность меньше, потратить меньше времени и денег и получить тот же самый результат. К тому же стоимость фичи тоже влияет на приоритеты.

Обязательно с самого начала взращивать культуру код-ревью – лучше с двумя апрувами. Это поможет сформировать «code style», который примет вся команда и позволит сформировать пул типичных решений – в проекты будет проще вникать новым людям. Соответственно, будет больше взаимозаменяемости. При этом свежий взгляд позволит отследить недочеты и избежать неоптимальных решений, сделанных под предлогом “это все равно никто не увидит”.

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

Техническая документация сократит количество ненужной коммуникации во время онбординга будущих сотрудников. Иначе придется тратить на объяснения личное время. Текст же можно перечитать. Стоит внедрять эту практику сразу. Потом это делать сложнее, ведь проектов становится много, а у всех в команде всегда самые срочные задачи. Новому человеку делегировать тоже не получится, ведь он не в курсе.

Каждый из команды должен быть взаимозаменяем. Сначала у нас было не так. Мы разделяли задачи на два типа: «платформа» и сбор и обработка данных. Первое время было здорово, ребята не отвлекались – каждый делал свое. Но потом это привело к разделению на два лагеря. Проблемы, которыми занимались одни, не были понятны другим. В итоге обе команды выгорели: и от однотипности задач и от внутренних конфликтов. Поэтому мы сделали рефреш и всех объединили. Сейчас у новичков новый флоу интеграции, они постепенно вникают в новые задачи. В итоге понимают, как устроено целое и имеют возможность переключаться между разными задачами.

Стремитесь создать легко масштабируемую систему с самого старта. Для начала нужно проанализировать, есть ли на рынке достаточно нужных специалистов. При этом нанимать тех, кто владеет самыми распространенными языками, не всегда лучшее решение. Специалисты дешевле, но тогда деньги уйдут в ресурсы – железо. Эффективность кода тоже будет страдать. Придется деньгами закидывать производительность. К тому же небольшие команды более эффективны в разработке. Больше сплоченности, личной ответственности и вовлеченности в продукт.

В стартапе особенно важно доверие внутри команды. Оно снижает уровень бюрократизированности всего процесса. Очень важно подбирать подходящих коллег, неравнодушных, с высоким уровнем самодисциплины. Это не про людей-исполнителей, которые просто ходят на работу отрабатывать свои часы.

Нужно быть готовым к тому, что видение продукта со временем может измениться. Сначала мы делали платформу для ASO-специалистов, зная по собственному опыту, что им нужно. Потом оказалось, что это слишком узкая аудитория. В нашей области много людей, не являющихся профессионалами, но нуждающихся в доступном функционале.

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

Больше тестировать и доверять данным, если есть такая возможность. Это поможет сэкономить ресурсы. К сожалению, у стартапов часто нет на это времени, потому что нужно быстро догонять конкурентов, которые на рынке уже давно.

С самого начала делать «открытые» фичи, чтобы их было легко расширить. На случай если появится необходимость что-то усложнить или добавить новый функционал. Иначе придется жертвовать новыми идеями или делать двойную работу, переделывая какой-то раздел. Это один из самых сложных моментов – продумывать все на несколько шагов вперед, оставлять пространство на будущее.

Учиться делать максимально понятные прототипы, чтобы процесс обсуждений не затягивался. На коммуникацию тратится очень много времени.

Заниматься развитием личного бренда, потому что тебя будут ассоциировать с продуктом.

Найти фичи, благодаря которым вы сможете выделиться среди конкурентов и при этом упростить жизнь пользователям. Для нас таким инструментом стала универсальная система индексов. Она позволяет быстро оценить разные стороны продвижения приложения. Начиналось же все с ASOindex – индекса, оценивающего качество оптимизации страницы приложения по многим параметрам. Когда мы его создали, подобного решения ни у кого не было. И этот функционал понятен абсолютно всем.

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

#aso #appstoreoptimization #маркетингприложений #оптимизацияприложений #asotools #мобильныймаркетинг