code-ai-installer 3.0.0 → 4.0.1-a

package/domains/product/.agents/skills/hypothesis-template/SKILL.md

@@ -1,469 +1,484 @@
----
-name: hypothesis-template
-description: Тестируемая гипотеза — We believe / Will result in / We'll know when [metric] reaches [threshold]
----
-# Hypothesis Template
-
-> **Категория:** Experimentation  ·  **Slug:** `hypothesis-template`
-
-## Когда использовать
-
-- Перед каждым experiment (A/B test, rollout, prototype test).
-- При assumption validation — convert assumption в testable hypothesis.
-- Для pre-mortem решений — «если мы делаем X, что ожидаем?».
-- Как часть PRD success criteria.
-
-## Вход
-
-| Поле | Обязательно | Описание |
-|------|:-----------:|----------|
-| Предлагаемое изменение / фича | ✅ | Что тестируем |
-| Лежащее в основе допущение | ✅ | Почему думаем, что сработает |
-| Метрика результата | ✅ | Что измеряем |
-| Базовые данные | ✅ | Текущий уровень метрики |
-
-## Источники данных
-
-1. `$assumption-mapping` — какие допущения тестировать.
-2. `$saas-metrics` + `$aarrr-metrics` — для выбора метрики результата.
-3. Исторические данные — базовый уровень.
-4. Отраслевые бенчмарки — ожидаемые размеры эффекта.
-
-### Связь с другими скилами
-
-| Скил | Что берём | Когда вызывать |
-|------|-----------|----------------|
-| `assumption-mapping` | Наиболее рискованные допущения → гипотезы | Перед hypothesis |
-| `ab-test-design` | Метод тестирования | После hypothesis |
-| `saas-metrics` | Метрики результата | Для измерения |
-| `north-star-metric` | Выравнивание первичной метрики | Для тестов, связанных с NSM |
-
-## Формат (Canonical)
-
-> **We believe** [proposed change / hypothesis]  
-> **For** [target user / segment]  
-> **Will result in** [expected outcome]  
-> **We'll know it's true when** [metric] **reaches** [threshold] **within** [timeframe]  
-> **Because** [underlying rationale]
-
-Пример:
-> **We believe** adding an in-app onboarding checklist  
-> **For** new users (trial signups, first 7 days)  
-> **Will result in** higher activation rate  
-> **We'll know it's true when** 7-day activation rate reaches **45%** (from baseline **32%**) **within** 6 weeks of rollout  
-> **Because** 12/15 interviews показали confusion about first steps, и competitor data suggests checklist approach drives +40% activation в category.
-
-## Протокол
-
-### Шаг 1 — Формулировка гипотезы
-
-**We believe:** конкретное изменение (фича, текст, поток)
-**For:** конкретный сегмент пользователей (не «все пользователи»)
-**Will result in:** направленный результат + метрика
-
-Правила:
-- Конкретное изменение, не расплывчатое («улучшить UX»)
-- Конкретный пользователь, не «пользователи»
-- Конкретный результат, не «лучшая вовлечённость»
-
-### Шаг 2 — Outcome Metric Selection
-
-Первичная метрика должна быть:
-- **Измеримой:** инструментирована или может быть инструментирована
-- **Опережающей или запаздывающей:** знать которой
-- **Согласованной:** связана с NSM / OKR
-- **Защищённой от манипуляций:** не поддаётся лёгкому искажению
-
-Распространённые метрики результата по типу гипотезы:
-- **Гипотеза онбординга/активации:** 7-дневный activation rate, time-to-first-value
-- **Гипотеза retention:** W/W retention, churn rate, частота использования
-- **Гипотеза монетизации:** conversion rate, ARPA, upsell rate
-- **Гипотеза вовлечённости:** DAU/MAU, длительность сессии, действия за сессию
-
-### Шаг 3 — Baseline + Threshold
-
-**Базовый уровень:** текущий уровень (на основе недавнего окна данных).
-
-**Порог:** что сигнализирует о «подтверждении гипотезы»? Два подхода:
-
-1. **Абсолютный:** «45% activation» (определённое абсолютное число)
-2. **Относительный:** «+20% activation» или «+5pp»
-
-Обоснование порога:
-- На основе бизнес-потребности (какой прирост делает запуск оправданным)
-- На основе обнаруживаемого эффекта (какой объём выборки поддерживает)
-- На основе отраслевых бенчмарков
-
-### Шаг 4 — Timeframe
-
-- Слишком короткий = шум
-- Слишком длинный = медленный цикл обучения
-- Типичный для B2B SaaS: 4-8 недель для activation, 8-12 для retention
-
-Обоснование: почему такая продолжительность?
-
-### Шаг 5 — «Because» — Rationale
-
-Лежащие в основе доказательства:
-- Исследование пользователей (цитаты, интервью)
-- Исторические данные (прошлые похожие изменения)
-- Отраслевые бенчмарки
-- Поведение конкурентов
-
-Без «because» — угадывание. С доказательствами — осознанная ставка.
-
-### Шаг 6 — Null Hypothesis (Explicit)
-
-Что если гипотеза не подтверждается? Что это означает:
-- Допущение не выдерживает проверки
-- Нужна новая гипотеза
-- Фича не запускается, ресурсы переходят к другому
-
-Будьте готовы отказаться от идеи, если данные говорят об этом.
-
-### Шаг 7 — Guardrail Metrics
-
-Что **не должно** деградировать даже при улучшении первичной метрики:
-- Churn rate (не должен расти)
-- NPS
-- Объём тикетов поддержки
-- Метрики производительности
-- Выручка на пользователя (если рост вовлечённости идёт за счёт ARPA)
-
-Если guardrail нарушается — несмотря на победу первичной метрики — считать провалом.
-
-### Шаг 8 — Confidence Level
-
-Байесовский неформальный:
-- **Высокая уверенность** (80%+): Сильные доказательства, похожие успешные запуски, чёткий механизм
-- **Средняя** (50-80%): Умеренные доказательства, новый механизм
-- **Низкая** (<50%): Исследовательская, много допущений
-
-Определяет инвестиции в эксперименты (более крупные тесты для низкой уверенности).
-
-### Шаг 9 — Segment Analysis Plan
-
-Указать сегменты для анализа после теста:
-- По размеру компании (SMB / mid / enterprise)
-- По роли пользователя (buyer / end-user / admin)
-- По тиру тарифного плана
-- По стажу (новые / постоянные)
-
-Общий прирост + разбивка по сегментам.
-
-## Валидация (Quality Gate)
-
-- [ ] Все 5 компонентов (believe / for / result / know / because) заполнены
-- [ ] Конкретное изменение + конкретный сегмент пользователей
-- [ ] Метрика результата измерима + инструментирована
-- [ ] Базовые данные предоставлены (недавнее окно)
-- [ ] Порог обоснован (бизнес + обнаруживаемость)
-- [ ] Обоснование временных рамок
-- [ ] Обоснование ссылается на ≥ 2 источника доказательств
-- [ ] Последствия нулевой гипотезы явны
-- [ ] Guardrail метрики перечислены
-- [ ] Уровень уверенности указан
-- [ ] План сегментного анализа
-
-## Handoff
-
-Результат является входом для:
-- **`ab-test-design`** — метод тестирования
-- **Data Analyst** — инструментирование
-- **PM** → секция критериев успеха PRD
-- **Engineering** → настройка feature flag
-
-Формат: hypothesis card (markdown). Через `$handoff`.
-
-## Anti-patterns
-
-| Ошибка | Почему плохо | Как правильно |
-|--------|-------------|---------------|
-| Расплывчатое изменение | Не тестируется | Конкретная реализация |
-| «Все пользователи» | Размывает сигнал | Конкретный сегмент |
-| Нет базового уровня | Невозможно обнаружить изменение | Сначала базовые данные |
-| Нет порога | «Улучшится» | Числовой порог + обоснование |
-| Нет обоснования | Угадывание | ≥ 2 источника доказательств |
-| Нет guardrails | Невидимый ущерб | Явные guardrails |
-| Игнорируемая нулевая гипотеза | Никогда не убивают проигрывающие идеи | Подготовить условия отказа |
-
-## Шаблон
-
-```markdown
-# Hypothesis: [Короткое название]
-
-**We believe** [изменение]
-**For** [сегмент]
-**Will result in** [результат]
-**We'll know it's true when** [метрика] reaches [порог] within [временные рамки]
-**Because** [обоснование, ≥2 источника доказательств]
-
-## Базовый уровень
-- Текущий [метрика]: X
-- Окно данных: [последние 30 дней и т.д.]
-- Уверенность: Средняя
-
-## Порог
-- Цель: X → Y
-- Обоснование: [бизнес-потребность + обнаруживаемость + бенчмарк]
-
-## Guardrails
-- Churn < [порог]
-- NPS ≥ [порог]
-- Тикеты поддержки < [порог]
-
-## Сегменты для анализа
-- Размер компании
-- Роль пользователя
-
-## Последствия нулевой гипотезы
-Если метрика не достигает Y:
-- Допущение X не выдерживает проверки
-- Запускать? Вероятно нет — данные говорят, что нет соответствия
-```
-
-## Worked Example — TeamFlow Hypothesis Cards (4 cards для AI Summarization launch)
-
-**Контекст:** Pre-MVP запуск, data analyst формирует карточки гипотез для каждого высокорискового допущения из assumption-map. Каждая карточка будет проверена через конкретный эксперимент.
-
-### Hypothesis Card H-001: AI Summary Willingness to Pay (V1 assumption)
-
-```markdown
-# Hypothesis: H-001 — Willingness to Pay для AI Tier
-
-**We believe** adding AI Summarization as Team Tier feature (+$8/seat/month premium)
-**For** TeamFlow customer base (200 existing Core accounts) + new trial signups с manager workflows
-**Will result in** 40 account upgrades to AI Team Tier within first quarter post-launch
-**We'll know it's true when** AI Team Tier adoption reaches **20%** of 200 existing customer base
-  (baseline: 0% (tier не existing pre-launch); target = 40 of 200 customer accounts upgrade)
-  **within** 90 days post-launch
-**Because** 
-  (1) 7 of 10 customer conversations в landing page test confirmed «we'd pay $10/seat for AI summaries»
-  (2) Competitor ChatGPT Teams priced at $25/user shows price ceiling exists (we're well-below)
-  (3) Post-Discovery survey: 34% of customers expressed interest в AI summarization, suggesting 20% conversion realistic conservative target
-
-## Базовый уровень
-- Текущий adoption AI Tier: 0 аккаунтов (тир не существовал до запуска)
-- Исторический темп обновления Core → Team Tier: 12% / год (отраслевая норма)
-- Окно данных: Q4 2025 + Q1 2026 (6 месяцев) — для базового churn / NPS
-- Уверенность: Средне-высокая (проверена в 2 методах исследования клиентов)
-
-## Порог
-- Цель: **20% конверсия** базы 200 клиентов за 90 дней = 40 аккаунтов
-- Обоснование: 
-  - Бизнес-потребность: OKR KR1.1 «40 аккаунтов обновлено»
-  - Верхняя граница: 34% выразили интерес (опрос Discovery) → 20% конверсия предполагает 60% конверсию интереса в обновление
-  - Бенчмарк: Успешные запуски premium-тиров B2B SaaS достигают 15-25% в первые 90 дней, когда фича соответствует потребности
-
-## Guardrails
-- Churn rate < 9% (от базового 8%) — если ценообразование вызывает отток
-- NPS ≥ 43 (от базового 45) — если нарушение тиров вызывает неудовлетворённость
-- Тикеты поддержки «ценообразование / путаница с тирами» < 5% от всех тикетов
-- Отток Core-тира не должен ускоряться (максимум +0.5pp)
-
-## Сегменты для анализа
-- Размер компании (SMB / mid-market / enterprise) — ожидаем enterprise > mid > SMB
-- Стаж (<6 мес / 6-24 мес / 24+ мес) — ожидаем постоянные > новые
-- Текущая интенсивность использования (топ-квартиль WAM / медиана / нижний) — ожидаем тяжёлые пользователи → обновление
-
-## Последствия нулевой гипотезы
-Если конверсия не достигает 8%:
-- **Ниже 3%:** Ценообразование неверное ИЛИ ценность фичи слабая. Триггер: пересмотреть ценообразование; рассмотреть unbundling
-- **3-5%:** Сигнал смешанный. Изучить по сегментам: вероятно enterprise внедряет, но mid-market чувствителен к цене
-- **5-8%:** Почти достигнуто — продлить наблюдение на 30 дней, скорректировать GTM сообщения, пересмотреть
-
-## Связанные эксперименты
-- Exp EXP-012: A/B тест сообщений страницы ценообразования (фокус на ценность vs фокус на экономию)
-- Exp EXP-015: A/B тест тайминга внутреннего upsell (день 7 vs день 14 vs день 30 с момента права на тир)
-
-## Уровень уверенности: Средне-высокий (75%)
-## Ожидаемое P-value если истинно: <0.05 в 90-дневном окне
-```
-
----
-
-### Hypothesis Card H-002: LLM Quality Acceptability (F1 assumption)
-
-```markdown
-# Hypothesis: H-002 — LLM Quality Acceptable для HR Use Case
-
-**We believe** GPT-4 level LLMs (primary OpenAI GPT-4-Turbo, fallback Anthropic Claude 3.5)
-**For** 30-minute 1:1 performance conversations in English
-**Will generate summaries** acceptable to managers >85% of the time
-  (Acceptable = manager approves без major edits (< 50% content changed))
-**We'll know it's true when** в Wizard-of-Oz test:
-  - Blind quality rating from managers: ≥ 4.0 out of 5.0 average (across N ≥ 100 meetings)
-  - Hallucination rate: < 5% of summaries contain factually wrong info
-  - Misattribution rate: < 3% of action items assigned to wrong person
-  **within** 4 weeks of Wizard-of-Oz testing
-**Because**
-  (1) Recent LLM benchmarks on summarization (Anthropic HELM, OpenAI evals) показывают 87-92% acceptance
-  (2) Our manual QA на 30 sample prompts achieved 90% acceptable rate
-  (3) Adjacent use cases (Fireflies.ai, Gong) report >80% customer satisfaction — lower bar but similar
-
-## Базовый уровень
-- Внутреннее QA тестирование промптов: 90% приемлемо (N=30 ручных тестов)
-- Нет внешнего базового уровня конкретно для HR-разговоров
-- Уверенность: Средняя (ограниченные HR-специфичные данные)
-
-## Порог
-- Цель: **≥85% приемлемость** в Wizard-of-Oz
-- Обоснование:
-  - Ниже 85% → доверие пользователей рушится, фича становится обузой
-  - 85-90% = готово к производству
-  - >90% = превышает ожидания
-
-## Guardrails
-- P95 задержка генерации ≤ 60с (ограничение пользовательского опыта)
-- Стоимость одного summary ≤ $0.10 (жизнеспособность — допущение FP5)
-- Нулевая утечка данных к LLM-провайдеру (проверено через аудит провайдера)
-- Нулевое обучение на данных клиентов (контрактное + техническое соблюдение)
-
-## Сегменты для анализа
-- Длительность встречи (короткая 5-15 / стандартная 15-45 / длинная 45-120 мин) — ожидаем средняя лучшая
-- Тип разговора (планирование / обратная связь / сложный разговор / catch-up) — ожидаем вариативность
-- Отрасль клиента (tech / услуги / производство) — ожидаем tech наивысший
-- Языковой состав (чистый английский / частично не-английский) — исключить не-английский для MVP
-
-## Последствия нулевой гипотезы
-Если приемлемость < 85%:
-- **<70%:** Убить фичу. LLM не готов для HR сценария, ждать 6-12 месяцев.
-- **70-80%:** Запустить с обязательным слоем человеческого контроля (feature flag). Снижает ценностное предложение, но запускается.
-- **80-85%:** Обширный prompt engineering + итерация до запуска. Задержка 2-4 недели.
-
-## Связанные эксперименты
-- **Exp EXP-020: Wizard-of-Oz тест** — 20 бета-менеджеров, 100+ встреч итого, слепая оценка качества
-- Exp EXP-021: Итерация prompt engineering (A/B разные промпты, измерить приемлемость)
-
-## Уровень уверенности: Средний (60%)
-## Инвестиции в риске: $200K engineering + 10 недель задержки при опровержении
-```
-
----
-
-### Hypothesis Card H-003: Manager Adoption Rate (V2 assumption)
-
-```markdown
-# Hypothesis: H-003 — Manager Adoption Rate Post-Launch
-
-**We believe** managers в AI-tier upgraded accounts
-**Will** adopt AI summarization at **≥60% weekly usage rate** within 90 days of account upgrade
-  (Adoption = ≥1 AI-summarized 1:1 per week)
-**Because**
-  (1) Discovery: 6 of 8 managers expressed direct desire for this feature
-  (2) Removes 3-4 hrs/week admin burden — very high individual incentive
-  (3) Onboarding checklist design will guide first-use в <7 days
-
-## Базовый уровень
-- Н/П (фича не существовала). Аналог: средний adoption существующих фич Team Tier 55% еженедельного использования за 90 дней.
-- Уверенность: Средняя
-
-## Порог
-- Цель: **60% еженедельный adoption** к Дню 90
-- Stretch: 75%
-- Обоснование:
-  - Ниже 50% — фича не удерживает; риск оттока
-  - 50-60% — приемлемо, но требует улучшения
-  - 60-75% — здорово
-  - 75%+ — определяет категорию
-
-## Guardrails
-- Обратный adoption (отказ) < 10% — пользователи, попробовавшие и остановившиеся
-- NPS стабильный или улучшается
-- Completion rate action items растёт у тех, кто внедрил (дополнительный сигнал)
-
-## Сегменты для анализа
-- Размер команды менеджера (малая 3-5 / средняя 6-10 / большая 11+ подчинённых) — ожидаем средняя/большая наивысший
-- Стаж менеджера в роли (<2 года / 2-5 / 5+) — ожидаем новые менеджеры наивысший (новинка помогает)
-- Отрасль / роль (tech / non-tech) — ожидаем tech наивысший
-- Время месяца (сезон оценок vs обычный) — должно быть стабильным
-
-## Последствия нулевой гипотезы
-Если adoption < 60%:
-- **<40%:** Провал фичи — пересмотреть дизайн, рассмотреть крупную переработку
-- **40-50%:** Требует итерации, вероятно проблемы с онбординговым потоком
-- **50-60%:** Почти достигнуто, итерировать онбординг + напоминания
-
-## Связанные эксперименты
-- Exp EXP-025: A/B тест наличия онбордингового чеклиста (с vs без)
-- Exp EXP-026: A/B тест тайминга первого напоминания о встрече
-- Текущий: когортный анализ по месяцу активации
-
-## Уверенность: Средняя (65%)
-```
-
----
-
-### Hypothesis Card H-004: Enterprise Tier Dashboard Upgrade Driver (V3 assumption)
-
-```markdown
-# Hypothesis: H-004 — Aggregate Dashboard Drives Enterprise Tier Upgrades
-
-**We believe** showing VP HR / CPO buyers aggregate dashboard (cadence + health score + benchmarks)
-**Will** drive **5 Enterprise tier upgrades** (to $50+/seat tier) within Q2
-**Because**
-  (1) 4 of 4 buyer interviews explicitly asked для dashboard visibility
-  (2) 8 of 10 enterprise prospects в Q1 asked «do you have 1:1 analytics?» — current blocker
-  (3) Existing mid-market → enterprise conversion rate 0% (no offering); we're creating demand
-
-## Базовый уровень
-- Текущие конверсии Enterprise тира из mid-market: 0/квартал (нет функции дашборда)
-- Текущий Enterprise тир = устаревшее ценообразование, 10 аккаунтов дедовских прав
-- Уверенность: Средняя (сильный сигнал покупателя, но новое движение)
-
-## Порог
-- Цель: **5 обновлений Enterprise тира** к 30 июня
-- Stretch: 10
-- Обоснование:
-  - 5 = обязательство OKR KR2.1
-  - На основе 80 подходящих mid-market аккаунтов × 6% конверсия (консервативно) = 5
-
-## Guardrails
-- Нет каннибализации существующих Enterprise тир аккаунтов (не должны снижаться)
-- Размер Enterprise сделки не разбавляется (поддерживается средний ACV)
-- Команда продаж не тратит непропорциональное время (мониторинг времени-на-сделку)
-
-## Сегменты для анализа
-- Размер аккаунта (100-299 / 300-499 / 500+ сотрудников) — ожидаем 300+ наивысшая конверсия
-- Текущий тир расходов (Team vs устаревший Enterprise) — Team с >50 местами наиболее вероятный
-- Отрасль (регулируемая / нерегулируемая) — регулируемая ниже (барьеры проверки соответствия)
-
-## Последствия нулевой гипотезы
-Если обновлений < 5:
-- **0-2:** Дашборд недостаточно ценен для тирной премии. Пересмотреть область фичи или ценообразование.
-- **3-4:** Почти достигнуто — продлить срок на 30 дней, улучшить sales motion
-- **5+:** Успех, расширить roadmap фич Enterprise тира
-
-## Связанные эксперименты
-- Exp EXP-030: 3 сессии concierge с design partner (качественный + намерение конверсии)
-- Exp EXP-031: A/B вариации питча команды продаж (питч сначала данные vs питч сначала ROI)
-
-## Уверенность: Средняя (60%)
-```
-
----
-
-### Обзор портфеля карточек гипотез
-
-| ID | Гипотеза | Уверенность | Метод валидации | Статус | Зависимость запуска |
-|----|-----------|:----------:|-------------------|:------:|-----------------|
-| H-001 | WTP $8/место премия | 75% | Landing page + разговоры с клиентами | ⏳ До запуска | Запустить ценовой тир |
-| H-002 | Качество LLM ≥85% | 60% | Wizard-of-Oz N=100+ | ⏳ Неделя 3-6 | Запустить AI фичу |
-| H-003 | 60% еженедельный adoption | 65% | Когортный анализ после запуска | 🔜 После запуска | Итерировать онбординг |
-| H-004 | 5 обновлений Enterprise | 60% | Сессии design partner + A/B продаж | ⏳ До запуска | Dashboard MVP |
-
-### Дерево решений на основе результатов
-
-```
-H-002 (качество LLM)
-  ├── >85% приемлемо → ЗЕЛЁНЫЙ СВЕТ для MVP запуска
-  ├── 70-85% → Запустить с слоем человеческого контроля, итерировать промпты
-  └── <70% → Задержка 2-3 месяца, ждать улучшения LLM
-
-H-001 (WTP)
-  ├── >8% конверсия → Подтверждено, масштабировать GTM
-  ├── 5-8% → Почти достигнуто, итерировать ценообразование / сообщения
-  └── <5% → Ценообразование неверное, пересмотреть цену или unbundle
-```
-
-> **Урок hypothesis:** 4 hypothesis cards cover **different types of risk**: value (H-001, H-004), feasibility (H-002), usability (H-003). Each с own validation method (landing page, Wizard-of-Oz, cohort analysis, design partner). The **null hypothesis consequences** section — что often skipped — делает кit actionable: «if <X, do Y». Без этого hypothesis cards = wishful thinking. Каждый card links назад к assumption-map risk score, закрывая discovery-to-validation loop.
+---
+name: hypothesis-template
+description: Тестируемая гипотеза — We believe / Will result in / We'll know when [metric] reaches [threshold]
+type: triggered
+domain: product
+owners:
+  - data_analyst
+gates:
+  - DATA_ANALYST
+tech: []
+topic: []
+triggers:
+  - hypothesis-template
+  - hypothesis
+  - гипотеза
+related: []
+budget_lines: 484
+schema_version: 1
+---
+# Hypothesis Template
+
+> **Категория:** Experimentation  ·  **Slug:** `hypothesis-template`
+
+## Когда использовать
+
+- Перед каждым experiment (A/B test, rollout, prototype test).
+- При assumption validation — convert assumption в testable hypothesis.
+- Для pre-mortem решений — «если мы делаем X, что ожидаем?».
+- Как часть PRD success criteria.
+
+## Вход
+
+| Поле | Обязательно | Описание |
+|------|:-----------:|----------|
+| Предлагаемое изменение / фича | ✅ | Что тестируем |
+| Лежащее в основе допущение | ✅ | Почему думаем, что сработает |
+| Метрика результата | ✅ | Что измеряем |
+| Базовые данные | ✅ | Текущий уровень метрики |
+
+## Источники данных
+
+1. `$assumption-mapping` — какие допущения тестировать.
+2. `$saas-metrics` + `$aarrr-metrics` — для выбора метрики результата.
+3. Исторические данные — базовый уровень.
+4. Отраслевые бенчмарки — ожидаемые размеры эффекта.
+
+### Связь с другими скилами
+
+| Скил | Что берём | Когда вызывать |
+|------|-----------|----------------|
+| `assumption-mapping` | Наиболее рискованные допущения → гипотезы | Перед hypothesis |
+| `ab-test-design` | Метод тестирования | После hypothesis |
+| `saas-metrics` | Метрики результата | Для измерения |
+| `north-star-metric` | Выравнивание первичной метрики | Для тестов, связанных с NSM |
+
+## Формат (Canonical)
+
+> **We believe** [proposed change / hypothesis]  
+> **For** [target user / segment]  
+> **Will result in** [expected outcome]  
+> **We'll know it's true when** [metric] **reaches** [threshold] **within** [timeframe]  
+> **Because** [underlying rationale]
+
+Пример:
+> **We believe** adding an in-app onboarding checklist  
+> **For** new users (trial signups, first 7 days)  
+> **Will result in** higher activation rate  
+> **We'll know it's true when** 7-day activation rate reaches **45%** (from baseline **32%**) **within** 6 weeks of rollout  
+> **Because** 12/15 interviews показали confusion about first steps, и competitor data suggests checklist approach drives +40% activation в category.
+
+## Протокол
+
+### Шаг 1 — Формулировка гипотезы
+
+**We believe:** конкретное изменение (фича, текст, поток)
+**For:** конкретный сегмент пользователей (не «все пользователи»)
+**Will result in:** направленный результат + метрика
+
+Правила:
+- Конкретное изменение, не расплывчатое («улучшить UX»)
+- Конкретный пользователь, не «пользователи»
+- Конкретный результат, не «лучшая вовлечённость»
+
+### Шаг 2 — Outcome Metric Selection
+
+Первичная метрика должна быть:
+- **Измеримой:** инструментирована или может быть инструментирована
+- **Опережающей или запаздывающей:** знать которой
+- **Согласованной:** связана с NSM / OKR
+- **Защищённой от манипуляций:** не поддаётся лёгкому искажению
+
+Распространённые метрики результата по типу гипотезы:
+- **Гипотеза онбординга/активации:** 7-дневный activation rate, time-to-first-value
+- **Гипотеза retention:** W/W retention, churn rate, частота использования
+- **Гипотеза монетизации:** conversion rate, ARPA, upsell rate
+- **Гипотеза вовлечённости:** DAU/MAU, длительность сессии, действия за сессию
+
+### Шаг 3 — Baseline + Threshold
+
+**Базовый уровень:** текущий уровень (на основе недавнего окна данных).
+
+**Порог:** что сигнализирует о «подтверждении гипотезы»? Два подхода:
+
+1. **Абсолютный:** «45% activation» (определённое абсолютное число)
+2. **Относительный:** «+20% activation» или «+5pp»
+
+Обоснование порога:
+- На основе бизнес-потребности (какой прирост делает запуск оправданным)
+- На основе обнаруживаемого эффекта (какой объём выборки поддерживает)
+- На основе отраслевых бенчмарков
+
+### Шаг 4 — Timeframe
+
+- Слишком короткий = шум
+- Слишком длинный = медленный цикл обучения
+- Типичный для B2B SaaS: 4-8 недель для activation, 8-12 для retention
+
+Обоснование: почему такая продолжительность?
+
+### Шаг 5 — «Because» — Rationale
+
+Лежащие в основе доказательства:
+- Исследование пользователей (цитаты, интервью)
+- Исторические данные (прошлые похожие изменения)
+- Отраслевые бенчмарки
+- Поведение конкурентов
+
+Без «because» — угадывание. С доказательствами — осознанная ставка.
+
+### Шаг 6 — Null Hypothesis (Explicit)
+
+Что если гипотеза не подтверждается? Что это означает:
+- Допущение не выдерживает проверки
+- Нужна новая гипотеза
+- Фича не запускается, ресурсы переходят к другому
+
+Будьте готовы отказаться от идеи, если данные говорят об этом.
+
+### Шаг 7 — Guardrail Metrics
+
+Что **не должно** деградировать даже при улучшении первичной метрики:
+- Churn rate (не должен расти)
+- NPS
+- Объём тикетов поддержки
+- Метрики производительности
+- Выручка на пользователя (если рост вовлечённости идёт за счёт ARPA)
+
+Если guardrail нарушается — несмотря на победу первичной метрики — считать провалом.
+
+### Шаг 8 — Confidence Level
+
+Байесовский неформальный:
+- **Высокая уверенность** (80%+): Сильные доказательства, похожие успешные запуски, чёткий механизм
+- **Средняя** (50-80%): Умеренные доказательства, новый механизм
+- **Низкая** (<50%): Исследовательская, много допущений
+
+Определяет инвестиции в эксперименты (более крупные тесты для низкой уверенности).
+
+### Шаг 9 — Segment Analysis Plan
+
+Указать сегменты для анализа после теста:
+- По размеру компании (SMB / mid / enterprise)
+- По роли пользователя (buyer / end-user / admin)
+- По тиру тарифного плана
+- По стажу (новые / постоянные)
+
+Общий прирост + разбивка по сегментам.
+
+## Валидация (Quality Gate)
+
+- [ ] Все 5 компонентов (believe / for / result / know / because) заполнены
+- [ ] Конкретное изменение + конкретный сегмент пользователей
+- [ ] Метрика результата измерима + инструментирована
+- [ ] Базовые данные предоставлены (недавнее окно)
+- [ ] Порог обоснован (бизнес + обнаруживаемость)
+- [ ] Обоснование временных рамок
+- [ ] Обоснование ссылается на ≥ 2 источника доказательств
+- [ ] Последствия нулевой гипотезы явны
+- [ ] Guardrail метрики перечислены
+- [ ] Уровень уверенности указан
+- [ ] План сегментного анализа
+
+## Handoff
+
+Результат является входом для:
+- **`ab-test-design`** — метод тестирования
+- **Data Analyst** — инструментирование
+- **PM** → секция критериев успеха PRD
+- **Engineering** → настройка feature flag
+
+Формат: hypothesis card (markdown). Через `$handoff`.
+
+## Anti-patterns
+
+| Ошибка | Почему плохо | Как правильно |
+|--------|-------------|---------------|
+| Расплывчатое изменение | Не тестируется | Конкретная реализация |
+| «Все пользователи» | Размывает сигнал | Конкретный сегмент |
+| Нет базового уровня | Невозможно обнаружить изменение | Сначала базовые данные |
+| Нет порога | «Улучшится» | Числовой порог + обоснование |
+| Нет обоснования | Угадывание | ≥ 2 источника доказательств |
+| Нет guardrails | Невидимый ущерб | Явные guardrails |
+| Игнорируемая нулевая гипотеза | Никогда не убивают проигрывающие идеи | Подготовить условия отказа |
+
+## Шаблон
+
+```markdown
+# Hypothesis: [Короткое название]
+
+**We believe** [изменение]
+**For** [сегмент]
+**Will result in** [результат]
+**We'll know it's true when** [метрика] reaches [порог] within [временные рамки]
+**Because** [обоснование, ≥2 источника доказательств]
+
+## Базовый уровень
+- Текущий [метрика]: X
+- Окно данных: [последние 30 дней и т.д.]
+- Уверенность: Средняя
+
+## Порог
+- Цель: X → Y
+- Обоснование: [бизнес-потребность + обнаруживаемость + бенчмарк]
+
+## Guardrails
+- Churn < [порог]
+- NPS ≥ [порог]
+- Тикеты поддержки < [порог]
+
+## Сегменты для анализа
+- Размер компании
+- Роль пользователя
+
+## Последствия нулевой гипотезы
+Если метрика не достигает Y:
+- Допущение X не выдерживает проверки
+- Запускать? Вероятно нет — данные говорят, что нет соответствия
+```
+
+## Worked Example — TeamFlow Hypothesis Cards (4 cards для AI Summarization launch)
+
+**Контекст:** Pre-MVP запуск, data analyst формирует карточки гипотез для каждого высокорискового допущения из assumption-map. Каждая карточка будет проверена через конкретный эксперимент.
+
+### Hypothesis Card H-001: AI Summary Willingness to Pay (V1 assumption)
+
+```markdown
+# Hypothesis: H-001 — Willingness to Pay для AI Tier
+
+**We believe** adding AI Summarization as Team Tier feature (+$8/seat/month premium)
+**For** TeamFlow customer base (200 existing Core accounts) + new trial signups с manager workflows
+**Will result in** 40 account upgrades to AI Team Tier within first quarter post-launch
+**We'll know it's true when** AI Team Tier adoption reaches **20%** of 200 existing customer base
+  (baseline: 0% (tier не existing pre-launch); target = 40 of 200 customer accounts upgrade)
+  **within** 90 days post-launch
+**Because** 
+  (1) 7 of 10 customer conversations в landing page test confirmed «we'd pay $10/seat for AI summaries»
+  (2) Competitor ChatGPT Teams priced at $25/user shows price ceiling exists (we're well-below)
+  (3) Post-Discovery survey: 34% of customers expressed interest в AI summarization, suggesting 20% conversion realistic conservative target
+
+## Базовый уровень
+- Текущий adoption AI Tier: 0 аккаунтов (тир не существовал до запуска)
+- Исторический темп обновления Core → Team Tier: 12% / год (отраслевая норма)
+- Окно данных: Q4 2025 + Q1 2026 (6 месяцев) — для базового churn / NPS
+- Уверенность: Средне-высокая (проверена в 2 методах исследования клиентов)
+
+## Порог
+- Цель: **20% конверсия** базы 200 клиентов за 90 дней = 40 аккаунтов
+- Обоснование: 
+  - Бизнес-потребность: OKR KR1.1 «40 аккаунтов обновлено»
+  - Верхняя граница: 34% выразили интерес (опрос Discovery) → 20% конверсия предполагает 60% конверсию интереса в обновление
+  - Бенчмарк: Успешные запуски premium-тиров B2B SaaS достигают 15-25% в первые 90 дней, когда фича соответствует потребности
+
+## Guardrails
+- Churn rate < 9% (от базового 8%) — если ценообразование вызывает отток
+- NPS ≥ 43 (от базового 45) — если нарушение тиров вызывает неудовлетворённость
+- Тикеты поддержки «ценообразование / путаница с тирами» < 5% от всех тикетов
+- Отток Core-тира не должен ускоряться (максимум +0.5pp)
+
+## Сегменты для анализа
+- Размер компании (SMB / mid-market / enterprise) — ожидаем enterprise > mid > SMB
+- Стаж (<6 мес / 6-24 мес / 24+ мес) — ожидаем постоянные > новые
+- Текущая интенсивность использования (топ-квартиль WAM / медиана / нижний) — ожидаем тяжёлые пользователи → обновление
+
+## Последствия нулевой гипотезы
+Если конверсия не достигает 8%:
+- **Ниже 3%:** Ценообразование неверное ИЛИ ценность фичи слабая. Триггер: пересмотреть ценообразование; рассмотреть unbundling
+- **3-5%:** Сигнал смешанный. Изучить по сегментам: вероятно enterprise внедряет, но mid-market чувствителен к цене
+- **5-8%:** Почти достигнуто — продлить наблюдение на 30 дней, скорректировать GTM сообщения, пересмотреть
+
+## Связанные эксперименты
+- Exp EXP-012: A/B тест сообщений страницы ценообразования (фокус на ценность vs фокус на экономию)
+- Exp EXP-015: A/B тест тайминга внутреннего upsell (день 7 vs день 14 vs день 30 с момента права на тир)
+
+## Уровень уверенности: Средне-высокий (75%)
+## Ожидаемое P-value если истинно: <0.05 в 90-дневном окне
+```
+
+---
+
+### Hypothesis Card H-002: LLM Quality Acceptability (F1 assumption)
+
+```markdown
+# Hypothesis: H-002 — LLM Quality Acceptable для HR Use Case
+
+**We believe** GPT-4 level LLMs (primary OpenAI GPT-4-Turbo, fallback Anthropic Claude 3.5)
+**For** 30-minute 1:1 performance conversations in English
+**Will generate summaries** acceptable to managers >85% of the time
+  (Acceptable = manager approves без major edits (< 50% content changed))
+**We'll know it's true when** в Wizard-of-Oz test:
+  - Blind quality rating from managers: ≥ 4.0 out of 5.0 average (across N ≥ 100 meetings)
+  - Hallucination rate: < 5% of summaries contain factually wrong info
+  - Misattribution rate: < 3% of action items assigned to wrong person
+  **within** 4 weeks of Wizard-of-Oz testing
+**Because**
+  (1) Recent LLM benchmarks on summarization (Anthropic HELM, OpenAI evals) показывают 87-92% acceptance
+  (2) Our manual QA на 30 sample prompts achieved 90% acceptable rate
+  (3) Adjacent use cases (Fireflies.ai, Gong) report >80% customer satisfaction — lower bar but similar
+
+## Базовый уровень
+- Внутреннее QA тестирование промптов: 90% приемлемо (N=30 ручных тестов)
+- Нет внешнего базового уровня конкретно для HR-разговоров
+- Уверенность: Средняя (ограниченные HR-специфичные данные)
+
+## Порог
+- Цель: **≥85% приемлемость** в Wizard-of-Oz
+- Обоснование:
+  - Ниже 85% → доверие пользователей рушится, фича становится обузой
+  - 85-90% = готово к производству
+  - >90% = превышает ожидания
+
+## Guardrails
+- P95 задержка генерации ≤ 60с (ограничение пользовательского опыта)
+- Стоимость одного summary ≤ $0.10 (жизнеспособность — допущение FP5)
+- Нулевая утечка данных к LLM-провайдеру (проверено через аудит провайдера)
+- Нулевое обучение на данных клиентов (контрактное + техническое соблюдение)
+
+## Сегменты для анализа
+- Длительность встречи (короткая 5-15 / стандартная 15-45 / длинная 45-120 мин) — ожидаем средняя лучшая
+- Тип разговора (планирование / обратная связь / сложный разговор / catch-up) — ожидаем вариативность
+- Отрасль клиента (tech / услуги / производство) — ожидаем tech наивысший
+- Языковой состав (чистый английский / частично не-английский) — исключить не-английский для MVP
+
+## Последствия нулевой гипотезы
+Если приемлемость < 85%:
+- **<70%:** Убить фичу. LLM не готов для HR сценария, ждать 6-12 месяцев.
+- **70-80%:** Запустить с обязательным слоем человеческого контроля (feature flag). Снижает ценностное предложение, но запускается.
+- **80-85%:** Обширный prompt engineering + итерация до запуска. Задержка 2-4 недели.
+
+## Связанные эксперименты
+- **Exp EXP-020: Wizard-of-Oz тест** — 20 бета-менеджеров, 100+ встреч итого, слепая оценка качества
+- Exp EXP-021: Итерация prompt engineering (A/B разные промпты, измерить приемлемость)
+
+## Уровень уверенности: Средний (60%)
+## Инвестиции в риске: $200K engineering + 10 недель задержки при опровержении
+```
+
+---
+
+### Hypothesis Card H-003: Manager Adoption Rate (V2 assumption)
+
+```markdown
+# Hypothesis: H-003 — Manager Adoption Rate Post-Launch
+
+**We believe** managers в AI-tier upgraded accounts
+**Will** adopt AI summarization at **≥60% weekly usage rate** within 90 days of account upgrade
+  (Adoption = ≥1 AI-summarized 1:1 per week)
+**Because**
+  (1) Discovery: 6 of 8 managers expressed direct desire for this feature
+  (2) Removes 3-4 hrs/week admin burden — very high individual incentive
+  (3) Onboarding checklist design will guide first-use в <7 days
+
+## Базовый уровень
+- Н/П (фича не существовала). Аналог: средний adoption существующих фич Team Tier 55% еженедельного использования за 90 дней.
+- Уверенность: Средняя
+
+## Порог
+- Цель: **60% еженедельный adoption** к Дню 90
+- Stretch: 75%
+- Обоснование:
+  - Ниже 50% — фича не удерживает; риск оттока
+  - 50-60% — приемлемо, но требует улучшения
+  - 60-75% — здорово
+  - 75%+ — определяет категорию
+
+## Guardrails
+- Обратный adoption (отказ) < 10% — пользователи, попробовавшие и остановившиеся
+- NPS стабильный или улучшается
+- Completion rate action items растёт у тех, кто внедрил (дополнительный сигнал)
+
+## Сегменты для анализа
+- Размер команды менеджера (малая 3-5 / средняя 6-10 / большая 11+ подчинённых) — ожидаем средняя/большая наивысший
+- Стаж менеджера в роли (<2 года / 2-5 / 5+) — ожидаем новые менеджеры наивысший (новинка помогает)
+- Отрасль / роль (tech / non-tech) — ожидаем tech наивысший
+- Время месяца (сезон оценок vs обычный) — должно быть стабильным
+
+## Последствия нулевой гипотезы
+Если adoption < 60%:
+- **<40%:** Провал фичи — пересмотреть дизайн, рассмотреть крупную переработку
+- **40-50%:** Требует итерации, вероятно проблемы с онбординговым потоком
+- **50-60%:** Почти достигнуто, итерировать онбординг + напоминания
+
+## Связанные эксперименты
+- Exp EXP-025: A/B тест наличия онбордингового чеклиста (с vs без)
+- Exp EXP-026: A/B тест тайминга первого напоминания о встрече
+- Текущий: когортный анализ по месяцу активации
+
+## Уверенность: Средняя (65%)
+```
+
+---
+
+### Hypothesis Card H-004: Enterprise Tier Dashboard Upgrade Driver (V3 assumption)
+
+```markdown
+# Hypothesis: H-004 — Aggregate Dashboard Drives Enterprise Tier Upgrades
+
+**We believe** showing VP HR / CPO buyers aggregate dashboard (cadence + health score + benchmarks)
+**Will** drive **5 Enterprise tier upgrades** (to $50+/seat tier) within Q2
+**Because**
+  (1) 4 of 4 buyer interviews explicitly asked для dashboard visibility
+  (2) 8 of 10 enterprise prospects в Q1 asked «do you have 1:1 analytics?» — current blocker
+  (3) Existing mid-market → enterprise conversion rate 0% (no offering); we're creating demand
+
+## Базовый уровень
+- Текущие конверсии Enterprise тира из mid-market: 0/квартал (нет функции дашборда)
+- Текущий Enterprise тир = устаревшее ценообразование, 10 аккаунтов дедовских прав
+- Уверенность: Средняя (сильный сигнал покупателя, но новое движение)
+
+## Порог
+- Цель: **5 обновлений Enterprise тира** к 30 июня
+- Stretch: 10
+- Обоснование:
+  - 5 = обязательство OKR KR2.1
+  - На основе 80 подходящих mid-market аккаунтов × 6% конверсия (консервативно) = 5
+
+## Guardrails
+- Нет каннибализации существующих Enterprise тир аккаунтов (не должны снижаться)
+- Размер Enterprise сделки не разбавляется (поддерживается средний ACV)
+- Команда продаж не тратит непропорциональное время (мониторинг времени-на-сделку)
+
+## Сегменты для анализа
+- Размер аккаунта (100-299 / 300-499 / 500+ сотрудников) — ожидаем 300+ наивысшая конверсия
+- Текущий тир расходов (Team vs устаревший Enterprise) — Team с >50 местами наиболее вероятный
+- Отрасль (регулируемая / нерегулируемая) — регулируемая ниже (барьеры проверки соответствия)
+
+## Последствия нулевой гипотезы
+Если обновлений < 5:
+- **0-2:** Дашборд недостаточно ценен для тирной премии. Пересмотреть область фичи или ценообразование.
+- **3-4:** Почти достигнуто — продлить срок на 30 дней, улучшить sales motion
+- **5+:** Успех, расширить roadmap фич Enterprise тира
+
+## Связанные эксперименты
+- Exp EXP-030: 3 сессии concierge с design partner (качественный + намерение конверсии)
+- Exp EXP-031: A/B вариации питча команды продаж (питч сначала данные vs питч сначала ROI)
+
+## Уверенность: Средняя (60%)
+```
+
+---
+
+### Обзор портфеля карточек гипотез
+
+| ID | Гипотеза | Уверенность | Метод валидации | Статус | Зависимость запуска |
+|----|-----------|:----------:|-------------------|:------:|-----------------|
+| H-001 | WTP $8/место премия | 75% | Landing page + разговоры с клиентами | ⏳ До запуска | Запустить ценовой тир |
+| H-002 | Качество LLM ≥85% | 60% | Wizard-of-Oz N=100+ | ⏳ Неделя 3-6 | Запустить AI фичу |
+| H-003 | 60% еженедельный adoption | 65% | Когортный анализ после запуска | 🔜 После запуска | Итерировать онбординг |
+| H-004 | 5 обновлений Enterprise | 60% | Сессии design partner + A/B продаж | ⏳ До запуска | Dashboard MVP |
+
+### Дерево решений на основе результатов
+
+```
+H-002 (качество LLM)
+  ├── >85% приемлемо → ЗЕЛЁНЫЙ СВЕТ для MVP запуска
+  ├── 70-85% → Запустить с слоем человеческого контроля, итерировать промпты
+  └── <70% → Задержка 2-3 месяца, ждать улучшения LLM
+
+H-001 (WTP)
+  ├── >8% конверсия → Подтверждено, масштабировать GTM
+  ├── 5-8% → Почти достигнуто, итерировать ценообразование / сообщения
+  └── <5% → Ценообразование неверное, пересмотреть цену или unbundle
+```
+
+> **Урок hypothesis:** 4 hypothesis cards cover **different types of risk**: value (H-001, H-004), feasibility (H-002), usability (H-003). Each с own validation method (landing page, Wizard-of-Oz, cohort analysis, design partner). The **null hypothesis consequences** section — что often skipped — делает кit actionable: «if <X, do Y». Без этого hypothesis cards = wishful thinking. Каждый card links назад к assumption-map risk score, закрывая discovery-to-validation loop.