4.pitch.md — Pitching of Trust: защита Банча конфигураций¶

Фаза PITCH цикла Product Sprint на Step 8 · [operating-model](../operating-model.md) [S1] VI.4, VI.7.

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

Pitching of Trust [S1] VI.4 — ритуал защиты Банча конфигураций: команда «заваливает» аргументы, слабые конфигурации выкидываются, сильные → в EXECUTE (валидация). На Step 8 PITCH = CP-гейт запуска тестов: проходит ли Банч на микро-уровень масштабирования (стартовый CP, метод 8.0 CP-гейт).

PITCH отвечает: готовы ли мы потратить бюджет теста (метод 8.1 ресурсы) на эти 2–3 конфигурации, при текущем уровне доверия (CP) и стоимости риска?

CP — ядро управления рисками [S1] VI.7 (вместо «Уверенности 1–10» из исходного 8.1). Включает оценку стоимости риска: «сколько ещё потратим ресурсов и негативного эффекта на клиентскую базу при таком уровне рисков?».

👤 Роль¶

Growth Engineer / Growth PM [S2] — защищает Банч: обосновывает NPV каждой конфигурации, целевой CAC, Bunch Window.
Product Engineer — челенджит: аугментация [S2] III.4 (альтернативная точка зрения, челендж рисков). Имеет veto при падении CP.
Зона человека [S2]: стратегическое решение о запуске тестов (распределение бюджетов) — всегда за человеком, не агентом.

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

На PITCH-фазе работает Experiment Design Agent (8.2 instruction) + метапознание-валидация: - Проектирует дизайн тестов для каждой конфигурации Банча: одна переменная за раз, равные выборки 50/50, минимальный период наблюдения по типу канала (метод 8.2 Phase 1). - Настраивает A/B-дизайн: классический (статзначимость ≥ 95%) или байесовский (P2BB ≥ 75%) для малых выборок (метод 8.2 Step 2.3). - Флагирует 3 фазы проверки каждой конфигурации: Demand (CTR/CR/CPL) → Purchase (CAC) → Unit Economics (LTV/CAC) — метод 8.2 структура. - Чеклист запуска каждой конфигурации (метод 8.2 Step 1.1): UTM настроены, цели проверены, лендинг работает на моб/десктоп, форма/CTA пишет в CRM, кабинет настроен, дневной лимит, дата старта зафиксирована.

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

Валидирует дизайн тестов на ошибки 1/2 рода в ИИ-A/B: I — ложный победитель → масштабирование непродукта; II — пропуск рабочей конфигурации.
Проверяет правила чистоты (метод 8.2 Phase 0): одна переменная, достаточная выборка (≥30–50 конверсий или P2BB ≥ 75%), одинаковые условия, отдельная аналитика/UTM на конфигурацию.
Запрет подглядывания (peeking): проверка результатов только после плановой выборки (метод 8.2 Step 2.3 правило 3; sequential testing — метод 8.4 Further Reading).
Veto на запуск, если CP недостаточен или аналитика не работает (метод 8.2 Problem 3 — данные с неработающей аналитикой не считаются).
Проверяет минимальный период наблюдения по типу канала (метод 8.2 Step 1.2): контекст/таргет 7–14 дней, email 7–10, холодные звонки 5–10, SEO 3–6 мес. Не делать выводов раньше срока — «данные за 2 дня не данные».

🧮 Прокси-метрики как ранние сигналы (метод `8.2` Step 2.2)¶

До набора статзначимой выборки PITCH согласовывает прокси-метрики (ранние индикаторы): retention 7d ↔ retention 30d; просмотр «Цены» ↔ CR в оплату; активация аккаунта ↔ CR лид→клиент. Прокси — не основа финального решения, а «ранний индикатор»: красная → готовиться к корректировке, зелёная → продолжать тест.

📦 Артефакт = узлы Нексуса системы роста¶

Финальный CP Банча — после Pitching of Trust; CP ≥ порога → gate pass.
Дизайны тестов (A/B-карточки) для EXECUTE — метод 8.2 шаблон A/B.
Журнал экспериментов с CP [S1] — по колесу Гилада: рост/падение доверия при появлении информации/срабатывании рисков.
Решение gate: pass (микро-уровень) / refuse (осознанный отказ → оптимизация 8.3 или смена конфигурации 8.1).

🚦 CP-гейт (микро→малая)¶

Gate pass (CP вырос) → запуск EXECUTE на микро-уровне (200–500 показов / 50–100 кликов, бюджет 3–5 тыс. ₽ — метод 8.0 CP-гейт). Gate refuse (CP упал) → осознанный отказ [S1] VI.3: либо оптимизация детали (8.3 — тот же канал, меняем плейсмент/гео/оффер, цель −20–40% CAC), либо смена конфигурации (8.1 — меняем один из трёх элементов).

Чем выше CP, тем выше шанс прохождения гейта или осознанного отказа [S1] VI.3. «Рост контекста = рост скорости процессов, в т.ч. отказа».

🛡️ Анти-workslop¶

Ошибки 1/2 рода в ИИ-A/B (острейший риск, reformation Часть VIII): I — ложный победитель (масштабирование непродукта); II — пропуск рабочей конфигурации. Лекарство: P2BB ≥ 75% + sequential testing + запрет подглядывания (из 8.2/8.3).
Workslop в материалах теста: AI-креативы/баннеры/скрипты без A/B-проверки = workslop [S2] III.7; каждый проходит A/B в EXECUTE.
«Подкручивание» параметров вместо отказа: PAF против — gate refuse = осознанный отказ или смена элемента, не «подкручивание» (метод 8.2 Step 3.3).

🧮 Стоимость риска на PITCH (метод `8.0`)¶

CP на PITCH включает оценку стоимости риска [S1] VI.7: «сколько ещё потратим ресурсов и негативного эффекта на клиентскую базу при таком уровне рисков?». На Step 8 это прямой расчёт: - Бюджет теста × вероятность деградации при масштабе (если микро-тест пройден, но стабильность под вопросом). - Негативный эффект на клиентскую базу: привлечение «не тех» клиентов (низкий LTV) при слабом оффере → каннибализация когорты. - Упущенная выгода от параллельных конфигураций (opportunity cost Bunch Window).

Если стоимость риска > ожидаемой информации от теста → gate refuse в пользу более дешёвой/быстрой конфигурации.

🔭 Связь с Тремя Линзами (3PL)¶

Business Lens (основная): PITCH = проверка, что Банч конфигураций действительно несёт рычаг дистрибуции → NPV, а не «дешёвый CAC без LTV».
Strategic Lens: запуск тестов = первая материализация Ставок (Bets) портфеля; gate = решение, какие Ставки разыгрывать.

🔗 Дальше¶

[5.execute](5.execute.md) — EXECUTE: event-based A/B-валидация конфигураций (Demand→Purchase→Unit Economics), оптимизация, масштабирование по лестнице бюджетов (микро→малая→средняя→полная).

Version: 1.0 · Last updated: 2026-06-20 · Ground truth: index.md [S1,S2] VI.4, VI.7, 8.2 instruction, 8.2 Валидация, 8.3 Оптимизация, naming_conventions.md.