Як валідувати продуктові гіпотези. Досвід 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, data that 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 this is 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 this is 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 recommend you 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. Experiments With, 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.
Fast Moving 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 approach and what you by 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 рішення завжди є шанс, що дані не відображають повної картини. Як ти балансіруешь між даними і інтуїцією?

Балансування між даними і інтуїцією? Не рекомендую балансувати між ними :)

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

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

— Як виглядає хороша гіпотеза і який підхід до пріоритизації ти використовуєш?

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

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

Дані.
Контекст.

— Що ти б порадив компаніям, які хочуть побудувати experimentation culture?

Мені здається, що один із тих аспектів, які уповільнюють швидкість експериментів — це пошук інструментів з очікуванням від них ефекту срібної кулі. В результаті, робота з інструментами для експериментів займає більше часу і сил, ніж самі експерименти.

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

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

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

З-за того, що ти часто профдеформирован і варишся в контексті корисно залучати колег і використовувати колективний розум як джерело різнобічних думок «тут і зараз».

— Як виглядає хороша гіпотеза і який підхід пріоритизації ти використовуєш?

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

— Що ти б порадив компаніям, які хочуть побудувати experimentation culture?

Перестаньте кидатися на будь-яку «проривну» ідею або новий напрямок, щодо якого ви впевнені, що будь вистрілить. Я в це просто не вірю і вмикаю трушного PdM, яка в усьому сумнівається. Критичне мислення — наше все.
Робіть MVP, пілоти, прототипи, навіть макраме (якщо треба), але покажіть це реальним користувачам. Чи вони готові голосувати гаманцем за вашу ідею? Найчастіше — ні. А ви вже витратили місяці на розробку...

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

Резюме

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

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

Опубліковано: 01/11/18 @ 11:15
Розділ Блоги Пошуковики

SEO Блог