CB Insights щороку публікує аналіз причин провалу стартапів. Роками перша причина залишається незмінною: «відсутність ринкової потреби». Не погане виконання. Не нестача грошей. Не слабка команда. Продукт просто не вирішував проблему, заради якої люди були б готові змінити свою поведінку.
Ця статистика вражає, якщо врахувати, скільки зусиль вкладається у створення продуктів. Команди витрачають місяці — іноді роки — проєктуючи системи, пишучи код, сперечаючись про архітектуру й удосконалюючи потоки. І найпоширеніша причина провалу — ніхто не запитав, чи вирішує все це реальну проблему.
Створювати продукти, які потрібні людям, — це не талант. Це дисципліна. У неї є метод, і цього методу можна навчитися.
Найпоширеніша помилка в розробці продукту — закохатися в рішення до того, як ви глибоко зрозуміли проблему. Це майже універсально для засновників першого рівня та напрочуд часто зустрічається у досвідчених. Паттерн завжди один: у когось є ідея, вона здається переконливою, і він починає будувати. Клієнт — запізніла думка, когось потрібно переконати, а не зрозуміти.
Протиотрута нескладна, але потребує дисципліни: витрачайте більше часу на проблему, ніж здається необхідним, перш ніж взагалі думати про рішення. Розмовляйте з людьми, у яких є ця проблема. Спостерігайте за їхньою роботою. Зрозумійте, якими обхідними шляхами вони користуються сьогодні і чому ці шляхи недосконалі. Лише тоді у вас буде достатньо контексту, щоб створити щось, що дійсно підходить.
Хороша розробка продукту — не пряма лінія, а петля. Кожна ітерація по петлі — це можливість замінити припущення доказами. Команди, що створюють продукти, які потрібні людям, — це ті, хто проходить цю петлю швидко та часто.
Петля — не формальність. Кожен етап має конкретний результат, який стає вхідними даними для наступного. Пропуск етапів — найчастіше стрибок від Проблеми до Створення — і породжує продукти, що не потрапляють у ціль.
Не всі проблеми варто вирішувати. Хороша продуктова проблема має три якості: вона часта (зачіпає людей часто, а не рідко), інтенсивна (люди відчувають її досить сильно, щоб хотіти полегшення) і існуючі рішення реально незадовільні (не просто трохи відрізняються від того, що ви б побудували).
Помилка — оптимізувати першу якість і ігнорувати другу й третю. «Люди витрачають час даремно на нарадах» — часто. Але якщо біль невеликий — якщо люди знайшли достатньо хороші обхідні шляхи — проблема може не варта комерційного вирішення. А якщо вже є дванадцять інструментів, що роблять те, що ви хочете зробити, вам потрібна дуже конкретна причина, чому обиратимуть саме ваш.
У досліджень погана репутація в продуктових колах — вони асоціюються з повільними консалтинговими компаніями, товстими звітами та висновками, які ніхто не читає. Це провал виконання, а не практики. Хороше продуктове дослідження — швидке, конкретне й змінює те, що ви створюєте.
Мета дослідження — не підтвердити, що проблема реальна. Ви вже маєте вірити в це до того, як вкладаєте значні ресурси в дослідження. Мета — зрозуміти проблему достатньо глибоко, щоб знати, як виглядає хороше рішення: хто конкретно має проблему, в якому контексті, що вже пробували, якими словами її описують і як для них виглядає «вирішено».
Гіпотеза — це конкретне, спростовне передбачення про те, що ви вважаєте правдивим. Вона змушує до ясності. Якщо ви не можете сформулювати чітку гіпотезу, ви ще недостатньо розумієте проблему, щоб створювати рішення.
Корисна продуктова гіпотеза має три частини:
Сигнал — найважливіша частина, і найчастіше упущена. Без заздалегідь прийнятого сигналу кожен експеримент «певною мірою спрацював». Команди знаходять способи інтерпретувати неоднозначні дані на свою користь. Гіпотеза без умови спростування — просто бажання.
Етап створення — там, де більшість команд витрачає занадто багато часу. Мета не створити продукт — мета створити мінімальне, що дасть сигнал по вашій гіпотезі. Це різні завдання, і вони дають дуже різні результати.
Для більшості ранніх гіпотез мінімум набагато менший, ніж думають команди. Чи можна вручну робити те, що робило б програмне забезпечення, для десяти людей, щоб перевірити, чи цінують вони результат? Чи можна поєднати існуючі інструменти й протестувати робочий процес до створення нової інфраструктури? Чи можна намалювати прототип і провести його через п'ять користувачів до написання будь-якого коду?
Дисципліна тут — запитувати перед створенням чого-небудь: «Що я намагаюся дізнатися?» і «Що мінімальне дозволить мені це дізнатися?» Відповідь майже завжди менша, ніж хоче створити команда.
Після запуску — чи то прототип, ручний пілот або розгорнута функція — етап вимірювання — там, де команди найчастіше вводять себе в оману. Вони запитують користувачів, чи сподобалося. Користувачі кажуть «так». Команда відзначає експеримент як підтверджений.
Настрій — не сигнал. Єдиний надійний сигнал — поведінка: чи робили люди те, що потрібно? Чи поверталися? Чи платили? Чи розповідали комусь?
Для кількісного вимірювання інструментуйте до запуску. Знайте, які конкретні дії ви відстежуєте. Встановіть поріг заздалегідь — «ми вважатимемо це підтвердженим, якщо X% користувачів завершать Y протягом Z днів». Для якісного вимірювання проводьте структуровані подальші інтерв'ю, а не відкриті опитування про задоволеність.
Етап висновків — оновлення вашої ментальної моделі користувача та проблеми, а не лише вирішення, що будувати далі. Команди, що пропускають цей крок, збирають дані, але не накопичують розуміння. Вони працюють швидко, але їхні судження не покращуються з часом.
Хороша сесія висновків ставить запитання: Що ми передбачали? Що реально сталося? Що розрив говорить нам про наші припущення? Що зараз є найважливішим невідомим?
Результат етапу висновків — чіткіше визначення проблеми, переглянута гіпотеза або — якщо експеримент явно провалився — рішення рухатися в зовсім іншому напрямку. Всі ці результати цінні. Найгірший результат — неоднозначність: «ми дещо дізналися, але не впевнені, що робити далі». Це ознака того, що експеримент був недостатньо конкретним.
Розробка продукту ніколи не досягає стадії, коли ви перестаєте проходити цю петлю. Запитання змінюються — на ранніх етапах ви перевіряєте, чи реальна проблема; пізніше — чи працює конкретний елемент рішення — але структура завжди одна. Спостерігайте, висувайте гіпотези, тестуйте, робіть висновки.
Команди, що створюють продукти, які потрібні людям, — це не ті, у кого найрозумніші початкові ідеї. Це ті, хто проходить петлю швидше та чесніше. Швидкість навчання, а не швидкість розробки, — це конкурентна перевага.