CB Insights ежегодно публикует анализ причин провала стартапов. Годами первая причина остаётся неизменной: «отсутствие рыночной потребности». Не плохое исполнение. Не нехватка денег. Не слабая команда. Продукт просто не решал проблему, ради которой люди были готовы изменить своё поведение.
Эта статистика поражает, если учесть, сколько усилий вкладывается в создание продуктов. Команды проводят месяцы — иногда годы — проектируя системы, пишя код, споря об архитектуре и совершенствуя потоки. И самая распространённая причина провала — никто не спросил, решает ли всё это реальную проблему.
Создавать продукты, которые нужны людям, — это не талант. Это дисциплина. У неё есть метод, и этому методу можно научиться.
Самая распространённая ошибка в разработке продукта — влюбиться в решение до того, как вы глубоко поймёте проблему. Это почти универсально для основателей первого уровня и удивительно часто встречается у опытных. Паттерн всегда один: у кого-то есть идея, она кажется убедительной, и он начинает строить. Клиент — запоздалая мысль, кого-то нужно убедить, а не понять.
Противоядие несложное, но требует дисциплины: тратьте больше времени на проблему, чем кажется необходимым, прежде чем вообще думать о решениях. Разговаривайте с людьми, у которых есть эта проблема. Наблюдайте за их работой. Поймите, какими обходными путями они пользуются сегодня и почему эти пути несовершенны. Только тогда у вас будет достаточно контекста, чтобы создать что-то действительно подходящее.
Хорошая разработка продукта — не прямая линия, а петля. Каждая итерация по петле — это возможность заменить предположения доказательствами. Команды, создающие продукты, которые нужны людям, — это те, кто проходит эту петлю быстро и часто.
Петля — не формальность. Каждый этап имеет конкретный результат, который становится входными данными для следующего. Пропуск этапов — чаще всего прыжок от Проблемы к Созданию — и порождает продукты, не попадающие в цель.
Не все проблемы стоит решать. Хорошая продуктовая проблема имеет три качества: она частая (затрагивает людей часто, а не редко), интенсивная (люди чувствуют её достаточно, чтобы хотеть облегчения) и существующие решения реально неудовлетворительны (не просто немного отличаются от того, что вы бы построили).
Ошибка — оптимизировать первое качество и игнорировать второе и третье. «Люди тратят время впустую на совещаниях» — часто. Но если боль невелика — если люди нашли достаточно хорошие обходные пути — проблема может не стоить коммерческого решения. А если уже есть двенадцать инструментов, делающих то, что хотите сделать вы, вам нужна очень конкретная причина, почему выберут именно ваш.
У исследований плохая репутация в продуктовых кругах — они ассоциируются с медленными консалтинговыми компаниями, толстыми отчётами и выводами, которые никто не читает. Это провал исполнения, а не практики. Хорошее продуктовое исследование — быстрое, конкретное и меняет то, что вы создаёте.
Цель исследования — не подтвердить, что проблема реальна. Вы должны уже верить в это до того, как вкладываете значительные ресурсы в исследование. Цель — понять проблему достаточно глубоко, чтобы знать, как выглядит хорошее решение: кто конкретно имеет проблему, в каком контексте, что уже пробовали, какими словами её описывают и как для них выглядит «решено».
Гипотеза — это конкретное, опровержимое предсказание о том, что вы считаете истинным. Она вынуждает к ясности. Если вы не можете сформулировать чёткую гипотезу, вы ещё недостаточно понимаете проблему, чтобы создавать решение.
Полезная продуктовая гипотеза имеет три части:
Сигнал — самая важная часть, и самая часто упускаемая. Без заранее принятого сигнала каждый эксперимент «в какой-то мере сработал». Команды находят способы интерпретировать неоднозначные данные в свою пользу. Гипотеза без условия опровержения — просто желание.
Этап создания — там, где большинство команд тратит слишком много времени. Цель не создать продукт — цель создать минимальное, что даст сигнал по вашей гипотезе. Это разные задачи, и они дают очень разные результаты.
Для большинства ранних гипотез минимум гораздо меньше, чем думают команды. Можно ли вручную делать то, что делало бы программное обеспечение, для десяти человек, чтобы проверить, ценят ли они результат? Можно ли объединить существующие инструменты и протестировать рабочий процесс до создания новой инфраструктуры? Можно ли нарисовать прототип и провести его через пять пользователей до написания какого-либо кода?
Дисциплина здесь — спрашивать перед созданием чего-либо: «Что я пытаюсь узнать?» и «Что минимальное позволит мне это узнать?» Ответ почти всегда меньше, чем хочет создать команда.
После запуска — будь то прототип, ручной пилот или развёрнутая функция — этап измерения — там, где команды чаще всего вводят себя в заблуждение. Они спрашивают пользователей, понравилось ли им. Пользователи говорят «да». Команда отмечает эксперимент как подтверждённый.
Настроение — не сигнал. Единственный надёжный сигнал — поведение: делали ли люди то, что нужно? Возвращались ли? Платили ли? Рассказывали ли кому-то?
Для количественного измерения инструментируйте до запуска. Знайте, какие конкретные действия вы отслеживаете. Установите порог заранее — «мы будем считать это подтверждённым, если X% пользователей завершат Y в течение Z дней». Для качественного измерения проводите структурированные последующие интервью, а не открытые опросы об удовлетворённости.
Этап выводов — обновление вашей ментальной модели пользователя и проблемы, а не только решение, что строить дальше. Команды, пропускающие этот шаг, собирают данные, но не накапливают понимание. Они работают быстро, но их суждения не улучшаются со временем.
Хорошая сессия выводов задаёт вопросы: Что мы предсказывали? Что реально произошло? Что разрыв говорит нам о наших предположениях? Что сейчас является самым важным неизвестным?
Результат этапа выводов — более чёткое определение проблемы, пересмотренная гипотеза или — если эксперимент явно провалился — решение двигаться в совершенно другом направлении. Все эти результаты ценны. Худший результат — неоднозначность: «мы кое-что узнали, но не уверены, что делать дальше». Это признак того, что эксперимент был недостаточно конкретным.
Разработка продукта никогда не достигает стадии, когда вы перестаёте проходить эту петлю. Вопросы меняются — на ранних этапах вы проверяете, реальна ли проблема; позже — работает ли конкретный элемент решения — но структура всегда одна. Наблюдайте, выдвигайте гипотезы, тестируйте, делайте выводы.
Команды, создающие продукты, которые нужны людям, — это не те, у кого самые умные первоначальные идеи. Это те, кто проходит петлю быстрее и честнее. Скорость обучения, а не скорость разработки, — это конкурентное преимущество.