03.08.2026

HDD — Hypothesis Driven Development

Движущая сила: проверяемая бизнес-гипотеза (фича = эксперимент с метрикой).

Уровень применения: продукт и организация (обнаружение ценности).

Статус: растущий (Eric Ries, The Lean Startup, 2011; цикл Build-Measure-Learn; Martin Fowler, HypothesisDrivenDevelopment, 2016).

Не путать с: FDD (там фича — требование к реализации; здесь фича — гипотеза для проверки) и с A/B-тестированием (это инструмент измерения, а не методология).

Общее

Hypothesis Driven Development (HDD) — подход к продуктовой разработке, при котором каждая функциональность трактуется не как готовое требование, а как проверяемая гипотеза о том, что она создаст ценность для пользователя и/или бизнеса. Разработка ведётся короткими циклами «сформулируй предположение → построй минимальный эксперимент → измерь → сделай вывод», и решение о дальнейшей судьбе фичи (масштабировать, убить, развернуться) принимается на основе данных, а не мнений. Ключевая идея: в условиях неопределённости (новый рынок, новая аудитория, новая фича) заранее неизвестно, сработает ли предположение — поэтому строить полную реализацию «на веру» расточительно; дешевле проверить гипотезу минимальным экспериментом и решить по результатам.

Подход был систематизирован Эриком Рисом (Eric Ries) в книге The Lean Startup (2011), где он адаптировал идеи бережливого производства (Lean, Toyota Production System) и научного метода к продуктовой разработке. Рис сформулировал цикл Build-Measure-Learn и ввёл понятия MVP (Minimum Viable Product — минимально жизнеспособный продукт), проверяемая гипотеза, persevere/pivot (упорствовать или развернуться). Корни метода — двойные: с одной стороны, научный метод (гипотеза → эксперимент → вывод), с другой — Toyota Kata (Майка Ротера, практика коротких циклов улучшения с проверкой). Позже Мартин Фаулер (Martin Fowler) в статье HypothesisDrivenDevelopment (2016) перенёс идею из стартап-контекста в инженерный мейнстрим, показав, что цикл «гипотеза → код → метрика → вывод» применим не только к продуктам, но и к техническим решениям (архитектура, производительность, инфраструктура).

Принципиальное отличие HDD от остальных «*DD» в этой серии — его движущая сила. Если в TDD дизайн направляют тесты, в DDD — модель предметной области, в FDD — процесс доставки функции, то в HDD драйвером выступает проверка бизнес-предположения через метрику. Это сдвигает фокус с инженерного уровня (как писать код) на продуктовый (стоит ли вообще писать эту фичу). Главное отличие от FDD концептуально: в FDD фича — это единица работы с заранее известным результатом («реализовать расчёт скидки»); в HDD фича — это вопрос к реальности («если мы добавим скидки, вырастет ли повторная покупка?»), и ответ может быть любым.

HDD — зонтичное понятие, и под ним в индустрии понимают несколько связанных, но не тождественных практик:

  • HDD в строгом смысле (продуктовый) — фичи как гипотезы, цикл Build-Measure-Learn, MVP как минимальный эксперимент. Именно об этом статья.
  • Lean Startup (Рис, 2011) — операционная методология, из которой HDD вырос; шире HDD и включает бизнес-модель в целом.
  • Lean UX (Gothelf & Seiden, 2013) — применение гипотез к продуктовому дизайну: предположения о пользователе проверяются прототипами.
  • Continuous Discovery (Тереса Торрес) — непрерывное формирование и проверка гипотез через интервью и эксперименты; см. discovery process.

Статья рассматривает HDD в первом, продуктово-инженерном смысле, опираясь на перечисленные источники как на конкретные практики.

Ключевые принципы

HDD — это не «запускать фичи и смотреть на графики» (это аналитика), а набор принципов, которые в совокупности меняют то, как продукт принимает решение о разработке. Ниже — формулировка каждого с пояснением, какую конкретную проблему он решает.

Гипотеза прежде фичи. Любая фича начинается не с реализации, а с явно сформулированного предположения о том, какую ценность она создаст и как это будет измерено. Проблема: фичи, запущенные «потому что заказчик попросил» или «потому что конкурент так делает», не имеют критерия успеха — непонятно, сработали они или нет; в итоге backlog заполняется работой без отдачи. Гипотеза принуждает автора фичи ответить на вопрос «во что мы верим и как это проверим» до того, как написана первая строка кода.

