7.1 instruction — Гипотезы решения как Identify-фаза Und-Id-Ex¶

Этап RB-STEP-7 — SOLUTION VALIDATION (Stage 6) · Линза: Product · Инструкция для Инженера Продукта нового поколения (PAF, [S1],[S2]). Преемственность метода: исходный раннбук RB-STEP-7-SOLUTION-VALIDATION/7.1 Гипотезы решения и проектирование UX.md.

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

Перевести подтверждённую ценность (из Stage 4–6) в Identify-фазу Und-Id-Ex [S1] VI.5: Кортекс генерирует кандидатов фич Банча из Нексуса продукта, AI UX Designer проектирует ИИ-метафоры взаимодействия, а скаутинг возможностей и угроз (Принцип 5 [S1]) заменяет RAT-приоритизацию списка.

Цель — не «сформулировать 3 гипотезы решения в Notion», а: - поднять Confidence Point гипотез решения до уровня, достаточного для входа в вайбкодинг-прототипирование (7.2); - насытить Нексус продукта узлами solution-hypothesis + cjm + user-flow.

Стадия открывает цикл Product Sprint [S1] VI.4: здесь начинается Bunch Saturation (насыщение банча). Контекст из предыдущих стадий (JTBD, персоны, поведение AS-IS, подтверждённая ценность) живёт в Нексусе потребителя и служит входом — гипотезы решения генерируются RAG по этим узлам, а не «с нуля в пустой комнате». Это null base [S1] VI.5 для нового продукта (нет данных → discovery с нуля) или data base для существующего.

Ключевая логика PAF [S1]: в более чем половине случаев гипотезу ценности невозможно провалидировать без конкретного решения, с которым может взаимодействовать пользователь. Поэтому 7.1 — одновременно доводим проверку ценности и начинаем проверку решения. Объект анализа сменился: теперь это не свойства потребителя, а его поведение внутри конкретного продукта. Продукт = способ изменения текущего поведения потребителя.

Контекст как новый способ конкуренции [S1] Принцип 2: «выиграет тот, у кого лучше контекст и кто сможет им эффективнее управлять».

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

Product Engineer — управляет насыщением Банча через Кортекс; задаёт целевую mNSM гипотезы решения; формулирует Гэп (gap) между текущим состоянием продукта и Видением [S1]. Проектирует «цифровой профиль продукта» (инженерия контекста, по Тоби Лютке [S2] III.6) и определяет AI workflow.
Discovery / Launcher PM — минимизация time-to-market/time-to-PMF; определяет, какой минимум знаний нужен для перехода к прототипу; человек-команда, full-stack [S2] III.6.
AI UX Designer — проектирует ИИ-метафоры взаимодействия [S2] III.8:
ментальная модель «намерение → черновик → уточнение» (вместо «команда → результат»);
метафора «партнёр/соавтор» (вместо «инструмент»);
«ошибка = альтернатива/уточнение» (вместо системного сообщения; ошибка = новый промпт);
ввод на естественном языке/референсы (валидация: синтаксис → семантика);
streaming + «мысли вслух»; tone-of-voice.
ИИ в продукт ≠ чат-бот без изменений UX.
Technical / AI Product Manager — если продукт содержит ИИ-свойства: оценивает LLM-дизайн гипотез решения, точность/прецизионность/полноту модели, COGS токенов на кандидат-фичу [S2] III.6.
Product Ops — поддерживает Нексус продукта и контекстные области Кортекса; следит за Context Ripeness = полнота × актуальность [S1] III.1; флаги увядания узлов.
Зона человека [S2] III.4: выбор JTBD-фокуса и решение, какая гипотеза решения закрывает Гэп с максимальным CP. Стратегическое планирование и распределение ресурсов не делегируется агенту — агенты суть инструменты, не акторы; ответственность не передать.

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

