The Lean Startup
О проверке продуктовых гипотез через короткие циклы создания, измерения и обучения.
Главная идея — уменьшать не время написания кода само по себе, а время до получения достоверного знания о поведении пользователя.
То, что стоит запомнить после закрытия страницы
Сначала гипотеза
Без формулировки того, что именно должно оказаться правдой, любой результат теста легко интерпретировать задним числом.
MVP — инструмент обучения
Минимальность имеет смысл не как плохая версия продукта, а как самый дешёвый способ проверить критичное предположение.
Метрики должны менять решение
Красивые цифры бесполезны, если они не помогают решить: продолжать, менять подход или отказаться от гипотезы.
Не только тезисы — как устроена идея целиком
The Lean Startup — не про выпуск сырого продукта как можно быстрее. Главная цель цикла build–measure–learn — сократить время до достоверного знания о том, что нужно пользователю и какая модель может работать.
Поэтому MVP не определяется количеством функций. Это минимальный эксперимент, который проверяет самое рискованное предположение. Иногда это код, иногда ручной сервис, лендинг, прототип или разговор с реальными пользователями.
Гипотеза должна быть фальсифицируемой
Фраза «людям понравится» слишком размыта. Хорошая гипотеза заранее говорит, какое поведение ожидается и какой результат заставит изменить мнение.
MVP измеряется обучением, а не размером
Маленький продукт, который ничего не проверяет, не является хорошим MVP. Ценность эксперимента определяется качеством знания, которое он создаёт.
Vanity metrics мешают обучению
Рост просмотров или регистраций может выглядеть убедительно, но не отвечать на главный вопрос. Метрика должна связываться с поведением, удержанием, оплатой или другим решением.
Pivot — изменение гипотезы, а не паническая смена всего
Если эксперимент опровергает предположение, нужно изменить конкретный элемент модели, сохранив полученные знания. Хаотичная смена идеи после каждого сигнала разрушает обучение.
Идея ломается, если применять её слишком буквально
Запускать плохое качество под видом MVP
Минимальный эксперимент должен быть достаточно качественным, чтобы проверять нужную гипотезу. Если пользователь уходит из-за грубой поломки, это мало говорит о ценности идеи.
Не определять критерий заранее
Без порога успеха любой результат можно объяснить как обнадёживающий. Критерий должен существовать до теста.
Собирать данные без решения
Эксперимент имеет смысл, если заранее понятно, какое действие последует при разных исходах.
Практический протокол на 7 дней
- 1
Запиши одно самое рискованное предположение текущего продукта.
- 2
Сформулируй наблюдаемое поведение, которое подтвердит или опровергнет его.
- 3
Придумай самый дешёвый тест без лишней разработки.
- 4
Определи порог успеха до запуска.
- 5
После результата зафиксируй решение: продолжить, изменить гипотезу или остановить направление.
Что можно проверить уже сегодня
- 1
Запиши самое рискованное предположение текущего продукта.
- 2
Придумай самый дешёвый тест, который может его опровергнуть.
- 3
Заранее определи метрику и порог, после которого изменишь решение.
Вопросы, после которых идея становится личной
Что должно оказаться правдой, чтобы продукт имел смысл?
Как проверить это дешевле, чем полноценной разработкой?
Какая метрика действительно изменит решение?
Что я сделаю, если тест даст плохой результат?
Этот материал объясняет идеи собственными словами и не повторяет структуру или текст оригинальной книги. Для полного контекста мы рекомендуем читать оригинал.