Discovery: интервью, JTBD, проверка проблемы

Discovery — это не «сходить поговорить с парой клиентов перед началом разработки». Это дисциплина принятия решений в условиях, где вы почти наверняка ошибаетесь, и задача — узнать об ошибке за неделю, а не за квартал.

В обзорной статье трека мы посчитали экономику роли: доля идей, которые действительно улучшают целевую метрику, держится около 1/3 даже у зрелых команд. Discovery — это машинка, которая отсеивает две трети до того, как они превратятся в код.

Ниже — от первых принципов: почему опрос «нужна ли вам такая фича?» систематически врёт, как устроено интервью, которое не врёт, что на самом деле утверждает JTBD, как превратить десять расшифровок в приоритизированный список проблем и как перепроверить их числами.

1. Зачем: цена решения, принятого не в тот момент

1.1. Стоимость информации падает во времени, стоимость ошибки растёт

Возьмём фичу стоимостью c = 8 человеко-недель. Решение «делать» принимается в момент t₀. Если гипотеза неверна, вы узнаете об этом:

Ключевая асимметрия: последняя строка никогда не обнуляется. Выпущенная и никому не нужная фича продолжает стоить денег вечно — её тестируют при каждом релизе, она усложняет интерфейс, её нельзя выключить, потому что «ей пользуются два крупных клиента».

Отсюда практический принцип, который в разных формулировках повторяют Марти Каган (SVPG, «Product Discovery») и Тереза Торрес (producttalk.org):

Discovery — это не этап перед разработкой. Это параллельный поток, который никогда не останавливается, и его продукт — не документ, а решения.

1.2. Четыре риска, и почему интервью закрывает только один

Каган раскладывает риск идеи на четыре независимых:

Интервью и JTBD-исследование бьют по риску ценности — самому дорогому и самому часто игнорируемому. Остальные три требуют других инструментов, и путать их нельзя: десять восторженных интервью ничего не говорят о том, окупится ли фича (это юнит-экономика) и получится ли её сделать за спринт.

1.3. Discovery как поиск, а не как сбор требований

Разница между «сбором требований» и discovery — в направлении причинности.

• Сбор требований: решение уже принято кем-то (заказчиком, CEO, крупным клиентом), задача продакта — записать его без искажений. Успех = точность записи.
• Discovery: решение ещё не принято, известна только желаемая перемена в поведении (outcome). Задача — найти множество проблем, мешающих этой перемене, и выбрать, какую атаковать. Успех = отброшенные варианты.

Если вы не отбрасываете варианты, вы не занимаетесь discovery — вы занимаетесь транскрибированием чужих решений.

2. Каркас: дерево возможностей

Тереза Торрес предложила структуру, которая не даёт скатиться в «хаотичный сбор пожеланий» — opportunity solution tree (producttalk.org/opportunity-solution-tree).

Правила, которые делают дерево рабочим, а не декоративным:

1. Корень — исход, а не фича. «Увеличить активацию до 40%», не «сделать онбординг».
2. Возможности формулируются словами пользователя и всегда как проблема/потребность, а не как решение. «Нужен экспорт в Excel» — это решение, замаскированное под проблему; настоящая возможность за ним обычно «мне нужно показать отчёт руководителю, который не заходит в ваш продукт».
3. Сравнивать решения можно только внутри одной возможности. Сравнивать «улучшить онбординг» с «добавить SSO» бессмысленно — это разные ветки. Формальные методы сравнения — в статье о приоритизации.
4. Одна возможность за раз. Выбрали ветку — довели до эксперимента — вернулись.

Дерево — это ещё и защита от главной политической проблемы продакта: когда приходит «сделай вот эту фичу», вы не спорите, а спрашиваете «какую возможность она закрывает и почему она лучше двух других в этой же ветке».

3. Почему прямой вопрос не работает

3.1. Три механизма искажения

