Для кого эта статья

Для тех, кто строит продукт в одиночку или почти в одиночку — соло-фаундер, мейкер, автор, у которого нет команды, способной остановить его на середине неправильного вывода. Источник гипотезы у такого человека почти никогда не рынок и не аналитический отчёт — это собственный опыт, собственная боль, наблюдение за своим ближайшим кругом.

Космолеты в гараже

Есть узнаваемый паттерн у людей, которые делают продукт в одиночку. Вместо того чтобы за неделю собрать грубый черновик и посмотреть, отзовётся ли он хоть у кого-то, человек уходит строить — месяцами, в одиночестве, вкладывая в разработку деньги, которых не было, и время, которое не вернуть. К моменту, когда продукт наконец показан миру, он уже не черновик, а произведение, в которое вложена часть личности автора. Если рынок отвечает молчанием, это не читается как «одна гипотеза не подтвердилась» — это читается как личный крах.

Ох, сколько я их наделала, вы даже не представляете. Казалось бы: ну нравится делать — делай, но у этих космолетов есть очень неприятные эффекты:

  • демотивация - ты понимаешь, что потратил столько времени и сил и все зря. Кому, зачем?
  • ты принимаешь решение убить продукт, хотя проблема была не в продукте, а многочисленных факторах: неправильные метрики, не сформулированная гипотеза, не правильные выводы, отсутствие дистрибуции, да и тупо просто не хватил смелости хорошо так попродавать.
  • в целом делается вывод — вернусь как я в найм, не работают эти ваши продукты.

Это тот самый эффект преждевременного масштабирования, который команда Startup Genome обнаружила, когда прогнала через анализ данные больше трёх тысяч быстрорастущих стартапов: 74% смертности интернет-стартапов , а 93% из тех, кто это сделал, так и не дошли до ста тысяч долларов месячной выручки. Слово «масштабирование» здесь не только про наём и рекламу — это в равной мере и про то, что человек строит не первую грубую проверку идеи, а сразу полноценный продукт, вложив в него ресурс, соразмерный уже готовому бизнесу, а не гипотезе.

Мы строим не продукт, а прототип гипотезы

Разворот, который снимает большую часть этой боли, простой по формулировке и трудный в исполнении: мы не создаём продукт, мы создаём прототип для проверки одной гипотезы. Да, он выглядит как полноценный продукт, можно нажимать кнопочки и он выполняет свои базовые функции, но это прототип гипотезы. У прототипа задача — дать ответ на конкретный вопрос как можно быстрее и дешевле. У продукта задача — приносить пользу и деньги на постоянной основе. Смешение этих двух целей и порождает космический корабль в гараже: человек начинает полировать прототип до продуктового качества, потому что подсознательно уже решил, что гипотеза верна, и просто достраивает подтверждение.

Как только прототип возвращается к своей единственной задаче — дать ответ на вопрос, — меняется и уровень детализации, в который стоит вкладываться. Если вопрос в том, готовы ли люди вообще платить за такое решение, не нужен работающий продукт — нужна страница с описанием и кнопкой оплаты. Если вопрос в том, удержит ли решение внимание дольше одного захода, нужен минимальный работающий кусок, а не всё дерево фич, которое видится в голове.

Откуда берётся гипотеза

Есть исследованный и подтверждённый способ находить продуктовые идеи, который не связан с рыночной аналитикой вообще: расти из собственной боли. Пол Грэм называет такие идеи органическими — они вырастают не из абстрактного анализа рынка, а из того, что человек сам столкнулся с неудобством, оно его достало, и в какой-то момент он понял, что может это решить. У такой идеи уже есть один реальный пользователь на старте — сам автор, а значит, идея приходит не из воздуха, а из настоящего трения.

Так, например, Дрю Хьюстон сделал Dropbox, потому что устал таскать файлы на флешке между компьютерами. Сара Блейкли отрезала стопы у колготок, чтобы под белыми брюками не было видно линий белья, — так появился Spanx. Ник Вудман собирал камеру, способную выжить в серфинге и закрепиться на доске, — так вырос GoPro.

Сначала проверить, что проблема есть

Но у этого подхода есть свои риски, и про них нужно знать, чтобы использовать этот подход осознанно. В психологии это называется эффектом ложного консенсуса — устойчивая склонность переоценивать, насколько твои убеждения, боли и привычки разделяют другие.

А у Эша Маурьи в «Running Lean» есть отельный этап problem/solution fit (реальна ли проблема) и только потом мы идем в цикл build-measure-learn.

