3 ошибки, которые лучше не совершать при запуске продукта

Меня зовут Василий Крылов, я один из основателей сервиса автопостинга SMMplanner. Изначально эту статью хотел назвать «Ошибки при запуске стартапа», но себя я никогда стартапером не считал – наш сервис начинался без инвестиций, питчингов и презентаций. Мы увидели нишу, заняли ее и уже 8 лет в ней работаем. За это время накопился определенный опыт – им и поделюсь.

Забить на исследование перед запуском

Первая ошибка – очевидная, но все же: забыть проверить работоспособность идеи до того, как она будет реализована и выпущена на рынок. 

Когда мы запускались в 2014 году, не опрашивали SMM-щиков, каким должен быть сервис автопостинга, а сделали его таким, каким видим сами. Я тогда работал в небольшой компании, занимался SEO и про SMM практически ничего не знал. Мы с ребятами нашли в Wordstat запрос «как опубликовать фото в Инстаграм* с компьютера» – клики стоили недорого, конкурентов не было. Увидели проблему и поняли: надо делать сервис.

Обратная ошибка: слишком долго проводить исследования перед запуском и годами строить продукт мечты

Быстро собрали MVP (минимально жизнеспособный продукт), но получилось не без трудностей: мы радостно продолбили принцип разделения прав – это в будущем очень дорого стоило. Если бы мог вернуться в прошлое и что-то посоветовать сам себе, это был бы тот самый момент: «Василий, добавь командный режим». 

Дело в том, что когда мы делали сервис, думали: есть один аккаунт в SMMplanner – ты в нем сидишь и работаешь. А то, что аккаунт может принадлежать команде и надо как-то предоставить доступ другим специалистам, не заложили в первичном ТЗ. В итоге несколько лет внедряли возможность работать команде на одном аккаунте, переделывая архитектуру сервиса. Хотя могли изначально учесть этот момент.

Как сейчас устроена функция работы в команде

Поэтому, когда делаете MVP, не стоит забывать, каким продукт будет в целом. И когда вы его разрабатываете, думайте про его будущее развитие. Архитектура приложения – как фундамент дома, а самое сложное в строительстве – перестраивать. Так было в нашем случае с админкой: программист не заложил функционал командной работы, а мы продолжили развивать сервис и обвешивать его новыми функциями. 

Сейчас мы планируем мобильное приложение и в этот раз идем уже от всех вариантов. Мы нарисовали все возможные функции, которые хотим видеть или которые нужны согласно кастдеву, чтобы программист увидел и понял, что нужно уже сейчас заложить в архитектуру приложения.

Главное:

• При формировании MVP стоит продумать его целиком или заложить функции на основе всех потенциальных вариантов использования. Разработчик должен заложить принципы, чтобы в дальнейшем они выросли в функции. 
• Проводите опросы пользователей, делайте кастдевы и собирайте списки всех возможных функций. Не факт, что они войдут в MVP, но со временем они появятся, и вы будете к ним готовы.
• Закладывайте одну функцию в MVP, даже если у вас их 100. Критерий выбора: функция-паровоз, которая выгодно отличает ваш продукт от других и потенциально может привлечь большую аудиторию.

Забыть про маркетинговую стратегию

Можно сделать крутой продукт, но если забыть про маркетинг, получится «Неуловимый Джо»: не то чтобы его никто поймать не может – он никому не нужен.

Когда только после запуска начинаешь искать клиентов

Ты должен знать, как будешь продавать продукт, до его создания и понимать, как зарабатывать на нем. Я как создатель и разработчик могу восхищаться своим сервисом, я знаю, что продукт получился классный, и могу даже набить татуху с его логотипом – но что дальше? Только правильный маркетинг в правильном месте сделает хорошую продажу продукта на рынке. Плюс, конечно, удача. 

На момент старта SMMplanner мы точно понимали, как будем его продавать. У нас было уникальное торговое предложение, которого не было у конкурентов – бесплатный постинг. Для продвижения выбрали контекстную рекламу в поисковике Яндекса. Мы видели запросы «как выложить фото в Инстаграм* с компьютера» в Директе и оценивали по ним возможность привлечь более 10 тысяч потенциальных пользователей. Рекламный клик стоил всего 2 рубля. 

Это была та самая удача: конкуренты продвигали сервисы автопостинга через таргетированную рекламу, а мы решили пойти в SEO. В таргете нельзя запускать рекламные кампании по четкому поисковому запросу, а вот в Директе – вполне. Поэтому у нас не было на этом канале конкуренции еще несколько лет. 

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

Главное:

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

Не проявлять гибкость

Если вы видите, что пользователи взаимодействуют с продуктом как-то не так – это повод его изменить, а не пытаться вернуть людей на «истинный путь».

Когда мы создавали категорию «Проекты», изначально закладывали такую функцию: допустим, у SMM-щика есть несколько рабочих аккаунтов. Он создает проект «Ромашка» и добавляет туда все соцсети компании, потом делает проект «Автосалон» и по аналогии добавляет страницы автосалона. Один аккаунт мог быть добавлен в один проект, что в целом логично.

Так выглядит списков проектов, где в каждой папке свой список соцсетей

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

Такой способ использования «Проектов» мы даже близко не закладывали в ТЗ. Но в итоге около 25 % пользователей используют проекты для массового постинга через сетку. Запрос есть, поэтому сейчас мы собираемся упростить работу и ввести систему тегов – она поможет отправлять контент не по проектам, а по меткам.

Главное:

• Отслеживайте поведение пользователей в вашем продукте или проводите А/Б-тестирование – меняйте логику интерфейса и замеряйте эффективность элементов.
• Используйте кастдев уже после релиза, а еще мониторьте комментарии и обзоры – это позволит посмотреть, как в реальности люди пользуются вашим продуктом.

Постскриптум

Еще несколько бонусных мыслей в финале:

• Подписка – это классно. Заметил, что многие коллеги боятся внедрять подписную модель, потому что считают, что люди не готовы к ежемесячным списаниям. Когда мы внедряли подписку в SMMplanner, тоже боялись хейта, но такая система получила хороший отклик.
• Копировать – нормально. Я сейчас не про бездумное копирование, а когда ты действуешь как художник: видишь идею-функцию и додумываешь, как ее сделать лучше или адаптировать под свой продукт. 
• Затирать негатив – не ок. Лучше отвечать на него, а не удалять. Отзывы пишут немногие, но читают-то их все. Когда люди видят, что к вам пришел человек на негативе, а вы решили его проблему или по-человечески ответили, то понятно: компания адекватная и не зарывает голову в песок. Только вот проблему реально надо будет решать – если несколько месяцев вы не исправляете функционал и кормите обещаниями, никакой комьюнити-менеджер не поможет.

*Соцсеть признана экстремистской и запрещена в России.