Зменшуємо кількість хибних рішень і заощаджуємо гроші за допомогою швидкої валідації гіпотез

Усі статті, обговорення, новини про продукти — в одному місці. Підписуйтеся на на телеграм-канал!

Привіт, мене звати Любомир Півторак, і я CPO застосунку для знайомств Hily в українській продуктовій IT-компанії appflame. На DOU Day у травні я вже торкався теми цієї статті, а тепер хочу додатково поділитися корисними технічними деталями та інструментами.

У продакт-менеджменті я вже дев’ять років, з яких п’ять — на позиції CPO. За цей час мені з командою вдалося запустити з нуля два наші флагманські застосунки Hily та Taimi, які зараз налічують понад 51 мільйон користувачів і входять до десятки найпопулярніших дейтингових застосунків у США. Звісно, реалізовували й продукти, які врешті не злетіли та які були змушені закрити.

Тож на досвіді запуску і закриття продуктів я продемонструю, як заощадити десятки, а то й сотні тисяч доларів, валідуючи гіпотези швидше та простіше. Також поділюся, як нам вдалося масштабувати Hily й підтримувати success rate гіпотез >30% (тобто впроваджувати більше змін, які дають значний результат).

Ця стаття буде корисна продакт-менеджерам, маркетинг-менеджерам, а також тим, хто планує запустити свій продукт.

Помилки в підходах до розробки продукту

У нашому застосунку для знайомств Hily був розділ стримінгу, і він був досить популярний: близько 30% користувачів хоча б раз пробували спілкуватися в такий спосіб.

Ми розуміли, що в нас є проблема в продукті, яку ми можемо розв’язати цією фічею, — це встановлення першого контакту між користувачами. Зазвичай повідомлення типу «Привіт!», «Як справи?», «Маєш гарний вигляд» ні до чого не приводять, тобто не переростають у тривалу комунікацію або глибокий діалог.

У нас виникла гіпотеза: розробити фічу blind dating. Користувачі заходять на стримінг, алгоритм метчить пару і пропонує три хвилини із заблюреними камерами поспілкуватися (при цьому дає підказки, про що саме), познайомитися ближче. Коли час вичерпається, є можливість обрати, продовжувати спілкування чи ні. Якщо так, їхні камери розблюряться. Якщо ні, вони продовжать пошук інших людей.

Blind dating

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

За попередніми оцінками, на розробку фічі мало піти три тижні, а за оптимістичним сценарієм — взагалі два. Насправді ж розробка зайняла два місяці. Ми не врахували багатьох технічних нюансів, які виявилися в процесі. Наприклад, робота з різними відео потоками: якщо користувачі стають у чергу, як їх потрібно метчити; а що, як користувач згорне застосунок; як connection має / не має обриватися тощо. Оскільки ми вірили, що це може бути справді революційна фіча (унікальна та інтерактивна), то не хотіли випускати її «сирою», а прагнули забезпечити її нормальне функціонування.

Критерієм успіху цієї фічі та знаком, що потрібно залишити її в продукті, для нас було б використання більш ніж 30% користувачами, які спробували фічу та повернулися б до неї повторно.

Коли ми запустили цю фічу, то зрозуміли, що тільки 8% користувачів розпочинають пошук, а з них успішно закінчують — лише 30%.

В рамках нашої аудиторії це вкрай мало. Ми почали шукати причини що ж пішло не так, бо вірили, що це класна фіча, яка точно має потенціал. Отож протягом наступного місяця зробили ще дві-три швидкі ітерації покращення функціональності: запустили більш явне промо; підсвітили цінність цієї фічі; розіслали користувачам сповіщення в праймтайм про появу такої фічі тощо. Все для того, аби користувачі зайшли та просто спробували нову можливість. І хоча використання вдалося підняти з 8% до 13%, ми зрозуміли: фіча не працює.

Як провалідувати велику фічу за тиждень, а не розробляти її два місяці, щоб дізнатися результат?

Запустити опитування (surveys)

Ми хотіли зрозуміти, чому фіча blind dating не працює. Для цього запустили серед користувачів survey: чи бачили ви цю фічу, чи розумієте її, як вам нова функціональність, чому не користуєтеся нею.