Минимально жизнеспособный эксперимент (MVE / MVP). Вместо полной реализации строится минимальный эксперимент, достаточный для проверки гипотезы. Проблема: полная реализация фичи стоит недели-месяцы; если гипотеза неверна, эти инвестиции потеряны. Минимальный эксперимент (прототип, dark launch, фейковая кнопка, manual-обработка за кулисами — «Wizard of Oz») проверяет предположение за дни и стоит на порядки дешевле. Главная цена эксперимента — не код, а решение по результатам.

Метрика решения (валидация). Каждая гипотеза сопровождается конкретной метрикой и порогом, по которому принимается решение. Проблема: без заранее оговорённой метрики команда после запуска трактует результат под желаемый ответ («график растёт — значит, сработало»; но он мог расти и без фичи). Заранее зафиксированная метрика и порог («если конверсия вырастет на ≥5% — масштабируем, иначе — откатываем») устраняет самообман.

Быстрая итерация. Цикл «гипотеза → эксперимент → метрика → вывод» длится дни-недели, а не кварталы. Проблема: длинные циклы (классический «квартальный релиз») дают мало точек проверки за год; команда не успевает учиться и повторяет одни и те же ошибки. Короткий цикл Build-Measure-Learn максимизирует скорость обучения — главного актива в условиях неопределённости.

«Убить или масштабировать» (persevere/pivot). По итогам эксперимента команда принимает явное решение: масштабировать (гипотеза подтвердилась — строим полную реализацию), убить (гипотеза опровергнута — выкатываем из эксперимента), или развернуться (pivot — гипотеза неверна, но наблюдение наводит на новое предположение). Проблема: фичи, попавшие в прод, часто «живут вечно» просто потому, что никто не принял решения их убрать; явный выбор «убить» противостоит этому накоплению мёртвого кода и сложности.

Данные вместо мнений (data-driven). Решение принимается по измерениям, а не по иерархии или громкости голоса. Проблема: в спорах «работает фича или нет» побеждает обычно тот, кто выше по должности или громче; это систематически ведёт к ошибкам, потому что интуиция о пользователях часто неверна. HDD смещает разрешение споров к метрике. Подробнее о работе с командными метриками — в материале о team metrics.

Принципы — система, а не меню. Гипотезы без минимального эксперимента превращаются в «рассуждения о будущем»; эксперимент без метрики — в «запустили и смотрим» без вывода; метрика без явного решения «убить/масштабировать» — в накопление фич без очистки. Частичное внедрение создаёт «HDD-theatre» — формальные гипотезы в Jira без реальной дисциплины измерения и без решений по результатам; полное — даёт тот сдвиг в продуктовом мышлении, ради которого методология создавалась.

Как это работает

HDD оперирует коротким циклом Build-Measure-Learn, повторяемым на каждой гипотезе. Ниже — механика.

Цикл: сформулируй → построй → измерь → реши

Шаг Что происходит Выход
Сформулируй гипотезу Команда записывает предположение по шаблону, выбирает метрику и порог Гипотеза с метрикой и критерием решения
Построй минимальный эксперимент Реализуется минимально достаточная версия для проверки (не полная фича) Эксперимент готов к запуску
Измерь Эксперимент запускается на подмножестве пользователей, собираются данные Данные по метрике
Реши (persevere / pivot / kill) Команда сравнивает результат с порогом и принимает решение Явное решение: масштабировать, развернуться или убрать

Цикл длится от нескольких дней до нескольких недель; чем короче, тем выше скорость обучения. Рис подчёркивал: цель цикла — не «выпустить фичу», а получить подтверждённое знание о том, работает ли предположение; фича здесь — лишь носитель эксперимента.

Шаблон гипотезы

Каноническая форма, восходящая к Lean UX (Gothelf & Seiden) и популяризированная Фаулером:

Мы верим, что [опущенное предположение о пользователе / бизнесе].
Если мы [построим это минимальное решение],
то [произойдёт измеримый эффект].
Мы измерим это через [конкретная метрика]
и сочтём гипотезу подтверждённой, если [пороговый критерий].

Конкретный пример:

Мы верим, что пользователи брошенной корзины возвращаются при напоминании. Если мы добавим email-напоминание через 1 час после брошенной корзины, то доля завершённых покупок вырастет. Мы измерим это через конверсию «брошенная корзина → покупка» и сочтём гипотезу подтверждённой, если прирост составит ≥ 5% при p < 0.05.

