Когда стоит делать RAT вместо MVP?

Когда есть критичная гипотеза с низкой уверенностью. RAT помогает проверить ее быстрее и дешевле, чем строить минимальную версию продукта.

Что проверяет прототип?

Прототип помогает проверить сценарий, интерфейс, понимание ценности, adoption и реакцию пользователя до разработки.

Что такое fake door?

Fake door проверяет интерес к возможности до разработки: пользователь видит предложение или кнопку, а команда измеряет сигнал спроса без полноценной функции.

Можно ли использовать оценщик вместо product discovery?

Нет. Оценщик показывает предварительный методический ориентир. Для важных решений нужны исследования, эксперименты, техническая оценка, данные и проверка человеком.

Сохраняются ли данные идеи и гипотез?

Нет. Проверка выполняется в браузере, данные идеи, гипотез и экспериментов не сохраняются и не отправляются на сервер.

Что делать, если build risk высокий?

Сократите scope и выберите более быстрый формат проверки: RAT, prototype, PoC, fake door, concierge или Wizard of Oz.

Validation Decision Lab

Конструктор MVP / RAT / PoC

Q: Когда нужен PoC?

PoC нужен, если главный риск связан с технической, операционной, data или integration реализуемостью.

Выберите формат проверки идеи: RAT, PoC, prototype, fake door, concierge, Wizard of Oz, pilot или MVP - по уровню риска, evidence и готовности команды.

Проверка выполняется в браузере
Данные не сохраняются
Помогает не строить лишний MVP
Находит самую рискованную гипотезу
Показывает следующий experiment

Выбрать формат проверки

Оценщик показывает методический ориентир, а не заменяет discovery, техническую оценку и решение команды.

Цепочка проверки

Идея
Риск
Гипотеза
Формат проверки
Метрика
Learning decision

Проверка выполняется в браузере. Данные идеи и эксперимента не сохраняются и не отправляются на сервер.

Когда полезен конструктор MVP / RAT / PoC

Команда часто называет MVP почти любую первую версию продукта. Но иногда не нужен MVP: достаточно проверить одну рискованную гипотезу через RAT, сделать технический PoC, собрать прототип, запустить fake door или проверить ценность вручную. Конструктор помогает выбрать формат проверки по текущему риску, а не по привычному названию.

•команда хочет строить MVP, но проблема еще не подтверждена
•неясно, что рискованнее: рынок, техника, UX, канал или экономика
•нужно проверить готовность платить
•нужно проверить техническую реализуемость
•нужно выбрать первый experiment после Lean Canvas
•нужно сократить scope первой версии
•нужно подготовить product discovery
•нужно объяснить команде, почему сначала нужен RAT, PoC или prototype
•нужно связать эксперимент с метрикой и success criteria

Контекст идеи

Тип продукта / проверки

Стадия идеи

Главная цель проверки

Название идеи / продукта

Не отправляется на сервер. Используется только в браузере.

Краткое описание идеи

Целевой сегмент

Шаблон проверки

Риски и evidence

Главная проблема клиента

Текущие альтернативы (опционально)

Evidence проблемы

Evidence спроса

Технический риск

UX / adoption risk

Channel risk

Revenue / willingness-to-pay risk

Операционный риск

Планируемая проверка

Формат, который команда сейчас рассматривает

Time to learn, дней

Предполагаемый MVP / experiment scope

Learning question

Success criteria (опционально)

Целевая метрика (опционально)

Effort 1-5

1 - очень легко, 5 - почти полноценная разработка.

Оценка стоимости

Есть ли owner проверки

Рискованные гипотезы

ImpactConfidence

Эксперименты

Time to learn, дней

Effort 1-5

Risk if skipped

Owner

Time to learn, дней

Effort 1-5

Risk if skipped

Owner

Time to learn, дней

Effort 1-5

Risk if skipped

Owner

Time to learn, дней

Effort 1-5

Risk if skipped

Owner

Time to learn, дней

Effort 1-5

Risk if skipped

Owner

Time to learn, дней

Effort 1-5

Risk if skipped

Owner

Time to learn, дней

Effort 1-5

Risk if skipped

Owner

Добавьте идею, сегмент, проблему и рискованные гипотезы, чтобы увидеть рекомендуемый формат проверки.

Recommended Validation Format

Problem interview

Final Score 8 / 100

Проблема пока подтверждена слабо. Начните с интервью или RAT.

Глубинные интервью с целевым сегментом.

Build Risk

40 / 100

Scope выглядит управляемым.

