Шосте відчуття не допоможе: як створити корисний продукт на основі даних

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

Привіт. Мене звати Юля, я — продакт-менеджерка Coupler.io, платформи для автоматизації та аналітики даних, створеної командою Railsware. Минулого разу я писала про рефайнмент беклогу та важливість цієї активності. Сьогодні ж хочу обговорити більш масштабну тему, а саме — найважливіший компонент створення успішного продукту. Хтось скаже, що це команда, хтось буде наполягати на технологіях чи методології розробки. Але після пʼятнадцяти років у бізнесі та семи років безпосередньо в ролі продакт-менеджерки можу з упевненістю сказати, що саме актуальна та правильно витлумачена інформація — головний дороговказ, що веде до успішного та популярного продукту. А це і є наша основна мета, чи не так?

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

головні принципи data-driven підходу;
функціонування цих принципів у наших продуктах;
поради, які варто впроваджувати в роботу всієї команди.

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

Термінологія

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

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

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

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

Розробка з data-driven підходом відбувається, коли продакт-менеджери ухвалюють рішення на основі доказів та перевіреної інформації, а не просто на інтуїції чи припущеннях. Вони збирають і аналізують дані про поведінку клієнтів, ринкові тенденції та використання продукту, щоб визначити можливості для вдосконалення та досягнення product-market fit.

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

Дані — ваш маяк під час розробки

У звіті NewVantage Partners за 2022 рік йдеться, що лише 56% компаній «запроваджують інновації, використовуючи дані». Менше як чверть компаній вдалося «започаткувати культуру використання даних».

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

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

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

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

Як ухвалювати рішення, спираючись на дані

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

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

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

Сам флоу фреймворку закодований у його назві. BRIDG — це акронім від слів Benefits (користь), Risks (ризики), Issues (проблеми), Domain knowledge (галузеві знання) та Goals (цілі). Це дескриптори основних суб’єктів певного контексту. Тобто людей, компаній чи організацій, які виграють від розв’язання проблеми. На сесії ми досліджуємо дескриптори кожного суб’єкта для того, щоб оцінити контекст проблеми комплексно.

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

Опис проблеми. Збираємо стейкхолдерів та експертів галузі в групу до вісьмох учасників та разом визначаємо суб’єктів, що страждають від проблеми й описуємо їхні «болі» (I). Потім до кожного зазначаємо (B) «плюшки», які субʼєкт отримає у разі розв’язання проблеми; ( R) ризики, які можуть виникнути; (G) їхню кінцеву мету та (D) будь-яку інформацію, що має стосунок до сфери чи індустрії та може вплинути на процес створення / роботи solution.
Пріоритизація. Не всі дескриптори однаково важливі. Саме тому їх варто відсортувати за важливістю, щоб розуміти, які аспекти матимуть найбільший вплив на майбутнє рішення чи продукт і без яких неможливий навіть MVP (musts), а про які речі можна забути, поки ми не отримуємо фідбек від ринку та реальних користувачів (won’ts).
Прописуємо варіанти рішень. Цей крок дає нам можливість пофантазувати та проаналізувати, які рішення ми можемо запропонувати до чинної проблеми. Іноді виявляється, що рішенням може бути не розробка нового застосунку чи програми, а звичайний чат з нагадуванням, уже наявна програма чи навіть відмова від розробки через підводне каміння, яке раніше не було помітним.
Декомпозиція рішення. Після того, як ми визначили, який з варіантів рішення буде оптимальний, ми розбиваємо його на маленькі частинки, які вже можна брати в роботу. Наприклад, якщо мовиться про новий софтверний продукт, то на цьому етапі ми будемо прописувати епіки, які й ляжуть в основу дорожньої карти продукту. Якщо ж говоримо про стратегію, то тут можна прописати покроково всі необхідні активності.

Дашборди продукту

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

Щоб відстежувати ключові показники, ми в команді зазвичай використовуємо адаптовану версію маркетингової воронки AARRR, її ще часто називають Pirate Metrics. Ми налаштовуємо наші дашборди так, щоб вони чітко показували метрики для таких стадій воронки:

Awareness — скільки людей знають про наш продукт (відвідали сайт).
Acquisition — скільки людей зареєструвалися.
Activation — скільки людей почали використовувати продукт (вимірюється різними способами).
Retention — скільки з них залишились у продукті та стали постійними користувачами.
Paid — скільки користувачів зробили першу покупку.
MRR — щомісячний поточний дохід.

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