Вежливость. Люди не хотят вас расстраивать. На вопрос «полезная идея?» ответ «да» стоит собеседнику ноль и избавляет от неловкости. Роб Фицпатрик называет весь класс таких ответов «комплиментами» и предлагает считать их шумом, а не данными («The Mom Test»).

Плохая интроспекция о будущем. Человек честно не знает, что он сделает. Намерение и поведение расходятся систематически — разрыв «intention–behaviour» измеряется десятилетиями в социальной психологии; в продуктовом контексте это выглядит как «конечно, я бы платил 10 $» → конверсия 0.4%.

Вопрос как подсказка. «Насколько вам мешает, что нет тёмной темы?» создаёт проблему в момент задавания. До вопроса человек о ней не думал; после — у него есть мнение, и он его выскажет.

3.2. Правило: прошлое вместо будущего, конкретика вместо обобщения

Единственный надёжный источник — то, что человек уже сделал. Прошлое поведение не нужно предсказывать: оно случилось, у него есть дата, обстоятельства и потраченные деньги.

Три сигнала, что проблема настоящая, а не выдуманная (Фицпатрик): человек уже тратит на неё деньги, уже построил костыль (таблица, скрипт, отдельный человек в штате), уже пробовал и бросил чужие решения. Костыль — самый сильный сигнал: его строят только тогда, когда боль превышает стоимость постройки.

3.3. Что делать с «комплиментами»

Комплимент нельзя записать в заметки как факт — его нужно обменять на конкретику:

• «Классная идея!» → «Спасибо. А когда у вас последний раз возникала эта ситуация?»
• «Мы бы точно взяли» → «Что должно произойти внутри компании, чтобы бюджет одобрили? Кто подписывает? Когда ближайшее окно?»
• «Обязательно напишите, когда будет готово» → «Давайте зафиксируем предзаказ / пилот на две недели / встречу с вашим финансистом».

Каждый шаг — это запрос обязательства (времени, репутации, денег). Отказ от обязательства при восторженных словах — это отрицательный результат, и это отличный результат: вы узнали правду за 40 минут.

4. Интервью: как оно устроено

4.1. Ход разговора

Обратите внимание, чего в диаграмме нет: демонстрации продукта, вопроса «а если бы мы сделали X», презентации. Всё это переводит разговор из режима «респондент вспоминает» в режим «респондент оценивает» — и включает вежливость.

4.2. Воронка вопросов

Внутри каждой темы двигайтесь сверху вниз, никогда наоборот:

1. Открывающий      «Расскажите, как вы это делаете сейчас»
2. Эпизодический    «Когда это было в последний раз? Что случилось?»
3. Уточняющий       «И что вы сделали дальше? Кому написали?»
4. Причинный        «Почему именно так, а не через отчёт в системе?»
5. Оценочный        «Насколько это было проблемой по сравнению с ...?»

Правило пяти секунд молчания: после ответа сделайте паузу. Самая ценная часть ответа — вторая, она приходит после того, как человек закончил социально приемлемую формулировку.

4.3. Роли и гигиена

• Два человека на интервью: один ведёт, второй пишет дословные цитаты. Ведущий не может одновременно слушать и конспектировать без потерь.
• Дословность важнее пересказа. «Клиенту не хватает аналитики» — бесполезно. «Я каждый понедельник в семь утра выгружаю CSV и пересчитываю руками, потому что начальник смотрит только PDF» — из этого рождаются решения.
• Запись + расшифровка. Память искажает в сторону вашей гипотезы; это подтверждение задним числом, а не исследование.
• Разбор в тот же день, максимум на следующий: 3 главные цитаты, 1 сюрприз, 1 опровергнутое ожидание.

4.4. Сколько интервью нужно

Два разных вопроса, которые постоянно путают.

Вопрос А: «сколько нужно, чтобы найти проблемы?» Здесь работает логика насыщения. Классическая оценка Нильсена для юзабилити: пять пользователей находят ~85% проблем интерфейса при вероятности обнаружения одной проблемы p ≈ 0.31 (NN/g). Формула: доля найденных проблем = 1 − (1 − p)ⁿ. Для проблемных интервью насыщение обычно наступает на 8–15 разговорах в одном сегменте; в качественной социологии типичная оценка — 9–17 интервью до насыщения.

