2.1 instruction — Hypothesis Generation via Cortex¶

Этап RB-STEP-2 — CUSTOMER VALIDATION (Stage 1) · Линза: Product (контекст: Business/Strategy) · Инструкция для Инженера Продукта нового поколения (PAF, [S1],[S2]). Преемственность метода: исходный раннбук RB-STEP-2-CUSTOMER-VALIDATION/2.1 Формирование гипотез о потребителе.md (4 типа гипотез, «поезд гипотез», шаблоны PAF).

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

Не «выписать 15–30 гипотез в Notion», а сгенерировать поезд гипотез 4 типов из узлов Нексуса рынка/продукта через Кортекс, превращая каждую гипотезу в кандидат-узел Нексуса потребителя с initial Confidence Point. Это Identify-фаза Und-Id-Ex: Кортекс генерирует идеи и тесты, поднимая CP [S1] VI.5. Гипотезы — это скаутинг возможностей/угроз на карте целей, а не пункт беклога [S1] Принцип 5.

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

Product Engineer — формулирует ядро Big Idea, задаёт Кортексу рамки генерации, валидирует, что каждая гипотеза проверяема и трассируется до узла Нексуса.
Product Ops — обслуживает RAG по Нексусам, гарантирует, что генерация идёт из существующих узлов (анти-галлюцинация).
Growth Engineer — добавляет 4-й мета-тип: гипотезу mNSM (монетизируема ли ценность сегмента).
Зона человека: выбор ядра идеи и отсечение нерелевантных гипотез (стратегический фокус).

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

Генератор гипотез (Hypothesis Generator Agent): - Вход: Big Idea + узлы Нексуса рынка/продукта (RAG) + каркас Нексуса потребителя из 2.0. - Действие: генерирует «поезд» гипотез 4 типов по шаблонам исходного раннбука 2.1: 1. Поведение — «Когда <роль>, <ситуация>, то <поведение>, потому что <мотивация>». 2. Проблема — «Когда <роль>, <ситуация>, то <проблема>, а это мешает <цель>». 3. Мотивация/Цель — «<Роль> хочет <желаемое>, а не <текущее>, чтобы <результат>». 4. Блокер — «<Роль> <поведение/проблема>, потому что <причина>». Каждая гипотеза привязывается к узлу Нексуса (маппинг гипотеза→узел), получает initial CP. - Выход: кандидат-узлы с initial CP, сгруппированные по сегментам-кандидатам.

«Поезд гипотез» — метод из исходного `2.1`¶

PAF-практика: за один заход генерируется сразу большой «поезд» (десятки гипотез). Во время одного интервью проверяются десятки — исследователь «отправляет поезд из депо». Одна гипотеза не подтвердилась → переход к следующей, пока не накопится достаточно знаний. Поэтому цель 2.1 — ≥15 гипотез (желательно 20–30), всех типов, а не одна «главная».

Ключевое различие: потребность ≠ проблема (по исходному `2.1`)¶

Потребность (need) — зонтичный термин PAF: всё между потребителем и желаемым состоянием (задачи + проблемы + цели).
Проблема — НЕ «отсутствие чего-то». «Нет CRM» — не проблема. «Менеджер тратит 2 часа на ручной ввод в Excel, потому что нет CRM» — проблема. Проблема = препятствие на пути к цели, существует только в контексте.
Следствие: гипотезы цели часто важнее гипотез проблемы — они расширяют сегмент и открывают нестандартные решения (пример «верёвочного парка» из 2.1: фокус на цели «комфортная поездка с детьми», а не на проблеме «нет машины»).

Шаблон карточки гипотезы-узла (по исходному `2.1`)¶

id: hyp-014
type: Проблема              # Поведение / Проблема / Мотивация / Блокер
text: "Когда родитель просматривает 20+ анкет, то не может сравнить специалистов,
       а это мешает выбрать проверенного репетитора"
big_idea_link: 🎯 ядро      # 🎯 ядро / ⭐ связанная / 💡 периферия
origin: гипотеза            # факт / гипотеза / интуиция (анти-галлюцинация)
cp_initial: 5
validation_criteria:
  confirm: "≥70% респондентов описывают похожую ситуацию с примерами"
  reject:  "≤30% узнают описанную ситуацию"
linked_node: problem-03
status: Новая               # Новая / В проверке / Подтверждена / Опровергнута / Уточнена

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

Чекпоинт: Product Engineer проверяет, что гипотеза не описывает продукт (запрет: слова «приложение/сервис/продукт» в формулировке) — по правилу исходного 2.1. Гипотеза описывает мир потребителя БЕЗ продукта.
Veto-право: отбраковать гипотезы, не связанные с ядром Big Idea (релевантность).
Метапознание: «очевидно верные» гипотезы часто ложны — проверять первыми (Build-Measure-Learn).

Вопросы-стимуляторы для генерации (из исходного `2.1`)¶

Если генератор «застрял», Product Engineer подаёт Кортексу 10 вопросов-стимуляторов: что делает при возникновении потребности · к кому обращается · какие инструменты использует · что не работает · сколько времени/денег тратит · что раздражает · чего хотел бы достигать · что мешает · что изменилось бы без проблемы. Каждый ответ → гипотеза.

Защита от узости (по исходному `2.1` Troubleshooting)¶