В АРИЗ (алгоритм решения изобретательских задач Альтшуллера) это называют ложной проблемой и есть даже чек лист диагностики ложной проблемы:

  1. А что будет, если задачу вообще не решать?
    • Что произойдёт, если оставить систему как есть и просто смириться с «недостатком»?
    • Насколько критичны последствия бездействия — реально ли это вред, или он надуман?
  2. Нельзя ли обойти задачу целиком?
    • Можно ли устранить саму необходимость в этом действии/функции, а не улучшать способ его выполнения?
    • Не является ли задача попыткой сохранить элемент системы, который на самом деле не нужен?
  3. Не решена ли уже эта задача — просто в другом виде?
    • Существует ли готовое решение в другой отрасли, для аналогичной по сути задачи?
    • Не пытаемся ли мы заново изобрести то, что уже изобретено
  4. Верно ли сформулирована сама проблема?
    • Не является ли это симптомом другой, более глубокой задачи?
    • Если подняться на уровень надсистемы — сохраняется ли задача там, или она снимается сама собой?
  5. Достаточно ли организационного/непроектного решения?
    • Нельзя ли решить вопрос не техническим изменением системы, а изменением условий её использования, регламента, порядка действий?

Если ответы показывают, что задача решается тривиально, обходом, готовым чужим решением или снятием на уровне надсистемы — она признаётся мнимой, и переходят к следующей по списку задаче. Если нет — переходят к формулировке технического противоречия и продолжают АРИЗ. Ровно так же и с продуктовой идеей: если выясняется, что проблема ложная, то продуктовый цикл не запускается или проверяется самым доступным дешевым способом. Эш Мaurya в «Running Lean» закрывает этот вопрос отдельной, более ранней стадией, которую называет соответствием проблемы решению: прежде чем строить хоть что-то, стоит ответить на вопрос, реальна ли вообще проблема и стоит ли она того, чтобы её решать.

Поэтому собственная боль — хороший источник гипотезы, но недостаточный источник доказательства. Разница между интуицией и методологией в том, проверяешь ли ты, что паттерн повторяется за пределами твоей головы. Здесь работает не опрос и не интервью, а наблюдение: за тем, что люди реально делают, а не за тем, что они говорят о своих намерениях. В экономике это называют наблюдаемыми предпочтениями — выбор человека под реальным ограничением времени или денег надёжнее, чем его прогноз о собственном будущем поведении, потому что выбор нельзя приукрасить из вежливости. Если у тебя есть практико-ориентированная среда — например, группа, которая проходит через реальную практику, а не отвечает на вопросы о гипотетическом будущем, — отчёты и инсайты из такой среды работают именно как проверка паттерна на количестве людей больше одного, оставаясь при этом наблюдением за действием, а не сбором мнений.

Дальше — правильный эксперимент

Здесь в дело идёт build-measure-learn в его прямом виде, с двумя уточнениями, без которых цикл легко скатывается в самообман:

  1. Каждый цикл проверяет одно допущение, а не несколько сразу. Если прототип меняет одновременно цену, интерфейс и формат подачи, а результат оказался плохим, невозможно понять, что именно провалилось. Хуже того, если результат оказался хорошим — тоже невозможно понять, что именно сработало, и повторить это осознанно в следующий раз.
  2. Допущение выбирается не то, которое приятнее проверять, а то, которое самое рискованное.

Александр Остервальдер и Дэвид Бланд предлагают простой способ расставить приоритеты: разложить все свои предположения на карте по двум осям:

  • насколько предположение критично для всей идеи — если оно неверно, рушится ли всё остальное
  • сколько по нему уже есть подтверждений — или это чистое предположение без всякой опоры

Проверять в первую очередь то, что одновременно критично и ничем не подтверждено. Именно там прячется риск, который убьёт идею, если окажется неверным, — а не риск, который приятно подтвердить лишний раз.

Метрика, которую стоит смотреть в этом эксперименте, тоже не одна и та же на всех этапах жизни продукта. Алистер Кролл и Бенджамин Йоскович в «Lean Analytics» описывают пять стадий, через которые проходит растущий продукт, и на каждой имеет смысл своя, и только своя метрика. На стадии эмпатии вопрос один — есть ли вообще незакрытая потребность у узнаваемой группы людей. На стадии липкости — держит ли продукт внимание тех, кто уже попробовал. Дальше идут вирусность, выручка и масштаб — и попытка мерить метрику стадии выручки, когда продукт ещё не прошёл стадию липкости, даёт цифры, которые ничего не говорят о реальном состоянии дел, зато создают иллюзию прогресса.

Почему сейчас цикл может быть быстрее

Экономика ошибки изменилась за последние годы сильнее, чем сама методология. Ещё недавно проверить гипотезу означало нанять разработчика и подождать недели, а то и месяцы, прежде чем появится хоть что-то, что можно показать людям. Сегодня вайбкодинг сокращают это время до дней, а иногда до часов — черновой прототип, который отвечает на один вопрос, больше не требует ни бюджета, ни команды.