І от за результатами цього дослідження ми з’ясували, що більшість користувачів не зацікавлена в такому форматі спілкування. Причини були різні: «незручно», «я в дорозі»; «не хочу просто зараз вмикати камеру, щоб мене бачили»; «мені ніяково» тощо. Виникали бар’єри, яких ми не врахували під час розробки фічі, бо припустили, що якщо в нас хороше використання лайвстримінгу, то користувачі захочуть спробувати й цю фічу. Насправді більшість аудиторії була не готова.

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

Тож по факту це опитування могло б показати нам, наскільки аудиторії відгукнеться ця фіча. Відповідно, ми могли б навіть не розробляти її, а побачити ці цифри ще спочатку.

Важливо! В опитуваннях (surveys) потрібно ставити запитання так, щоб користувачі правильно зрозуміли їхню суть.

Якщо говорити про нашу систему опитувань — це наш внутрішній і власноруч створений сервіс, тож він досить персоналізований та «гнучкий». Ми самі можемо обирати логіку: коли і як запускати опитування; де саме показувати (наприклад, після конкретного екрана або дії користувача); налаштовувати if-then умови в самому survey.

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

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

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

Провести Fake Door Test

На Hily нові користувачі приходять органічно та через перформанс-маркетинг. В останньому випадку користувач бачить рекламу в різних нетворках, переходить за нею, потрапляє в App Store / Google Play та завантажує наш застосунок. Далі він обирає спосіб реєстрації в застосунку.

Ми бачили, що користувачі, які приходять зі Snapchat і реєструються через нього, активніше використовують основний продукт та частіше повертаються.

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

Після кейсу з blind dating ми знали: перш ніж додавати велику фічу, спочатку потрібно зрозуміти попит на неї (наскільки це доцільно для користувачів).

Не маючи можливості провести опитування (адже користувач ще не зареєструвався та не зайшов у сам застосунок), ми вирішили провести Fake Door Test — імітацію функціональності для замірювання конверсії.

На екрані ми додали кнопку реєстрації через TikTok, але фактично вона не працювала. Коли користувач натискав на неї, з’являвся поп-ап: «Вибач, цей метод зараз недоступний, спробуй інший».

Ми нічого не втратили через запуск такого тесту — користувачі все одно реєструвалися через інші методи і % проходження реєстрації від інсталу був такий же.

Натомість ми зрозуміли, що попит на реєстрацію через TikTok виявився набагато нижчим (8%), ніж через Snapchat (30%), а складностей у підсумку могло бути чимало:

• технічна підтримка цього способу реєстрації в майбутньому;
• що більше в користувачів варіантів, то складніше їм обирати.

Тож буквально за день ми збагнули, що не варто розробляти таку функціональність у продукті.

Створити рубрику Feature Requests

Feature Requests — це розділ, у якому користувачі можуть:

• додати ідеї бажаних фіч у продукті;
• проголосувати за чи проти ідей інших користувачів;
• побачити статус ідей (in process, done).

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

Важливо! Для того щоб уникнути ситуації, коли користувачі голосують за варіанти, які вже мають найбільшу підтримку, ми зробили механізм «шафлінгу» ідей. Тобто завжди спочатку відкривається вкладка New й ідеї відображаються в рандомізованому порядку.

Далі ми попередньо валідуємо ідеї, намагаємося зрозуміти, які з них мають потенціал, пріоритезуємо, запускаємо швидкі й недорогі А/В-тести та аналізуємо результати.

У середньому за один квартал ми отримуємо 100 Feature Requests. З них 10% беремо в роботу, близько 5% є успішними. Наші найтоповіші реквести мають понад 100 тис. голосів — користувачі самі активно залучаються до голосування, тож немає потреби якось додатково їх мотивувати. Хоча в нас є ідеї, як ми хотіли б розвивати цей інструмент надалі.

Як і опитування (surveys), Feature Requests — це не стовідсоткова істина. Не завжди те, що хочуть користувачі, потрібно вашому продукту і буде ефективно для бізнесу. Але це точно один із сигналів, на який можна спиратися під час ухвалення рішень з розробки певної функціональності. Він допоможе вам краще розуміти свою аудиторію та її пріоритети.

Challenging & Grooming

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

Челенджинг — це процес рев’ю іншими продакт-менеджерами (як правило з іншої кросфункціональної команди). Ціль — довести, що це потрібно робити та чому, а також спростити завдання так, щоб можна було через мінімальні зміни переконатись у доцільності. Учасники ставлять багато запитань, діляться фідбеком та своїм досвідом. У цьому є цінність для обох сторін, адже ніхто не хоче витрачати свій час на те, що не дасть результату.