Вопрос Б: «сколько нужно, чтобы оценить, у скольких людей эта проблема есть?» Здесь интервью не работают в принципе — нужен опрос или данные. Никакие 20 интервью не дадут вам «проблема у 40% пользователей»; они дают перечень проблем, а не доли.

Кривая насыщения считается тривиально — и её стоит рисовать по ходу исследования, чтобы решение «остановиться» было основано на данных, а не на усталости:

"""Кривая насыщения: сколько новых кодов приносит каждое следующее интервью."""
from typing import Iterable


def saturation_curve(coded: Iterable[set[str]]) -> list[tuple[int, int, int]]:
    """coded — список множеств кодов (тем), извлечённых из каждого интервью
    в хронологическом порядке.

    Возвращает список (номер интервью, новых кодов, всего кодов).
    Сложность: O(sum |Sᵢ|) по времени, O(|U|) по памяти, где U — все коды.
    """
    seen: set[str] = set()
    out: list[tuple[int, int, int]] = []
    for i, codes in enumerate(coded, start=1):
        new = codes - seen
        seen |= codes
        out.append((i, len(new), len(seen)))
    return out


interviews = [
    {"ручной_excel", "отчёт_для_руководителя", "нет_прав_доступа"},
    {"ручной_excel", "дубли_данных", "отчёт_для_руководителя"},
    {"нет_прав_доступа", "ручной_excel", "срочность_по_понедельникам"},
    {"ручной_excel", "отчёт_для_руководителя", "дубли_данных"},
    {"ручной_excel", "срочность_по_понедельникам"},
    {"ручной_excel", "отчёт_для_руководителя"},
]

for n, new, total in saturation_curve(interviews):
    bar = "#" * new
    print(f"интервью {n}: новых кодов {new} (всего {total}) {bar}")

# интервью 1: новых кодов 3 (всего 3) ###
# интервью 2: новых кодов 1 (всего 4) #
# интервью 3: новых кодов 1 (всего 5) #
# интервью 4: новых кодов 0 (всего 5)
# интервью 5: новых кодов 0 (всего 5)
# интервью 6: новых кодов 0 (всего 5)
# → три интервью подряд без новых кодов: насыщение по этому сегменту достигнуто

Важная оговорка: насыщение достигается внутри сегмента. Если вы поговорили с 15 менеджерами среднего звена и остановились, вы ничего не знаете о владельцах малого бизнеса — там кривая начнётся заново.

4.5. Кого звать и как не испортить выборку

• Сегмент определяется поведением, а не демографией. «Команды, которые за последний месяц создали ≥2 проекта и хотя бы раз выгружали CSV» — рабочее определение. «Маркетологи 25–40 лет» — не рабочее.
• Ошибка выживших — главный убийца качества: вы говорите только с активными пользователями продукта. Обязательно добавляйте отвалившихся и тех, кто не купил. Причина отказа информативнее причины покупки.
• Не платите слишком много. Крупное вознаграждение приводит профессиональных респондентов, которые дадут вам любые ответы. Лучший стимул — искренний интерес к их проблеме плюс обещание поделиться результатами.
• Не зовите знакомых и дружественных клиентов на проверку ценности: они максимально вежливы и максимально нерепрезентативны.

Карта того, какой метод что вообще способен рассказать:

Правило чтения карты: гипотезы рождаются слева, подтверждаются справа сверху. Интервью не доказывают ничего, кроме существования явления; аналитика и эксперименты не объясняют ничего, кроме масштаба.

5. Jobs To Be Done

5.1. Что JTBD утверждает на самом деле

Основной тезис: люди не «покупают продукты», они нанимают решение, чтобы продвинуться в конкретной ситуации к желаемому результату (Клейтон Кристенсен, «Know Your Customers’ Jobs to Be Done», HBR, 2016).

