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

4.2 instruction — Rapid Validation через Validation Agent

Этап RB-STEP-1 — BIG IDEA (прелюдия) · Линза: Product (валидация гипотез фич) · Инструкция для Инженера Продукта нового поколения (PAF, [S1],[S2]). Преемственность метода: исходный раннбук RB-STEP-1-IDEA/4.2 Rapid Validation.md — 4 метода по уровню CP (smoke tests 1–3: landing/concierge/Wizard-of-Oz; prototypes 4–6: Figma/pre-sale; customer validation 7–8: deep interviews/data analysis) с порогами (5–10% конверсия, 70% completion, 80% interest). Эта инструкция: Validation Agent с автогенерацией smoke test/прототипа через вайбкодинг ([reformation] §1.5, [S2] III.6), авто-обновление CP (вместо ручного Step 3 в исходнике), защита от «ложного ощущения готовности».

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

Провести rapid validation гипотез Банча (4.1), чтобы поднять CP фич по stage-gate (Принцип 4 [S1]) — не «проверить гипотезу ради галочки», а снизить неопределённость через evidence.

В Execute/Identify-фазе Und-Id-Ex [S1] VI.5 Кортекс (через вайбкодинг [S2] III.6) автогенерирует smoke test/прототип, собирает сигналы и обновляет CP. Цель — NPV фичи растёт по мере роста CP (доказанная ценность → больший NPV [S1] Принцип 6).

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

  • Product Engineer — выбирает метод валидации (по CP фичи); валидирует сигналы; veto на premature scale.
  • Discovery/Launcher PM (если есть) — вайбкодит smoke test/прототип через Кортекс (full-stack: продуктовые компетенции + вайбкодинг [S2] III.6); rapid-итерации.
  • Product Ops — настройка вайбкодинг-пайплайна (генерация лендинга/прототипа из Hypothesis Card).
  • Зона человека: решение о масштабировании по результатам валидации — за человеком (ложное ощущение готовности — сквозной риск [reformation] Часть VIII).

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

Validation Agent [reformation] §1.5:

  • По CP фичи (из 4.1) выбирает метод (smoke/prototype/customer validation — из исходника 4.2).
  • Автогенерация smoke test/прототипа через вайбкодинг: из Hypothesis-Card-узла генерирует лендинг (Tilda/web)/Figma-прототип/no-code — rapid, итеративно [S2] III.6.
  • Сбор сигналов: конверсия, completion rate, willingness-to-pay, цитаты (для smoke — по порогам исходника 4.2).
  • Авто-обновление CP по результатам (колесо Гилада [S1] VI.7): сигнал ≥ порога → рост CP; < порога → падение CP или переформулировка.

  • Различает «оффер сработал» vs «ценность подтверждена» [reformation] §4.6 (критический анти-workslop-чек: конверсия на лендинге ≠ подтверждение ценности).

  • Вход: Hypothesis-Card (4.1) + Feature (3.3).

  • Выход: Validation-Result-узел (метод, сигнал, pass/fail, новая дельта CP), автообновлённый CP фичи.

Пороги (преемственность из исходника 4.2): - smoke: 5–10% конверсия в signup; - prototype: 70%+ completion rate задач; - customer validation: 80% выражают сильный интерес.

Промпт-идея:

«По CP фичи выбери метод валидации. Сгенерируй smoke test/прототип из Hypothesis Card (вайбкодинг). Собери сигналы. Различай "оффер сработал" (конверсия) и "ценность подтверждена" (доказательство JTBD). Обнови CP по колесу Гилада.»

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

  • Главный workslop-риск: «оффер сработал» ≠ «ценность подтверждена» [reformation] §4.6. Конверсия на лендинге может быть от любопытства, не от ценности. Инженер проверяет: сигнал подтверждает JTBD или только интерес?
  • Veto-право: premature scale (масштабировать по одному smoke-сигналу) — veto; нужна конвергенция сигналов [reformation] Часть VIII.
  • Вопрос:
  • «Этот smoke test подтвердил ценность или только кликабельность оффера? Какой сигнал доказывает, что JTBD выполнена?»
  • «Конверсия 8% — это curiosity-click или реальная потребность?»

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

  • Создаются/обновляются: Validation-Result-узлы (метод, сигнал, pass/fail, дельта CP); автообновлённый CP фичи; Validation-Artifact (URL лендинга/прототипа).
  • Метаданные: источник (Hypothesis-Card), метод, сигнал (число), pass/fail, delta-CP, timestamp, тип-сигнала (offer-click vs value-confirmation).
  • Прирост Context Ripeness: +10–15% (evidence из реальных сигналов — ядро созревания).

🚦 Confidence Point-гейт

  • Критерий перехода к 4.3: каждая фича Банча имеет Validation-Result (pass/fail) с дельтой CP; фичи с CP<порога после валидации → отсев или переформулировка.
  • Стоимость риска: «Сколько ресурсов на smoke test? Какой NPV-потенциал теряем, если валидация поверхностная?» — приоритет по NPV-потенциалу.

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

  • Активная: Product Lens (валидация ценности).
  • Связь с Business Lens: подтверждённая ценность → рост NPV фичи.
  • Связь со Strategy Lens: валидация подтверждает/опровергает Bet.

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

  • Workslop-риск: «оффер сработал» как ложное подтверждение ценности (главный риск Value-стадий [reformation] §4.9); premature PMF/готовности по одному сигналу.
  • Признак: конверсия на лендинге принята как подтверждение JTBD; CP поднят по одному smoke без повторной проверки.
  • Правило верификации: различать оффер/ценность; конвергенция ≥2 сигналов для масштабирования; CP растёт только от снижения неопределённости, не от возбуждения [reformation] §4.9.

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

  • Skill Map [S3]: сектор 4 Growth & Experiments (эксперименты, MVP)
  • сектор 3 Development & Delivery (вайбкодинг прототипа). Уровень — внутренний + средний круг: атомарная гипотеза/проект.
  • Профстандарт 06.012 [S4]: функция B (B/03.5 план развития, B/06.5 вывод на рынок), уровень 5; для Launcher PM — A/03.4 дизайн/выпуск.

🔗 Связи

Назад: 4.1 instruction · Дальше: 4.3 instruction Связанные: reformation · index · [[naming_conventions]