--- 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