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