3 простых способа генерации и проверки идей, с помощью которых я нашла идею для стартапа

Привет! Меня зовут Даша Беглова — я продакт-менеджер в ProductStar и магистрант ИТМО. В рамках программы Преакселератора ИТМО я развиваю идею сервиса, который на базе машинного обучения определяет, какой чекаут или пейволл показывать вашим пользователям — Qonverty. Делюсь, как на собственном опыте мы с друзьями нашли идею для стартапа и привлекли первых пользователей.

В августе 2020 года я написала нескольким друзьям из IT с идеей поучаствовать в программе Преакселератора ИТМО. Так у нас появилась команда из четырех человек: три продакта и один ML-разработчик.

Здесь важно отметить, что Преакселератор — это не курсы, вас там ничему не учат. Вам просто дают человека из сферы бизнеса и он в свою очередь помогает вам корректировать путь. А делаете вы все сами ;)

Стратегия была достаточно простая:

1. Мы открыли Notion и завели Workspace, шуточно обозвав его #Стартапкухня.

2. Договорились о совместном звонке для мозгоштурма.
3. Перед встречей было важное условие: каждый расписывает интересные ему/ей крупные направления в IT.

4. Далее каждый из нас детализировал направления до конкретных ниш.

5. Затем был звонок, на котором каждый питчил всем остальным в команде список своих идей.
6. Так, за несколько раундов созвонов в Zoom и переписок в оргчате мы намозгоштурмили идею продукта.

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

Моя рекомендация простая: чтобы что-то придумать, надо много читать.

Читайте регулярно новости из мира IT в крупных интернет-изданиях, например, The Verge, TechCrunch, серфите ProductHunt, смотрите тематические конференции (например, Apple WWDC). Также полезно подписаться на YCombinator in Russia и следить за тем, что там пишут разные команды. Для кого-то эти рекомендации очевидны, но не для начинающих стартаперов.

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

1. Выбираем одно направление.

2. Выписываем все возможные ниши этого направления.

3. Выбираем конкретную нишу и начинаем гуглить и изучать выдачу. Например, запрос: Best Video Chat Apps 2020.

4. Анализируем, анализируем и еще раз анализируем.

5. Расписываем направления развития этой ниши, ориентируясь как и на собственные наблюдения, так и на аналитику или исследования.

6. Описываем, какие сегменты пользователей у этих решений и какие у них Use Cases.

Например, мы останавливаемся на ИТ-сотрудниках, работающих на удаленке и общающихся по сервисам видеосвязи.

Детализируем возможные сценарии, когда им нужно использовать видео-сервис.

7. Выдвигаем гипотезы, проводим проблемные интервью, возможно, находим какое-то интересное решение.

8. Решаем, хотим ли мы развивать эту идею дальше или будем искать новую.

9. Если нам интересно и мы верим в эту идею, а интервью с пользователями подтверждают наши гипотезы —> собираем MVP (например, в виде лендинга) и тестируем дальше.

10. Пробуем привлечь первых клиентов (например, на лендинг) и сделать первые продажи (early access или early funding).

• По сути, это «голое» обещание, что в ближайшем будущем вы доработаете идею и отдадите ее вашим первым пользователям. Я называю это «коммерческие отношения, построенные на доверии пользователей к основателям стартапа». Например, ваши первые пользователи — ваши знакомые и знакомые знакомых, которые знают, что вы классные специалисты и у вас может что-то получиться.
  

• Самое главное: поймите, интересно ли вам и вашей команде развивать эту идею совместно. У всех ли горят глаза? Это очень важный фактор, о котором, как мне кажется, многие забывают. Если вам или кому-то в вашей команде идея не интересна — скорее всего, вы прогорите.

Я называю этот способ «метод рандомных опросов»:

1. Берем существующую пока еще в нашей голове проблему: «За время пандемии появились новые потребности в доставке/заказе/вызове чего-то, что еще не решает ни один on-demand сервис».
2. Ищем крупные ИТ-сообщества — я взяла коммьюнити ProductCamp.
   
3. Пишем всем подряд в личку.

Я искренне верю, что в какой-то момент вашего опроса вы наткнетесь на очень интересные ответы. Так получилось у меня: я нашла девушку, которая уехала работать продуктовым дизайнером в маленькую провинцию в Швеции, где, как оказалось, все очень плохо с сервисами:

