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. Калькулятор.
Для рекламного кабинета нужно было задизайнить калькулятор расчета определенной величины, затем разработать на фронте и на беке, а также протестировать. Оценили в 2-3 спринта.
Решение. Первая версию калькулятора сделали в Excel. Добавили формулы и вопросы для пользователей, они отвечали и получали на выходе необходимое значение. Эту версию начали тестировать с пользователями, чтобы она уже приносила пользу, а мы получали ценный фидбек. Так как главное в этом продукте не красивый интерфейс, а результат, то люди охотно пользовались нашим Excel, а мы сэкономили много ресурсов.
Для первой версии продукта можно пожертвовать дизайном, главное — польза для ваших клиентов и их фидбек. Соберите функцию в каком-то доступном инструменте, том же Excel, проведите бета-тестирование, и только потом делайте полноценную фичу.
Кейс 2. Интеграция без автоматизации.
Нужно сделать фичу с интеграцией сторонних систем. Это может быть подключение услуги, создание аккаунта, смена тарифного плана или запрос аналитического отчета. Для пользователя — это одна кнопка, а под капотом может быть большой объем работы по интеграции разных систем, требующий взаимных усилий команд этих сервисов.
Решение. Сначала дать пользователям услугу, потом автоматизировать процесс. В первой версии продукта можно обрабатывать запросы вручную — формировать заявки, которые потом будет выполнять менеджер. Для второй версии можно нанять людей, которые будут вручную выполнять функции продукта. Это позволит освободить менеджеров, выиграть время, проверить гипотезы и не потратить много ресурсов на разработку.
Иногда фичи могут запускаться не автоматически, и ручного режима вполне достаточно. Если ваши пользователи готовы подождать ответа на свой запрос, то можно протестировать идею с менеджерами и не тратить ресурсы на разработку.
Кейс 3. Автопарсер.
Создать функцию, которая автоматизировала бы создание объявлений и заменила собой 2-х ступенчатый процесс. Это очень дорогая функция: нужны были 3 команды, несколько спринтов на бэкенде и интеграции с другими системами.
Решение. Мы написали скрипт, который автоматизировал первую ступень создания объявлений. Его запускали вручную, а результат работы скрипта отдавали системе создания рекламных объявлений. Эта версия «на ручном приводе» работала и приносила пользу клиенту несколько месяцев. В текущей версии этот процесс автоматизирован.
Дорогостоящие фичи можно проверять в «ручном режиме». Это позволит протестировать гипотезу и собрать реальные метрики, на основе которых принимается решение о запуске.
Анжелика Рахметова. Подготовка к первому релизу. 3 недели до
Релиз продукта — это всегда нервное дело, потому что многое может пойти не так. Смотрим на примеры.
Кейс 1. ProdTech/FinTech.
Нужно было создать MVP маркетплейса недвижимости для выгодных инвестиций.
Основной фокус — мобильное приложение. Веб-приложения не было, только маркетинговый лендинг.
15 человек команды, почти безлимитные ресурсы. На MVP потратили чуть больше года.
Что пошло не так?
- Год разработки и четыре полных редизайна. Из-за того, что у 5 стейкхолдеров были разные вкусы, приложение пришлось 4 раза полностью редизайнить.
- Лендинг провисел всего 6 часов. Затем позвонил юрист заказчиков и сказал снять сайт. Проблема в том, что все, включая стейкхолдеров, забыли, что наше приложение относится не только к ProdTech, но и к FinTech тоже. Последнее — это одна из самых регулируемых сфер. Там нужно быть очень внимательным к тексту. А его на сайте писали маркетологи и копирайтеры. Юристы проверяли сайт 2 месяца.
- Пришлось сдвинуть маркетинговую кампанию большого релиза, потому что App Store согласовывал релиз 1,5 недели, хотя бета-версию одобрил быстро.
Надо привлекать юристов на стадии дискавери, чтобы изучить обязательные стандарты. Иначе — рискуем сильно менять продукт и сроки запуска.
MVP должно быть MVP. Прежде чем вносить изменения в работу и дизайн, гипотезы нужно проверить, а руководствуясь только ощущениями можно наделать ошибок.
Нужно проверять сроки проверки Apple. Для стейджа и прода разные условия и сроки. А еще лучше закладывать запас времени.
Хорошее финансирование — не всегда полезно. Убедите стейкхолдеров тратить деньги на маркетинг, а не на редизайны.
Кейс 2. EdTech
Делали B2C SaaS приложение для заказчицы — блогера из штатов. Идея платформы была в том, чтобы по подписке давать доступ к курсам подготовки к государственным экзаменам. У клиента был готовый MVP, нужно было создать полноценный продукт. Мы провели CustDev, на его основе создали дизайн, переписали бэкенд, расширили функциональность и создали портал для админа с CMS.
Что пошло не так?
- Забыли обновить SSL-сертификат. Поэтому вместо главной страницы приложения пользователи видели предупреждение о том, что их данные с сайта можно украсть. К счастью, заказчица — блогер, и поэтому смогла вернуть кредит доверия, осветив ситуацию в соцсетях.
- Увеличили Retention rate на 23%, но уронили Sign up на 38%. Из-за чего пострадали доходы от приложения. Это произошло, потому что при разработке ориентировались только на старых пользователей. В итоге приложение вышло слишком сложным для новичков.
Перед запуском проверяйте очевидные мелочи, вроде срока действия SSL-сертификата.
Если продуктом уже пользуются, нужен отдельный CustDev для старых и новых пользователей.
Ошибок нельзя избежать. Но можно минимизировать, если прописать чек-листы для каждого отдела. Разработчики должны проверить все сертификаты, все хостинги. Дизайнеры — все ли элементы на месте, соответствует ли дизайн стандартам.
Анонсы новых митапов с ссылкой на регистрацию мы выкладываем в наш телеграм-канал. Подписывайтесь, чтобы не пропустить полезные инсайты от новых спикеров.
Последний доклад — типичные проблемы проджектов)
Полностью согласны)