Шаблон не косметический: он принуждает автора явно выделить предположение (что именно мы не знаем), действие (что строим), ожидаемый эффект (что должно измениться), метрику (как измерим) и порог (когда признаём подтверждённой). Гипотеза без порога — не гипотеза, а пожелание: после запуска всегда найдётся интерпретация «ну, немного же выросло».

Vanity-метрики vs actionable-метрики

Один из ключевых тезисов Риса — разведение тщеславных (vanity) и действенных (actionable) метрик. Первые хорошо выглядят на графиках, но не ведут к решению; вторые позволяют принять решение «убить/масштабировать».

Тип Пример Признак Пригодность для HDD
Vanity (тщеславная) Зарегистрированные пользователи, просмотры страниц, загрузки приложения Растёт почти всегда; не связана с решением; легко «накрутить» Непригодна — не даёт вывода
Actionable (действенная) Конверсия в покупку, retention на 7-й день, доля повторных покупок, cost per acquisition Связана с бизнес-моделью; меняется от эксперимента; имеет порог Пригодна — ведёт к решению
Критерий Vanity Actionable
Что показывает «Как у нас дела» (отчётность) «Что делать дальше» (решение)
Динамика во времени Растёт почти всегда Может падать и расти
Связь с экспериментом Слабая Прямая
Пригодность для A/B Низкая Высокая

Типичная ловушка: команда выбирает vanity-метрику («общее число пользователей выросло!») и на её основе решает «масштабировать», хотя фича ни на что не повлияла — рост объясняется другими факторами. Actionable-метрика («конверсия в платную подписку в когорте, получившей фичу, vs контрольная группа») даёт честный ответ.

Persevere / Pivot / Kill

По итогам измерения команда принимает одно из трёх решений:

  • Persevere (упорствовать). Гипотеза подтверждена — масштабируем минимальный эксперимент в полную реализацию.
  • Pivot (развернуться). Гипотеза в исходном виде опровергнута, но данные наводят на новое предположение; команда корректирует гипотезу и запускает новый цикл. Рис выделял несколько типов pivot-ов (zoom-in, zoom-out, сегмент клиентов, изменение метрики и др.).
  • Kill (убить). Гипотеза опровергнута и новых предположений нет — эксперимент выкатывается из кода. Это решение самое трудное организационно, потому что «выбросить написанное» психологически больно (sunk cost fallacy), но именно оно предотвращает накопление мёртвых фич и технического долга.

Влияние на команду и процесс

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

Планирование через гипотезы, а не фичи. Roadmap меняет форму: вместо списка обязательств («в Q3 доставим фичу X») он становится списком вопросов («в Q3 проверим, снижает ли фича X отток»). Проблема: roadmap как обязательство вынуждает команду «доставить во что бы то ни стало», даже если midway выясняется, что фича не работает; roadmap как набор экспериментов разрешает убить фичу по результатам измерения. Для руководителя это сдвиг в управлении ожиданиями стейкхолдеров: «гарантия срока» заменяется на «гарантию ответа на вопрос».

Роли: продукт / данные / разработка. HDD вводит или усиливает три ключевые роли:

Роль Зона ответственности в HDD
Product Manager / Owner Формулирует гипотезы, приоритизирует эксперименты, принимает решения по результатам
Data Analyst / Data Scientist Проектирует метрики, считает статистическую значимость, защищает от самообмана vanity-метриками
Разработка Строит минимальные эксперименты, внедряет instrumentation (отслеживание событий), обеспечивает feature flags для быстрых kill-ов

Без аналитика/дата-сайентиста HDD вырождается: команда запускает эксперименты, но не умеет их корректно измерить. Без разработки, готовой к feature flags и instrumentation, цикл замедляется — каждый эксперимент превращается в полноценный релиз.

Instrumentation-first. Способность системы измерять поведение пользователя (события, воронки, когорты) становится предусловием HDD. Проблема: без instrumentation невозможно измерить метрику; фича, запущенная без отслеживания, не проверяема. Это означает, что в roadmap закладывается работа над инфраструктурой измерений как первоочередная задача — до самих экспериментов. Команды, пропустившие этот шаг, получают «HDD без данных» и принимают решения на глаз.