Из этого следуют два практических вывода, ради которых теория и нужна.

Вывод 1: конкурент — не тот, кто в вашей категории. Настоящий конкурент — всё, что человек может нанять на ту же работу, включая «ничего не делать» и «сделать руками». У Slack конкурент — не Teams, а совещание и почта. У онлайн-курса — не другой курс, а YouTube, ментор на работе и прокрастинация.

Вывод 2: категории пользователей по демографии почти бесполезны. Один и тот же человек в разных ситуациях нанимает разные продукты на разные работы. Стабильна не персона, а связка «ситуация + мотивация + желаемый результат».

5.2. Две школы, и почему их путают

Обе школы полезны, но отвечают на разные вопросы. Не пытайтесь мерить силы прогресса в анкете и не пытайтесь вытащить нарратив из опроса на 500 человек.

5.3. Формат job story

Классические user story («как маркетолог, я хочу…») теряют главное — контекст. Job story (формат Intercom) начинается с ситуации:

Когда <ситуация>,
я хочу <мотивация>,
чтобы <ожидаемый результат>.

Плохо: «Как менеджер, я хочу дашборд, чтобы видеть метрики». Хорошо: «Когда в понедельник утром руководитель просит статус по проектам, я хочу за 5 минут собрать цифры, которым доверяю, чтобы не выглядеть неподготовленным и не тратить вечер воскресенья».

Из первого варианта следует «сделать дашборд». Из второго — минимум четыре разных решения: дашборд, еженедельная рассылка в 8:00, экспорт-ссылка для руководителя, Slack-бот. И решения теперь можно сравнивать по тому, насколько хорошо они закрывают ситуацию. Дальше эти формулировки становятся входом для требований и user stories.

5.4. Четыре силы прогресса

Боб Моэста описал механику переключения: человек меняет решение, только когда сумма сил «за» перевешивает сумму сил «против».

Практический смысл: продуктовая работа — не только усиливать PULL (рассказывать, как у нас хорошо). Чаще выигрыш дают снятие тревоги и разрушение привычки:

Практически всегда самая недооценённая клетка — тревога. Команды вкладывают в маркетинг (Pull), когда воронка ломается о «страшно переносить данные».

5.5. Switch-интервью: таймлайн покупки

Ключевой инструмент JTBD — восстановление хронологии решения, а не обсуждение продукта.

Что даёт этот таймлайн, чего не даёт обычное интервью:

• Триггерное событие — точка, где формируется спрос. Это готовый таргетинг: если люди начинают искать после смены руководителя, вы знаете, кому и когда показываться.
• Слова активного поиска — это ваши поисковые запросы и заголовки на лендинге. Люди ищут не «платформа управления проектами», а «как быстро собрать статус по проектам».
• Отброшенные варианты — реальная карта конкурентов, включая «остаться в Excel».
• «От чего отказались» — то, что продукт вытеснил; это и есть измеримая ценность.

6. От расшифровок к решениям: синтез

Самый недооценённый этап. Десять расшифровок без синтеза — это ноль знания; они лежат в Notion, и каждый помнит из них то, что подтверждает его позицию.

6.1. Кодирование

Тематический анализ в три прохода:

1. Открытое кодирование: размечаете каждую содержательную фразу коротким кодом близко к словам респондента (руками_сводит_в_excel, боится_что_данные_разъедутся). Никакой интерпретации на этом шаге.
2. Осевое кодирование: группируете коды в темы (костыли_вокруг_отчётности).
3. Отбор: темы, встречающиеся у ≥N респондентов и связанные с вашим исходом, становятся возможностями в дереве.

Простой инструмент, чтобы увидеть картину целиком, — матрица «код × респондент». Считать её вручную бессмысленно, а кода тут на двадцать строк:

"""Матрица код×респондент: частота, покрытие сегментов и кандидаты в возможности."""
from collections import defaultdict

