Что будет, если скрестить Double diamond и все модные фреймворки с реальной жизнью.
Распространенная проблема продуктовых команд — отсутствие системного подхода. Знания обрывочны, фрагментарны, что приводит к тому, что команда “забивает мух молотком”.
Популярные фреймворки вроде ‘’Double diamond’’отвечают на вопрос «Что делать”, но не объясняют «Как делать”. Изучение конкретных методов и тулов (например, глубинных интервью или А/Б тестов) помогает находить ответы на вопрос "Как делать”, но совсем не помогают с определением »Когда”.
Продуктовые менеджеры и предприниматели на словах понимают важность дискавери фазы и быстрой и ранней проверки гипотез, но затрудняются объяснить, что именно за этим стоит: что нужно валидировать, какие исследования применять в том или ином случае и до какого момента это имеет смысл, а когда уже можно и нужно в продакшн.
В результате, процесс становится неуправляемым и хаотичным. А хаос — это состояние, когда успех становится делом случая.
Поделюсь фреймворком в котором соединены ‘’Что, Как и Когда”, по которому я выстраиваю работу в своих продуктах.
Дисклеймер: это обобщённый подход, который подходит для средней команды в вакууме. На разных стадиях развития продукта/команды/компании все может быть совсем по-другому. И это ок.
1. Получаем сигнал о проблеме или идею для улучшения.
Процесс генерации идей — процесс непрерывный и, во многом, творческий. Редким командам удается сделать его системным. Идеи могу поступить к нам из:
- инсайд из интервью с юзерами, с экспертами. Иногда это может стать фокусом на данном этапе развития продукта (дискавери) или фокусом для отдельных команд (Дискавери команды). Но значительная часть выполняется “ад-хок”;
- фидбэк от клиентов в сыром виде или в аккумулированном виде от команд сейлз/кастомер саппорта. Это может быть форма на сайте, NPS опрос или тэг в социальной сети. Такой фидбэк нет смысла мониторить ежедневно, но полезно регулярно (например, 1 раз в месяц) выгружать и проcматривать;
- данные и бенчмарки. Речь идет как о регулярных отсмотрах метрик(”Ого, что-то у нас упал ретеншн в когорте X — надо углубиться”), так и каком-то неожиданном озарении (’’Видел в отчете у конкурентов, что у них активация Y%, у нас значительно ниже.” ). Эти источники, в среднем, имеют чуть больший вес, потому что объективны;
- Product sense, он же “чуйка”. Самый спорный инструмент, который часто путают с сильным мнением основателя или вкусовщиной. На самом деле, это комбинация экспертности+насмотренности+озарения, на который можно и нужно полагаться.
На этом этапе многие команды после озарения переходят сразу на этап дизайна — продумывают интерфейс и реализацию, проектируют фичу. Не надо так: велик риск того, что вы будете решать не ту проблему, или делать это не самым оптимальным способом.
Важно воспринимать идею как сигнал о проблеме, который требует проверки. Не привязывайтесь к идее, и не начинайте проектировать решение. Оставьте себе максимально широкое простанство вариантов.
2. Идея → Гипотеза.
То, что вы получили на первом этапе — это еще не сигнал к действию. Теперь нужно выдохнуть и посмотреть на нее критически: а какую проблему мы решаем? Действительно ли такая проблема существует у наших клиентов? Мы точно не преувеличиваем ее масштаб и важность?
Тут важно сформулировать вашу находку как гипотезу проблемы, а не как готовое фича-решение.
Например, “Нужно дать юзерам возможность добавлять в избранное” — это плохо, содержит решение.
А вот “Мы видим, что в сегменте X churn rate выше, чем в среднем по конкурентам. Может это потому, что они не готовы принять решение здесь и сейчас? Надо проверить”.
3. Хранение и приоритезация гипотез.
Теперь нужно определиться, какую проблему решать в первую очередь. Для этого нужно приоритизировать вновь найденную проблему среди уже существующих. Для этого нужно привести все проблемы к общему знаменателю — пользе для бизнеса, выраженной в деньгах, клиентах и так далее.
Иногда на этом этапе может не хватать данных для приоритезации — это нормально. В этом случае может потребоваться дополнительное исследование: залезть в данные, поговорить с юзерами или экспертом.
Тут плохо работает product sense — велика вероятность, что в вас будет говорить эмоциональная привязанность к идее и вы будете “подгонять” ответ.
У меня обычно есть 2 бэклога: первый с сырыми идеями, на уровне “А вдруг”, “А что если”. Для такого бэклога достаточно верхнеуровевой приоритезации на основе вашей экспертизы. Это слабо организованный чердак продуктовых идей, куда попадает абсолютно все. Этот бэклог только для внутреннего использования, его мы не показываем команде и стейкхолдерам.
Во второй бэклог попадают гипотезы с формулой “Если мы починим X, то получим Y’’. У таких гипотез есть понятная ценность, по которой их можно отсортировать сверху вниз. Этот документ уже становится публичным и используется для синхронизации со стейкхолдерами и командой. Задачи в данном бэклоге могут объединяться в смысловые группы — продуктовые эпики.
Например, вы заметили, что ваша секция “Прайсинг” существенно отличается от конкурентов. Этот паттерн повторяющийся, и вы знаете, что они серьезно подходят к разработке продукта и тестируют все изменения. Стоит ли бросаться копировать их подход? Нет. Но это совершено точно сигнал к тому, чтобы углубиться в тему: посмотреть, сколько переходов/платежей генерит СTA из секции и сравнить с бенчмарком; изучить, как ваши пользователи взаимодействуют с этим разделом и с какими проблемами сталкиваются.
Некоторые гипотезы останутся в Бэклоге 1 навсегда — это нормально. У нас нет цели сделать все — есть цель сделать то, что принесет максимальную пользу для бизнеса и счастья пользователей.
Приоритезируйте без сожалений: “нет” — самое важное слово в работе продуктовой команды.
4. Проектируем и тестируем решение.
Теперь берем самую верхнюю гипотезу проблемы и несем ее команде.
На этом этапе важно не формулировать решение в условии задачи. Любой фрейминг ограничивает нашу креативность. Вы же работаете с профессионалами, дайте им делать свою работу!
Плохая задача продуктовому дизайнеру: “Нужно сделать кнопку больше и ярче”
Хорошая задача продуктовому дизайнеру: “Нужно сделать CTA более заметным.”
Я скептически отношусь к тому, когда UX дизайнер приносит 1 вариант решения. Здорово, когда мы используем майндсет “я знаю, что мало что знаю” и рассматриваем все пространство решений. Если сместить угол на это, то получается, что мы все еще работаем с “Гипотезами решений”, которые еще предстоит исследовать.
По этой же причине на этом этапе важно тестировать гипотезы решений: проводить ux тесты, fake door и так далее. Чем раньше мы это сделаем — тем дешевле и быстрее получится обратная связь.
Конечно, бывают случаи, когда команда провела много исследований и хорошо изучила свои пользователей. Иногда такое можно записать на счет своего “product sense” и двигаться дальше.
На этом этапе важно оставаться пластичным — воспринимать все возникающие варианты как “гипотезы решения” до определенного предела. И быть готовым вновь и вновь проходить цикл получения обратной связи, возвращаясь на этап проектирования.
5. Тестируем и/или раскатываем решение.
Мы перешли к самому дорогостоящему этапу — разработке и количественному тестированию. Все, что будет сделано здесь будет стоить компании денег, а самое главное, времени.
Наша задача на этом этапе — убедиться, что придуманная нами “гипотеза решения” действительно решает проблему на широкой выборке пользователей и при этом ничего не ломает в связке.
Рассматривайте ваши действия здесь под этим углом — если профит понятен, риски минимальны, а степень вашей уверенность — велика, можно пропустить этот этап (да, так тоже можно). В конце концов, ваша цель — нанести непоправимую пользу, и фактор времени играет не последнюю роль в счастье пользователей.
На этом этапе легко скатится в привычный паттерн. Помните, что любое исследование — это инструмент достижения цели, но не самоцель.
6. Оцениваем результаты и принимаем решение.
Как бы вы оказались к этой точке, на этом этапе наступает время аналитики и ретроспективного анализа. Независимо от того, делали вы А/В, копили данные по когортам, или положились на свой product sense, нужно сравнить то, что мы получили с тем, что планировали на этапе гипотезы проблемы и гипотезы решения. Для этого нужно было четко сформулировать ожидаемый результат, но вы же это уже сделали, верно? :)
Если рост метрик оправдал ожидания, то нужно определить следующие шаги (например, как будем раскатывать на всех пользователей). Здорово поделиться этим и разделить успех с командой.
Если ожидания не оправдались — проанализировать причины, сформулировать новые гипотезы и вернуться с ними на новый круг. То, куда стоит вернуться, будет определяться результатами вашей аналитической работы.
Мы видим сигналы, что проблема есть, но наше решение решало ее не самым оптимальным образом? Ок, возвращаемся на шаг проектирования “Гипотезы решения”.
Видим, что рост метрик не такой уж и значительный и, похоже, проблема не болит или болит не настолько, чтобы за нее платить? Ок, вернемся на этап “Гипотезы проблемы” и посмотрим, что мы могли понять не так.
Критическое мышление и непредвзятость - это важнейший метанавык.
Теперь у вас есть ответы на вопросы "Что, как, когда".
Схема в хорошем разрешении лежит здесь, а для связи есть linkedin, tg @irina.beltyukov и, конечно, мой тг канал про всякое айтишное.