Если все гипотезы про один сегмент — сменить угол: кто платит / кто пользуется / кто решает / кто рекомендует (особенно в B2B).
Если гипотезы «описывают продукт» — переформулировать в поведение без продукта.
Если «все очевидно верны» — сигнал опасности: проверять первыми.

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

Кандидат-узлы типов Сегмент / Триггер / Проблема+Причина / Мотивация, порождённые гипотезами.
Метаданные узла-гипотезы: тип (4 типа), формулировка, связь с Big Idea, initial CP, критерий валидации (≥70% подтверждают / ≤30% опровергают — из исходного 2.1).
Context Ripenity растёт: добавление узлов увеличивает полноту.

🚦 Confidence Point-гейт¶

Критерий: сгенерировано ≥15 гипотез всех типов, каждая привязана к узлу Нексуса, есть initial CP.
Стоимость риска: «Если проверим нерелевантные гипотезы — потратим интервью-ресурс впустую; сколько стоит ошибка фокуса?» [S1] VI.7.

Success Criteria (по исходному `2.1`)¶

Банч гипотез-кандидатов готов, когда: ≥15 гипотез · все 3 основных типа + блокеры · каждая по шаблону · каждая проверяема · сгруппированы по сегментам · CR бэклога гипотез 40–60% (сырые — нормально, проверка на интервью). В PAF «бэклог» = Банч в моменте, не накопительный список.

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

Product Lens — гипотезы поведения/проблем — ядро Product Sprint. Business Lens — гипотезы mNSM (Growth Engineer) проверяют монетизируемость сегмента. Связь со стратегической линзой — через узлы Нексуса рынка из RB-STEP-1.

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

Генерация только из RAG по существующим узлам — без «изобретения» фактов (галлюцинации) [reformation 2.9].
Гипотеза без связи с узлом Нексуса → workslop, отбрасывается.
Маркировка факт/гипотеза/интуиция в поле «откуда взялась» (по шаблону карточки из исходного 2.1).

🔄 Преемственность: классика → PAF¶

Было (исходный `2.1`)	Стало (PAF)
15–30 гипотез в Notion вручную	Генератор гипотез (RAG по Нексусу) → кандидат-узлы
«Беклог гипотез» как список	Банч гипотез-кандидатов (в моменте)
4 типа (шаблоны) вручную	Те же 4 шаблона, но маппинг гипотеза→узел Нексуса
Гипотезы без initial CP	Каждая с initial CP + критерий валидации
Преемственность с Big Idea — качественно	mNSM-слой (Growth Engineer) — монетизируемость
Identify вручную	Identify-фаза Und-Id-Ex через Кортекс

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

Skill Map сектор 1 (Discovery & Researches) — формирование гипотез о потребителе [S3] IV.2.
Профстандарт B/01.5 «Продуктовые исследования» [S4].
Уровень: внутренний круг (атомарная задача — одиночная гипотеза) → средний (группа гипотез).

📖 Пример «поезда гипотез» (по исходному `2.1`, AI-репетитор)¶

Поведение: ГП-01 «Когда родителю нужен репетитор, спрашивает в WhatsApp-чате, потому что доверяет личным рекомендациям». ГП-02 «Смотрит соцсети репетитора до контакта, чтобы понять тип человека». Проблема: ГПр-01 «Когда просматривает 20+ анкет на Profi.ru, не может сравнить — выбирает по фото/случайно». ГПр-02 «Каждый разговор с нового: 20–30 мин рассказа о ребёнке». Цель: ГЦ-01 «Хочет одну рекомендацию, а не шортлист из 10, чтобы начать быстрее». ГЦ-03 «Репетитор хочет один канал учеников, а не ведение нескольких соцсетей». Блокер: ГБ-01 «Не может выбрать из 20 анкет, потому что все выглядят одинаково: одни слова, нет реальных кейсов». Каждая → кандидат-узел Нексуса с initial CP, маппинг на сущность (Сегмент/Триггер/Проблема/Мотивация).

❓ Контрольные вопросы (метапознание)¶

Сформулировано ≥15 гипотез всех типов? Есть ли «поезд», а не один «вагон»?
Не описывает ли гипотеза продукт (запрет: «приложение/сервис»)?
Каждая ли гипотеза проверяема (понятно, что услышать от респондента)?
Все ли гипотезы привязаны к узлу Нексуса (маппинг)?
Не «очевидно ли всё верно»? Если да — это сигнал проверять первыми.
Есть ли гипотезы цели (а не только проблемы)? Они расширяют сегмент и открывают инновации.

⚠️ Типичные ошибки 2.1¶

Гипотеза описывает продукт («пользователи будут пользоваться приложением») → переформулировать в поведение без продукта.
Все гипотезы про один сегмент → сменить угол: кто платит / пользуется / решает / рекомендует (B2B особенно).
Галлюцинации генератора (факты «из воздуха») → только из RAG по узлам, маркировка origin.
«Проблема = отсутствие чего-то» («нет CRM») → переформулировать как препятствие к цели с контекстом.
Один «вагон» вместо «поезда» → цель ≥15 гипотез всех типов для насыщения одного интервью десятками проверок.

🔗 Связи¶

Назад: 2.0 instruction · Дальше: 2.2 instruction Связанные: reformation · index · naming_conventions · PAF-ANALYSIS