# после кодирования: кто какие коды упоминал и из какого сегмента
transcripts = {
    "R1": {"segment": "SMB", "codes": {"ручной_excel", "отчёт_руководителю", "страх_миграции"}},
    "R2": {"segment": "SMB", "codes": {"ручной_excel", "дубли_данных"}},
    "R3": {"segment": "ENT", "codes": {"нет_прав_доступа", "отчёт_руководителю", "страх_миграции"}},
    "R4": {"segment": "SMB", "codes": {"ручной_excel", "отчёт_руководителю"}},
    "R5": {"segment": "ENT", "codes": {"нет_прав_доступа", "аудит_изменений"}},
    "R6": {"segment": "SMB", "codes": {"ручной_excel", "отчёт_руководителю", "дубли_данных"}},
}

freq: dict[str, int] = defaultdict(int)
by_segment: dict[str, set[str]] = defaultdict(set)
for rid, t in transcripts.items():
    for code in t["codes"]:
        freq[code] += 1
        by_segment[code].add(t["segment"])

n = len(transcripts)
print(f"{'код':<22}{'упом.':>6}{'доля':>8}{'сегменты':>14}")
for code, cnt in sorted(freq.items(), key=lambda kv: -kv[1]):
    segs = ",".join(sorted(by_segment[code]))
    print(f"{code:<22}{cnt:>6}{cnt / n:>8.0%}{segs:>14}")

# код                    упом.    доля      сегменты
# отчёт_руководителю         4     67%       ENT,SMB
# ручной_excel               4     67%           SMB
# страх_миграции             2     33%       ENT,SMB
# дубли_данных               2     33%           SMB
# нет_прав_доступа           2     33%           ENT
# аудит_изменений            1     17%           ENT
#
# Сложность: O(Σ|codes|) по времени, O(|codes| + |segments|) по памяти.

Читать это надо так: отчёт_руководителю встречается в обоих сегментах — кандидат в «общую» возможность. нет_прав_доступа живёт только в ENT — это возможность для конкретного сегмента, и решение будет другим.

Критическое предупреждение. Столбец «доля» здесь — доля среди тех, кого вы позвали, а не среди пользователей. При n = 6 и неслучайной выборке 67% не значат ничего, кроме «встречается часто у этих шестерых». Использовать это число в презентации для руководства как «у 67% пользователей проблема с Excel» — это подлог. Проценты по интервью — эвристика для себя, не аргумент для других.

6.2. Приоритизация возможностей

Когда возможностей набралось два десятка, нужен способ выбрать. Быстрая версия — двумерная карта: как часто ситуация случается × насколько она болезненна.

Более строгий вариант из ODI — opportunity score Ульвика. Респондентов просят оценить по 10-балльной шкале важность результата (I) и удовлетворённость текущим решением (S); возможность тем больше, чем важнее и хуже удовлетворено:

opportunity = I + max(0, I − S)

Смысл формулы: важное и плохо решённое (I=9, S=3 → 15) обгоняет важное и уже хорошо решённое (I=9, S=8 → 10) и неважное (I=3, S=1 → 5). Значения выше ~12 обычно считают недообслуженными потребностями. Разбор шкал и других формул сравнения — в статье о приоритизации.

7. Проверка проблемы числами

Интервью говорят, что явление существует. Чтобы понять масштаб, нужны данные. Это самый пропускаемый шаг discovery — и самый дешёвый: обычно данные уже есть.

7.1. Ищите следы костыля в логах

Если респонденты сводят данные руками в Excel, в продукте останется след: повторяющиеся выгрузки, одни и те же фильтры, работа по понедельникам утром.

