3.bunch — BUNCH / Bet-узлы Strategy Lens (Step 3: Market)¶

Фаза 🔴 ТЯЖЁЛАЯ · Линза: Strategy (Strategic Sprint → Нексус рынка → Ставки/Bets) [S1] VI.1. Источник: 3.6 instruction (CP-gate, колесо Гилада, стоимость риска, Bet-узлы).

🎯 Цель фазы для Step 3¶

Сформировать Bet-узлы (Ставки стратегического сценария) из спелого подграфа Нексуса рынка (после SCOUT) и провести их через CP-gate стратегии. Это Identify-фаза Und-Id-Ex [S1] VI.5: рыночные гипотезы кристаллизуются в Ставки. Главная PAF-трансформация этой фазы — замена чекбокса go/no-go по объёму рынка на CP-gate с управлением рисками (Принцип 4) и привязка к области потребностей (не «рынок в целом»).

В Step 3 Банч — это не связка фич (как в Product Lens), а Ставки портфеля (Bet-узлы): элементы стратегического сценария, которыми владеет Portfolio Manager. Strategic Sprint = долгосрочные цели + Нексус рынка → Ставки/Bets [S1] VI.1.

👤 Роль¶

Portfolio Manager — владелец Bet-узлов (ведущая роль фазы): формирует Ставки на спелом подграфе, максимизация NPV портфеля, баланс маржинальности/каннибализации, решение go/no-go/pivot. Product Engineer — формулирует область потребностей, проверяет привязку TAM/SAM/SOM к сегменту, защищает Bet на Pitching of Trust. Product Ops — настраивает CP-скорер по колесу Гилада (ICE/RICE → CP), авто-расчёт стоимости риска, версионирование Bet-узлов.

⚠️ Зона человека (не делегируется ИИ) [S2] III.4: решение go/no-go/pivot, стратегические Ставки, оценка стоимости риска. Агенты = инструменты, не акторы; ответственность не передать.

🤖 Кортекс-агенты¶

Агент-CP-gate (Confidence Point Gate Agent) ведёт CP рыночной гипотезы по колесу Итамара Гилада [S1] VI.7: - Рост CP по stage-gate и при появлении информации, снижающей неопределённость (каждый верифицированный Force/Trend/Competitor-узел поднимает CP). - Падение CP при срабатывании рисков/отклонениях (устаревание данных, расхождение методов TAM >2×). - Стоимость риска: «сколько ещё потратим ресурсов и негативного эффекта на клиентскую базу при таком уровне рисков?» [S1] VI.7.

Агент-Bet (Bet Architect) формирует Bet-узлы: - перевод рыночной гипотезы в Ставку (элемент стратегического сценария); - оценка {CP ≥ порога} ∧ {стоимость риска приемлема} ∧ {mNSM-потенциал SOM > 0}; - рекомендации: GO (Bet принят, переход в RB-STEP-4) / NO-GO (осознанный отказ, новая гипотеза) / PIVOT (уточнение сегмента/задачи/гео).

Алгоритм go/no-go/pivot (через CP-gate)¶

{CP рыночной гипотезы ≥ порога} ∧ {стоимость риска приемлема} ∧ {mNSM-потенциал SOM > 0}?
   ├── НЕТ → NO-GO. Зафиксировать причину отклонения в базе. Новая гипотеза.
   │          PAF: «сэкономил месяцы разработки».
   ├── CP пройден, НЕТ gap → PIVOT. Сузить до под-сегмента, пересчитать SOM.
   │          Если ниже порога → NO-GO.
   └── ДА → GO. Bet-узел принят. Переход в RB-STEP-4.
            Зафиксировать assumptions_to_verify для Customer Validation.

Привязка к области потребностей (исходный `3.6` Phase 1)¶

Проверка Bet-узла: TAM считался для людей с этой задачей (не с более широкой потребностью)? SAM ограничен по гео/возрасту/платёжеспособности именно этого профиля? SOM отражает реальную долю первого года?

🧠 Человек (метапознание)¶

Решение go/no-go — стратегическая зона (не делегируется ИИ). PAF/исходный 3.6: лучше час на решение, чем полгода на продукт без рынка.
Предзадание критериев (исходный 3.6 FAQ): договориться о минимальном пороге SOM до просмотра цифр — снимает предвзятость.
Проверка внутренней согласованности: «кто клиент» соответствует «для кого считался TAM»? Ближайшие конкуренты решают именно ту задачу? gaps связаны с болью клиента?
NO-GO — ценная информация, не провал.
Veto на Bet-узел с галлюцинированной цифрой (CP=0 без источника).

📦 Артефакт = Bet-узлы (+CR)¶

type: Bet
market_hypothesis: <сегмент + задача + контекст>
scope: <область потребностей>
tam_sam_som_ref: <ссылка на TAM-SAM-SOM-узел 3.3>
nearest_competitors_ref: [<ссылки на Competitor-узлы 3.5>]
gaps_ref: [<ссылки на Gap-узлы 3.4>]
mnsm_potential: <монетизируемая ценность SOM>
npv_potential: <возврат на инвестицию>
cp: <Confidence Point по колесу Гилада>
risk_cost: <стоимость риска>
decision: GO | NO-GO | PIVOT
justification: <обоснование>
assumptions_to_verify: [<что уточнить в Customer Validation>]
timestamp, decay_status

Нексус рынка обновлён до v1.0 с CR ≥ 60% (все 7 типов Узлов представлены).

🚦 CP-гейт фазы (главный гейт Step 3)¶

Bet-узел проходит CP-gate стратегии, когда: - {CP рыночной гипотезы ≥ порога} ∧ {стоимость риска приемлема} ∧ {mNSM-потенциал SOM > 0}; - область потребностей чётко сформулирована (кто + что); - TAM/SAM/SOM привязаны к сегменту (не к рынку «в целом»); - внутренняя согласованность профиля проверена; - CR Нексуса рынка ≥ 75% (исходный 3.6 Success Criteria).

NO-GO и PIVOT — валидные исходы gate (осознанный отказ).

🛡️ Анти-workslop¶

Замена чекбокса go/no-go на управление рисками (Принцип 4) — главная трансформация. go/no-go по объёму = workslop; CP-gate со стоимостью риска = PAF.
Иллюзия точности = workslop: «SAM = 487 356 000 ₽» без источника — иллюзия; «SAM ≈ 500 млн ₽ ± 50%» — корректно.
CP как новая vanity: растёт только от снижения неопределённости, не «по галочкам».
Ложное ощущение готовности: CP-gate пройден на симуляции без реальных данных клиентов → снятие: Soft Launch в RB-STEP-4 обязателен, CP не поднимается без a posteriori.
NPV-потенциал как чёрный ящик: явная трассировка допущений в Bet-узле (агент-оценщик выдал число → человек понимает, из каких допущений).
Дофаминовая петля ИИ [S2] III.7: Bet-узлы приятно формировать через Кортекс, но метрика gate — реальное изменение CP/NPV, не «ощущение готовности».

🔗 Дальше¶

→ 4.pitch (PITCH) — Pitching of Trust: защита Bet-узла, рост CP, гейт-решение.

Назад: 2.scout.

Version: 1.0 · Last updated: 2026-06-20 · Maintained by: AI-KORTEX