5-дневный спринт: что это, когда работает и когда нет

Три месяца, которые ничего не дали

Команда из шести человек три месяца строила модуль аналитики для B2B SaaS-платформы. Дизайнер, два разработчика, PM, тестировщик. Квартальный план, еженедельные стендапы, демо каждые две недели. Всё по процессу.

Запустили — и тишина. Из 200 аккаунтов модуль открыли 14. Вернулись на следующий день — трое. PM написал в Slack: Нам нужно больше данных, чтобы понять, в чём проблема». Но проблема была не в данных. Проблема была в том, что три месяца назад никто не проверил, нужен ли этот модуль хотя бы пяти клиентам

Знакомо? Тогда вот другой способ: вместо 3-х месяцев потратить все ресурсы шести людей на 5-ти дневный чекап идеи и подтверждения ценности.

Что такое 5-дневный спринт (и почему это не agile-спринт)

5-дневный спринт — это исследовательский цикл с жёстким дедлайном. Четыре фазы: гипотеза → эксперимент → сигнал → решение. На выходе — не код, не фича и не презентация, а простое решение: start, stop, pivot

Принципиальное отличие от agile-спринта в одном слове. Agile-спринт — это производство: что мы доставим за две недели. Research Sprint — это исследование: что мы узнаем за пять дней. Когда команда путает эти два режима, она получает худшее из обоих: медленное исследование и крайне эффективное, но бессмысленное производство.

«Мы привыкли мерить прогресс в фичах. А нужно мерить в решениях. За квартал можно выпустить 12 фич — и ни одного продуктового решения.» — паттерн, который повторяется в каждой второй B2B-команде на Series A.

Почему именно 5 дней

Закон Паркинсона: работа займет все доступное время. Дайте команде две недели на проверку гипотезы — и первые десять дней уйдут на подготовку, выравнивание ожиданий и «ещё один раунд обсуждений».

Менее 5 дней — не хватает глубины. За три дня можно написать гипотезу и собрать лендинг. Но добраться до реального пользователя, провести интервью и получить сигнал — физически не получится. Особенно в B2B, где на согласование звонка уходит день-два.
Более 5 дней — включается режим строительства. На шестой день PM начинает «дорабатывать прототип». На седьмой — дизайнер просит ещё день на анимации. К десятому дню команда уже строит продукт, а не проверяет гипотезу. Спринт в CRM-стартапе Saleswhale (сейчас 6sense) показал это наглядно: первые два спринта по неделе давали чёткие сигналы, третий растянули до двух недель — и закончили с прототипом, который все хвалили, но никто не купил.

Пять дней — минимальный горизонт, за который полный цикл проходит без потери качества сигнала. Не больше, не меньше. В Пн 10:00 начинается, в Пт 18:00 Мск принимается решение start/stop/pivot

Когда спринт работает

01 Есть конкретная гипотеза о проблеме или решении. «Средний клиент теряет 3 часа в неделю на ручной экспорт отчётов» — гипотеза. «Нам нужно что-то сделать с аналитикой» — не гипотеза. Чем точнее формулировка, тем сильнее сигнал на выходе.
02 Есть доступ к 5–7 потенциальным пользователям. В B2B SaaS это могут быть текущие клиенты, пользователи триала или контакты из LinkedIn. Если вы не можете за два дня организовать пять 30-минутных звонков — спринт буксует на старте. Команда Intercom на ранних стадиях держала правило: каждую неделю минимум пять разговоров с клиентами. Это не формальность — это топливо для спринта.
03 Один участник команды может посвятить спринту всю неделю. Не полчаса между митингами, а фокусный блок. В минимальном варианте это PM с ИИ как рабочим инструментом. В командном — PM плюс один инженер или дизайнер.
04 Результат можно проверить без месяцев разработки. Fake door, лендинг, Wizard of Oz, скрипт на Typeform — если гипотезу нельзя упаковать в что-то тестируемое за два дня, спринт не подходит.

Как пишет Тристен Кромер «у хорошей команды минимум один эксперимент в неделю — иначе она просто не учится.»

Когда спринт НЕ работает

01 Greenfield без понимания аудитории. Если вы не знаете, кто ваш клиент, спринт не поможет — вам нужен этап discovery, а не проверка гипотезы. Сначала 20 custdev-интервью, потом спринт.
02 Enterprise-сделки с 6-месячным циклом решений. Когда закупка требует согласования четырёх департаментов и тендера — сигнал в виде «посмотрели лендинг» не даёт ничего. Здесь нужны другие форматы: LOI, пилотные договоры, conditional commitments.
03 Регуляторные продукты с compliance на каждом шаге. Финтех, медтех, страхование — если каждый эксперимент требует юридической проверки, пятидневный цикл ломается.
04 Команда не может принимать решения без трёх уровней согласования. Спринт требует одного решателя. Если на итог спринта нужно благословение VP of Product, VP of Engineering и CEO — результат протухнет быстрее, чем пройдёт согласование.

Как выглядят 5 дней: обзор по шагам

День 1 — Проблема, гипотеза, исследование. Фиксируете контекст: для кого, какая боль, почему сейчас. Заполняете Hypothesis Canvas — одностраничный документ с сегментом, болью, предполагаемым решением, ключевым риском и критерием успеха. Критерий: к концу дня у вас есть одна проверяемая гипотеза и LeanPRD документ с записанным определением «что считаем достаточным сигналом», «проблема, сегмент, боль, эксперимент»
День 2 — Минимальная упаковка. Создаёте артефакт для теста: лендинг, прототип в Figma, Typeform-воронку или Wizard of Oz. Это не продукт — это инструмент получения сигнала. Notion на ранних этапах проверяла новые use cases через Google-форму с описанием сценария и кнопкой «хочу попробовать». Критерий: артефакт можно показать клиенту
День 3 — Первый трафик и интервью. Направляете 20–50 целевых контактов на артефакт. В B2B это чаще всего прямой outreach: LinkedIn, email, существующая база. Параллельно — 3–5 интервью, где вы показываете артефакт и наблюдаете реакцию. Критерий: минимум 20 контактов увидели артефакт, минимум 3 интервью проведены. Для B2C можно прямо трафиком проверить.
День 5 — принятие решения. Собираете данные: конверсия лендинга, реакция в интервью, запросы на «когда будет готово?» или тишина. Сверяете с критерием успеха из Дня 1. Принимаете одно из трёх решений: start (гипотеза подтвердилась — переходим к разработке), stop (гипотеза не подтвердилась — фиксируем, что узнали, двигаемся дальше) или pivot (сигнал есть, но в другую сторону — переформулируем и запускаем следующий спринт).

Чеклист готовности к спринту

Гипотеза записана в формате: [сегмент] испытывает [боль] и готов [действие], если мы дадим [решение]
Критерий успеха зафиксирован до старта (не «будет понятно по ощущениям»)
Есть список из 5–7 людей для интервью и 20+ контактов для трафика
Один человек выделен на полную неделю
Решатель определён — тот, кто скажет continue, kill или pivot в пятницу

Если хотя бы одно условие не выполнено — не начинайте спринт. Начните с выполнения этого условия.

Что вы получаете на выходе

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

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

Следующий шаг

Если вы узнали свою ситуацию — начните с Дня 1. Возьмите одну гипотезу из бэклога, заполните Hypothesis Canvas и назначьте пятницу днём решения.