«Більшість компаній гинуть, тому що вони пропонують продукт, який не потрібен споживачам», — це відомий вислів Еріка Райса, автора методології Lean Startup. Розробка на основі гіпотез допоможе вашому проєкту уникнути цієї пастки. Вона спрямована на дослідження попиту на ваш майбутній продукт. Розпочати дослідження варто зі складання набору гіпотез про потреби споживачів. Вони відповідають на запитання, які проблеми та труднощі допоможе вирішити ваш майбутній продукт.

Формування гіпотез – це творчий процес, і тут складно дотримуватися певної процедури, але деякі правила все ж діють. Женя Акімов, маркетолог компанії з розробки мобільних додатків Devlight, розповість про алгоритм створення набору продуктових гіпотез і їх подальшу перевірку за результатами опитування користувачів.

Що таке розробка на основі гіпотез?

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

Ось кілька прикладів гіпотез для розробки продуктів з різних сегментів:

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

Чому в Devlight використовують розробку на основі гіпотез

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

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

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

Єдиний спосіб перевірити список гіпотез — якомога швидше надати продукт потенційному клієнту. Якщо ви послідовно дотримуватиметеся цієї методології, ви зрозумієте, що більшість гіпотез помилкові. Ви припускаєте, зазнаєте невдачі й щоразу змушені повертатися до початку, щоб перевірити нові гіпотези.

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

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

  • Яка гіпотеза в проекті є найбільш сумнівною?
  • Як це найшвидше перевірити?

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

Розгляньмо простий приклад. Скажімо, ми обираємо проєктний підхід (який ставить завдання, а не висуває гіпотези) до сервісу з продажу товарів. Ми вирішуємо додати до нього опцію доставки. Ми вирішуємо найняти кур’єрів, купити їм брендовий одяг, сумки, можливо, транспорт. Команда розробників створює сторінку, де можна ввести адресу доставки та бажану дату. Потім ми пишемо сервіс, який передає замовлення з магазину кур’єру, і додаток для цих кур’єрів. Що відбувається в негативному сценарії? – Ми втрачаємо сотні тисяч доларів.

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

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

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

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

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

Як перевірити гіпотезу про попит на продукт і цінність без розробки

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

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

  • Відданість ідеї блокує критичне мислення (типове для стартапів).
  • Бюрократичний апарат сприймає перевірку гіпотез як ту частину процесу розробки проєкту, за якою неминуче слідує реалізація, незалежно від результатів перевірки (типово для корпорацій). Навіть якщо всі перші тести показують, що продукт у його нинішньому вигляді не має шансів, він все одно йде в розробку.
  • Третя помилка – перевірка неважливих речей. Замість тестування ключових ризиків (попиту та цінності) перевіряються другорядні елементи, пов’язані з суб’єктивним сприйняттям (зовнішній вигляд, непрофільні функції тощо). У результаті витрачається час, а сам процес перевірки гіпотези знецінюється.

Перевірка гіпотези попиту на новий продукт

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

Необхідно вивчити цільову аудиторію і її завдання, щоб перевірити попит, іноді продати ще не створений продукт:

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

Перевірка гіпотези цінності нового продукту

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

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

Як створити та перевірити список гіпотез для продукту

Методологія HADI (Hypothesis – Action – Data – Insights) – це найпростіший алгоритм для циклічної перевірки ідей – від гіпотези через дію до даних і висновків.

Цикл управління розробкою на основі гіпотез починається з формулювання гіпотези відповідно до принципів «якщо» і «тоді». На другому етапі необхідно провести роботу для запуску експерименту (Action), потім зібрати дані за заданий період (Data), і в кінці зробити однозначний висновок про те, чи була гіпотеза успішною, що і як можна покращити, запустивши наступний цикл перевірки гіпотез (Insights).

Крок 1. Формування гіпотези