Feature flags как инженерная основа. Быстрый цикл «запустить → измерить → убить/масштабировать» требует способности включать и выключать фичу для подмножества пользователей без релиза. Feature flags (LaunchDarkly, Unleash, собственные реализации) — технический фундамент HDD, без которого цикл ломается о тяжесть релизов. Это прямая инженерная инвестиция, которую руководитель должен закладывать в план.

Roadmap от обязательств к экспериментам. Для руководителя это один из самых болезненных переходов. Классический roadmap — это обещание стейкхолдерам («в декабре будет фича Y»). HDD-roadmap — это портфель экспериментов с вероятностями («в декабре проверим гипотезу Z; с вероятностью 60% масштабируем, с 40% — убьём»). Финансовое планирование при этом усложняется, потому что предсказать, какие именно фичи попадут в прод, невозможно. Платой становится радикально более высокая доля запущенных фич, реально работающих на бизнес-метрику.

Культура «безопасно ошибаться». HDD систематически производит «провалы» — гипотезы, которые не подтвердились (по некоторым данным, 60–80% экспериментов в зрелых продуктовых командах не дают ожидаемого эффекта). Если культура наказывает за «провалившиеся» гипотезы, команда перестаёт формулировать рискованные (а значит, и потенциально прорывные) предположения и сводит эксперименты к тривиальным. Напротив, культура, в которой опровергнутая гипотеза — это полученное знание, а не неудача, создаёт пространство для реального обучения. Подробнее о климате для экспериментов — в материалах о командной культуре и ретроспективах.

Преимущества

Снижение затрат на ненужные фичи. Главное преимущество. Минимальный эксперимент стоит на порядки дешевле полной реализации; гипотеза, опровергнутая за неделю, экономит месяцы работы, которые иначе ушли бы на фичу, не создающую ценности. По данным зрелых продуктовых команд, значительная доля проверяемых гипотез не подтверждается — и именно эти «не подтвердившиеся» фичи не попадают в прод, освобождая ресурс для работающих.

Данные вместо мнений. Споры «работает/не работает» разрешаются измерением, а не иерархией. Это снижает внутреннюю политику и систематически улучшает качество решений, потому что интуиция о пользователях ненадёжна.

Быстрая валидация. Цикл в дни-недели даёт множество точек проверки за квартал. Команда учится быстрее конкурентов, ведущих классическую «квартальную» разработку, и за тот же период проверяет больше предположений.

Продуктовая фокусировка. Команда перестаёт измерять себя «выпущенными фичами» (vanity) и начинает — «подтверждёнными гипотезами» (actionable). Это смещает внимание с объёма работы на её отдачу, что принципиально меняет приоритизацию backlog-а.

Явная чистка неперспективного. Решение «kill» противостоит накоплению мёртвого кода и сложности. Команда, убивающая 30% экспериментов, держит систему чище той, что оставляет «всё на всякий случай».

Мост между продуктом и разработкой. Разработка получает понятный критерий «зачем мы это делаем» (метрика гипотезы), а не только «как». Это повышает осмысленность работы и снижает разрыв между инженерным и продуктовым взглядом.

Недостатки и риски

Локальная оптимизация. Если каждая гипотеза проверяется изолированно, команда может увязнуть в микро-экспериментах, каждый из которых «подтверждается» на сотых долях процента, в ущерб стратегическим ставкам. Симптом: backlog из сотни мелких гипотез и ни одного крупного продукта. Решение — балансировка портфеля: часть ресурсов на эксперименты, часть — на стратегические ставки, не разложимые на короткие циклы.

Vanity-метрики и самообман. Выбор «удобной» метрики, которая растёт независимо от фичи, подрывает весь метод. Команда «доказывает» успех там, где его нет, и масштабирует то, что не работает. Защита — независимый data-аналитик и заранее зафиксированный критерий (метрика + порог до эксперимента, не после).

Затраты на instrumentation. Способность измерять — не бесплатна. Instrumentation, хранение событий, аналитические пайплайны, A/B-платформа — это инфраструктурная инвестиция, часто недооцениваемая. Команды, начавшие HDD без этой базы, буксуют: эксперименты запускаются, а измерить их корректно нельзя.

Культура, не готовая к «провалам». HDD производит много опровергнутых гипотез по определению. В культуре, где «провал» наказывается, команда либо перестаёт рисковать, либо подгоняет результаты под «успех». Это разрушает метод изнутри. Предусловие — психологическая безопасность, и без неё HDD не внедряется.