За підсумками останніх трьох челенджів було ухвалено такі рішення:

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

Щодо технічного грумінгу, то ми збираємося з технічною командою і продумаємо, як фіча буде працювати «під капотом» від початку до кінця. Що більше технічного грумінгу на старті, то краще.

Урок 1. Необов’язково розробляти фічу, щоб зрозуміти, у скількох користувачів вона знайде відгук

Помилки під час запуску нових продуктів і як їх уникнути

Дзвіночок про дедлайни

Як ви вважаєте, за скільки часу можна визначити, чи злетить продукт?

Перший продукт я закрив за півтора року, другий — за рік. Сьогодні я переконаний, що для розуміння успішності продукту достатньо трьох місяців. Якщо вам цікаво, як ми проходили цей еволюційний шлях, рекомендую прочитати мою попередню статтю «Як та чому ми закрили продукт: кейс мобільного застосунку Frenzie».

Нижче я розповім детальніше, які інструменти використав би зараз, щоб уникнути попередніх помилок, та які уроки для себе виніс.

Помилки під час розробки MVP

Перед запуском нового продукту перед продакт-менеджером завжди постає питання: а що ж має бути в MVP? Які фічі дійсно треба додати, а які можна скіпнути? Що є критично важливим для користувачів, а що ні?

Часто трапляється, що продакт-менеджер або команда «закохуються» у свою ідею, починають вірити, що такий продукт потрібен, а та чи інша фіча спрацює. Так сталося і з нами.

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

Та під час розробки MVP ми припустилися кількох помилок:

• додали в перший MVP багато фіч, які спочатку не потрібні;
• не провалідували дешево те, що основна функціональність достатньо розв’язує проблему користувачів, а займались її ітеруванням.

Всі перелічені хиби об’єднує те, що ми пішли неправильним шляхом розробки MVP (How NOT to make an MVP).

Розробка MVP

Щоб уникнути цих помилок, важливо розуміти, що в MVP варто враховувати саме декілька аспектів: чи дійсно працює продукт, чи він юзабельний, чи зрозумілий UX. І найголовніше — чи дійсно продукт може розв’язати проблеми та задовольняти потреби користувача.

Тут добре керуватися класичним принципом Парето: 20% ваших зусиль дадуть вам 80% розуміння, чи злетить ваш продукт.

Що нам варто було робити з Frenzie? Простіший MVP та більше радикальних змін.

Помилки під час валідації маркетингу

Під час запуску Frenzie ми також припустилися помилок:

• не провалідували маркетинг одразу, а чекали запуску MVP;
• керувалися гіпотезою, що ціна проведення нових користувачів через перформанс-маркетинг буде набагато нижчою, ніж у дейтингу, адже не матиме таких обмежень;
• думали, якщо знайдемо спосіб зробити класний продукт, то зможемо придумати, як на цьому заробляти.

Проте цього не сталось.

Як максимально дешево провалідувати маркетинг на старті

Для швидкої валідації маркетингу необов’язково мати реальний (готовий) продукт, на якому ви будете перевіряти основні метрики:

• яка ціна залучення нових користувачів;
• яка готовність користувачів платити за продукт;
• яка конверсія потенційного завантаження застосунку.

Є набагато простіші рішення на ранніх етапах:

• pre-order в App Store та Google Play;
• імітований App Store та Google Play;
• запуск рекламних кампаній на Landing Page.

Як це виглядає? Ще не маючи готового продукту, ви можете запустити передзамовлення в App Store та Google Play або ж використати аналогічний інструмент — імітований App Store та Google Play. Користувачі натискатимуть кнопку «GET», але замість завантаження застосунку їх перекидатиме на Landing Page (яку, звісно ж, дешевше та швидше розробити, ніж продукт). Так ви зможете зрозуміти, яка у вас конверсія потенційного завантаження застосунку та яка ціна залучення нових користувачів.

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

• Користувачі можуть записатися у waitlist, і коли ви вже будете готові до запуску, їм усім прийде розсилка: продукт доступний для завантажування. Для продуктів з нетворк-ефектами (продукти, цінність від яких для користувача зростає зі збільшенням кількості інших користувачів цього продукту) така стратегія була б правильнішою.
• Можна піти далі й продавати підписку на лендингу, щоб зрозуміти, яка буде конверсія та готовність користувачів платити за продукт. Ці гроші можна одразу повернути користувачу і повідомити, що сервіс в розробці.

