Перейти к содержанию

8.1 instruction — Acquisition Bunch Agent: генерация Банча конфигураций

Этап RB-STEP-8 — ACQUISITION CONFIGURATION (Stage 7) · Линза: Business/Growth · Инструкция для Инженера Продукта нового поколения (PAF, [S1],[S2]). Преемственность метода: исходный раннбук RB-STEP-8-ACQUISITION-CONFIGURATION/8.1 Гипотезы конфигурации привлечения.md (конфигурация = 7 полей: сегмент, канал, оффер, воронка, метрики, ресурсы, обоснование).

🎯 Цель в PAF-оптике

Сгенерировать Банч конфигураций привлечения (связку «сегмент–канал–оффер» в моменте) из текущего состояния Нексуса системы роста — не «список гипотез + волны» (это Беклог, который PAF упраздняет [S1]), а живой Банч, переформируемый каждым обновлением Нексуса.

  • Harvesting модели роста: каждая конфигурация = Bale (инкремент + оффер + план дистрибуции) [S1].
  • Перебор комбинаций = скаутинг возможностей/угроз (не приоритизация списка) [S1, принцип 5].
  • CP как критерий отбора вместо «Уверенности 1–10» из исходного 8.1.
  • Дистрибуция = bottleneck [S2]; цель Банча — найти путь к PCF (NPV рычага > 0).

КЛЮЧЕВОЙ сдвиг: «сводная таблица гипотез + Волна 1/2/3» исходника → Банч в моменте: определяется только текущим состоянием Нексуса, живёт только сейчас.

👤 Роль и ответственность

  • Growth Engineer / Growth PM — ставит задачу Кортексу на генерацию конфигураций; определяет целевые CAC/LTV из юнит-экономики; отвечает за mNSM, time-to-activation, COGS токенов [S2].
  • Product Engineer — проектирует AI workflow: какие узлы Нексуса подсвечивать агенту, как валидировать его вывод [S2].
  • Product Ops — поддерживает Спелость контекста Нексуса роста; без спелого контекста Кортекс усиливает мусор [S1].
  • Зона человека: стратегический выбор приоритетных конфигураций для теста (распределение ресурсов); валидация обоснования гипотез (AI не должен выдавать «из головы» без источника).

🤖 Что делает Кортекс-агент (Acquisition Bunch Agent)

Реализует методику Und-Id-Ex [S1] над Нексусом роста:

  • Understand: читает каталоги каналов/сегментов/офферов (узлы Нексуса, импортированные из GTM, медиаплана, Sales & Marketing Kit); извлекает три списка — «строительный материал» (метод исходного 8.1 Phase 1).
  • Identify: генерирует 5–15 комбинаций «сегмент–канал–оффер»; для каждой заполняет 7 полей исходной карточки, но в моменте (не в накопительной таблице). Нейтральна к типу канала (performance / органика / direct / referral / offline — метод из 8.1 сохранён).
  • Execute: расставляет конфигурации в очередь тестирования не «по волнам», а event-based — по событию «CP предыдущей конфигурации изменился».
  • Скаутинг вместо приоритизации: применяет критерии исходника (объём сегмента, ёмкость канала, сила боли, стоимость теста, скорость данных) → но как фильтр возможностей, а не выбор элемента списка.
  • CP как критерий отбора: для каждой конфигурации агент оценивает стартовый CP (по колесу Гилада [S1]) и стоимость риска; CP ≥ порога → в Банч.

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

  • Валидирует обоснование гипотезы: почему сегмент / почему канал / почему оффер — трассировка до инсайтов Customer Validation, GTM, аналогов конкурентов (метод 8.1 «Обоснование»).
  • Ловит workslop: AI-сгенерированные офферы без привязки к реальным болям → маркировка, A/B-проверка.
  • Проверяет, что целевой CAC рассчитан (правило: LTV/3), а не «из головы» (метод 8.1).
  • Veto: конфигурации с CP ниже порога не идут в тест без явного обоснования.
  • Метапознание-фильтр [S2]: «AI предлагает конфигурацию X — какие у меня основания ей доверять, кроме того, что она убедительно сформулирована?»

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

  • Каталог каналов (тип / платформа / формат / бюджет в медиаплане) — узел.
  • Каталог сегментов (демография / поведение / JTBD / размер) — узел.
  • Каталог офферов (ЦП / формат / CTA) — узел.
  • Банч активных конфигураций (в моменте): для каждой — 7 полей исходника, стартовый CP, стоимость риска, целевой CAC/LTV, критерий успеха.
  • Очередь тестирования event-based (не «Волна 1/2/3»): следующая конфигурация запускается по событию CP.

🚦 Confidence Point-гейт

  • Стартовый CP конфигурации = функция от: наличия инсайтов из Customer Validation, обоснованности канала (данные/аналоги), силы оффера (из интервью), оценки ёмкости.
  • CP-порог в Банч: конфигурация попадает в активный Банч при CP ≥ согласованного порога; ниже порога → осознанный отказ (или резерв, не «Беклог на потом»).
  • Колесо Гилада [S1]: CP растёт при появлении информации, снижающей неопределённость; падает при срабатывании рисков (например, конкурент уже занял канал с тем же оффером).
  • Каждый CP включает оценку стоимости риска: «сколько ещё потратим ресурсов и негативного эффекта на клиентскую базу при таком уровне рисков?» [S1].