-- Сколько аккаунтов регулярно выгружают CSV — след ручной сводки отчётов.
-- Определение "регулярно": >= 3 недель из последних 8 с хотя бы одной выгрузкой.
WITH weekly AS (
    SELECT
        account_id,
        date_trunc('week', event_ts) AS wk,
        count(*) AS exports
    FROM events
    WHERE event_name = 'report_exported'
      AND event_ts >= now() - interval '8 weeks'
    GROUP BY 1, 2
),
regular AS (
    SELECT account_id, count(*) AS active_weeks, sum(exports) AS total_exports
    FROM weekly
    GROUP BY 1
    HAVING count(*) >= 3
)
SELECT
    count(*)                                        AS accounts_with_workaround,
    (SELECT count(DISTINCT account_id) FROM events
     WHERE event_ts >= now() - interval '8 weeks')  AS active_accounts,
    round(100.0 * count(*) / nullif(
        (SELECT count(DISTINCT account_id) FROM events
         WHERE event_ts >= now() - interval '8 weeks'), 0), 1) AS share_pct,
    round(avg(total_exports), 1)                    AS avg_exports_per_account
FROM regular;

Дополнительные запросы, которые почти всегда что-то находят:

• обращения в поддержку с текстовым поиском по словам из интервью;
• отвал в конкретном шаге воронки, о котором рассказывали респонденты;
• «повторение действия N раз подряд» — почти всегда признак отсутствующей массовой операции.

Как строить такие метрики системно — в статьях о метриках и о продуктовой аналитике. Если запросы приходится писать самому и данные лежат в сыром виде — базовые понятия конвейеров описаны в треке data engineering.

7.2. Опрос: сколько людей нужно и как читать результат

Опрос отвечает ровно на один вопрос: «какая доля сегмента X сталкивается с Y». Оценка доли — это доверительный интервал, и его надо считать. Нормальное приближение врёт на малых выборках и крайних долях; используйте интервал Вилсона.

"""Доверительный интервал для доли (Вилсон) и необходимый размер выборки."""
import math

Z95 = 1.959963985


def wilson_interval(successes: int, n: int, z: float = Z95) -> tuple[float, float]:
    """Интервал Вилсона для доли. Корректен при малых n и p близких к 0/1.
    Сложность O(1)."""
    if n == 0:
        return (0.0, 1.0)
    p = successes / n
    denom = 1 + z * z / n
    centre = (p + z * z / (2 * n)) / denom
    half = z * math.sqrt(p * (1 - p) / n + z * z / (4 * n * n)) / denom
    return (max(0.0, centre - half), min(1.0, centre + half))


def sample_size(margin: float, p_expected: float = 0.5, z: float = Z95) -> int:
    """Сколько ответов нужно для полуширины интервала не больше margin.
    p=0.5 — консервативная оценка (максимум дисперсии)."""
    return math.ceil(z * z * p_expected * (1 - p_expected) / (margin * margin))


for k, n in [(8, 12), (40, 60), (200, 300), (2000, 3000)]:
    lo, hi = wilson_interval(k, n)
    print(f"{k}/{n}: p̂={k / n:.0%}, 95% CI = [{lo:.0%}, {hi:.0%}], ширина {hi - lo:.0%}")

print("нужно ответов для ±10%:", sample_size(0.10))  # 97
print("нужно ответов для ±5% :", sample_size(0.05))  # 385
print("нужно ответов для ±3% :", sample_size(0.03))  # 1068

# 8/12: p̂=67%, 95% CI = [39%, 86%], ширина 47%   ← из этого нельзя делать выводы
# 40/60: p̂=67%, 95% CI = [54%, 77%], ширина 23%
# 200/300: p̂=67%, 95% CI = [61%, 72%], ширина 11%
# 2000/3000: p̂=67%, 95% CI = [65%, 68%], ширина 3%

Первая строка — ровно та ситуация, когда команда после 12 интервью заявляет «у двух третей пользователей эта проблема». Честный интервал — от 39% до 86%: разница между «нишевая история» и «главная боль продукта». Вывод недопустим.

И отдельно: уменьшение случайной ошибки не лечит смещение выборки. Опрос на 3000 человек, разосланный только активным пользователям, даст узкий интервал вокруг неправильного числа. Точность ≠ корректность.

7.3. Проверка спроса до строительства

Когда проблема подтверждена, а решение ещё нет, спрос проверяют дешёвыми пробами:

Порядок силы сигнала: деньги > потраченное время > оставленный контакт > клик > слова. Планируйте пробу так, чтобы результат нельзя было толковать двояко: критерий успеха («≥12% из увидевших кнопку нажмут её») фиксируется до запуска. Подробно — в статье про MVP и эксперименты.

8. Гипотеза как единица работы

8.1. Формулировка

Гипотеза, которую нельзя опровергнуть, бесполезна. Рабочий шаблон:

Мы верим, что <изменение> для <сегмент, определённый поведением>
приведёт к <измеримый эффект на метрике>.
Мы поймём, что правы, если <метрика> изменится с <baseline> до <порог>
за <срок> при <объём выборки>.
Если этого не произойдёт, мы <что конкретно сделаем>.

Пример: «Мы верим, что кнопка “попросить доступ у админа” в модалке приглашения для пользователей без прав на приглашение увеличит долю команд с ≥2 участниками на 7-й день. Правы, если доля вырастет с 22% до ≥27% за 3 недели при ≥4000 команд в каждой ветке. Если нет — отказываемся от ветки “не знает, кто админ” и переходим к возможности “админ не понимает ценности”».

Последняя строка — обязательная. Без заранее описанного действия при провале команда всегда найдёт способ объяснить отрицательный результат («трафик был плохой», «надо было ярче кнопку»).

8.2. Жизненный цикл

Две дуги здесь важнее остальных:

• Опровергнута → Возможность, а не → [*]. Провалившееся решение не закрывает проблему; проблема остаётся, а вы теперь знаете о ней больше.
• Выпущено → Измерено. Без неё команда никогда не узнаёт, была ли она права — и точность прогнозов не растёт годами.

8.3. Ведите журнал решений

Минимальная запись на каждое продуктовое решение (можно yaml в репозитории, можно база в Notion — важен факт, а не инструмент):

id: OPP-2026-014
исход: активация команд, доля с 2+ участниками на 7-й день
возможность: "не может позвать коллегу — нужен админ"
свидетельства:
  интервью: [R3, R7, R11, R12]     # ссылки на расшифровки
  цитата: "я написал в общий чат, кто у нас админ, и на этом всё заглохло"
  данные: "18% команд имеют >=1 отклонённое приглашение за 30 дней"
гипотеза: "кнопка 'попросить доступ' поднимет долю команд 2+ с 22% до 27%"
тест: A/B, 3 недели, 4000 команд на ветку
результат: "22.4% -> 23.1%, p=0.21 — не подтверждена"
решение: "ветка закрыта, переходим к 'админ не понимает ценности'"
дата: 2026-05-14

Через год такой журнал становится самым ценным активом команды: он показывает, какие классы гипотез у вас систематически не сбываются, и калибрует интуицию. Заодно он прекращает споры «мы же это уже пробовали» — пробовали, вот запись, вот цифры.

9. Как это выглядит в проде

Ритм вместо проектов. Тереза Торрес формулирует минимальный порог непрерывного discovery: минимум одно интервью в неделю, которое проводит продуктовая тройка (продакт, дизайнер, инженер), а не отдельный «отдел исследований» («Continuous Discovery Habits»). Причина в том, что знание, полученное исследователем и переданное документом, теряет ~90% полезной части: детали, интонацию, сомнения.

Постоянный поток респондентов. Разовый набор занимает недели и убивает регулярность. Рабочие способы: авто-приглашение внутри продукта после релевантного действия («вы только что третий раз выгрузили отчёт — поговорим 20 минут?»), очередь из продаж и поддержки, панель постоянных участников.

Репозиторий исследований. Расшифровки, теги, цитаты в одном поисковом месте. Без него организация переспрашивает одно и то же каждые полгода и «открывает» уже известные проблемы.

Инженеры на интервью. Самый дешёвый апгрейд качества решений: инженер, слышавший боль своими ушами, предлагает варианты, до которых продакт не додумается, и перестаёт спорить о приоритетах.

Discovery не останавливает delivery. Это два параллельных потока: пока команда строит подтверждённое, discovery готовит следующее. Если discovery — «фаза перед спринтом», он первым и вылетит под давлением сроков.

10. Типичные ошибки

1. Питчить вместо слушать. Как только вы рассказали идею, интервью закончилось — дальше вы слышите вежливость.
2. Спрашивать о будущем. «Будете пользоваться?» — данные нулевой ценности.
3. Считать проценты по интервью. «6 из 9 сказали» — это не 67% рынка (см. §7.2).
4. Говорить только с довольными. Отвалившиеся и не купившие знают больше.
5. Один сегмент под видом всех. Насыщение внутри сегмента не переносится на другие.
6. Записывать выводы, а не цитаты. «Нужна аналитика» — потерянная информация.
7. Discovery как разовая фаза. Через два месяца выводы протухают, а команда продолжает ссылаться на них ещё год.
8. Подтверждающий поиск. Вы уже решили строить фичу и ищете, кто это одобрит. Противоядие: до интервью письменно зафиксировать, какой ответ вас переубедит.
9. Ловушка «клиент попросил». Просьба — это уже решение клиента; ваша работа — вернуться на шаг назад, к его ситуации.
10. Игнорировать данные, которые уже есть. Половина гипотез проверяется одним SQL за час — до всяких интервью.
11. Оценивать discovery по количеству интервью. Метрика — количество изменённых решений, а не проведённых разговоров.
12. Отсутствие критерия провала. Гипотеза без заранее записанного порога всегда «частично подтверждается».

11. Мини-итог

• Discovery закрывает риск ценности — самый дорогой из четырёх; остальные требуют других инструментов.
• Прямые вопросы о будущем и о мнении систематически врут. Спрашивайте о прошлом поведении: что делали, когда, сколько заплатили, какой костыль построили.
• Комплимент — не данные. Обменивайте его на обязательство: время, деньги, репутация.
• JTBD переводит фокус с персоны на ситуацию + мотивацию + результат, находит настоящих конкурентов и через четыре силы объясняет, почему люди не переключаются. Чаще всего мешает тревога, а не отсутствие функций.
• Синтез обязателен: кодирование → темы → возможности в дереве. Проценты по интервью — эвристика для себя, не аргумент для других.
• Масштаб проблемы проверяется данными и опросом с доверительным интервалом, а не количеством интервью.
• Гипотеза = изменение + сегмент + метрика + порог + срок + что сделаем при провале.
• Ритм важнее размаха: одно интервью в неделю всей тройкой годами бьёт квартальное исследование на 40 человек.

Источники

• Rob Fitzpatrick, «The Mom Test» — momtestbook.com
• Teresa Torres, «Continuous Discovery Habits» и дерево возможностей — producttalk.org
• Marty Cagan, «Inspired»; четыре риска и product discovery — svpg.com/product-discovery
• Clayton Christensen et al., «Know Your Customers’ Jobs to Be Done», HBR 2016 — hbr.org
• Bob Moesta, «Demand-Side Sales 101» — demandsidesales.com
• Alan Klement, «What is Jobs to be Done» — jtbd.info
• Tony Ulwick, Outcome-Driven Innovation и opportunity score — strategyn.com
• Steve Blank, «The Four Steps to the Epiphany» / customer development — steveblank.com
• Ash Maurya, «Running Lean» — leanstack.com
• Erika Hall, «Just Enough Research» — abookapart.com
• NN/g, «Why You Only Need to Test with 5 Users» — nngroup.com
• NN/g, «When to Use Which User-Experience Research Methods» — nngroup.com
• Strategyzer, Value Proposition Canvas — strategyzer.com
• E. B. Wilson, «Probable Inference, the Law of Succession, and Statistical Inference», JASA 1927 — происхождение интервала Вилсона

Что дальше

Проблема найдена и подтверждена. Следующий вопрос — как измерять, что решение работает: какие метрики выбрать, что такое North Star и почему без юнит-экономики любая продуктовая гипотеза остаётся наполовину непроверенной.

Продуктовые метрики: AARRR, North Star, unit-экономика