Привет, Хабр! Меня зовут Юлия Запольская, я продакт-менеджер в Яндексе, а сегодня еще и гостевой автор Friflex. В этой статье я поделюсь инсайтами, благодаря которым у меня получилось запустить продукт за четыре месяца.
Мой продукт называется CodeRun. В нем можно прокачивать свои навыки в формате решения практических задач по нескольким направлениям: фронтенд, бэкенд, аналитика, ML и мобильная разработка. Еще там можно общаться в коммьюнити (мы его модерируем и всячески поддерживаем), обращаться за помощью в решении задач к редакторам и соревноваться за призы и сокращенную схему найма в Яндекса.
Перенесемся в февраль 2024 года. У коллег была классная идея и ресурсы в виде большого количества контента и задач для тренировки навыков разработчиков, которые долгое время использовались в Яндексе для различных соревнований, но не публиковались для внешних пользователей. А также было огромное желание начать помогать разработчикам, которые очень хотят попасть в Яндекс или начать свой путь в IT.
С помощью этого контента и команды был собран бета-тренажер. Его запустили на узкую аудиторию — и сделали главный вывод, что он «зашел», надо делать.
Было принято решение запуститься в июне 2024 года: оставалось четыре месяца для того, чтобы полностью собрать фактуру, погрузиться и запустить продукт.
Что требовалось сделать? Во-первых, сильно расширить функциональность продукта, потому что она была супер базовая. В публичный запуск с такой функциональностью выходить сложно, потому что рынок конкурентов перенасыщен и важно было показать что-то особенное.
Во-вторых, нужно было построить стратегию позиционирования (а это продвижение, PR, маркетинг и так далее).
Discovery
Первым делом нужно было провести исследование. В моей жизни был только один период, когда у меня было полноценное время на discovery: когда я делала исследовательское агентство. Ко мне приходили владельцы бизнеса или другие продакты и делегировали мне и моей команде проведение продуктовых исследований для их задач. Я исследовала, а они параллельно вели разработку.
И делегирование исследования, кстати, очень хорошее решение, потому что позволяет его хотя бы провести в контексте обычной загруженности продактов. Но на этапе зарождения продукта я, как продакт, все-таки люблю сама погрузиться, поисследовать, понять и принять стратегические решения. Конкретно в этой ситуации я побоялась делегировать все, поэтому решила делегировать определенные части.
Конечно, хотелось бы сделать все полноценно, самостоятельно спроектировать и провести интервью, выделить гипотезы, проверить их — но так сделать не получилось.
Я начала с экспертных интервью. Это очень классный инструмент, я много где его использую. Например, когда прихожу на новую работу, в новую команду, в любую незнакомую для себя сферу, обычно начинаю с экспертных интервью. Когда у меня еще нет своих фильтров восприятия и я не могу принимать решения, проще опросить пять-шесть экспертов, понять их картину мира и уже полагаясь на это знание, продолжать исследование.
Про что я разговаривала:
Про рынок и тренды, новых игроков;
Сегменты, у которых есть сильные боли;
Сами боли, как можно объединить людей с ними;
Про каждый сегмент и что объединяет людей в них;
Какой бы продукт сейчас сделал сам эксперт (для какого сегмента и в чем его ценность);
Что можно улучшить в продукте и почему;
Как продукт лучше коммуницировать.
Конечно, каждый раз я адаптирую вопросы под конкретный кейс.
Важная деталь — когда я прихожу и говорю: «привет, я Юля, продакт тренажера для разработчиков…», эксперт сразу начинает думать в призме тренажера для разработчиков. Здесь важно помочь эксперту не зацикливаться на конкретном продукте и переходить к нему от абстрактного. Может быть, эксперт скажет, что рынок перенасыщен, вообще такой проблемы нет, ВУЗы прекрасно готовят программистов, и все сразу могут выходить на работу. И это тоже хороший ответ.
Кабинетное исследование (конкурентный анализ, анализ рынка) я как раз делегировала агентству. У нас получился огромный документ на ≈149 страниц с кейсами, скринами — все про конкурентов.
И это все получилось потом распределить в классический конкурентный анализ, где можно было выставить баллы по каждому конкуренту и понять, где наша бета-версия продукта на этом рынке сейчас и в какую сторону нам хочется идти. Кстати, в таких ситуациях, когда мы видим свое место относительно конкурентов, иногда мы начинаем понимать, что собираемся выйти не совсем на тот рынок и нужно как-то отстроиться. Это тоже хорошее решение, но здесь такого не произошло.
Экспертная валидация
При ускоренной подготовке к запуску я приняла решение пропустить очень важные этапы продуктового дискавери — например, jobs-to-be-done интервью для поиска сегмента и для поиска продукта. Но так как времени не было, здесь мы обходились экспертной валидацией целей.
Экспертная валидация — это когда ты заходишь к экспертам в разных областях с разных сторон. Например, я приходила к продактам, которые запускали продукты именно в Яндексе, и спрашивала про специфику; у пиара спрашивала, с какой стороны лучше позиционировать. И со всеми мы калибровали цели.
Да, экспертная валидация не позволяет аргументировать цели запуска так круто, как полноценное исследование, но если нет времени — я считаю, это тоже вполне рабочий вариант.
Брейншторм по реализации
Дальше все было супер бегом.
У нас был брейншторм по реализации. Самое важное в брейнштормах — сломать первый лед и не фреймить, но у нас было не совсем так. Я рискнула и поставила коллегам ограничение, потому что мне было важно сфокусироваться на конкретной цели. Мы собрались с командой разработки, пригласили других заинтересованных экспертов и обозначили гипотезы на доске в Miro.
Я описывала их в таком виде:
«Когда я участвую в соревновании по программированию, я хочу иметь возможность получать дополнительные баллы, чтобы чувствовать постоянные дофаминовые подкрепления» (гипотеза сформулирована по JTBD). И на что это должно повлиять: на количество решенных задач в соревновании и на retention, чтобы пользователи не уходили в течение соревнований (в нашем случае соревнование длится два месяца).
Возможно, такой формат не подойдет, когда нужно придумать что-то революционное, но мою задачу в условиях ограниченных сроков он помог решить довольно хорошо.
Дальше мы сделали классическую приоритизацию фичей по RICE (Reach, Impact, Confidence, Effort). Исходя из этого уже сформировали roadmap продукта — причем roadmap и продуктовый, и коммуникационный, и продвижения продукта.
UX-тесты
Так как у нас не было полноценной количественной проверки на пользователях, мы делали точечные UX-тесты на этапах дизайна. Дизайнер собирал в Figma прототипы, и мы показывали их респондентам. Когда-то это было порядка 16-20 респондентов для тестирования одной фичи, когда-то — фокус-группы, чтобы проверить, как ведут себя пользователи.
На UX-тестах после каждого клика или перехода на новую страницу, мы спрашивали респондента: что ты видишь, что думаешь, что чувствуешь? Если были ответы: «я вообще ничего не понимаю и хочу закрыть этот сайт», мы понимали, что нужно переделывать.
План коммуникации
Дальше мы составлили план коммуникации вместе с командами маркетинга и PR. Важный момент: расширенные исследования и стратегию мы оставили на этап после запуска.
Я считаю, таким способом можно приоритизировать исследование в моменте, когда сложно со временем. То есть важные моменты для запуска мы провели до запуска, а конкретный план исследования и построения четкой стратегии перенесли на время после запуска (чем я наконец-то сейчас и занимаюсь).
Нам нужно было работать с огромным количеством контента: интерфейс, SMM, CRM-коммуникация, PR, юридическая документация, техподдержка, раздатка… Над текстами работала команда авторов, но я стала тем человеком, который контролирует и правит все — стиль, смыслы. Мне было очень грустно и дальше так жить не хотелось, поэтому я решила ввести практику Tone of Voice. Это голос, которым продукт разговаривает с внешними пользователями. Часто Tone of Voice используют в маркетинге, когда делают характер бренда. Вряд ли кто-то спутает голос Mercedes с голосом McDonalds — у каждой компании своя специфика. Это и есть Tone of Voice.
Мы собрали Tone of Voice нашего сервиса. Подумали, каким бы человеком мог быть наш сервис, каких людей мы хотим привлекать и как мы хотим с ними говорить. Мы пришли к тому, что хочется, чтобы от нашего продукта было ощущение, как от уютного домашнего кота, которого ты сажаешь к себе на коленочки и идешь под пледиком вечером кодить. И при этом немножко шкодного котика, поэтому мы ввели коммуникацию на «ты», интересные символы в текст, немного шутливое общение, даже сленг иногда.
В итоге у нас получился документ, в который мы включили:
Портрет нашего пользователя, целевой аудитории;
Ядро нашей целевой аудитории;
Компетенции этой целевой аудитории;
Стили эмоций;
Что должен показывать текст и визуал;
Примеры использования для техподдержки, поста в Telegram, раздатки, внутри интерфейса и так далее.
Мы раздали это всем командам. Получилось так, что не я напрямую ухожу и валидирую каждый кейс, а через Tone of Voice мы общаемся со всеми людьми, которые пишут тексты. Я до сих пор пользуюсь этим документом, когда мне нужно писать какие-то тексты, пополнять контент.
Так что сначала это выглядело как факап, но в итоге сыграло нам на руку: процессы с контентом мы хорошо закрыли документом Tone of Voice.
Чем ближе к запуску, тем проще
На самом деле, чем ближе — тем тревожнее. Поэтому я стараюсь учесть, что перед запуском соблюдать процессы так, как они были выстроены в спокойный период времени, будет сложно.
Что я решила сделать? Примерно за три-четыре недели до запуска я решила упростить все процессы. Перед началом мы говорили об этом всей команде: за такой-то период до запуска будет сильное упрощение в процессах, чтобы коммуникация была более прямая. Вместо трекера стали использовать линейный список. То есть «monkey see, monkey do». Манки видит задачу — делает задачу. Все, ни о какой структуре не думаем.
У нас были двухнедельные спринты. За пару месяцев до запуска мы сделали их недельными, чтобы каждую неделю мы могли вносить изменения, были более подвижными.
Делали меньше процессных встреч и больше встреч, направленных на разбор конкретной задачи.
Практически убрали статусы со стейкхолдерами и заменили их на частые короткие демо. Пару раз в неделю мы проводили демо и показывали изменения. И просто прописывали статус в чате. Это позволяло всем быть включенным в процесс, стейкхолдерам — не волноваться, а нам не волноваться, что волнуются стейкхолдеры.
И ветвистую структуру коммуникации, когда многие общаются через менеджера — мы упразднили и ввели прямую коммуникацию.
Конечно, это очень зависит от команды — не все команды готовы к такому формату. Например, есть разработчики, которые говорят: «Уберите от меня новый лишний чат или переписку». Но у нас с командой все получилось довольно неплохо, и процесс стал идти быстрее.
Чек-лист «Я забыл, что я забыл»
По сути, это большая памятка из кучи пунктов для тревожных (таких же, как я) людей, которые перед каждым запуском переживают, что они что-то забудут. Под каждый проект она своя.
Погнали!
Исследования
экспертные интервью
анализ рынка
анализ конкурентов или кабинетное исследование
исследование (интервью) на поиск сегмента
сегментация (по работам / ABCDX / соцдем)
исследование (интервью) на поиск продукта
CJM / граф работ
создание дерева метрик продукта
определение целей запуска
стратегия продукта
согласование стратегий со стейкхолдерами
погружение команды в стратегию
создание Tone of Voice продукта
коммуникационная стратегия
количественная валидация гипотез
брейнштормы с командой / смежниками / экспертами
UX тесты / коридорки / фокус группы
MVP / beta
Дизайн
бриф от продакта на брендинг продукта
разработка брендинга / аудентики продукта
адаптация брендинга для использования (ui/ux / рекламные креативы / маркетинг / физические носители)
Разработка
роадмап разработки до запуска
продуктовые проработки
документация продуктовая и техническая
разработка
написание текстов интерфейсов
проверка интерфейсов на доступность
создание экстренного документа перед запуском (что делать, если все упало)
Сбор статистики и аналитика
создать и установить счетчик
выставить необходимые цели сбора данных по счетчику
построить план принятия решений в зависимости от собранных метрик
Контент
поиск авторов / редакторов / корректоров контента
построение процессов регулярного обновления и валидации контента
написание ТЗ на контент
создание FAQ по сервису
Продвижение
определение таргетов продвижения
сбор фактуры для рассказа ЦА
агрегация каналов коммуникации
генерация идей и форматов продвижения
определение бюджетов
копирайт
создание контент плана (в т.ч. и внутри компании)
создание креативов
настройка поисковой оптимизации
написание и согласование пресс-релиза со стейкхолдерами
Поддержка
погружение поддержки в продукт и ToV
сбор базы знаний поддержки
интеграции формы поддержки в продукт
построение процессов работы с саппортами
построение процесса разбора тикетов поддержки разработкой / менеджерами / редакторами
построение процесса аналитики обращений в поддержку
Юридические риски
написание условий использований сервиса
написание правил сервиса
проверка корректности работы с пользовательскими данными
добавление необходимых согласий пользователя перед стартом использования продукта
валидация сервиса юристом
Оффлайн запуск
определение площадки
формирование плана площадки
сценарий запуска
механики взаимодействия с гостями
производство сувенирки
А какие лайфхаки помогают вам исследовать и запускать продукт, когда мало времени? Делитесь в комментариях :)