Problem Evidence

Market Signal

Technical Feasibility

Solution Confidence

Experiment Readiness

Learning Velocity

MVP Scope Risk

Riskiest Assumption

Клиент готов оставить заявку или заплатить

Time to Learn

14 дн

Effort 3 / 5

Suggested Next Experiment

Problem interview

Главный риск

weak problem evidence

Penalty 30 · Validation Format Fit 38

Сохранить или обсудить

PDF собирается в браузере - мы не сохраняем ваши данные. Письмо открывается в вашем почтовом клиенте - вы сами решаете, что отправить.

Обсудить с экспертом

Опишите идею или продукт

Конструктор работает по введенным данным.

Опишите сегмент

Без сегмента нельзя выбрать формат проверки.

Главная проблема не описана

Сначала уточните, какую боль клиента вы проверяете.

Проблема пока подтверждена слабо

Начните с problem interviews или RAT.

Высокий revenue risk

Добавьте sales test, fake door, paid pilot или concierge.

Нет learning question

Сформулируйте вопрос, на который должен ответить эксперимент.

Нет success criteria

Задайте критерии успеха до начала проверки.

Нет метрики

Привяжите эксперимент к одной измеримой метрике.

Много high critical / low evidence гипотез

Сначала проверьте самую рискованную через RAT.

Validation Format Matrix

Матрица соотносит главный риск и подходящий формат проверки.

Тип риска	Сигнал	Подходящий формат
Problem	Проблема не подтверждена интервью	Problem interview, RAT
Market	Спрос не подтвержден сигналами	Fake door, landing test, sales test
Technical	Высокий риск интеграций или данных	PoC
UX	Сценарий и интерфейс непонятны пользователю	Prototype, Wizard of Oz
Revenue	Готовность платить не подтверждена	Fake door, paid pilot, concierge
Operations	Процесс пока не отработан	Concierge, Wizard of Oz
Evidence сильное и риски сбалансированы	Можно проверять минимальный сценарий	Narrow MVP

Riskiest Assumption Board

Гипотеза	Тип	Crit	Evidence	Conf	Impact	Test	Score
Клиент действительно испытывает проблему	Problem	Высокая	Только гипотеза	40	5 / 5	Problem interview	60
Проблема возникает достаточно часто	Problem	Высокая	Только гипотеза	35	5 / 5	Problem interview	65
Клиент уже ищет альтернативы	Market	Средняя	Только гипотеза	40	4 / 5	Problem interview	37
Клиент готов оставить заявку или заплатить	Willingness-to-pay	Высокая	Только гипотеза	30	5 / 5	Fake door	70
Решение понятно без объяснения команды	UX	Средняя	Только гипотеза	40	4 / 5	Prototype	37
Техническая часть реализуема	Technical	Высокая	Только гипотеза	45	5 / 5	PoC	55
Канал привлечения достижим	Channel	Средняя	Только гипотеза	40	4 / 5	A/B-тест	37
Scope MVP можно проверить без полной разработки	Solution	Высокая	Только гипотеза	40	5 / 5	RAT	60

MVP Scope Guardrail

Что входит в scope: -
Что исключить: второстепенные модули, интеграции и UI, не отвечающие на learning question.
Что проверяет scope: сформулируйте learning question
Метрика: -
Риск, если scope расширить: увеличится build risk и время до evidence; усилится зависимость от ресурсов.

Experiment Readiness Board

Problem interviewsProblem interview · 7 дн · effort 2
Learning: Возникает ли проблема минимум раз в неделю и вызывает ли измеримые потери?
Success: 6 из 10 респондентов сталкивались с проблемой за 30 дней
Prototype testPrototype · 10 дн · effort 2
Learning: Понимает ли пользователь сценарий и доходит ли до результата?
Success: 4 из 5 пользователей доходят до целевого экрана без подсказки
Technical PoCPoC · 14 дн · effort 3
Learning: Можно ли реализовать критичную интеграцию в нужном качестве?
Success: PoC проходит ключевой test case без блокеров
Fake doorFake door · 7 дн · effort 1
Learning: Нажимают ли в целевом сегменте на кнопку с обещанием ценности?
Success: CTR ≥ 5% и ≥ 10 заявок за 2 недели
Concierge testConcierge · 21 дн · effort 3
Learning: Готовы ли клиенты получать ценность вручную и платить?
Success: 3 клиента оплачивают ручной сервис в первый месяц
Wizard of OzWizard of Oz · 14 дн · effort 3
Learning: Работает ли продуктовый опыт, если часть выполняется людьми?
Success: 5 пользователей доходят до результата с приемлемым качеством
Paid pilotPilot · 30 дн · effort 4
Learning: Готовы ли клиенты платить за пилот ограниченного scope?
Success: 2 платящих пилота за 30 дней

