Product discovery, дефицит ресурсов и 3 недели до запуска продукта: Purrweb Product Meetup #3

Конспект третьего митапа Purrweb для всех, кто запускает продукты. На этот раз опытом поделились Сергей Колосков, автор Телеграм-канала Fresh Product Manager, СЕО Akhter Discovery&Design, СРО в проектах Рекульт и Classlytics, Дмитрий Уляшев, продакт менеджер в Яндекс Директ и Анжелика Рахметова, продакт менеджер в STRV.

Делимся записью и конспектом выступлений.

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

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

Что лежит в основе дискавери:

• UX экспертиза. Все накопленные данные по юзабилити, jobs to be done, паттерны поведения.
• Продуктовое видение. Описывает общие цели проекта, позволяет лучше понять цели создания продукта и потенциал в будущем.
• Дорожная карта развития продукта. Вступает в игру уже после создания рыночной версии. Позволяет также приоритезировать дискавери.
• Технический аудит. Дает информацию о технических возможностях продукта, чтобы желания соотнести с реальностью.

Артефакты дискавери нужно обогащать после каждого спринта. Опирайтесь на них при исследованиях.

• Lean model Canvas. Концептуальное описание бизнес-модели будущего продукта в виде схемы. Описывает все бизнес-процессы, касающиеся продукта. Например, предложение, инфраструктура, потребители и финансовые аспекты.
• Customer journey map. Карта коммуникации клиента с продуктом. Визуализирует все предполагаемые точки и каналы взаимодействия, а также мысли, эмоции, цели, мотивы и страхи клиента на пути к результату.
• User flow. Схема экранов приложения и переходов между ними. Помогает определить, как пользователь будет взаимодействовать с интерфейсом нового продукта.
• User stories map. Описывает функциональные требования к системе и критерии приемки. Позволяет заказчику эффективно расставлять приоритеты по реализации функций продукта.
• Нефункциональные требования. Рекомендации о свойствах системы и ограничениях, не относящихся к поведению системы. Например, оптимальный стек, архитектура инфраструктуры и ожидаемая нагрузка.

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

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

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

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

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

Кейс 1. Калькулятор.

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

Для первой версии продукта можно пожертвовать дизайном, главное — польза для ваших клиентов и их фидбек. Соберите функцию в каком-то доступном инструменте, том же Excel, проведите бета-тестирование, и только потом делайте полноценную фичу.

Кейс 2. Интеграция без автоматизации.

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

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

Кейс 3. Автопарсер.

Решение. Мы написали скрипт, который автоматизировал первую ступень создания объявлений. Его запускали вручную, а результат работы скрипта отдавали системе создания рекламных объявлений. Эта версия «на ручном приводе» работала и приносила пользу клиенту несколько месяцев. В текущей версии этот процесс автоматизирован.

Дорогостоящие фичи можно проверять в «ручном режиме». Это позволит протестировать гипотезу и собрать реальные метрики, на основе которых принимается решение о запуске.

Релиз продукта — это всегда нервное дело, потому что многое может пойти не так. Смотрим на примеры.

Кейс 1. ProdTech/FinTech.

Что пошло не так?

• Год разработки и четыре полных редизайна. Из-за того, что у 5 стейкхолдеров были разные вкусы, приложение пришлось 4 раза полностью редизайнить.
• Лендинг провисел всего 6 часов. Затем позвонил юрист заказчиков и сказал снять сайт. Проблема в том, что все, включая стейкхолдеров, забыли, что наше приложение относится не только к ProdTech, но и к FinTech тоже. Последнее — это одна из самых регулируемых сфер. Там нужно быть очень внимательным к тексту. А его на сайте писали маркетологи и копирайтеры. Юристы проверяли сайт 2 месяца.

• Пришлось сдвинуть маркетинговую кампанию большого релиза, потому что App Store согласовывал релиз 1,5 недели, хотя бета-версию одобрил быстро.

Надо привлекать юристов на стадии дискавери, чтобы изучить обязательные стандарты. Иначе — рискуем сильно менять продукт и сроки запуска.

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

Нужно проверять сроки проверки Apple. Для стейджа и прода разные условия и сроки. А еще лучше закладывать запас времени.

Хорошее финансирование — не всегда полезно. Убедите стейкхолдеров тратить деньги на маркетинг, а не на редизайны.

Кейс 2. EdTech

Что пошло не так?

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

• Увеличили Retention rate на 23%, но уронили Sign up на 38%. Из-за чего пострадали доходы от приложения. Это произошло, потому что при разработке ориентировались только на старых пользователей. В итоге приложение вышло слишком сложным для новичков.

Перед запуском проверяйте очевидные мелочи, вроде срока действия SSL-сертификата.

Если продуктом уже пользуются, нужен отдельный CustDev для старых и новых пользователей.

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

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