Запуск Великого вибуху проти набору номера у видінні

Генеральні директори та лідери продуктів часто уявляють себе Стівом Джобсом, випускаючи iPhone на сцену під хвилю шокованих і обожнюючих оплесків. Коли стартапи поєднують пункт призначення (маркетинговий запуск) з подорожжю (створення продукту), ми називаємо це запуском Великого вибуху.

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

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

Запуски Великого вибуху

„Запуск Великого вибуху” – це коли ви вкладаєте значний час та енергію в маркетинг дискретного запуску, який не був ітеративно розроблений та перевірений. Наприклад, стартап створює новий додаток для iPhone, тестує лише внутрішньо і постачається з магазином додатків, включаючи натискання та спробу вірусної кампанії запрошення, перш ніж здійснити будь-яке бета-розгортання когорти за когортою.

Чому запуски Великого вибуху є проблематичними

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

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

Що призводить людей до запусків “великого вибуху”

Дві найпоширеніші речі, які я бачу, підводячи стартапи до темної сторони сили за допомогою цих запусків великого вибуху; 1) нерозуміння того, як перетворити бачення на стратегію, 2) нерозуміння того, як перетворити стратегію на тактику.

Я часто бачу два класи непорозуміння навколо “Lean Startup”. Деякі люди думають, що ви можете просто надіслати випадкову функцію і перейти до продукту без будь-якого бачення, просто запитуючи користувачів, що вони хочуть. Це не працює; ви не можете змусити щось, що люди хочуть, просто запитавши їх. Поступове розгортання бачення – це не продукт. З іншого боку, деякі люди думають, що якщо у вас є велике бачення, це передбачає запуск великого вибуху. Цей підхід не вдається, оскільки між зором і пікселями є довгий шлях. Вам потрібен процес, щоб “набрати своє бачення” та повторити маніфестований продукт під час його побудови, і цей процес повинен бути адаптований до конкретного продукту.

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

Набір у видінні

Спочатку вам потрібне міцне бачення – і не лише те, що, а чому.

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

Давайте поговоримо про перші 6 тижнів або „фазу завантаження“ нового продукту. Планувати навіть 6-10 спринтів наперед важко, оскільки основні гіпотези можуть бути втрачені під час лише перших 1-2 спринтів і змінити те, як ви бачите прояв бачення. Тож замість традиційної важкої та статичної багатотижневої дорожньої карти продукту, я заохочую плавний рейтинг MVP щодо основних гіпотез, поки цінність основного продукту не оселиться – це означає, що він добре тестує і відчуває себе надійним для лідера продукту.

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

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

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

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

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

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

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

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

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

На завершення

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

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

Спочатку ця публікація була опублікована за адресою https://www.linkedin.com/pulse/big-bang-launch-vs-dialing-vision-bradford-cross/.

Bradford Cross люб’язно дозволив нам перекласти і опублікувати цю статтю.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: