Як генерувати та перевіряти гіпотези під час розробки продукту. Інструкція продакт-менеджерки

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

Всім привіт! Я — Юля, продакт-менеджерка в компанії Railsware. За теперішньої ситуації на ринку стає очевидною суттєва нестача сильних та досвідчених продакт-менеджерів, особливо в продуктових компаніях. Багато спеціалістів вимушені приміряти на себе цю роль та припускатися помилок, оскільки якісної освіти у цьому напрямку ще просто не існує.

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

Що таке продуктова гіпотеза

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

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

Вони:

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

Якщо ви прихильник data-driven development, тоді вам обов’язково треба навчитись будувати та перевіряти гіпотези. Адже саме за допомогою гіпотез більшість даних і збирається. Щобільше, перевірка гіпотез допомагає продуктовій команді приймати неупереджені рішення щодо розвитку продукту.

Приклади гіпотез

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

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

«Якщо ми скоротимо швидкість завантаження сторінки А на 5% (змінна 1), ми збільшимо кількість реєстрацій на 15% (змінна 2).» Отже, якщо ми покращимо швидкість завантаження сторінки А на 5%, а кількість реєстрацій збільшиться на 15%, то наша гіпотеза є доведеною. Якщо кількість істотно не збільшилася, або не збільшилася взагалі, то гіпотезу буде спростовано.

Ось вам ще декілька прикладів гіпотез:

• Якщо додати нову фічу «шаблони імейлів» до продукту Mailtrap, ми збільшимо активність використання нашого API для відправлення електронної пошти.
• Створення актуальних відеоуроків та їхнє поширення на YouTube призведе до збільшення кількості реєстрацій на Coupler.io.
• Якщо ми опублікуємо інтерв’ю з нашим CEO на TechCrunch, ми зможемо заохотити 500 людей відвідати наш сайт, з яких 10 завантажать наш продукт.

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

Повернімось до прикладу про статтю в TechCrunch. Згідно з цією гіпотезою ми очікуємо, що 500 читачів відвідають сайт нашого продукту, а коефіцієнт конверсії цих унікальних відвідувачів у користувачів становитиме 2%, тобто 10 осіб.

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

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

• Якість впливу.
• Розмір впливу.
• Імовірність впливу.

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

Коли створювати гіпотези

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

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

Пишемо гіпотези

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

Крок 1. Визначаємо змінні

Змінні — це головні елементи гіпотези, тож пропоную почати з їхнього визначення. Коли пишете гіпотези, варто розмежовувати залежні та незалежні змінні. Якщо коротко, незалежна змінна — це причина, а залежна змінна — наслідок. Все як у функціях, які ви вчили у школі, де x впливає на те, як змінюється y.

Отже, у прикладі Mailtrap, який ми згадували раніше, «функція додавання шаблонів електронних листів» є причиною, тобто елементом, яким ми хочемо маніпулювати. Водночас «збільшене використання API для надсилання емейлів» — результат, на який очікуємо.

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

Залежні змінні часто вказують у вигляді метрик. Наприклад:

• Кількість реєстрацій.
• Кількість покупок.
• Процент активації (у різних продуктах процес активації ліда відрізняється та виглядає по-різному).
• Частота використання певних функцій продукту.
• Кількість активних користувачів на місяць тощо.

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

Наприклад, у гіпотезі «Користувачі відпадають, тому що їм важко налаштувати проєкт» змінні визначені погано. Фрази на кшталт «відпадають» та «важко налаштовувати» надто розпливчасті. Набагато краще було б сказати «Якщо чітко визначити кроки налаштування проєкту, ми побачимо зменшення відтоку користувачів.» У цьому прикладі зрозуміло, яка залежна змінна була обрана і чому.

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

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

Крок 2. Поєднуємо змінні

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

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

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

Ось деякі типові помилки, яких слід уникати під час визначення зв’язку між двома чи більше змінними:

Зв’язок слабкий. Ви можете припустити, що збільшення відвідуваності сайту призведе до збільшення кількості реєстрацій. Це слабкий зв’язок, оскільки відвідувачі сайту не обов’язково мотивовані використовувати ваш продукт. Зазвичай для реєстрації потрібно більше кроків. Кращою гіпотезою буде: «Якщо ми змінимо CTA на сторінці цін, то кількість реєстрацій збільшиться». Цей зв’язок набагато сильніший і пряміший.

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

Змінні взаємозалежні. Змінні завжди повинні бути ізольовані одна від одної. Адже логічно, що якщо ми приберемо опцію «зареєструватись через Google», ми отримаємо менше користувачів з Google workspace акаунтами тому, що тут є пряма залежність.

Крок 3. Визначте критерії перевірки

По-перше, у вашій гіпотезі мають бути вбудовані критерії перевірки. Подумайте про відсотки (наприклад, збільшення/ зменшення на 5%) і виберіть відповідний показник продукту для відстеження — процент активації, рівень відтоку юзерів тощо.

Але не затискайте самі себе в жорсткі рамки. Можливо, підвищення якогось показника на 3% так само допустимо, як і 5%. І це доводить, що між вашими змінними існує зв’язок.

По-друге, завжди переконуйтесь, що ваша гіпотеза реалістична. Припустімо, у вас є гіпотеза: «Якщо ми покажемо користувачам банер з нашою новою фічею, її використання зросте на 10%». Спитайте себе:

• Чи є 10% розумним збільшенням, виходячи з поточного рівня користування фічею?
• Чи є у вас ресурси для створення та розповсюдження рекламних матеріалів — розробка кількох варіантів банерів, розповсюдження їх в різних каналах, таких як всередині продукту, через електронну пошту, у блозі?
• Чи варті витрачені ресурси очікуваного результату?

Ще трішки теорії, або метод даблчекінгу

У статистичному дослідженні існує два способи формулювання гіпотези: нульова або альтернативна гіпотеза. Але цей науковий метод також можна використовувати в розробці.

Альтернативна гіпотеза — це твердження, яке ви плануєте довести як істинне шляхом проведення експерименту та аналізу результатів. Усі приклади, які я наводила вище і є альтернативними гіпотезами.

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

А навіщо вам взагалі це все знати? Що ж, розгляньмо фразу «Невинний, допоки вину не доведено» як версію нульової гіпотези. Ми не припускаємо, що існує будь-який зв’язок між «підсудним» і «злочином», поки ми не отримаємо доказів.

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

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

Створення гіпотез є досить цікавим завданням у результаті якого ви можете отримати 5, 10, а може й 20 різних гіпотез. Але, якщо захочете протестувати їх всі, ви, скоріше за все, витратите купу ресурсів та змарнуєте дорогоцінний час.

Тож, перш ніж переходити безпосередньо до перевірки гіпотез, варто оцінити, наскільки вони важливі для поточних цілей, та обрати 3-5 для перевірки.

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

Назва фреймворку — це абревіатура від Must-have, Should-have, Could-have і Won’t-have.

• Must-have — гіпотези, які необхідно перевірити, оскільки вони тісно пов’язані з нашими нагальними цілями.
• Should-have — гіпотези, які тісно пов’язані з першочерговими цілями проєкту, але не є пріоритетом.
• Could-have — гіпотези, які добре б було протестувати, але які можуть почекати на перевірку.
• Won’t-have — низькопріоритетні гіпотези, які можна або не перевіряти взагалі, або перевірити пізніше, коли матимемо більше часу.

Процес перевірки гіпотез

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

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

Наприклад, для редизайну цільової сторінки не обов’язково створювати клікабельний прототип. Тут підійде й загальнодоступне оновлення.

Ось декілька підходів, які ми в команді, зазвичай, використовуємо для перевірки гіпотез.

A/B тестування

A/B або спліт-тестування передбачає створення двох або більше версій вебсторінки, фічі, або функціональності та збір даних щодо реакції користувачів на них.

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

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

