CustDev: от гипотезы и интервью до проверки решения

CustDev, или Customer Development, — работа с предположениями о клиентах и бизнесе: выяснить, у кого есть задача, как её решают сейчас, что ограничивает выбор и какой результат люди готовы проверять. Интервью — один из инструментов. Полный цикл заканчивается решением о следующем эксперименте, изменении гипотезы или отказе от неё.

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

Разберём весь цикл на вымышленном сервисе переноса занятий. Все интервью, организации, числа и результаты экспериментов ниже придуманы; это учебный пример, а не результаты клиентов Текстослава.

Начните с решения, для которого не хватает данных

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

В одной фразе смешаны минимум четыре гипотезы:

Общая логика «гипотеза → эксперимент → подтверждение или пересмотр» лежит в основе Customer Discovery у Стива Бланка. В практической работе важно не объявлять ответ на первую строку подтверждением всех четырёх.

Для первого этапа решение команды узкое: какой участок переноса проверять — выбор времени или согласование участников? Разработка полного продукта пока не требуется для ответа на этот вопрос.

Задайте границы аудитории и найдите противоположные случаи

«Все образовательные организации» — слишком широкая аудитория для одного вывода. В учебном исследовании сравним два контекста:

• школа, где координатор согласует перенос между преподавателем и учеником;
• самостоятельный преподаватель, который договаривается со своим учеником напрямую.

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

Для первого разговора нужен человек, лично организовавший перенос за последний месяц. Для изучения оплаты отдельно понадобится владелец бюджета. Пользователь, покупатель и участник согласования могут быть разными людьми.

Ищите подходящих участников в нескольких доступных каналах: среди текущих контактов, в профессиональном сообществе, через нейтральное приглашение. В листе рекрутинга фиксируйте канал, роль, недавний опыт, критерий включения и отказ. Это позволяет увидеть перекос: например, если все участники — знакомые сторонники вашей идеи. Ограничения исследовательских панелей и важность правильного отбора разобраны в NN/G.

Не требуйте от кандидата заранее подтвердить проблему. Скринер спрашивает: «Какие изменения расписания вы лично оформляли недавно?» и «Кто участвовал в последнем переносе?», а не «Часто ли вам приходится страдать из-за неудобных чатов?». Для сравнения полезен и подходящий координатор, у которого всё прошло без повторной работы.

Подготовьте критерии пересмотра до интервью

Для этого учебного исследования команда заранее записывает:

Если координаторы описывают свободное время как уже найденное, а трудность возникает в подтверждении, пересматриваем гипотезу автоматического подбора. Если задача решается текущим инструментом без существенных последствий, выясняем условия такого процесса. Если проблемы различаются между группами, не объединяем их в одно предложение.

Это правила интерпретации, а не статистический тест. Шесть разговоров в примере — объём учебного материала; они не гарантируют достаточности исследования. В качественных интервью размер зависит от разнообразия опыта и глубины темы, а не от универсальной квоты. NN/G объясняет, почему число интервью не даёт само по себе права обобщать результат на рынок.

После каждого разговора отмечайте, появились ли новое условие, альтернативное объяснение, незнакомая роль или противоречие. Если да, уточняйте отбор следующего участника. Отсутствие нового названия темы ещё не означает, что её причины уже понятны.

Проведите интервью о конкретном опыте

Для первого этапа не начинайте с презентации сервиса. Восстановите недавний перенос:

1. Кто и почему попросил изменение?
2. Какой шаг участник сделал первым?
3. Как искали вариант и получали ответы?
4. Когда стало понятно, что перенос завершён?
5. Что пришлось повторить и к чему это привело?
6. Какие средства уже использовали и почему сохранили их?
7. Был ли похожий случай, где всё прошло иначе?

Связывайте уточнение с ответом, а не с желательной функцией. «Вы сказали, что вернули старое время: что произошло перед этим?» помогает восстановить событие. «Значит, нужна кнопка подтверждения?» переводит участника в обсуждение вашего объяснения.

Готовый сценарий, рекрутинг и полный учебный диалог есть в руководстве по глубинному интервью. Если задача — понять, почему человек сменил инструмент, используйте JTBD-интервью: там важны история выбора, альтернативы и момент перехода.

Отдельно согласуйте запись и допустимое использование материалов. Не собирайте имена учеников и внутренние документы, если исследовательскому вопросу достаточно обезличенного описания. Если участник не помнит точное время, оставьте это неизвестным.

Разложите материал на свидетельства, интерпретации и пробелы

Учебный фрагмент:

Ирина, координатор, 12:20: «Окно во вторник я нашла сразу. Преподаватель ответил “можно”, а ученик ещё уточнял час. Я уже поменяла календарь, потом вернула старое время и снова спросила обоих».
13:10, исследователь: «Получается, вам нужен единый сервис подтверждений?»
13:18, Ирина: «Я не знаю, какой сервис. Важно не считать согласие одного человека окончательным».

Рабочий разбор:

Слова интервьюера не становятся доказательством, даже если респондент не спорит. Сохраняйте вопрос рядом с ответом. Если доступны согласованные обезличенные материалы, отмечайте, что именно удалось проверить по ним. Интервью о прошлом собирает сообщённое поведение; прямое наблюдение — другой источник. Практическую границу методов разбирает NN/G в материале о том, почему интервью могут не дать нужного ответа.

Сравните случаи, включая те, которые не поддерживают идею

Пример матрицы из шести вымышленных интервью. Единица здесь — один описанный эпизод одного участника, а не число похожих фраз.

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

