Статті

Як не схибити: 5 помилок запуску цифрових продуктів у великих компаніях

Погляд з боку сервісної команди

Розроблення і запуск нового цифрового продукту, який орієнтований на кінцевого споживача, є частиною цифрової трансформації бізнесу. Це одна з дієвих стратегій адаптації бізнесу до наявних реалій. Covid-19 тільки прискорив процеси активного руху в цей бік. Зокрема, найбільший американський ринок показує зростання сегмента е-комерс на рівні понад 30%. Це означає, що, якщо тенденція збережеться, офлайн-ритейл втратить більшу частину своїх клієнтів, і це стимулюватиме трансформацію бізнес-моделей в бік нових цифрових продуктів.

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

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

Як збільшити шанси на успіх нового цифрового продукту або нового напряму бізнесу – давайте розберемося, розглянувши типові помилки, з якими нам довелося зіткнутися.

Помилка 1. Закохалися в ідею, склали ТЗ і почали розробку

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

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

Йде час. Зазвичай це строк від 6 місяців до року. Часто відбувається ще й зміна команди через розбіжності в процесі робіт – як правило, це строки, або команди «відвалюються» на етапі, коли бачать перші релізи, як це виглядає або працює.

Чому так відбувається і що з цим робити?

Ключова проблема криється в простому – шанси на успіх нових цифрових продуктів у великих компаній або корпорацій прирівнюються до такої ж статистиці, як і в технологічних стартапів (вмирають 92% запущених проєктів, Startup Genome Report). А це означає, що необхідно застосовувати кращі практики й моделі (фреймворки) розроблення нових продуктів, як і в технологічних стартапів.

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

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

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

Помилка 2. Робимо новий цифровий продукт на базі наявних бізнес-процесів або поточної структури компанії

В основному нам доводилося стикатися з тим, що роботу над ідеєю нового цифрового продукту проводили команди з маркетинг-департаментів. З хорошим залученням СЕО або керівників С-рівня. Тільки в одному кейсі, працюючи над тендером для великого банку, робота команди відбувалася в спеціально створеному департаменті і навіть іншому офісі. Банк найняв консультантів з Big Four, і першим кроком проєкту стало формування окремого напряму у вигляді інноваційного бізнес-юніта.

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

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

Який вихід?

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

Перевага такого підходу полягає в тому, що новий напрям дозволяє створити свою культуру технологічного стартапу та не отримати «вірус» старих процесів і підходів. Забезпечити фокус і концентрацію. При цьому важлива й інтеграція новоствореного outpost з поточною структурою. В ідеалі така інтеграція відбувається через СINO з боку outpost і CEO з боку компанії.

Помилка 3. Оцінюємо ресурси фіксовано: конкретні терміни та бюджет

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

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

Оцінка вартості проєкту найбільш релевантна в оплаті праці команди по моделі Time and Material. Суть моделі полягає в оплаті часу команди, що було витрачено на виконання завдань. Гнучкість полягає в тому, що команда може різко змінити процес розроблення (не важливо, це дизайн загалом або інженерне розроблення) у будь-який час, коли це потрібно проєкту. Це ідеальна мотивація для всіх сторін.

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

Помилка 4. Забуваємо про те, що клієнт – у центрі

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

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

Як це виправити?

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

Основний критерій успішного MVP – він має викликати бажання купити. І важливим залишається факт швидкості, зокрема і швидкості зазнати невдачі. Для багатьох бізнес-моделей фактор швидкості виходу на ринок є ключовим. А це практично неможливо здійснити за допомогою продукту з великим набором функцій. І неможливо побудувати новий продукт, не спілкуючись з клієнтами.

Помилка 5. Запускаємо рекламу, купуємо трафік або розробляємо бренд

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

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

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

У випадку з масованою рекламною кампанією ми отримуємо, як правило, просто трафік і в кращому разі нових клієнтів. А як тільки рекламна кампанія закінчується, відбувається відтік користувачів-клієнтів, тому що вони не возвращаются.

Бренд варто створювати тільки тоді, коли ви отримали підтвердження зростання або знайшли ринок.

Як це можна виправити?

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

Як не робити помилок при створенні нових цифрових продуктів?

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

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

І найголовніше – домогтися єдиного розуміння культури експерименту всередині.

Давайте створювати більше цифрових продуктів, які полюблять клієнти!