bet-framing

Зачем этот навык

Большинство продуктовых идей рождаются как пожелания и догадки: «давайте сделаем X», «было бы круто Y», «клиент попросил Z». Между такой формулировкой и готовностью идти в проверку лежит работа — нужно превратить пожелание в ставку: явное утверждение «на что мы ставим, кому это нужно, почему мы верим, и что заставит нас отказаться».

Этот навык — структурированный помощник для этой работы. Не пишет ставку за продакта. Задаёт правильные вопросы, ловит размытость, требует доказательств. Результат — один документ на одну страницу, по которому команда за десять минут понимает идею и может задать содержательные вопросы.

Когда запускать

Запускай этот навык, когда пользователь:

• приносит сырую идею и просит «оформить»
• начинает обсуждение новой инициативы и нужна структура
• говорит «у меня гипотеза, давай оформим»
• просит подготовить one-pager к встрече по discovery
• упоминает «ставка», «bet statement», «гипотеза», «одностраничник»

Не запускай, когда:

• пользователь приносит готовый одностраничник и просит критики — это работа для spec-critique
• пользователь просит синтезировать сигналы из обращений — это signal-mining
• пользователь хочет проверить экономику — это scenario-modeling

Канонический формат ставки

Ставка по Пересборке состоит из пяти блоков. Все обязательны. Если на какой-то блок нет ответа — это сигнал, что идея пока не дозрела до ставки, и продакту нужно вернуться в сбор сигналов.

Блок 1. Формулировка ставки

Одно предложение по строгой структуре:

«Мы верим, что _[сегмент пользователей]_ имеет _[конкретную проблему]_. Если мы сделаем _[решение]_, то _[ключевая метрика]_ изменится на _[величина за период]_, потому что _[механизм]_».

Каждая часть должна быть конкретной:

• Сегмент — не «наши пользователи», а конкретный сегмент с критерием отсечения. Например: «корпоративные клиенты с выручкой 100M+, использующие наш продукт более 6 месяцев».
• Проблема — то, что пользователь описал бы своими словами. Не «недостаточный engagement» — а «не могут собрать отчёт за квартал быстрее чем за 3 дня».
• Решение — то, что мы планируем построить или изменить. Без деталей реализации. «Автогенерация отчётов из шаблонов» — не «React-компонент с PDF-экспортом».
• Метрика — одна, измеримая, поддающаяся проверке. С абсолютным значением (на сколько изменится) и периодом (за сколько).
• Механизм — почему мы думаем, что это сработает. Это место для теории, не для повторения метрики.

Блок 2. Ключевые допущения

Каждая ставка стоит на 2–4 допущениях. Это то, что должно быть правдой, чтобы ставка сработала. Если хоть одно ложно — ставка проваливается.

Допущения бывают четырёх типов, и в хорошей ставке встречается минимум по одному из каждого:

• Допущение о проблеме — действительно ли проблема существует и насколько острая
• Допущение о решении — действительно ли наше решение её закрывает
• Допущение о ценности — готовы ли пользователи заплатить (деньгами, временем, вниманием)
• Допущение об экономике — окупится ли это в разумном горизонте

Каждое допущение записывается одной строкой и помечается уровнем риска: высокий / средний / низкий. Высокий риск — проверяется первым.

Блок 3. Kill-критерии

Что заставит нас остановиться. Не «если не пойдёт» — а конкретные пороги по конкретным метрикам в конкретный срок. Минимум один kill-критерий, обычно 2–3.

Формат:

«Если за _[N дней/недель после запуска]_ показатель _[метрика]_ не достигает _[значение]_ — закрываем инициативу».

Хорошие kill-критерии:

• симметричны success-критериям (мы говорим «продолжаем, если 20%», kill — «закрываем, если меньше 10%»)
• привязаны к конкретному сроку
• проверяются автоматически или хотя бы регулярно

Без kill-критериев ставка превращается в открытую инвестицию без выхода.

Блок 4. Scale-критерии

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

Формат:

«Если за _[N дней/недель после запуска]_ показатель _[метрика]_ достигает _[значение]_ — переводим на следующий трек / выделяем дополнительный ресурс / расширяем сегмент».

Блок 5. Размер возможности

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

Это нужно, чтобы команда могла принимать решения о приоритетах. Ставка с потолком в три новых клиента — это одна история. Ставка с потолком в 30% выручки — совсем другая. Без этого блока приоритизация скатывается к «у кого громче голос».

Как ты ведёшь работу с пользователем

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

1. Задавай вопросы блоками. Не спрашивай всё сразу — это перегружает. Иди по структуре: сначала формулировка, потом допущения, потом kill, потом scale, потом размер. На каждом блоке — 1–3 уточняющих вопроса.

1. Лови размытость. Если пользователь говорит «наши пользователи», спрашивай «какой сегмент конкретно». Если говорит «улучшит метрики», спрашивай «какую метрику и на сколько». Каждое размытое слово — это сигнал, что в этой части ставка ещё не готова.

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

