Як IT-розробнику перевірити стартап-ідею за тиждень — без продукту і без бюджету
Розповідає Сергій Шапіренко, CEO & Co-founder у Revisior
Більшість розробників, коли їм спадає на думку ідея, роблять одне й те саме: відкривають редактор коду. Через місяць у них є MVP. Ще через місяць — усвідомлення, що це нікому не потрібно. Ця історія вже стара як світ.
Втім, код не завжди є джерелом проблеми. Біда в тому, що найдорожчий ресурс витрачається до того, як отримано найважливішу відповідь: чи існує насправді проблема, яку ти розв’язуєш?
Один тиждень правильних запитань може врятувати місяці розробки. В цій статті, разом із Сергієм Шапіренком, лектором курсу «Стартапи в ІТ», розповідаємо, як це зробити.
Сформулюйте проблему, а не рішення
«Перший та найпоширеніший капкан — закохатися у власне рішення раніше, ніж зрозуміти проблему. Закоханість у рішення — це завжди пастка. Ви починаєте шукати підтвердження замість того, щоб шукати правду».
Щоб сформулювати проблему, запишіть одним реченням: хто саме страждає, від чого конкретно і чому не може розв’язати це зараз. Не: «малий бізнес має проблеми з аналітикою», а: «власник кав'ярні витрачає дві години щонеділі на зведення таблиць в Excel, бо не може дозволити собі бухгалтера».
Різниця принципова. Перше — це категорія. Друге — людина з болем.
Також важливо відрізнити симптом від кореневої проблеми. Якщо хтось каже: «Мені потрібен зручніший таск-менеджер» — це симптом. Корінь проблеми може бути в тому, що команда не розуміє пріоритетів або менеджер не вміє делегувати. Інструмент не розв’яже поведінкову проблему.
«Правильна команда, швидкість навчання, прийняття рішення та вміння адаптуватись є набагато важливішими за саму ідею».
Знайдіть 10 потенційних користувачів
Проводити дослідження в голові — марна справа. Вам потрібні реальні люди, з реальними проблемами, які зможуть неупереджено дати фідбек.
«На ранньому етапі не потрібні складні дослідження. Потрібні правильні розмови з правильними людьми».
На щастя, в сучасному світі знайти їх легко:
- Reddit — найлегший спосіб. Існує ціла купа спільнот, де люди діляться досвідом, питають порад і обговорюють болі.
- Telegram- і Discord-спільноти. На цих платформах теж є чимало тематичних груп, де вже зібрана аудиторія.
- LinkedIn хоч і складніший, але теж варіант. Можна напряму написати людям з відповідною посадою або галуззю.
- Профільні заходи й нетворкінг — навіть онлайн-конференції дають доступ до потрібних людей.
Мета — знайти 10 осіб, які теоретично могли б бути користувачами. Цього достатньо для першого раунду.
«Зрештою, стартап — це не про ідею. Ідеї нічого не варті без чіткого розуміння, перевірки та усвідомлення масштабу проблеми».
Проведіть проблемні інтерв'ю
«Ідея без інтерв’ю з клієнтами — це фантазія. І зазвичай дорога фантазія. Втім, інтерв’ю не завжди підтверджує ідею, часто воно її руйнує — і це нормально».
Головне правило — не запитуйте про своє рішення. Запитуйте про їхнє життя. Більшість засновників роблять одну й ту саму помилку: приходять на інтерв'ю та починають презентувати ідею, а потім питають: «Як тобі?». У відповідь отримують ввічливе «Звучить непогано» — і йдуть з хибним відчуттям підтвердження.
Метод Mom Test Роба Фіцпатріка розв’язує саме цю проблему. Назва походить від простого тесту: уявіть, що питаєте думку у своєї мами. Вона любить вас і не хоче засмутити, тому на запитання «Мамо, як тобі моя ідея?» завжди відповість щось підбадьорливе — навіть якщо ідея погана.
Але якщо запитати її про власний досвід — як вона зараз справляється з цією задачею, що її дратує, скільки часу це займає, — вона просто розповість правду, бо не знає, що ти хочеш почути.
Саме так мають виглядати правильні інтерв'ю: запитання про минулий досвід і конкретні ситуації, а не про гіпотетичне майбутнє.
- «Чи купив би ти такий продукт?» — погане запитання, бо людина відповідає на те, чого ще немає.
- «Як ти розв’язував це востаннє?» — хороше, бо відповідь спирається на реальність.
А отже, ось 5 запитань, які працюватимуть:
- Розкажіть, як ви зараз розв’язуєте цю задачу?
- Що в цьому процесі найбільше дратує?
- Коли востаннє ви стикалися з цією проблемою — що саме сталося?
- Що ви вже пробували робити, щоб розв’язати це?
- Скільки часу або грошей це коштує вам зараз?
Варто особливо уважно підмічати конкретні ситуації з минулого, емоції під час розповіді, те, що люди вже пробували робити самостійно. Це сигнали реального болю.
На противагу цьому ігноруйте гіпотетичні «я б точно використовував», компліменти на адресу вашої ідеї, розпливчасті «так, це актуально».
«Після проведення інтерв'ю потрібно дослідити розмір проблеми, зрозуміти, наскільки великий ринок, хто на ринку основні гравці, яка динаміка ринку та потенціал. І лише після цього починати будувати.
Інтерв'ю показують напрямок, а от дослідження ринку дає розуміння доцільності подорожі».
Перевірте готовність платити
Симпатія — це не валідація. Реальний інтерес підкріплюється або грошима, або часом.
Найшвидший спосіб це перевірити — створити fake door. Суть методу проста: ви створюєте «двері», які виглядають як реальний продукт, але за ними поки що нічого немає. Людина бачить лендингову сторінку з описом рішення, натискає кнопку «Приєднатися до бета-тестування» або «Дізнатися ціну» — і саме цей момент є вашим виміром. Не те, що вона сказала в розмові, а те, що вона зробила, коли дійшло до дії.
Це чесний метод: ви не продаєте продукт, якого не існує, а перевіряєте реальний інтерес. Якщо людина залишає email або клікає — це сигнал. Якщо закриває сторінку — теж сигнал, просто інший.
Створити таку сторінку можна за дві години на Tilda, Carrd або навіть у Notion. Структура мінімальна: одне речення про проблему, одне — про рішення, кнопка з дією. Запустити трафік можна через особисті повідомлення або пости в тематичних спільнотах. Далі — спостереження за конверсією.
Якщо landing page здається надмірним на цьому етапі — поставте пряме запитання в кінці інтерв'ю:
- «Якби завтра з'явився інструмент, який розв’язує саме це, — скільки ви готові платити на місяць?»
Або ще краще:
- «Ви б заплатили X гривень прямо зараз, щоби потрапити в ранній доступ?»
Важливо розуміти різницю між сигналами. Якщо людина каже «так» на гіпотетичне запитання — це слабкий сигнал: люди охоче погоджуються з тим, що нічого не коштує. Якщо вона готова залишити email, передзамовити або заплатити — це вже щось реальне, бо вона витратила або час, або гроші.
Проаналізуйте сигнали
Після інтерв'ю та першого тесту у вас є дані. Тепер потрібно прочитати їх чесно. Їх, умовно, можна поділити на зелені та червоні прапорці.
До зелених віднесемо такі сигнали:
- Люди самі описували проблему до того, як ви її назвали
- Вони вже витрачають гроші або час на неідеальні рішення
- Кілька людей попросили повідомити, коли буде готово
- Є хоч одна передплата або підписка на waitlist
До червоних же належатимуть такі сигнали:
- Всі кажуть «цікаво», але ніхто не хоче залишити контакт
- Проблема існує, але люди звикли з нею жити й не шукають виходу
- Ринок занадто вузький або аудиторія не готова платити
- Ви самі починаєте «допомагати» людям відповідати правильно
«Ні» — це не завжди погано.
- «Ні, але якби це робило ось це — я б точно взяв» є ціннішим за десять байдужих «так».
«Якщо проблема звучить абстрактно, то, скоріше за все, вона не болить достатньо сильно, щоб за неї платили».
Вирішіть: будувати, міняти вектор чи відмовитись
Після тижня у вас має бути достатньо даних, щоб ухвалити одне з трьох рішень.
Будувати — якщо проблема підтверджена, аудиторія реальна, є хоча б кілька людей з сильним болем і готовністю платити. Починайте з найменшого можливого рішення.
Змінити вектор — якщо проблема є, але не та, на яку ви очікували. Або аудиторія не та. Це нормально: ви зберегли місяць розробки та отримали новий напрямок і ще й цілий ряд інсайтів.
Відмовитись — якщо проблема слабка, аудиторія байдужа, а єдиний ентузіаст — ви самі. Це теж можна розцінювати не як поразку, а радше як урок. Зрештою, ви не витратили ресурси на те, що не працює.
«Такі рішення приймати складно. Я досить часто бачу сильних розробників або продактів, які можуть створити крутий продукт, але не розуміють, як його монетизувати. І навпаки, підприємці без IT не розуміють специфіку продуктового підходу. Курс “Стартап в ІТ” допоможе закрити цей gap».
На завершення
Валідація — це не про невпевненість у собі. Це інженерний підхід до невизначеності: спочатку зібрати дані, потім будувати. Розробники звикли розв’язувати технічні задачі системно — і задача «чи потрібен цей продукт» не відрізняється від будь-якої іншої.