После 10 минут беседы в Telegram меня добавили в чат русских айтишников в Швеции, где я задала ребятам те же самые вопросы, что задавала индивидуально — магия:) В чате началась бурная беседа и обсуждения различных проблем с сервисами в Швеции.

Берем ручку или открываем гугл таблицу и записывае!:)

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

Оффтоп

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

Каждый хотел делать что-то свое, и причины очевидны. Каждый из нас специалист в определенной доменной области (TravelTech, Computer VIsion, Fintech…), и каждый хорошо разбирается в своей тематике, но другим было сложно это понять и задрайвиться на идею.

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

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

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

Именно так я и поступила.

Дело в том, что до прихода в EdTech я 2.5 года проработала в Mobile Dev — разработка мобильных приложений преимущественно под iOS.

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

Чтобы разработать приложение, вам необходимо использовать различные сервисы до того момента, когда вы нажмете кнопку «Send for Review». Но и на этом разработка не заканчивается. Вам также нужно продумать, как вы планируете продвигать ваш продукт, где вы будете собирать аналитику по событиям и по закупке трафика, как вы будете проводить А/Б-тесты подписочных экранов (об этом мы поговорим подробнее далее).

Что сделала я, когда вспоминала весь свой опыт работы в Mobile и что же мне хотелось улучшить?

1. Быстро расписала mindmap в Miro по различным B2B-сервисам для мобильных стартаперов в зависимости от этапа работы над мобильных продуктом.

2. Написала всем своим знакомым из мобильной тусовки в Минске и договорилась на получасовые интервью.

3. Вот вопросы, которые я задавала на старте, чтобы подвести разговор к нужной мне теме: B2B-продукты для предпринимателей в сфере мобильной разработки.

4. Далее я открывала доску в Miro и показывала области на MindMap.

5. Внимательно слушала, что по каждой ветке говорит мой собеседник.

Уже на втором интервью я сузила предмет разговора до конкретной ниши — сервисы для работы с подписками в iOS-приложениях.

Вишенкой на торте был вопрос про существующие проблемы в процессе работы с подписками.

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

В результате у меня «подсветилось» два направления, куда можно двигать мысль дальше.

В первом случае есть риск, связанный с очередными изменениями в пользовательской политике Apple. Те, кто работает в мобильной сфере, не понаслышке знают, как Apple любит часто менять свою политику и вводить новые правил и ограничения, что сильно сказывается на доходах мобильных разработчиков. Очередное такое изменение коснется огромной индустрии — атрибуции мобильного трафика. В ближайшее время Apple планирует запрашивать разрешение у пользователей на трекинг (IDFA). По этому поводу можно почитать целую статью в блоге Олега Якубенкова.

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

Без IDFA мобильный разработчик, скорее всего, уже не сможет детально отследить по каждому пользователю его покупки и посчитать LTV конкретно по нему. Мы будем просто получать базовую информацию о количестве установок и количестве целевых действий. Следовательно, для iOS будет неактуально считать детально LTV на уровне source, campaign и т. д.

Оставалась вторая продуктовая гипотеза — конструктор онбордингов и подписочных экранов. Основа сервиса — А/Б-тесты подписок без перезаливки билда с использованием алгоритмов машинного обучения.

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

Давайте-ка прогуляемся по воронке:

1. Рекламные видео и баннера в правильно подобранных рекламных источниках.
2. Качественно оформленная посадочная страница в AppStore (иконка, видео, скриншоты, тексты).
   
3. Онбординг и/или подписочный экран.
   

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

• % отвала из перехода с экрана на экран;
• конверсия из просмотревших подписку в покупку.

Для этого регулярно проводятся А/Б тесты новых концептов, мониторится рынок и ключевые конкуренты для трекинга их тестов:

Какой сегодня экран в какой стране тестирует конкурентное приложение?
Что изменилось на экране?
Почему убрали онбординг и оставили только подписку?
Сколько тарифных планов сейчас на подписочном экране?
Что там обещают пользователю? и т. д.

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

Сам процесс мониторинга и тестирования достаточно трудоемкий:

1. Установить приложения конкурентов на телефон.
2. Заскринить экраны.
   
3. Собрать результаты на какой-нибудь борд.
   
4. Расписать отличия.
   
5. Проанализировать, что вы тестировали, а что еще нет.
   
6. Придумать и написать ТЗ для новых экранов.
   
7. Пережить итерацию с отрисовкой и правками у дизайнера.
   
8. Несколько раз все это дело согласовать.
   
9. Отдать ТЗ разработчику.
   
10. Протестировать работу новых экранов по ТЗ.
    
11. Перезалить билд с новыми экранами и пережить ревью. А, возможно, получить заветный реджект от Apple.
    

12. Поправить экраны, перезалить билд и написать объяснительную в Apple.

    Ну и далее…

Боль 1: необходимость задействовать для этой задачи несколько игроков команды.

На одном из моих предыдущих мест работы мы разработали свою внутреннюю систему и процесс для более быстрого А/Б тестирования.

1. Мы исключили трудозатраты разработчиков из этой задачи с того момента, как было написано само решение.

2. Пригласили в команду отдельного Frontend-разработчика с навыками веб-дизайнера, который исправлял нам HTML-код по новым ТЗ экранов. Фактически, он работал 24/7!

3. Далее без перезаливки билда раскатывали новые экраны в определенных странах.
4. Собирали результаты тестов через Appsflyer.

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

6. В соседнем столбце прописывали полученные метрики.

Получается, что для нового процесса так или иначе нам пришлось задействовать из своих внутренних ресурсов сразу нескольких специалистов:

• Бэкенд-разработчик
• HTML-верстальщик
• Продуктовый дизайнер
• Продуктовый маркетолог
• Продакт-менеджер
  

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

Маркетолог с продактом мучились с тем, чтобы собирать и визуализировать результаты тестов в одном месте, так как самописное решение не предполагало наличие хоть какого-то дашборда.

Боль 2: необходимость проводить слишком много тестов, аккуратно и поэтапно изменяя элементы дизайна.

Еще одна ключевая боль, которую я хорошо запомнила — необходимость тестировать поэтапно с командой множество платежных экранов мобильных приложений, изменяя конкретные элементы дизайна постепенно:

• тексты на кнопках;

• сами кнопки оплат;
• наличие крестика или его отсутствие на экране оплаты;
  
• различные вариации призывов к действию;
  
• где / что / как написано.

Таким образом, тестирование растягивалось и не всегда давало быстро нужный результат и рост конверсий.

Боль 3: необходимость постоянно перезаливать билд с новыми экранами и проходить Review в App Store. Сюда же добавляется боль с локализациями.

Эту задачу мы также решали по-своему: размещали на экраны Settings сразу несколько различных опций оплат, и по тапу по разным опциям открывались те самые платежные экраны. На главный экран ставили один экран, а в настройки — еще с десяток. Делали это для разных стран. А в iTunes Connect по каждому продукту прикрепляли скриншот и описание пути для ревьювера, как найти эту подписку.

В самописном решении локализации можно было обновлять удаленно.

Как сейчас решаются вышеперечисленные проблемы?

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

Результаты опроса пользователей, кто уже успел опробовать разработку, показали, что в текущем решении сильно урезан функционал:

• по дизайну (экраны получаются максимально базовые);
• в конструкторе не хватило доп. функций (JSON, анимашки и так далее);
  
• нет возможности тестировать сразу много экранов.
  

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

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

Именно эту идею я и моя новая команда (Python ML/Backend Developer и Product Marketing Manager) пробуем сейчас развивать. У нас уже есть небольшое MVP, и мы ищем дружественные веб/мобильные продукты для тестирования алгоритма.

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

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

Рекомендация, как НЕ надо искать респондентов на интервью:

Как думаете, как много людей откликнулось?) Правильно — ноль.

А вот как можно переформулировать свой запрос и словить на живца:

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

Наверняка, среди читающих найдется не мало людей, кто развивал, развивает или только в начале пути развития своей идеи. Давайте находиться и общаться!: )

P.S. Немного слов благодарности. Спасибо редакторам vc.ru за возможность опубликовать текст статьи. Спасибо трекеру Косте Хомченко за наставления во время поиска идеи. Спасибо всем, кто помогал сделать дизайн, собрать работающий сайт, сделать корректуру текстов.

#идеи