Тут ви формулюєте те, що хочете знати. Яку проблему ви намагаєтеся вирішити? Визначте, який рівень продукту ви хочете протестувати:

  • Рівень цінності — перевірте проблему, яку має вирішити ваш продукт. Зрозумійте, чи варто її вирішувати.
  • Рівень функцій – це функціональність, за допомогою якої користувач швидко усвідомлює цінність нашого продукту.
  • Рівень дизайну означає дизайн і візуалізацію. Як ваші функції працюють з точки зору взаємодії з користувачем? Простіше кажучи, чи люди інтуїтивно розумітимуть, як керувати, куди клацати та що робити з вашим продуктом?
  • Рівень здійсненності розробки на основі гіпотез стосується технічної реалізації всього, що ви створили.

Гіпотеза базується на принципі «Якщо…, то…». 

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

  • Вплив.
  • Впевненість.
  • Легкість.

ICE розраховується наступним чином:

Звичайно, це лише один варіант. Однак пам’ятайте, що формула для всіх гіпотез, які ви порівнюєте, повинна залишатися незмінною, а ваш ICE повинен мати той самий діапазон оцінок — або від 1 до 10, від 1 до 100, або іншу шкалу (визначте її на початку).

Вплив

Вплив оцінює, наскільки ідея позитивно вплине на показник, який ви намагаєтесь покращити. Щоб визначити вплив, ми ставимо наступні запитання: Наскільки це буде ефективним? Наскільки це вплине на показники (конверсія, утримання, LTV, MAU, DAU)?

Впевненість

Впевненість показує, наскільки ви довіряєте оцінкам впливу та простоті впровадження. Щоб визначити цю метрику розробки на основі гіпотез, вам потрібно відповісти на запитання: наскільки ви впевнені, що ця функція призведе до покращення, описаного в «Вплив» (Impact), і її буде так само легко реалізувати, як описано в «Легкість» (Ease)?

Легкість

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

Крок 2. Виконання дії

На початку кожного циклу ми беремо кілька гіпотез і починаємо перевіряти їх за допомогою наступних методів:

A/B тестування або спліт-тестування

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

Кількісне опитування користувачів

Скористайтеся спеціальними сервісами, що полегшують створення та проведення опитування. Наприклад, Survey Monkey. Подібні сервіси дозволяють вибрати потрібну аудиторію і поставити їй питання. З безкоштовним планом ви можете створювати анкети до 10 питань. Посилання на анкету можна розмістити на сайті або в соціальних мережах.

Якісне дослідження або розвиток клієнтів

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

  • Зручність використання (Usability) — допоможе зрозуміти, чи можуть користувачі взагалі використовувати ваш продукт для вирішення з його допомогою своїх завдань і досягнення поставлених цілей.
  • Відкриття (Discovery) – детально досліджує стан, проблеми та сприйняття користувачів певної групи. У таких співбесідах ми зазвичай задаємо питання типу «Хто? Як? Чому? Де?».

Скільки таких інтерв’ю вам потрібно, щоб перевірити гіпотезу? Зазвичай ми починаємо з п’яти. Потім ми продовжуємо, поки люди не перестануть давати нові відповіді. Ви можете зупинитися, як тільки інформація почне повторюватися. Для гіпотез перевірки невеликих змін продукту може бути достатньо 5-7 інтерв’ю. Для запуску абсолютно нового продукту — 50-70 інтерв’ю.

Крок 3. Аналіз даних

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

Потім, коли ваш експеримент закінчиться, ви можете визначити гіпотезу як підтверджену, спростовану або навіть відмовлену, якщо ви вирішите припинити її тестувати надалі через результати. Спочатку вирішуйте гіпотези з найвищим ризиком – так ви досягнете хороших результатів якомога раніше та не будете інвестувати ресурси в непотрібну роботу.

Крок 4. Інсайти

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

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

Розробка на основі гіпотез: підсумок

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

  • Йдеться про послідовність тестів для підтвердження або спростування ідей.
  • Вона забезпечує кількісно вимірний результат і сприяє постійному навчанню.
  • Дозволяє користувачеві – критично важливому стейкхолдеру – надавати безперервний зворотний зв’язок для кращого розуміння невідомого.
  • Дозволяє нам зрозуміти мінливе середовище та поступово виявляти цінність.

Продукти, розроблені на основі перевірених гіпотез, мають великий і сприятливий вплив на бізнес-цілі компанії. Використання даних, які тісно пов’язані з цілями компанії, гарантує, що потреби клієнтів є пріоритетними.