Build-Measure-Learn Loop

Build

Что именно делаем?

Например, fake door, prototype, PoC или RAT-эксперимент

Measure

Какую метрику смотрим?

Например, CTR, paid pilots, task success rate

Learn

Какой вопрос проверяем?

Сформулируйте learning question

Decide

Continue / change / stop?

Задайте success criteria

Decision Recommendation

Recommended format: Problem interview

Why: Проблема пока подтверждена слабо. Начните с интервью или RAT.

What to test: Клиент готов оставить заявку или заплатить

What not to build yet: полную версию продукта

First next step: Problem interview · 14 дней

Risk if skipped: weak problem evidence

Как выбрать формат проверки

RAT
Используйте, когда есть одна критичная гипотеза, которая может изменить весь план.
PoC
Используйте, когда главный риск - техническая, операционная или data-feasibility реализуемость.
Prototype
Используйте, когда нужно проверить сценарий, интерфейс, понимание ценности или adoption.
Fake door
Используйте, когда нужно проверить интерес к возможности до разработки.
Concierge
Используйте, когда ценность можно временно доставить вручную и проверить спрос.
Wizard of Oz
Используйте, когда клиентский опыт можно показать как автоматизированный, но часть процесса пока выполняется вручную.
Pilot
Используйте, когда нужно проверить решение в ограниченной группе клиентов или команд.
MVP
Используйте, когда проблема, сегмент, ключевой сценарий и метрики достаточно понятны для минимального продуктового запуска.

Как считается рекомендация формата проверки

Riskiest Assumption Score = impact if false × (100 − confidence) × criticality factor
Experiment Readiness = learning question × 0.30 + success criteria × 0.30 + metric × 0.20 + owner × 0.10 + time-to-learn × 0.10
MVP Scope Risk = effort × 15 + cost risk × 15 + weak evidence penalty + long time-to-learn penalty
Build Risk = MVP Scope Risk × 0.40 + weak evidence × 0.30 + high effort × 0.20 + no success criteria × 0.10
Validation Format Fit Score =
  problem evidence × 0.18 + market signal × 0.18 + technical feasibility × 0.14
  + solution confidence × 0.12 + experiment readiness × 0.18
  + learning velocity × 0.10 + low build risk × 0.10
Final Score = clamp(0, 100, Validation Format Fit Score − Risk Penalties)

Оценщик использует локальные эвристики: уровень evidence, тип риска, критичность гипотез, готовность эксперимента, time-to-learn, effort и scope. Это методический ориентир, а не решение о запуске продукта.

Что оценщик не учитывает

фактический спрос
качество интервью
качество прототипа
сложность архитектуры
безопасность и privacy
юридические ограничения
точную стоимость разработки
доступность команды
качество данных
конкурентный контекст
стоимость привлечения
бренд и доверие
качество канала
статистическую значимость теста
долгосрочный retention
unit economics
технический долг
операционные ограничения

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

Чем MVP отличается от RAT

MVP проверяет минимальный продуктовый сценарий, а RAT проверяет самую рискованную гипотезу. Если главный риск еще не подтвержден, RAT часто полезнее, чем разработка первой версии продукта.

Когда нужен PoC

PoC полезен, когда главный вопрос не в спросе, а в технической или операционной реализуемости: интеграции, данные, скорость, качество, безопасность или сложная логика.

Когда достаточно прототипа

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

Почему MVP должен быть узким

MVP полезен, когда проверяет один критичный сценарий и связан с метрикой. Если MVP превращается в большой продукт, команда тратит ресурсы до получения evidence.

Хотите проверить идею без лишней разработки?

Конструктор помогает выбрать формат проверки, но не заменяет discovery. Если команда спорит между MVP, RAT, PoC и прототипом, стоит отдельно разобрать гипотезы, evidence, technical risk, scope, метрики и первый learning step.

Разобрать формат проверки

Переход не передает данные идеи, гипотезы или результат проверки. Вы сами решаете, что отправлять в заявке.

Частые вопросы

Он помогает выбрать формат проверки идеи: problem interview, RAT, prototype, PoC, fake door, concierge, Wizard of Oz, pilot или narrow MVP - по рискам, evidence, метрикам и scope.