Автор статьи: Павел Аксенов

CPO цифровой платформы Самолет

Всем привет! Меня зовут Аксёнов Павел. Я работаю CPO (директором по продукту) цифровой платформы Самолет Плюс и преподаю управление продуктом в OTUS. А еще у меня есть опыт работы на Head позициях в Яндекс, Ozon и Mail. Кроме всего этого, я менторю нескольких продактов и веду канал про продукт и бизнес.

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

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

Итак, почему «гипотеза», а не «задача»? Потому, что задача по умолчанию не требует доказательства. То есть, в проектную команду заказчик приносит задачу, объявляет ее приоритет – и все, она в какой-то момент времени идет в работу. А цель продуктового подхода – понять, что наибольшую ценность принесет в данный момент и проверить это как можно более простым способом. Если сказать прямо – каждую свою гипотезу нужно как можно раньше стараться опровергнуть. Чтобы потерять как можно меньше времени на той, которая не даст прироста метрик.

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

Давайте рассмотрим простой пример. Допустим, у нас проектный подход. Тот, который не про гипотезы, а про задачи. И в нашем сервисе есть продажа товаров, но способ получения только один – самовывоз. Заказчик решает нанять курьеров, приобрести им фирменную одежду, сумки и, возможно, транспорт. Команда разработки создает страничку, на которой можно ввести адрес доставки и желаемую дату, пишет сервис, который передает заказы из интернет-магазина курьеру, а, возможно, и приложение для курьера. Что происходит в негативном сценарии? Правильно, заказчик теряет много миллионов рублей.

А что было бы, если бы у нас был продуктовый подход? Во-первых, мы бы сначала написали гипотезу и, чтобы под ней были основания, мы бы подтвердили, что клиентам в принципе нужна доставка, поняли комфортную стоимость и срок доставки, посчитали Unit-экономику. Провели бы опрос или интервьюирование пользователей, узнали бы от них про их потребности. Потом сделали бы фейковую кнопку на сайте или в приложении «курьерская доставка». Посмотрели бы, сколько из увидевших ее, на нее нажало. Точного спроса это упражнение не даст потому, что после нажатия есть еще десятки способов убить конверсию: сложные формы, плохие доступные интервалы доставки, высокая стоимость и тд. Но мы бы, как минимум, поняли — условно из 10 тысяч увидевших на кнопку нажало три человека или восемь тысяч. А потом бы, для проверки гипотезы в боевых условиях, мы бы не делали свою курьерскую доставку, а воспользовались бы готовым B2B-решением. Причем, чтобы не тратить время на интеграции, мы бы собирали заказы, складывали их в базу данных, а потом бы кто-то вручную оформлял заказы во внешнюю курьерку через их web-форму. И выкатили бы это на маленькую долю аудитории, чтобы посмотреть, сколько реальных заказов делается с доставкой. Что произошло бы в самом негативном сценарии? Ничего страшного, мы бы не потеряли много миллионов рублей и много недель на разработку.

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

Давайте начнем с самого начала: как гипотеза рождается.

Этап 1. Генерация гипотезы

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

Этап 2. Формулировка гипотезы

На данном этапе достаточно сформулировать ее коротко, в 2-10 слов, чтобы была понятна суть. Например, «Добавить оценку товара» или «авторизация через учетку Google». 

Этап 3. Расчет Unit-экономики

Это расчет экономики на один юнит, то есть, на одного пользователя. Грубо говоря, в мобильном приложении LTV пользователя выше на 20%. Продакт хочет сделать поп-ап на вебе «скачивайте мобильное приложение, первый заказ в нем будет со скидкой 20%». Тогда ему нужно посчитать, что рост LTV перекроет скидку.

Этап 4. Метрики и их скорринг

Нужно четко проработать, какие метрики должны вырасти, а какие при этом не должны упасть (например, мы растим средний чек и при этом важно, чтобы не упала конверсия). Когда все метрики понятны, нужно провести скоринг (приоритезацию) гипотез. Например, ICE, RICE, WSJF, Moscow и тд.

Этап 5. Описание гипотезы

Вам нужен шаблон. Во-первых, шаблон формулировки гипотезы, принятый в компании, по которому описывается изменение и его смысл для пользователей, динамика роста метрики, дизайн A/B теста. Во-вторых, там должны быть разделы, которые понадобятся команде. Контекст, декомпозиция сценариев, референсы, ограничения и тд.

Этап 6. Дизайн

Это все этапы, которые выполняются при разработке дизайна. Наброски, макеты, арт-ревью и тех-ревью, ревью продакта, интерактивные прототипы, разработка спецификаций, апдейт дизайн-системы. 

Этап 7. Ресерч

В данном случае — UX тесты. На вход исследователь, продакт, либо дизайнер готовят гайд и бриф, на выходе — отчет, по которому готовится список правок.

Этап 8. Груминг

Команда разбирает, декомпозирует, описывает и оценивает подзадачи вашей гипотезы.

Этап 9. Разработка, код-ревью, автотесты

Это все, что делает разработчик

Этап 10. Тестирование, арт-надзор, багфиксинг

Этот этап — проверки тестером, дизайнером, продактом и исправление ошибок и неточностей.

Этап 11. A/B-тесты

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

Этап 12. Принятие решения

Мы смотрим результаты A/B-тестов и, в зависимости от роста метрик, принимаем решение: выкатывать на 100% аудитории, отказаться от гипотезы и заняться другими или доработать эту гипотезу. Еще изредка бывает, что технические специалисты просят отложить запуск, чтобы сделать какие-то доработки.

Теперь вы знаете жизненный цикл продуктовой гипотезы. Вперед, к росту метрик!

А всех, для кого актуален вопрос прохождения собеседований и в целом поиска работы на позицию продакт-менеджера, приглашаем на открытый карьерный вебинар. На этом занятии разберем: структуру идеального резюме продакта, как проходит собеседование, какие вопросы задают HR. Проведем собеседование онлайн на 30-40 мин.

• Регистрация на открытое занятие.