Створення прототипу

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

Також, цей спосіб перевіряти гіпотези можна застосовувати, якщо ви працюєте над впровадженням суттєвих змін в продукті (створення абсолютно нової функції, зміни в юзер-флоу тощо).

Щоб зекономити на створенні прототипу, обирайте правильні інструменти. Наприклад, для дизайну можна обрати Figma, а от для швидкої розробки фічей — безкодову платформу типу Bubble.

Приклад Deliveroo

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

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

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

Запитати користувачів

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

Інтерв’ю зазвичай проводять продакт-менеджери з одним клієнтом за раз. Вони можуть проходити віч-на-віч або онлайн і тривати від 30 хвилин до 1 години.

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

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

Чарівник країни Оз

Підхід «Чарівник країни Оз» підходить для вимірювання інтересу користувачів до нових фічей. Він проводиться через створення прототипу відсутньої фічі та спостереження за тим, як клієнти або тестові користувачі взаємодіють з нею.

Наприклад, ви можете припустити, що кількість активних користувачів збільшиться на 15%, якщо ви створите нову фічу. Отже, ви створюєте вебсторінку або просто кнопку, яка пропонує користувачам отримати доступ до нової фічі. Але коли вони натискають на кнопку, з’являється попап з повідомленням на кшталт «скоро реліз».

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

Оновлення для всіх користувачів

Одним з найшвидших способів перевірити гіпотезу є реліз оновлення для всіх користувачів. Його налаштування може зайняти менше часу та зусиль, ніж інші тести (залежно від масштабу оновлення).

Але через пов’язаний ризик варто виконувати такі тести тільки для невеликих гіпотез. У нашій команді ми використовуємо цей підхід лише тоді, коли ми впевнені, що наша гіпотеза вірна.

Наприклад, одного разу ми припустили, що ім’я одного з об’єктів Mailtrap є основною причиною низького рівня активації юзерів. Користувачі Mailtrap надсилають тестові електронні листи до місця під назвою «Demo Inbox». Ми припустили, що ця назва радше збиває з пантелику ніж пояснює, що це за місце. Нам здалося, що це заважає новим користувачам взаємодіяти з їхніми обліковими записами.

Тож ми оновили сторінку, змінили назву на «My Inbox» та додали кілька «to-do» кроків для нових користувачів. Майже одразу ми побачили збільшення рівня активації, що підтвердило нашу гіпотезу.

Прапорці фічей (Feature Flags)

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

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

Як це працює на практиці

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

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

Але A/B-тестування, мабуть, найкраще підходить для цього завдання. Залежно від нашого бюджету та мети ми можемо протестувати кілька різних варіантів текстів:

• тексти наявної цільової сторінки;
• тексти, за які ми заплатили 10 000 маркетинговому агентству;
• нові тексти, які ми написали самі або старі видозмінені тексти — просто щоб побачити, як невелика зміна може вплинути на показники.

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

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

Запис гіпотез і результатів тестування

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

Наші продакт-менеджери створюють документ для кожної окремої гіпотези в Coda або Google Sheets. У ньому ми записуємо гіпотезу, а також наші плани, процес, результати, скріншоти, метрики продукту та припущення.

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

Інтерпретація результатів та планування подальших дій

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

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

1. Ретельно збирайте та аналізуйте дані. Переконайтеся, що ваші дані точні й актуальні під час проведення кількісних тестів та відстеження поведінки користувачів через панель аналітики. Якщо ви проводите CustDev інтерв’ю, обов’язково зробіть запис зустрічі (за згодою), щоб ваші нотатки були якомога точнішими.

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

3. Оберіть правильний сегмент аудиторії. Не згрібайте всіх до однієї купи. Перш ніж запускати тест, заздалегідь визначте, від кого ви хочете збирати дані. Інакше результати тестування не будуть надійними, і ви не дізнаєтеся нічого нового.

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

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

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

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

Наостанок

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

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

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