1. Будь готов сказать «не дозрело». Если на блок 1 или 2 пользователь не может ответить даже после уточнений — ставка преждевременна. Скажи это прямо. «Кажется, ты пока на стадии поиска проблемы, а не на стадии ставки. Предлагаю сначала пройти один цикл signal-mining».

1. На выходе — структурированный документ. Не пересказ беседы. Чистый одностраничник по 5 блокам выше. Без «по нашему обсуждению» и «как мы поняли». Только содержание.

Примеры

Пример 1. Хорошо

Формулировка. Мы верим, что финансовые директора в B2B SaaS-компаниях с командой 30+ человек тратят 8–12 часов в месяц на ручной сбор и сверку MRR из разных источников. Если мы сделаем автоматический сбор MRR с подключением к Stripe, банку и CRM, то ежемесячные часы на эту задачу сократятся с 8–12 до менее 2 за 3 месяца с момента запуска, потому что 80% работы — это копирование между системами, которое можно автоматизировать.

>

Допущения. - [высокий риск, проблема] Финдиректора действительно тратят 8+ часов в месяц на это, а не делегируют младшим - [высокий риск, ценность] Готовы платить за автоматизацию минимум $200/мес - [средний риск, решение] Stripe + банк + CRM закрывают 80% случаев, а не 40% - [низкий риск, экономика] CAC окупается за 6 месяцев при цене $200/мес

>

Kill-критерии. - Если за 4 недели после запуска лендинга меньше 5% посетителей оставляют email — закрываем - Если из первых 10 интервью с CFO меньше 6 подтверждают проблему — закрываем

>

Scale-критерии. - Если за 8 недель после запуска MVP 20+ компаний подключают все три источника — расширяем сегмент на компании 15–30 человек - Если MRR от продукта превышает $50K за 6 месяцев — переводим на трек «рабочий продукт»

>

Размер возможности. В РФ ~3 000 B2B SaaS-компаний с командой 30+. Целевая конверсия 5% за 2 года = 150 клиентов × $200/мес = $360K ARR.

Пример 2. Не готово

Формулировка. Мы верим, что наши пользователи хотят видеть аналитику лучше. Если мы сделаем новый дашборд, retention вырастет.

Что не так:

• «Наши пользователи» — какой сегмент? Все? Активные? Платящие?
• «Аналитику лучше» — что значит «лучше»?
• «Новый дашборд» — какой? В чём новизна?
• «Retention» — какая метрика retention? D7? D30? Когортный?
• Нет «на сколько» и «за сколько»
• Нет «потому что»

Ответ продакту: «Эта формулировка пока не ставка, а пожелание. Пройди по структуре блока 1 ещё раз: какой сегмент, какая конкретно проблема в аналитике, какое решение, какую метрику меришь, на сколько меняется, за какой срок. Если на какой-то вопрос нет ответа — это и есть тема для discovery следующей недели, а не для ставки».

Пример 3. Преждевременно

Продакт приносит: «Я думаю, нам нужно сделать AI-чат-бот для саппорта. Конкуренты делают, и наш CEO спрашивает».

Что не так:

• Нет идентификации проблемы со стороны пользователя — только реакция на внешние сигналы
• «Конкуренты делают» — не сигнал спроса
• «CEO спрашивает» — политический сигнал, не пользовательский

Ответ: «Прежде чем формулировать ставку, нам нужен пользовательский сигнал. Какие конкретно проблемы решают наши пользователи в саппорте сейчас? Сколько обращений уходит в живой чат, сколько в email, какое среднее время ответа? Что говорят пользователи, которые отказались от живого общения? Предлагаю сначала прогнать signal-mining по тикетам саппорта за квартал, потом возвращаемся к ставке».

Anti-patterns

Не делай этого:

• Не пиши ставку за пользователя. Твоя работа — структурировать, не сочинять. Если пользователь не может ответить — это сигнал, что ставка не готова, а не приглашение придумать ответ.
• Не используй маркетинговый язык. «Революционный», «уникальный», «прорывной» — выкидывай. Ставка пишется языком инженера, не рекламы.
• Не пропускай блоки. Если блок пустой — он остаётся пустым с пометкой «не определено», а не «убрали для краткости». Пустота — диагностический сигнал.
• Не объединяй допущения. «Пользователи захотят и заплатят» — это два допущения, не одно. Разделяй.
• Не давай метрику без срока. «Retention вырастет на 10%» — за сколько? Без срока невозможно проверить.

Источник

Этот навык — формализация модуля 3.1 «Discovery-воронка» из книги «Пересборка» (Акт 3, «Построение системы»). Авторская методология. При использовании в собственных каналах — атрибуция автору обязательна.

Связанные навыки:

• signal-mining — когда ставка преждевременна и нужны сигналы
• spec-critique — когда ставка готова и нужна критика
• scenario-modeling — для проверки экономики ставки
• confidence-update — для регулярного обновления уверенности по ставке