Landing Page Frenzie

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

Урок 2. Необов’язково мати продукт, щоб зрозуміти, у скільки вам обійдеться новий користувач та чи запрацює ваша Unit-економіка

Яким має бути ефективний продуктовий процес

Щомісяця ми тестуємо на Hily близько 50 гіпотез та реалізовуємо до 30 A/B-тестів. Вже орієнтовно рік нам вдається масштабувати продукт та підтримувати success rate гіпотез >30%, тоді як індастріз-стандарт становить 10–20%.

Динаміка success rate Hily

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

• Досвід та винесені уроки з помилок вище.
• Використання (водночас простого і складного) методу пріоритезації ICE.

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

Impact — потенційний вплив наших змін на таргет метрику. Оцінюємо: low, high, very high.

Шкала Impact

Confidence — це те наскільки ми впевнені в цій ідеї, підкріплено конкретними даними. Оцінюємо: від 1 до 3 points.

Шкала Confidence

Effort — зусилля, які потрібні на реалізацію. Оцінюємо: small, medium, large (ми рахуємо в Story Points).

Шкала Effort

Цей метод дає нам можливість ліпше зрозуміти потенційний вплив наших змін на таргетметрику й, відповідно, краще пріоритезовувати наші рішення, а також прибирає фактор суб’єктивності, який ставав на нашому шляху, коли ми «закохувалися» у свої гіпотези.

Як це виглядає на практиці? Подивімося на приклад нижче.

Допустимо в команди є квартальна ціль: збільшити ретеншен наступного дня на 10%.

З попереднього досвіду ми знаємо, що 40% користувачів, які роблять 10 лайків у першу сесію, мають ретеншен наступного дня 60% (інші 60% користувачів — 40%). Якщо ми збільшимо їх у структурі до 45%, то загальний ретеншен зросте з 50% до 52% (40% від нашої цілі). Тож, відповідно, до шкали Impact буде very high (5 балів).

Шкала Impact (приклад)

Як підтвердження нашої гіпотези ми маємо Data Validation (2) — ми провели аналітичне дослідження і зрозуміли з нього різницю в ретеншені різних сегментів + Closed Experiment (2) — у нас є успішний попередній досвід коли ми піднімали % користувачів, які роблять певну кількість лайків в першу сесію і отримували приріст в ретеншені. Отже, відповідно до цього, Confidence буде High (4 бали).

Шкала Confidence (приклад)

Розробники сказали нам, що на цю таску може знадобитися 8–13 Story Points, тож Effort буде M (3 бали).

Шкала Effort (приклад)

У підсумку маємо такий підрахунок.

Шкала ICE Result (приклад)

Зараз у Hily ми стараємось реалізовувати ті фічі, які мають хороший скоринг (>50). Оскільки приклад вище має 133 бали, то цю гіпотезу варто реалізовувати. Але яка її пріоритетність?

Якщо ми використаємо цей метод для наших 50 гіпотез на місяць, то можемо отримати таку пріоритезацію їхньої реалізації.

Пріоритезація гіпотез

Деякі фічі, які мають менш ніж 50 балів, ми можемо допрацьовувати на моменті проєктування. Наприклад, спробувати спростити в реалізації фічу з high / very high effort до low / medium. А фічі, які мають low condidence, very high impact та low effort (дешеві в розробці) — швидше та менш затратно зробити, ніж проводити додаткові валідації.

Цей підхід зараз дає нам можливість масштабувати наш продукт, покращувати продуктові метрики, мати хороший success rate наших гіпотез та робити осмисленіші зміни, які мають більший вплив на продукт.

Висновок

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

Та пам’ятайте про головне:

• Необов’язково мати продукт, щоб зрозуміти, у скільки вам обійдеться новий користувач та чи запрацює ваша Unit-економіка.
• Необов’язково розробляти фічу, щоб зрозуміти, у скількох користувачів вона знайде відгук.
• Щоб збагнути успішність продукту, вистачить і декількох маленьких ітерацій.
• Досягти та підтримувати success rate гіпотез >30% — цілком реально.

Буду радий відповісти на ваші запитання в коментарях під статтею або в LinkedIn, а також чекатиму на фідбек.