Статистическая неграмотность. Корректный эксперимент требует понимания выборки, статистической значимости, эффекта причины-следствия vs корреляции. Команда без этих навыков делает ложные выводы: видит рост там, где его нет (regression to the mean), или не видит эффекта там, где он есть (маленькая выборка). Защита — участие data-аналитика в дизайне эксперимента.

Не подходит для задач с известным решением. Если ответ заранее известен (задача типа «обновить версию фреймворка», «пофиксить регуляторное требование»), формулировать гипотезу бессмысленно — это лишние накладные. HDD — инструмент для неопределённости; в определённости он избыточен.

Длинный tail инфраструктуры. Feature flags, A/B-платформа, instrumentation, чистка убитых экспериментов — всё это требует постоянной инженерной поддержки. Без неё система обрастает «висящими» флагами и сломанной телеметрией.

Когда использовать

  • Продуктовая разработка с высокой неопределённостью. Новый продукт, новая аудитория, новая монетизация — там, где заранее неизвестно, что сработает. Главный сценарий применимости HDD.
  • Стартапы. Поиск продукт-маркет фит — классический случай: цикл Build-Measure-Learn создавался именно для поиска работающей бизнес-модели.
  • Новые фичи на зрелом продукте. Значительные изменения (новый onboarding, изменение воронки, новая монетизация), где риск «не сработает» велик; проверка гипотезой дешевле полной реализации.
  • Выход на новые рынки. Локализация, новые сегменты пользователей — предположения о поведении новой аудитории нужно проверять, а не принимать на веру.
  • Есть аналитическая база и зрелый CI/CD. HDD требует instrumentation, feature flags и частых релизов; без этой инженерной базы цикл ломается. Предусловие, а не пожелание.
  • Команда с доступом к данным и навыком их интерпретации. Data-аналитик или продуктовый исследователь — обязательный участник цикла.

Когда НЕ использовать

  • Регуляторные и legacy-домены. Там, где изменение требует долгих согласований (финансы, медицина, гос) и где «убить фичу по результату эксперимента» практически невозможно из-за обязательств перед регулятором, HDD теряет главное преимущество — быстрый цикл.
  • Задачи с известным решением. Обновление версии фреймворка, починка регуляторного требования, миграция БД — там, где нет неопределённости в «сработает ли», формулировать гипотезу бессмысленно. Здесь работают классические инженерные подходы.
  • Технический долг и рефакторинг. Ценность рефакторинга не проверяется бизнес-метрикой (он не повышает конверсию напрямую); пытаться «прогипотезировать» техническую работу — значит ввести себя в заблуждение. Рефакторинг обосновывается инженерными метриками (время сборки, стоимость изменения), а не продуктовыми.
  • Чистая инфраструктура. CI/CD, observability, внутренние платформы — там, где «пользователь» это сам разработчик, а метрика — инженерная. HDD здесь часто переформулируется в инженерный аналог (Фаулеровский HypothesisDrivenDevelopment), но продуктовый цикл Build-Measure-Learn ложится плохо.
  • Нет инженерной базы. Без feature flags, instrumentation и частых релизов цикл не работает; команда получает «HDD-theatre» — формальные гипотезы в таск-трекере без реальной дисциплины измерения и kill-ов.
  • Культура без психологической безопасности. Если «опровергнутая гипотеза» карается, метод вырождается в подгонку результатов под успех. Сначала — культура, потом — HDD.

Связанные подходы

HDD — не единственный «*DD» в разработке; за разными аббревиатурами стоят разные «движущие силы». Статья входит в серию материалов о driven-подходах; ниже — краткая карта, со ссылками на уже опубликованные материалы базы знаний.

