1.pulse — PULSE / Progress Pulse (Step 7: Solution & PMF)¶
Фаза лёгкая · Линза: Product · Узлы Нексуса продукта (состояние v0.3 из Step 4–6). Источник: 7.1 instruction · [S1] VI.4.
🎯 Цель фазы для Step 7¶
Зафиксировать состояние Нексуса продукта перед SCOUT — «как пилоты у приборной панели» [S1] VI.4. На входе Step 7 Нексус продукта существует как v0.3: узлы ценностного предложения (VP-node, VPC-node из Step 4 🟧), узлы бизнес-модели (NPV>0, 🟥 biz-model fit из Step 5), Bale/Germination/позиционирование (Step 6). Решения ещё нет — есть подтверждённая ценность и спрос.
Pulse измеряет Context Ripeness (CR) v0.3 и формирует Гэп (gap) → intent цикла [S1] III.3: разрыв между текущим состоянием продукта и Видением (Vision). Гэп = якорь Банча: без явно сформулированного Гэпа гипотезы решения «висят в воздухе».
Pulse отвечает на вопросы: 1. Какой фокусный JTBD закрываем в этом цикле Sprint? (один JTBD → одна фокусная гипотеза → один минимальный user flow — не «всё сразу»). 2. Какова текущая CR Нексуса продукта по узлам решения? (узлов решения пока нет → CR по решению ≈ 0%). 3. Каков Гэп (текущее состояние → Видение)? 4. Какой intent: насыщение (SCOUT → Identify гипотез решения) → какой минимум знаний нужен для перехода к прототипу (7.2)?
Это null base [S1] VI.5 для нового продукта (нет данных о поведении внутри продукта → discovery с нуля) или data base для существующего продукта.
👤 Роль¶
Product Engineer — определяет фокус-вопрос Pulse («какой JTBD закрываем в этом цикле?»), формулирует Видение (Vision) = образ продукта из фич и Гэп (gap) между текущим и Видением [S1]; проектирует цифровой профиль продукта; определяет AI workflow. Discovery/Launcher PM — определяет, какой минимум знаний нужен для перехода к прототипу; минимизация time-to-market. Product Ops — снимает live-CR, флаги увядания узлов ценности.
Зона человека [S2] III.4: выбор фокусного JTBD и формулировка Гэпа — не делегируется; агенты = инструменты, не акторы.
🤖 Кортекс-агент¶
Nexus-Builder / CP-скорер [7.1]:
- Считает CR Нексуса продукта = полнота × актуальность [S1] III.1; показывает узлы v0.3 (VP, VPC, biz-model, Bale) с CP, timestamp, decay_status.
- Показывает, что узлов решения нет (solution-hypothesis, cjm, user-flow, ai-metaphor) → CR по решению ≈ 0%.
- Триггерит intent: «для CP-gate прототипа (7.2) не хватает: solution-hypothesis ≥3, cjm фокусного сценария, user-flow, ai-metaphor».
- Предлагает фокусный JTBD из Нексуса потребителя (самый важный/частый) как точку приложения Банча.
Шкала CR Step 7 (по стадиям из 7.x)¶
| После фазы | CR Нексуса продукта |
|---|---|
| Старт (v0.3) | ~10% (узлов решения нет) |
| 7.1 (SCOUT/BUNCH) | ~20–25% |
| 7.2 (прототип) | ~40% |
| 7.3 (валидация) | ~60% |
| 7.4 (цифровой профиль) | ~70% |
| 7.5 (MVP) | ~75% |
| 7.6 (PMF-точка) | ~80%+ |
🧠 Человек (метапознание)¶
- Конвергенция JTBD: выбирает фокусный JTBD (самый важный/частый) и фокусную боль на CJM как точку приложения Банча. Один JTBD → одна фокусная гипотеза → один минимальный user flow. Не пытаться решить всё сразу.
- Проверяет, что Видение и Гэп сформулированы явно (без Гэпа Банч не формируется — это объект управления инженера [S1]).
- Veto на «решаем сразу несколько JTBD» — рецепт workslop и распыления ресурсов.
- Отличает факт (узел ценности с CP из Step 4–6) от гипотезы (кандидат решения, которого ещё нет).
📦 Артефакт = snapshot + intent (узлы Нексуса продукта)¶
phase: PULSE
nexus_product_version: v0.3
context_ripeness: <0..100%> (по решению ~10% на старте)
nodes_present: [VP-node, VPC-node, biz-model, Bale] ← из Step 4–6
nodes_missing: [solution-hypothesis, cjm, user-flow, ai-metaphor, gap]
focus_jtbd: <один фокусный JTBD> ← НЕ «все сразу»
vision: <образ продукта из фич>
gap: <текущее состояние → Видение> ← якорь Банча
gap_to_intent: «поднять CR по решению с ~10% до CP-gate прототипа: насытить {solution-hypothesis ≥3, cjm, user-flow, ai-metaphor}»
next_phase: SCOUT
Snapshot сохраняется в Нексус продукта; intent передаётся в SCOUT.
🚦 CP-гейт фазы¶
PULSE — не гейт-фаза (фиксация состояния). Условие перехода в SCOUT: фокусный JTBD зафиксирован (один), Видение и Гэп сформулированы, intent понятен (какие узлы решения насыщать). Если JTBD не выбран → SCOUT генерирует «всё для всех» = workslop.
Рост CP идёт по колесу Гилада [S1] VI.7: только от появления информации, снижающей неопределённость, а не от «мне кажется».
🛡️ Анти-workslop¶
- Гэп как якорь: без явно сформулированного Гэпа (текущее → Видение) Банч не формируется — гипотезы решения «висят в воздухе» [7.1].
- Один JTBD: попытка закрыть несколько JTBD в одном цикле Sprint = workslop и распыление. Начать с одного узкого места.
- Нексус ≠ документ с галочками: узлы v0.3 должны иметь метаданные (источник, CP, timestamp, статус увядания); «иллюзия живого Нексуса» — узлы без фазы увядания [S1] III.1.
- Premature PMF-риск здесь: не путать «ценность подтверждена (Step 4)» с «решение подтверждено» — решение ещё не построено; CP по решению ≈ 0% на старте.
🔗 Дальше¶
→ 2.scout (SCOUT) — Identify-фаза Und-Id-Ex: генератор гипотез решения, CJM/User Flow-билдер, AI UX Designer-агент (ИИ-метафоры) через 3 Линзы.
Назад: overview · Назад в хребет: overview.
Version: 1.0 · Last updated: 2026-06-20 · Maintained by: AI-KORTEX