Щоб спростити аналіз даних і процес ухвалення рішень, я б рекомендувала виводити на панель не більше як 8-10 різних показників та не захаращувати екран даними, які вам не потрібні. Наприклад, ми не відстежуємо показники «Рекомендації», хоч він і входить у воронку AARRR. Усе через те, що для нашого продукту він не є показовим та важливим, принаймні наразі. Загальна рекомендація така: якщо показник не є важливим для коротко- чи довгострокових цілей продукту, не виводьте його на панель взагалі. А власне коротко- і довгострокові показники виводьте на різні екрани, оскільки ви маєте працювати з ними по-різному.

Ось простий флоу того, як створити дашборд саме для вашого продукту:

Визначте мету дашборду. Які рішення ви будете ухвалювати на його основі? Це може бути і визначення бюджету маркетингових кампаній в розрізі каналів на наступний місяць, і аналіз того, як покращилась активація користувачів після останніх змін в UX.
Оберіть показники, що відповідають меті дашборду. Пам’ятайте про упередження підтвердження.
Створіть чернетку дашборду в Google Spreadsheet та «пограйтеся» з відображенням даних.
Визначте, які сирі дані потрібні для того, аби отримати вибрану вами візуалізацію.
Створіть дашборд за допомогою таких інструментів як Coupler.io, Looker Studio, Tableau або Power BI для автоматизації потоків даних. Дашборд ‒ це репрезентація даних, яка оновлює дані самостійно. Якщо ви готуєте їх руками ‒ це репорт. Не робіть так :)
Вдосконалюйте дашборд щоразу, коли стикаєтеся з незвичайною поведінкою користувачів. І не обовʼязково міняти основний екран. Найчастіше я додаю нові вкладки, на яких інформація більш деталізована і відповідає на запитання, які я ставлю, дивлячись на основну вкладку.

Чого не варто робити під час використання data-driven підходу

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

Хибна думка 1. Дані — це головне

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

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

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

Хибна думка 2. Усе і завжди має бути data-driven

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

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

Хибна думка 3. Дані не брешуть

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

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

Інший приклад: під час співбесіди ви ставите своїм клієнтам забагато «так / ні» запитань, і вони відповідають абищо, лишень би закінчити цей потік запитань.

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

ігнорувати сезонні фактори. Якщо ви не знаєте про сезонні закономірності своїх продажів, ви можете пов’язати збільшення доходу з нещодавньою зміною (новою фічею, оновленим дизайном тощо), а не з тим, що зараз час року, коли люди зазвичай витрачають більше. Наприклад, зимові свята;
робити поспішні висновки щодо продуктивності команди. Уявімо, ви помітили, що ефективність обробки тікетів нового менеджера служби підтримки за один день нижча, ніж була. Але, копнувши глибше, ви можете побачити, що цього місяця просто було згенеровано менше тікетів. Або через розширення команди кожен член команди підтримки тепер має менше заявок для обробки;
не відстежувати щоденні показники. Деякі місяці, наприклад, лютий чи квітень, мають менше днів, ніж інші, тому не доцільно порівнювати їх із липнем чи жовтнем. Крім того, дані можуть відрізнятися залежно від кількості вихідних у місяці. Моя порада: не лякайтеся невеликих коливань і шукайте пояснень в аналітиці, коли помічаєте щось незвичайне. І взагалі, не робіть ніяких висновків на основі малих даних. 50% конверсії це краще, ніж 33%, але якщо різниця лише в одному клієнтові, то не варто радіти.

Інструменти продакт-менеджера для роботи з даними

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

Для збору ключових даних:

Amplitude — для відстеження поведінки та взаємодії користувачів (рахує відвідування, перегляди, кліки);
Microsoft Clarity — для відстеження поведінки та взаємодії користувачів (робить записи сеансів, теплові мапи). Не Hotjar, звичайно, але безплатний. Чудовий початок, аби зрозуміти як це працює і чи воно вам потрібно достатньо, аби платити за якісніші платні аналоги;
Google Analytics (куди ж без неї).

Для управління даними:

Coupler.io — щоб збирати дані з багатьох джерел, трансформувати їх без коду, додавати їх до сховища даних, створювати автоматизовані потоки даних і підмикатися до інструментів візуалізації даних;
BigQuery — для зберігання, організації та парсингу великих наборів даних;
GSheets — для вивантаження певного зрізу з BigQuery й ad-hoc-гри з даними (обожнюю pivot-таблиці) і створення простих або табличних візуалізацій даних.

Для візуалізації даних:

Looker Studio;
Power BI;
Tableau (але особисто я віддаю перевагу першим двом);
ProfitWell — для візуалізації даних з доходів.

Для натхнення

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

Теми: data, product, Product Management, інформація, аналіз даних, стартап