Более точный итог: в двух из трёх описанных случаев координаторов возникла трудность подтверждения; третий показывает условие, при котором текущий процесс достаточен. Это наблюдение о выбранных случаях. Оно задаёт следующий вопрос: можно ли сделать предварительное согласование понятным и устойчивым, сохранив привычные каналы участников?

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

Как организовать проверяемый разбор в Текстославе

Соберите согласованные записи одной исследовательской задачи в проект. До анализа проверьте текст, названия и подписи спикеров. Для отдельного разговора в «Чате с ИИ» попросите восстановить эпизод и перечислить неизвестное; исследовательская расшифровка объясняет, как сохранить контекст для дальнейшего сравнения.

Для серии откройте «Аналитика» → «Новое исследование» → «Свой вопрос». Пример постановки:

Проверяем предположение о трудностях переноса занятий.
Сравни случаи координаторов и самостоятельных преподавателей.
Найди конкретное событие, участников, последовательность,
использованные способы, место затруднения,
последствие и признак завершения.
Сохраняй источники каждого эпизода.
Отдельно покажи случаи без повторной работы,
вопросы без ответа и гипотезы исследователя.
Не принимай предложение функции за доказанную потребность.

В «Составе данных» разделите сведения «Из записи» и интерпретации «Вывод ИИ». Для каждого поля задайте правило: например, завершение подтверждено, если участник описывает согласие обеих сторон на одно время; обещание «потом спрошу» остаётся незавершённым шагом. Эти правила относятся к учебному кейсу, а не ко всем исследованиям.

После сбора открывайте находки с цитатами в таблице. Фильтруйте по контексту, сравнивайте противоречия, проверяйте неизвестные значения. Затем создайте отчёт по выбранной базе: исходная гипотеза, поддерживающие случаи, противоположные случаи, ограничения и следующая проверка. Новый материал требует обновления результата. Доступность проектной аналитики и собственных настроек зависит от плана.

Текстослав помогает вернуться от вывода к словам участника и сопоставить записи. Решение о продукте требует ещё и сведений вне этих разговоров: поведения в эксперименте, реального процесса покупки и допустимых условий работы.

Проверьте решение отдельно от существования проблемы

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

Сначала можно проверить бумажный или кликабельный прототип: предложенное время, ответ преподавателя, ответ ученика, окончательное подтверждение, изменение ответа. Задание участнику: провести учебный перенос и объяснить, когда можно освободить старый слот. Не демонстрируйте заранее нужную последовательность, иначе проверите запоминание вашей инструкции.

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

В учебном тесте прототипа три координатора выполняли один сценарий с раздельными ответами. Двое дождались согласия обеих сторон; третий принял метку «получен ответ» за окончательное подтверждение. Команда разделила метки ответа одной стороны и общего согласования. Два новых участника прошли изменённый сценарий без этой ошибки. Это ограниченная проверка конкретного взаимодействия; она не доказывает понятность для всех ролей. Следующий пилот использует изменённый вариант.

Затем проверяется рабочий процесс на ограниченном пилоте. Это отдельный эксперимент: смогут ли все участники использовать способ в реальной работе и кто возьмёт ответственность за результат? Стив Бланк подчёркивает необходимость задавать гипотезы и pass/fail-эксперименты; конкретные условия нужно выбрать до результата, а не подогнать после.

Заполненный план и результат учебного пилота

Ниже всё вымышлено. Это пример записи условий и вывода, не рекомендуемая всем квота или гарантия успеха.

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

Учебный результат:10 из 12 переносов завершены без повторного вопроса, два потребовали повторного контакта; преждевременно окончательных переносов — 0. Две школы выбрали продолжение, одна отказалась: преподавателю неудобно следить за дополнительным статусом. Все 12 случаев учтены.

Критерии пилота выполнены. Однако отказ третьей школы показывает ограничение способа: дополнительный контроль может переносить работу с координатора на преподавателя. Следующий эксперимент должен проверить доступность статуса для этой роли, сохраняя критичное правило подтверждения. Нельзя объявить массовое внедрение успешным только по сумме 10/12.

Если бы появилась хотя бы одна преждевременная фиксация, критичное условие не выполнено даже при 11 удачных переносах. Тогда решение — исправить способ различения статусов и повторить соответствующую проверку. Не заменяйте заранее установленную границу средним баллом удобства.

Что проверять для покупки

Пилот подтвердил часть процесса, но не коммерческую гипотезу. Следующий этап требует отдельного разговора с человеком, который выбирает и оплачивает решение:

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

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

Закончите записью решения

Учебная карточка по итогам цикла:

Исходное предположение: главный барьер координаторов — подбор свободного времени.
Что изменилось: в двух описанных случаях время было найдено; повторная работа связана с раздельным подтверждением. Есть контрпример достаточности старого процесса.
Новое направление: проверить состояние согласования для нескольких участников.
Что удалось проверить: понятность прототипа и ограниченный процесс в трёх школах.
Ограничение: дополнительный статус неудобен одной роли; рыночная распространённость и покупка не измерены.
Решение: уточнить способ для преподавателя и отдельно проверить коммерческие условия; общий запуск пока не обоснован.
Основания: матрица интервью, записи с цитатами, условия пилота и журнал всех 12 случаев.

Такую карточку можно оспорить предметно: показать другой эпизод, иной результат или неподтверждённую связь. В этом практическая ценность CustDev: команда меняет решение на основании свидетельств и понимает, какое утверждение ещё предстоит проверить.