Генератор гипотез решения — RAG по Нексусу продукта (узлы current-state, vision, gap) и Нексусу потребителя (JTBD, поведение AS-IS, боли, мотивации) → кандидаты фич Банча в формате Solution Hypothesis Card:
«Если [конкретное действие/фича/UX-решение], то [ожидаемое изменение поведения], что подтвердится [измеримый показатель и порог], ведь [обоснование из исследований]»;
поля карточки: уровень уверенности (CP), источник уверенности, способ проверки, критерий успеха, срок проверки;
каждый кандидат трассируется до узла-источника (без источника CP = 0);
минимум 3 альтернативы — конкуренция гипотез, а не монополия первой идеи (первая идея редко лучшая).
AI UX Designer-агент — для каждого кандидата проектирует ИИ-метафору по 5 уровням из [S2] III.8:
(1) ментальная модель — «намерение → черновик → уточнение», дизайн для итераций;
(2) метафора — «партнёр/соавтор», интерфейс поддерживает диалог;
(3) ошибка — «альтернатива/уточнение», ошибка = новый промпт;
(4) ввод — естественный язык, референсы;
(5) время — streaming + «мысли вслух», ожидание заполнено мышлением.
Возвращает варианты tone-of-voice.
CJM-билдер — строит Customer Journey Map [NNGroup] из узлов поведения AS-IS и JTBD:
этапы (Осознание → Поиск → Сравнение → Запись → Получение ценности), фокус 5–7 этапов, один ключевой сценарий;
строки: Цели и ожидания, Действия, Точки контакта, Мысли, Эмоции 😊/😐/😠, Боли, Возможности;
выявляет самую болезненную точку, основную причину отказа, неожиданные инсайты, узкое место воронки, момент получения ценности — 3–5 ключевых инсайтов.
User Flow-билдер — детализирует Motivation → Stages → Actions внутри продукта; связывает с узлами экранов; отличается от CJM тем, что это техническая схема навигации внутри интерфейса — конкретные шаги и экраны, чтобы дизайнер/разработчик мог нарисовать экраны без доп. вопросов.
CP-скорер (колесо Гилада) [S1] VI.7 — объективизирует «уровень уверенности 1–10» через ICE/RICE-структуру с оценкой стоимости риска; расставляет кандидатов на скаутинг-карте возможностей/угроз (замена RAT-приоритизации списка [naming_conventions]).

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

Валидация ИИ-генерации (критический фильтр [S2] III.4): каждая сгенерированная гипотеза проверяется на:
(а) проверяемость метрики с порогом;
(б) наличие обоснования из реального узла-источника;
(в) различимость альтернатив (минимум 3 кандидата);
(г) баланс конкретности («если добавить X» / «то пользователь сделает Y» / «что подтвердится ростом Z на N%» / «ведь мы знаем, что...»).
Если хотя бы один пункт отсутствует — гипотеза не готова.
Veto: Product Engineer отклоняет кандидатов без трассировки до Нексуса (CP = 0) и/или с workslop-формулировкой («пользователь будет доволен», «удобно», «правильно» — непроверяемо). Техника «Шесть шляп»: первая идея (очевидная) / что делают конкуренты / что будет, если убрать самое сложное — три разных угла.
Конвергенция JTBD: человек выбирает фокусный JTBD (самый важный/частый) и фокусную боль на CJM как точку приложения Банча. Один JTBD → одна фокусная гипотеза → один минимальный user flow. Не пытаться решить всё сразу — начать с одного узкого места на CJM.
ИИ-метафора: решение о том, какая метафора («партнёр» vs «инструмент») соответствует Видению, — за Product Engineer + AI UX Designer; агент предлагает варианты, человек выбирает. Четвёртая роль потребителя — «секретарь/адъютант» (агент с поведением и потребностями) + сущность «поручение» [S2] III.8 — учитывается при проектировании метафоры.

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

solution-hypothesis — узел-кандидат с полями:
фича/UX-решение, ожидаемое поведение;
метрика+порог, обоснование;
CP, источник-узел[];
способ проверки, критерий успеха, срок проверки.
cjm — узел Customer Journey Map (этапы → цели/действия/точки контакта/мысли/эмоции/боли/возможности) + 3–5 ключевых инсайтов.
user-flow — узел детального потока внутри продукта (Motivation → Stages → Actions → экраны).
ai-metaphor — узел ИИ-метафоры взаимодействия {ментальная модель, метафора, поведение при ошибке, режим ввода, режим времени, tone-of-voice}.
gap — узел Гэпа (текущее состояние → Видение) как якорь Банча [S1].
Каждый узел: источник, CP, timestamp, статус увядания. Context Ripeness Нексуса продукта после 7.1 → ~20–25% стадии.

