×

Как валидировать продуктовые гипотезы. Опыт Google, MacPaw и SendPulse

Всем привет, меня зовут Руслан. За 4 года карьеры проектного менеджера я увидел много грамотно написанных проектов, которые так и не стали успешными, медленно превращаясь в зомби-проекты. У всех были одни и те же недостатки: ориентир на чутье вместо данных, неправильная приоритизация, уверенность в своих идеях и нежелание их валидировать.

Попытка понять, чем отличаются успешные продукты от неуспешных, привела меня в продуктовый менеджмент. Именно поэтому последний год я работаю над внедрением продуктового подхода во всей нашей компании. 60% наших проектов — это стартапы, 40% — средний бизнес, которому нужна автоматизация процессов.

В прошлой статье я рассказал о самых распространенных подходах к приоритизации, а также, как это делают в MacPaw, Readdle, Grammarly и EduNav.

В этой статье вы узнаете, как сформировать и провалидировать гипотезы, создать культуру экспериментов внутри компании и как балансировать между данными и интуицией на примерах продуктового менеджмента в Google, MacPaw и SendPulse.

Почему важно иметь гипотезу

Типичный подход представителей бизнеса — «Let’s build 10 things and find out what will work» — почти всегда ни к чему хорошему не приводит. И почти всегда приходится объяснять, что необходимо избегать крупных финансовых вливаний и максимально быстро проверять гипотезы. В ответ такому клиенту всегда следует фраза: «Why don’t we experiment 10 things and build the 3 that worked?».

Но даже при втором подходе можно потратить тысячи долларов и сотни часов, валидируя что-то, что вообще не даст никакого результата, либо даст, но он будет несоизмерим с потраченными средствами. Помните случай, когда в Google тестировали 41 оттенок голубого? Они использовали 2 разных оттенка голубого. Один на домашней странице поисковика, а другой — на странице Gmail. Чтобы узнать, какой цвет самый эффективный, они начали тестировать оттенки, чтобы в итоге стандартизировать цвет на всей платформе. В 2009-м это послужило причиной ухода Lead Desiner’а Douglas Bowman, который заявил:

«Yes, it’s true that a team at Google couldn’t decide between two blues, so they’re testing 41 shades between each blue to see which one performs better. I had a recent debate over whether a border should be 3, 4 or 5 pixels wide, and was asked to prove my case. I can’t operate in an environment like that. I’ve grown tired of debating such miniscule design decisions. There are more exciting design problems in this world to tackle».

Какая была проблема у Гугла? Какая была гипотеза? Стоило ли тратить время на столь незначительное дизайн-решение? Я согласен с Дугласом: порой чрезмерная зависимость от данных и over-analytical mindset мешают принимать хорошие решения. Похожая история была и в Yahoo, когда они тестировали 30 новых логотипов. Я думаю, что четко сформулированная гипотеза и рациональная приоритизация, на тот момент, привела бы команду Гугла к более значащим результатам. Именно поэтому формировать гипотезы чрезвычайно важно. Об этом писали еще до того, как методология Lean Startup стала популярной:

Как формировать гипотезу

Teresa Torres, создатель блога Producttalk предлагает следующий подход:

1. Know what you want to learn

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

2. Understand what level you are testing

Нужно понять, какой уровень продукта мы собираемся провалидировать.

Представьте, что вы работаете над Sign Up flow своего Landing Page. Ваш дизайнер предлагает 2 варианта, вы делаете сплит-тест и выбираете победителя. Проблема в том, какое заключение можно сделать, если один дизайн оказался хуже второго? Можно ли сделать вывод, что он действительно хуже? В данном случае будет полезным понять, какой продуктовый уровень вы валидируете.

Выделяют следующие уровни:

Value level — на этом уровне мы можем провалидировать проблему, которую будет решать продукт, и понять, стоит ли вообще эту проблему решать.

Feature level — это сам функционал, который отражает ценность продукта.

Design level — это то, как именно функционал будет работать с точки зрения UX.

Feasibility level — это всё, что касается технической реализации функционала.

Возвращаясь к примеру с Landing Page. Мы можем сделать заключение, что Sign Up форма не была юзабельна, только если это была валидация дизайн-уровня.

Может оказаться, что текст на лендинге, который объясняет преимущество нашего продукта, не резонирует с проблемой пользователей, и именно поэтому первый Landing был хуже. В таком случае это будет валидация уровня Value.

Или может оказаться, что Landing был сделан криво и страница загружалась 10 секунд, что будет относиться к уровню feasibility.

Прежде чем проводить любую валидацию, нужно спросить себя: «Уверен ли я в своём value proposition? Уверен ли я, что это правильная фича? Уверен ли я, что это тот дизайн? Уверен ли я, что это вообще возможно? И что из всего этого я хочу валидировать?».

3. Build hypothesis right

Хорошая гипотеза состоит из ответов на 5 вопросов:

  • Какое изменение?
  • Какой результат?
  • Для кого?
  • На сколько?
  • Как долго?

