Чому не потрібно робити ідеальний продукт
Сьогодні ніякої філософії - лише практично корисні букви, тільки хардкор. Нещодавно ми відправили вам лист про MVP: в чому його відмінність від прототипу, якою має бути цінність та інше. Якщо не Новомосковсклі, то ось воно.
Сьогодні продовжимо цю тему: покажу приклади MVP, розповім про відміну автоматизованих і ручних MVP і розповім про інструменти, які допоможуть у створенні перших.
Відразу внесу ясність - справа не стосується hardware, тому що я на цьому полі бамбук не садити. Якщо цікава тема hardware, напишіть відповіддю - може покличу того, хто знає, і запив спільний матеріал.
Трохи про сенс MVP
Все крутиться навколо цінності - штуки, яку клієнт отримує в обмін на гроші. На ранній стадії стартап повинен дізнатися, яка цінність потрібна людям, чи можна її втілити в продукті, і знайти спосіб заробляти на цій цінності.
Постійні Новомосковсктелі розсилки знають, що посадкова сторінка (або по-російськи «Лендінгем») - не MVP. Посадкова допомагає зрозуміти, чи потрібен продукт кому-небудь, якщо продукту ще не існує. MVP ж допомагає зрозуміти, чи вмієте ви надавати клієнту цінність, яку пообіцяли на посадкової. Якщо простіше, то:
- • Посадкова допомагає підтвердити попит на цінність.
- • Прототип допомагає підтвердити можливість цю цінність створити.
- • MVP допомагає зрозуміти, що продаючи цінність, можна заробити гроші.
На етапі MVP потрібно зробити економічно ефективне рішення, а значить - заробити їм гроші. Це важливо, тому що успіх з посадкової і прототипом як «затримка». Отриманий кеш ж - дві смужки, які сигналізує про те, що тепер точно можна купувати підгузники. Ну і забути про сон і особисте життя.
MVP бувають двох типів: ручні і автоматизовані. Підемо по порядку і зосередимося на перших.
ручні MVP
Ручні MVP - це коли цінність виявляється клієнту руками. Чи не буквально, звичайно. [Твитнуть] У такого MVP два завдання: максимально швидко зрозуміти, в чому саме цінність, і переконатися, що за неї готові платити.
Передбачається, що MVP потрібно тестувати на людях. Так ось, не варто цього робити на друзях - позитивний висновок може бути хибним. Це те, що Ілля Корольов з ФРІІ називає false positive - підтасовування результатів, щоб отримати бажаний висновок. Друзі не підходять з трьох причин:
1) Вони довіряють вам.
2) Вони можуть сказати те, що ви хочете почути.
3) Вони можуть заплатити просто щоб ви відстали.
Коротше, якщо хочете, щоб результати тестування були чистіше хірургічної сталі - продавайте MVP незнайомим людям. Найпростіше дотягнутися до тих, хто в одному-двох рукостискання від вас.
Тепер спробую показати як могли б виглядати ручні прототипи на прикладах парочки відомих сервісів.
Перше завдання - потрібно визначити головну цінність сервісу. Це виклик машини через один тап або все ж низькі ціни? Давайте перевіримо обидва варіанти - стрибаєте в свою тачку, одягаєте кашкет і починаєте возити клієнтів.
Якщо головна цінність - можливість викликати машину одним тапом, то елементарно відправляємо людям повідомлення: «Расшарьте свою геолокацію, я приїду і довезу за стандартним тарифом таксі». Далі чекаємо замовлень, возимо клієнтів і збираємо фідбек.
А якщо головна цінність в низьких цінах? На цей раз нічого не говоримо про геолокації, але робимо акцент на лоукост тарифах.
Але це ще не все, MVP не готовий. У нас адже 2-sided market - двосторонній ринок, де крім залучення клієнтів потрібно ще залучати водіїв, які будуть на вас працювати.
Потрібно обійти людей і запропонувати відзначити на календарі свої відпустки, в які вони поїдуть подорожувати. Далі знаходимо тих, чиї дати випадають на більш-менш один час, щоб витратити менше часу на тестування MVP. Пропонуємо їм здати свої квартири в короткострокову оренду. З вашої комісією, зрозуміло.
Тепер фотографуємо квартири, і йдемо їх здавати представникам різних сегментів. Вийшло - кайф. Не вийшло - сорри, что-то не так з цінністю. Може варто зробити професійні фотки?
Круто я свій стартап вставив в один ряд з Airbnb і Uber? Суть продукту в покупці подорожі з невідомим пунктом призначення. Покупець дізнається, куди летить за 2 години до вильоту. Замість монструозного бекенда і мобільного застосування, я вручну купував квитки всіх тестових клієнтам, а менеджен їх усередині подорожі за допомогою СМС.
Такий хід допоміг мені без створення автоматизованого продукту знайти дірки в економіці і вчасно зупинитися. А міг би злити купу грошей, причому, як своїх, так і чужих. Цінний урок. До речі, проект закритий.
З останнього прикладу особливо добре видно, що річний MVP відмінно допомагає позбутися від деяких ілюзій. Наприклад, що головною цінністю може бути зручний інтерфейс, гарний дизайн, «пасхалка» та інша туфта.
Але, на жаль, не завжди є можливість зробити ручний MVP. Instagram, Facebook, Dropbox - моя фантазія не знаходить шляхи донести цінність без кодинга. Що ж, тоді в бій ідуть автоматизовані MVP.
А чи потрібно переходити до автоматизації MVP?
А тепер супер-пупер важлива думка: перехід від ручного MVP до автоматизованого потрібен не завжди. Кінцева мета стартапа полягає в пошуку стійкої і масштабованої бізнес-моделі.
Потрібно прагнути немає швидше почати програмувати, а швидше рости. Шукайте самий простий і швидкий спосіб вплинути на метрики, а не найпрогресивніший і наворочений.
Якщо вузьке місце, яке перешкоджає росту - кількість менеджерів з продажу, то йдіть, і найміть більше менеджерів з продажу. Така тактика гнучкіша і безпечніше з точки зору ризиків.
автоматизовані MVP
Автоматизовані MVP зазвичай роблять після того, як успішно пройдений етап ручного MVP і немає іншого способу отримати кратне зростання. Тепер ми повинні мінімізувати ручну роботи, замінивши її скриптами і алгоритмами.
Зрозуміло, у кожного засновника стартапів все дуже індивідуально, але я хочу запропонувати три інструменти, які можуть допомогти в цьому нетривіальною справі. При виборі я керувався двома вимоги:
- • Гнучкість - щоб вносити зміни в продукт швидко, і мати широкий вибір можливостей.
- • Простота - тому що чим менше навичок повинно бути у команди для створення MVP, тим краще.
Бот для месенджера - програма, яка веде діалог з користувачем в чаті. Вони набирають популярність. По-перше, формат чату - приголомшливо природний спосіб взаємодії клієнта з бізнесом. Всі вміють чатитись, цього не потрібно вчити. Наприклад, український стартап Luka потрапив в Y Combinator, найвідоміший акселератор в світі, з таким ось чат-проектом.
По-друге, в ботах досить широкий простір для маневру - всередині чату можна приймати платежі, вставляти інтерактивні елементи, відправляти файли і ще купа всього.
Майже у половини стартапів, які приходили в #tceh з історією «ми 2 роки програмували і малювали, але чо-то не продається», результат дворічної праці можна було реалізувати в вигляді бота для месенджера.
«Пошуковик подарунків для чоловіків» - напишіть бота в Telegram.
«Дейтинг для IT-фахівців» - так без проблем, бот допоможе.
Рішення не гнучке, але просте при наявності розробника в команді і неймовірно зручне з точки зору супроводу - ніяких апрувов від еппсторов.
Конструктор інтернет-сервісів зі слоганом «You do not need to be an engineer». З цією штуковиною людина без навичок програмування може підняти досить складний сервіс. І коли я кажу «складний», я маю на увазі щось типу Twitter.
Звичайно, це не повністю drag'n'drop рішення, але при старанності і бажанні зробити можна практично будь-який веб-сервіс. Резидент #tceh Кирило Миколаїв за новорічні свята зробив на базі Bubble.is проект Fintere.st, не написавши жодного рядка коду.
Неймовірно гнучка середовище та досить проста, але є проблема - при розростанні фич починаєш трохи губитися в інтерфейсі.
Найпростіший приклад - якщо користувач мого MVP натискає на кнопку, то йому відправляється СМС. Цей ланцюжок з двох дій - в реальності їх може бути тисяча, і робиться все за хвилини.
Ну і ще вони вміють працювати з big data в реальному часі, вибудовувати реакції на базі поведінки користувачів та інше. Так, повністю позбутися від розробки не вийде - вам точно знадобиться програміст в команді, але гнучкість сервісу зашкалює.
MVP не живуть довго. Зазвичай, якщо ви доводите стійкість бізнес-моделі на цьому етапі, відбувається перехід до наступної стадії - викинути MVP в відро, і на основі отриманого досвіду, зібраних знань і перевірених гіпотез вибудувати готовий до масштабування продукт.
Шлях стартапа: посадкова -> прототип -> ручної MVP -> автоматизований MVP -> продукт. Сподіваюся, цей матеріал став для вас корисним.