🚦 Confidence Point-гейт¶

Gate 7.1 → 7.2 (Understand → Identify):
CP ≥ порога по ≥3 кандидатам фич Банча;
CJM построена для фокусного сценария (5–7 этапов);
User Flow покрывает путь от входа до получения ценности;
сработал CP-скорер с оценкой стоимости риска;
сгенерированы ИИ-метафоры для каждого кандидата;
есть понимание, с какой гипотезы начинать прототипирование.
До порога — итерация насыщения (дособрать поведение AS-IS из Нексуса потребителя, дополнить JTBD).
Рост CP идёт по колесу Гилада [S1] VI.7: только от появления информации, снижающей неопределённость, а не от «мне кажется». CP падает (Кортекс/инженер) при срабатывании рисков или отклонениях. Чем выше CP, тем выше шанс прохождения гейта или осознанного отказа [S1] VI.3.

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

Product Lens [S1] VI.1: объект управления — продукт; 7.1 = старт Product Sprint (Нексус продукта → состояние → Банч; размер Банча = time-to-market). Спринт продукта = Нексус продукта → текущее состояние → Банч.

Базовая логика управления [S1]: 1. Инженер формирует Видение (Vision) = образ продукта из фич (Features). Разрыв между текущим и Видением = Гэп (gap). 2. Функция инженера — сократить Гэп. Набор фич = Банч (Feature Bunch), определяется только текущим состоянием (Нексусом). 3. После релиза Кортекс обновляет Нексус → меняется Банч → цикл повторяется.

Связь с Business Lens через метрику гипотезы решения → кандидат mNSM (7.6 превратит кандидата в подтверждённую mNSM → NPV как возврат монетизируемой ценности на инвестиции [S1] Принцип 6).

Связь со Strategy Lens через Гэп к Видению (долгосрочная Ставка/Bet портфеля) [S1] III.3.

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

Workslop в формулировках гипотез («удобно», «пользователю понравится», метрика без порога, обоснование «потому что это логично») — главный риск 7.1. ~15,4% материалов перекладывают когнитивную нагрузку на потребителя; MIT: 95% не получают отдачи от инвестиций в ИИ именно из-за workslop [S2] III.7.
Метапознание-фильтр: каждый кандидат проходит проверку «можно ли это опровергнуть?». Нет — workslop. Junior без метапознания + ИИ = нулевой прирост; компетентный, но забивший на верификацию = «убедительные, но неверные» результаты (Harvard × BCG) [S2] III.4.
Трассировка до Нексуса: гипотеза без связи с узлом JTBD/боли/поведения → CP = 0, в Банч не попадает. Запрещены сгенерированные «персоны» без доказательной базы.
premature PMF-риск здесь: не путать «гипотеза решения подтверждена в голове команды» с ростом CP — CP растёт только от данных. Иллюзия живого Нексуса — узлы без фазы увядания.
Гэп как якорь: без явно сформулированного Гэпа (текущее состояние → Видение) Банч не формируется — гипотезы решения «висят в воздухе». Гэп = объект управления инженера.
Малая команда: под может быть из одного человека (весь цикл), единственная обязательная роль — инженер продукта [S1] III.2; в 7.1 этот человек совмещает насыщение Банча и вайбкодинг.

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

Skill Map [S3] IV:
сектор 2 Value & Solution Design (ценностные предложения и решения на базе исследований) — средний круг, middle/senior;
плюс сектор 1 Discovery & Researches (поведение AS-IS, JTBD);
конфигурации навыков под роль/контекст.
Профстандарт 06.012 [S4] V: обобщённая функция B «Управление ИТ-продуктом», уровень 5 — B/02.5 «определение продукта/дизайн/требования». PAF переопределяет способ работы — через Нексус и Кортекс, а не вручную. Связка стандарт ↔ PAF интерпретативна (B≈Product Engineer) [S3]+[S4].

🔗 Связи¶

Назад: 7.0 instruction — Product Sprint & Нексус продукта (при наличии) / 6.6 instruction · Дальше: 7.2 instruction — Вайбкодинг-прототипирование Связанные: reformation · index · naming_conventions