Самым сложным в формировании гипотезы по такому шаблону является ответ на вопрос «На сколько»? Ответ на этот вопрос даёт понять, какую отдачу ты ожидаешь получить после валидации.

Подробнее прочитать о том, как следует формулировать гипотезы, можно на Product Talk.

Какие подходы валидации гипотез бывают

A/B testing

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

В A/B тестировании самое важное — определить размер выборки для того, чтобы результаты были статистически значимыми. Также, определив размер выборки, мы можем приблизительно понять, сколько будет длиться сплит-тест.

Steve Wu, Senior Product Manager at Ever’s, отлично объясняет весь процесс сплит-тестирования в своей лекции.

Jon Noronha, продуктовый менеджер Optimizely, советует задуматься о сплит-тестировании, только если у вас есть как минимум 10 000 monthly active users. Но что делать, если вы только начали, и у вас нет такого трафика? К вашим услугам другие способы валидации гипотез.

User interview

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

Usability помогает понять, смогут ли вообще юзеры использовать продукт и достичь своей цели. Discovery-интервью позволяет детальнее вникнуть в самого пользователя и ответить на вопросы: «Кто? Где? Зачем? Как?».

Главный вопрос — «Сколько интервью нужно провести, чтобы подтвердить или опровергнуть гипотезу?».

  • Gaskin, Griffin и Hauser советуют 10-30 интервью;
  • Daniel Bertaux в своём социологическом исследовании 1981 года сказал, что 15 — это наименьшая допустимая выборка;
  • Greg Guest сделал заключение в своем этнографическом исследовании, что ему хватило 12 интервью;
  • Jakob Nielsen говорит, что в большинстве случаев 5 достаточно.

На самом деле нет правильной цифры, ведь нам приходится делать разные интервью в разных доменах с разными группами населения.

Мне кажется разумным начать с 5 и интервьюировать до тех пор, пока респонденты перестанут давать новую информацию. Для небольших изменений в продукте 5-7 интервью может хватить. Для запуска нового продукта может понадобиться 50-70.

В своей статье Michael Margolis, UX Research at GV, part дает отличные советы по проведению пользовательских интервью.

Card Sorting

Card sorting — это метод для структурирования информации, построения лучшей навигации и создания информационной архитектуры.

Давайте представим, что вы разрабатываете сайт для аренды машин. Ваша компания предлагает более 60 моделей. Как бы вы раскидали эти машины по категориям, которые позволят людям быстро найти свой идеальный транспорт? К примеру, можно создать следующие категории: семейные машины, машины класса люкс, представительские машины. Но пользователи могут не иметь ни малейшего понятия, в чем разница. Тут может помочь card sorting. Вы просите своих пользователей раскидать транспорт по категориям, которые им понятны, а затем наблюдаете за паттернами, которые возникают.

Детальнее с этим методом и его видами можно ознакомиться на nngroup.com.

Survey

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

Как правильно составлять вопросы для своего опросника, можно прочитать в блоге Neil Patel.

На SurveyMonkey описывают, как посчитать количество респондентов для опроса.

Как валидируют гипотезы в Google, MacPaw и SendPulse

Itamar Gilad, Product, Strategy and Growth Consultant, Ex-Google PM

— When making data-driven decisions there is always a chance, that data doesn’t capture a complete story. How do you balance between data and intuition?

Data never tells a whole story. You have to analyze and interpret the data to understand what’s really going on, and often you need to use qualitative research to answer the question «Why is this happening?». Consider this example — sales went down 5% last week.

What does it mean? It could mean that you pushed a bad code change that is hurting conversion. It could mean that something in your pipeline is not working properly. It could mean that a new competitor is entering your market. All of these are serious issues. However, it can also be that out measurements were inaccurate and therefore the data is not reliable, or that fluctuations of +/-5% are normal, or that there was a one-of abnormal event. In these cases, this data point is far less important. So we need to ask ourselves: what does it mean? why is this happening? is it important? how can we further test and validate? Here is where human skills: pattern detection, coming up with theories, weighing up options and intuition, — are very important.

— What would you recommend for companies that want to build a culture of experimentation?

The first thing is to realize that in tech the future is unknowable and therefore unpredictable. This is very different from projects such as designing a bridge, a car or a new type of consumer packaged good where the level of uncertainty is far lower. A/B experiments run by Netflix, Microsoft, Google, and many other companies show that at most one in three ideas yields positive results. How do you know which ideas these are? Not testing is putting blind bets. With experiments, you reduce the risk of investing in the wrong things significantly.

The other challenge I see in many organizations is the belief that experimentation is a slow and inefficient way to build products. Going all-in on one idea feels more effective to many people.

I try to point that:

  • This approach is optimizing for output (code, launches) rather than outcomes.
  • By testing more ideas we are more likely to generate a high-impact product quicker.
  • Moving fast on development and experimentation aren’t mutually exclusive. In fact, for this reasons, I developed the GIST planning framework that allows testing many ideas while making rapid progress on the goals.