🔑 7 полей конфигурации (метод исходника 8.1, в PAF = узлы Нексуса)

Acquisition Bunch Agent заполняет для каждой конфигурации:

  1. Сегмент — демография, поведение, психография, JTBD, размер (кто наш клиент).
  2. Канал — тип (performance/органика/direct/referral), платформа, формат размещения.
  3. Оффер — ЦП, формат (бесплатный период/скидка/демо/кейс), CTA.
  4. Воронка — точка входа, ключевые шаги, точка конверсии («привлечённый клиент»).
  5. Целевые метрики — целевой CAC, ожидаемая конверсия по этапам, целевой LTV, период окупаемости.
  6. Ресурсы — бюджет теста, ответственный, материалы, срок запуска, длительность.
  7. Обоснование — почему сегмент/канал/оффер (инсайты Customer Validation, аналоги, логика) — поле, где работает метапознание-валидация.

В исходнике поле 7 включало «Уверенность 1–10». В PAF это заменено на стартовый CP со стоимостью риска (см. Confidence Point-гейт).

🧮 Целевой CAC (метод 8.1 Troubleshooting, PAF-сохранение)

Если CAC неизвестен: правило большого пальца — целевой CAC = LTV / 3 (CAC должен окупаться в 3 раза). Если LTV неизвестен — консервативная оценка с пометкой «preliminary»; первые тесты покажут реальный CAC, корректировка по ходу. Оптимальный размер Банча: 7–12 конфигураций (меньше 5 — мало данных; больше 15 — размазывается бюджет) — метод 8.1 FAQ.

🧮 Критерии отбора в Банч (метод 8.1 Step 2.1, PAF-оптика)

Скаутинг возможностей (не приоритизация списка [S1]) ведёт по 5 критериям исходника, но фильтр — CP:

Критерий Что оцениваем
Объём сегмента насколько большая аудитория (Market Research)
Ёмкость канала сколько охватить (прогноз медиаплана)
Сила боли насколько остро (интервью Customer Validation)
Стоимость теста дорого ли проверить
Скорость данных как быстро результат

Матрица исходника: высокий потенциал + низкая стоимость → тест первыми ✅; высокий потенциал + высокая стоимость → вторыми ⚠️; низкий потенциал → не тестировать ❌. В PAF — через стартовый CP: высокий CP + низкая стоимость → в активный Банч.

✅ Success Criteria (PAF-перевод критериев исходника 8.1)

После Acquisition Bunch Agent: - Каталоги каналов / сегментов / офферов = узлы Нексуса (из GTM, медиаплана, Sales & Marketing Kit). - Банч активных конфигураций в моменте (5–15, в идеале 7–12), каждая с 7 полями + стартовый CP. - Для каждой конфигурации определены целевой CAC (LTV/3), критерий успеха (число), бюджет теста, ответственный. - Очередь тестирования event-based (не «Волна 1/2/3») — следующая конфигурация по событию CP. - Медиаплан сверен с Банчем (бюджет теста ≤ строки по каналу; KPI карточки = KPI медиаплана) — метод 8.1 Phase 3. - Context Ripeness ≈ 70–80% (метод 8.1): знаем, что тестировать, в каком порядке, за какие деньги.

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

  • Business Lens (основная): каждая конфигурация = гипотеза о рычаге дистрибуции → рост NPV модели роста [S1].
  • Product Lens: оффер = инкремент продукта; воронка = путь пользователя в продукте.
  • Strategic Lens: набор конфигураций = набор Ставок (Bets) портфеля; приоритетная конфигурация = ставкой на канал/сегмент.

🛡️ Анти-workslop чекпоинт

  • AI-креативы/офферы: каждый AI-сгенерированный оффер маркируется; обязательна A/B-проверка перед включением в Банч (метод сохранён: «плохой оффер + запущенный тест → данные; хороший оффер без теста → ничего» из 8.1).
  • Галлюцинации в каталогах: каналы/сегменты/офферы берутся только из верифицированных узлов Нексуса (GTM, медиаплан, Sales & Marketing Kit) — RAG по верифицированным источникам; CP=0 без источника.
  • Метапознание-чекпоинт перед передачей Банча в тест: инженер проходит быструю проверку качества каждой конфигурации (сегмент конкретен? канал/платформа указаны точно? целевой CAC обоснован? критерий успеха — число?).
  • Запрещённые синонимы [naming_conventions]: НЕ «продакт-менеджер/маркетолог» (→ Growth Engineer); НЕ «волны/сводная таблица как объект» (→ Банч); НЕ «приоритизация списка» (→ скаутинг).

🧩 Маппинг к Skill Map / профстандарту 06.012

  • Skill Map [S3]: сектор 4 Growth & Experiments (внутренний круг — атомарная задача/гипотеза без валидации); луч связи — без навыка формирования гипотез нет смысла в приоритизации.
  • Профстандарт 06.012 [S4]: B/06.5 вывод на рынок (определение каналов и целевых сегментов); функция B (уровень 5) → Product Engineer.

🔗 Связи

Назад: 8.0 instruction · Дальше: 8.2 instruction (Event-based валидация) Связанные: reformation · index · naming_conventions


Version: 1.0 · Last updated: 2026-06-20 Ground truth: index.md [S1,S2], naming_conventions.md, reformation.md §8.5 (строка 8.1), RB-STEP-8-ACQUISITION-CONFIGURATION/8.1…md.