Это преимущество технологий и его стоит использовать сознательно . Чем дешевле и быстрее одна итерация, тем больше итераций можно себе позволить до того, как закончатся деньги и мотивация. SpaceX построена ровно на этом принципе: инженеры называют свой подход «богатым на железо» — испытание собирается, запускается, и то, что сломалось при запуске, изучается и чинится, а не просчитывается заранее в бесконечных симуляциях. Это осознанное решение снижать стоимость одной попытки, чтобы позволить себе больше попыток — а не меньше промахов за одну попытку. То же самое доступно сейчас в продуктовой разработке в масштабе, недоступном ещё несколько лет назад.

Позиция наблюдателя — отдельный навык

Правильно спроектированный эксперимент защищает от одной ошибки — неверного вывода. Он не защищает от другой, отдельной ошибки — эмоционального разрушения, когда вывод оказывается отрицательным. Это два разных навыка, и первый не тянет за собой второй автоматически.

Механизм, который держит человека прикованным к провалившейся идее, в поведенческой экономике называется ошибкой невозвратных затрат: чем больше уже вложено, тем труднее признать, что решение было неверным, — потому что остановиться означает признать, что вложенное время пропало не в процессе роста, а в процессе тупика. Защита от этой ошибки — не сила воли, а конкретная и тренируемая техника, которую называют когнитивным дистанцированием: сознательно смотреть на ситуацию как бы со стороны, глазами наблюдателя, а не участника.

Так, например, когда Илон Маск запускал свои ракеты, а они падали и взрывается — он просто шел с инженерами и они собирал обломки и смотрели, что где не так. Взрыв не читается как приговор всей программе, потому что с самого начала было понятно: это одно из ожидаемых испытаний, а не финальный экзамен.

Замкнуть контур

Собранные вместе, три слоя:

  • проверка, что проблема реальна,
  • дисциплина эксперимента над решением
  • позиция наблюдателя, которая держит психику в рабочем состоянии Это — усиливающий контур обратной связи. Каждый цикл проверки даёт больше данных, чем предыдущий, и эти данные не откладываются в сторону, а меняют следующую гипотезу — какую боль решать точнее, какое допущение проверить следующим, какую метрику вообще имеет смысл смотреть на этой стадии. Продукт не рождается из одной верной догадки, он появляется как сумма всё более точных догадок, каждая из которых опирается на данные предыдущей.

Шаблон эксперимента

Формула гипотезы — то, что называют test card (карточка теста):

Мы верим, что [конкретное действие или решение] приведёт к [измеримому результату] для [группа людей]. Поймём, что правы, если увидим [конкретный сигнал, а не ощущение].

Дальше по каждому эксперименту фиксируются четыре поля — все до того, как результат уже известен:

  • допущение — что именно проверяем, самое рискованное по карте допущений, а не самое приятное/безопасное
  • тест — какой минимальный прототип или действие даст ответ на этот вопрос за один-два дня
  • метрика — что именно измеряем: число или доля, а не общее впечатление
  • критерий успеха — конкретное значение метрики, записанное заранее, при котором допущение считается подтверждённым, а при котором — опровергнутым

Какую метрику вообще имеет смысл ставить в четвёртое поле, зависит от стадии, на которой находится продукт — это те же пять стадий Lean Analytics, просто развёрнутые в вопрос, на который отвечает каждая:

  • эмпатия — есть ли вообще у узнаваемой группы людей незакрытая потребность
  • липкость — возвращаются ли те, кто уже попробовал, без напоминаний
  • вирусность — приводит ли текущий пользователь новых сам, без рекламного бюджета
  • выручка — готовы ли люди платить сумму, которая окупает стоимость привлечения
  • масштаб — держится ли экономика, когда объём вырастает на порядок

Мерить метрику стадии выручки, когда продукт ещё не прошёл стадию липкости, — то же самое, что тестировать четвёртое поле test card, не заполнив первое.

Приземление на свой опыт

  • Какая боль не отпускает тебя дольше нескольких месяцев — и видела ли ты, что похожим образом её решает кто-то ещё из твоего ближайшего круга, а не только ты сама?
  • Если бы одно-единственное твоё допущение оказалось неверным и обрушило всю идею — какое это допущение, и проверяла ли ты именно его, а не то, что проверить приятнее?
  • Какой самый дешёвый черновик за один-два дня ответит на этот вопрос — не финальная версия, не MVP, а минимальный кусок, который отвечает ровно на один вопрос?
  • Когда ты в последний раз смотрела на неудачный эксперимент как на данные для следующего цикла, а не как на приговор себе?