Подход Движущая сила Что управляет дизайном Уровень применения
TDD Тесты Тесты как исполняемая спецификация Код и команда
DDD Домен Модель предметной области и единый язык Команда и организация
BDD Поведение Сценарии Given-When-Then Команда и заказчик
FDD Функция (фича) Процесс доставки фичи Команда и организация
MDD Формальная модель Модель как источник истины для кодогенерации Команда
ATDD Критерии приёмки Приёмочные тесты как спецификация Команда и заказчик
HDD (этот материал) Бизнес-гипотеза Эксперимент с метрикой Продукт и организация
  • TDD — Test Driven Development — родственный подход на инженерном уровне. TDD проверяет, хорошо ли написан код; HDD проверяет, нужно ли вообще писать эту фичу. Они дополняют друг друга: HDD определяет, что строить (по результату эксперимента), TDD страхует, как это написать.
  • BDD — Behaviour Driven Development — родственный подход на уровне требований. BDD формулирует ожидаемое поведение в сценариях; HDD формулирует ожидаемый бизнес-эффект в гипотезах. BDD отвечает «как система должна себя вести», HDD — «приведёт ли это поведение к бизнес-результату».
  • DDD — Domain Driven Design — родственный подход на уровне модели. DDD строит общий язык домена; HDD пользуется этим языком при формулировке гипотез о пользователях и ценности.
  • FDD — Feature Driven Development — концептуальный контрапункт HDD. В FDD фича — это требование к реализации с известным результатом; в HDD фича — это вопрос к реальности, ответ на который неизвестен. FDD уместен там, где ценность фичи очевидна; HDD — там, где она под вопросом.
  • ATDD — Acceptance Test Driven Development — родственный подход на уровне приёмки. ATDD проверяет, соответствует ли фича критериям приёмки; HDD проверяет, приводят ли эти критерии к бизнес-результату.
  • Discovery process — продуктовое исследование, в рамках которого формулируются гипотезы; Continuous Discovery (Торрес) — непрерывный вариант HDD на уровне интервью и экспериментов.
  • Design thinking и UX-research — методы генерации гипотез о пользователях до их проверки в HDD-цикле.
  • Usability — качество, которое само по себе может быть предметом гипотезы («улучшение юзабилити onboarding снизит отток»).
  • Agile и Scrum — процессные рамки, в которые HDD встраивается как способ приоритизации backlog-а: гипотезы ранжируются по ожидаемой ценности и стоимости проверки.
  • Team metrics — метрики команды; важно не путать продуктовые метрики гипотез (actionable) с командными метриками (velocity и т. п.).
  • Итеративная модель и SDLC — HDD естественно ложится на короткие итерации с обратной связью; классический водопадный SDLC циклу Build-Measure-Learn противоречит.
  • Технический долг — обратная сторона kill-решений: без дисциплины «убивать» опровергнутые эксперименты система обрастает мёртвым кодом.

Родственные driven-подходы — TDD, ATDD, BDD, DDD, FDD, MDD, а также «сатирические» варианты вроде Panic Driven Development — рассматриваются в соответствующих статьях серии.

Краткий вердикт для руководителя

HDD — это инвестиция в продуктовую обоснованность, а не способ писать код быстрее. Эффект: меньше затрат на ненужные фичи, данные вместо мнений, быстрая валидация предположений, явная чистка неперспективного. Цена: инфраструктура измерений (instrumentation, feature flags, A/B-платформа), необходимость data-аналитика в цикле, болезненный переход roadmap-а от обязательств к экспериментам, и — главное — культура, в которой «опровергнутая гипотеза» это знание, а не провал. Берите, если продукт сталкивается с высокой неопределённостью (стартап, новая фича, новый рынок), у вас зрелый CI/CD с feature flags и есть доступ к данным. Не берите, если домен регуляторный или legacy, задача имеет известное решение (рефакторинг, миграция), или культура наказывает за «провалы». И помните: HDD — это не «запускать фичи и смотреть на графики», а дисциплина гипотеза → минимальный эксперимент → заранее оговоренная метрика → явное решение; без этой дисциплины метод вырождается в самообман на vanity-метриках.

Источники и материалы

Первоисточники и ключевые публикации

  • Eric Ries. The Lean Startup. Crown Business, 2011 — первоисточник цикла Build-Measure-Learn, понятий MVP, проверяемой гипотезы, persevere/pivot.
  • Martin Fowler. HypothesisDrivenDevelopment (martinfowler.com, 2016) — перенос идеи из стартап-контекста в инженерный мейнстрим; HDD для технических решений.
  • Jeff Gothelf, Josh Seiden. Lean UX: Applying Lean Principles to Improve User Experience. O’Reilly, 2013 — шаблон гипотезы «We believe…» и применение HDD к продуктовому дизайну.
  • Alistair Croll, Benjamin Yoskovitz. Lean Analytics. Wiley, 2013 — разведение vanity- и actionable-метрик, выбор метрики для стадии продукта.
  • Mike Rother. Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results. McGraw-Hill, 2009 — корни HDD в коротких циклах улучшения с проверкой.
  • Teresa Torres. Continuous Discovery Habits. Product Talk, 2021 — непрерывное формирование и проверка гипотез через интервью.

Связанные материалы базы знаний