Lastly, I would recommend organizations to invest in their data infrastructure, experimentation framework, and dashboarding tools. Companies that do that put themselves at an advantage since they are able to learn much more rapidly.

— How to structure good hypotheses and what approach you normally use for prioritization?

I like this simple template:

We believe that ____ (doing this)
for ___________(target group)
Will achieve _______________ (this outcome or impact).

Example. We believe that showing related items under the shopping cart for desktop shoppers who have selected one item, will increase the average shopping cart value by up to 10% and reduce abandonment by 5%.

For prioritization, I like ICE scores (Impact, Confidence, Effort). It’s explained in detail in this article.

Ярослав Степаненко, Product Marketing Manager в MacPaw

— Когда приходиться принимать data-driven решение всегда есть шанс, что данные не отражают полной картины. Как ты балансируешь между данными и интуицией?

Балансирование между данными и интуицией? Не рекомендую балансировать между ними :)

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

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

— Как выглядит хорошая гипотеза и какой подход к приоритизации ты используешь?

Хорошая продуктовая гипотеза всегда основана на качественных и количественных данных. Опять таки, одних данных не будет достаточно, ровно как и только контекстом невозможно ограничиться при формировании гипотезы.

Порядок этих двух аспектов при формировании гипотезы:

  1. Данные.
  2. Контекст.

— Что ты бы посоветовал компаниям, которые хотят построить experimentation culture?

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

Имею хороший пример: 25 октября мы организовывали конференцию Growth Marketing Stage, одним из докладчиков на которой был David Ly Khim. Senior Growth Marketing Manager в HubSpot. Он очень детально рассказал о том, как его команда формирует гипотезы и проводит эксперименты. Ни слова про инструменты. Упор на качественно собранные данные и синки команд, которые работают над разными экспериментами одновременно.

Дмитрий Горин, Product Manager в SendPulse

— Когда приходиться принимать data-driven решение всегда есть шанс, что данные не отражают полной картины. Как ты балансируешь между данными и интуицией?

Тут приходит на помощь здравый смысл и желание решить конкретную проблему пользователя. Нельзя быть ведомым только интуицией или тупо следовать данным. Здравый смысл — то, что не дает заменить людей на скрипт принятия решений.

Из-за того, что ты зачастую профдеформирован и варишься в контексте — полезно привлекать коллег и использовать коллективный разум как источник разносторонних мнений «здесь и сейчас».

— Как выглядит хорошая гипотеза и какой подход приоритизации ты используешь?

Наличие гипотезы — уже хорошо :) Какой-то одной техники приоритизации, которую использую, — нет. Все зависит от множества факторов в определенный момент. Чаще всего — Story Mapping, MoSCoW, метод Джиро Кавакита и относительное взвешивание (нравятся своей легковесностью и возможностью их миксовать). Из тех, что хотел бы попробовать на практике — модель Кано и Qualitative Cost of Delay.

— Что ты бы посоветовал компаниям, которые хотят построить experimentation culture?

Перестаньте бросаться на любую «прорывную» идею или новое направление, насчет которого вы уверены, что по-любому выстрелит. Я в это попросту не верю и включаю трушного PdM, который во всем сомневается. Критическое мышление — наше все.
Делайте MVP, пилоты, прототипы, даже макраме (если надо), но покажите это реальным пользователям. Готовы ли они голосовать кошельком за вашу идею? Зачастую — нет. А вы уже потратили месяцы на разработку...

Используйте CustDev, будьте открыты к своим потенциальным пользователям и задавайте правильные вопросы (это хорошо описано в книге «The mom test» Rob Fitzpatrick). Проводите интервью до того момента, пока не закончатся инсайты или вы уже чувствуете, что нащупали основную волну. Не рвите связи со своими пользователями, они будут классными первопроходцами решения.

Резюме

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

Вы сможете вживую пообщаться на тему валидации продуктовых гипотез с Итамаром, Ярославом, Дмитрием и многими другими продуктовыми менеджерами на продуктовой конференции ProductSense в Минске 7-9 ноября. Специально для читателей DOU — промокод на −10% скидки. При регистрации укажите промокод «pro_500».

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Схожі статті




8 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Отличная статья. Порадовали ссылки на первоисточкики. Есть чего почерпнуть. Спасибо!

Удивительно, что упомянув Гугл в такой статье ни слова не сказано про их собственный метод тестирования идей — Sprint.

Привет! Отлично подмечено. Design Sprint от Google GV отличный способ протестировать идеи.

Если бы не продажа билетов в конце, была бы неплохая статья. А так осталась горечь )

Show Your Work! — рекомендую, там є пункт 9.
«Заробляйте, навіть Відродженню потрібні були спонсори. Мікеланджело намалював Сікстинську капелу тільки тому, що йому заплатили».

Привет! Спасибо за фидбек. При написании следующей учту!

Підписатись на коментарі