Фреймворк пользовательских интервью для маленьких команд: быстрая…

Не верьте, когда пользователи говорят «хочу»

Несколько лет назад я делал AI-помощник для написания текстов. Первые два месяца — сплошные догадки. Я составил список из дюжины функций, убеждённый, что каждая необходима. Когда прототип был готов, показал друзьям. Все сказали «отлично», «полезно». Я был уверен в себе, пока на третьем месяце не поймал незнакомца в кафе и не поговорил с ним 20 минут. Этот единственный разговор опрокинул три моих самых дорогих предположения.

С тех пор я взял за правило: прежде чем писать первую строку кода, провести минимум три раунда пользовательских интервью, по 2–3 человека в каждом, всего не больше десяти. Это не статистически значимая выборка, но её достаточно, чтобы увидеть слепые зоны. Речь не о непринуждённых беседах «какой цвет вам нравится». Это систематическая проверка гипотез.

Интервью — это ставки, а не беседы

Большинство маленьких команд пропускают интервью, потому что думают: нет времени/денег, или «я в этой индустрии, я знаю пользователя». Обычно это иллюзия. Разрыв между тем, что пользователи на самом деле делают, и тем, что вы думаете, огромен. Проекты, пропускающие этот шаг, часто запускаются и обнаруживают, что никому не нужна решённая ими проблема.

Мой подход — записывать гипотезы в форме «Если … то …». Например: «Если пользователи тратят 20 минут в день на ручное составление протоколов встреч, то инструмент автоматического резюмирования будет считаться необходимым». Затем я иду с этой ставкой к людям, не чтобы доказать свою правоту, а чтобы найти доказательства, которые могут её опровергнуть.

Три подготовительных шага

1. Выпишите три самых неопределённых предположения

Не пишите тривиальные вещи вроде «пользователи выходят в интернет». Сосредоточьтесь на том, от чего зависит основная ценность, и в чём вы меньше всего уверены. Например:

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

2. Найдите «холодных» пользователей из целевой аудитории

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

3. Разработайте сценарий направленной беседы

Не анкету, а последовательность. Обычно я строю её так:

Фон: что вас больше всего раздражало в последнее время на работе/в жизни? (Не упоминайте продукт.)
Текущие решения: что вы пробовали? Почему не прижилось?
Затем покажите очень грубый демо-макет: рисунок на бумаге, низкодетализированный прототип или просто одностраничное описание. Не называйте это «продуктом». Скажите: «Я изучаю эту проблему — не могли бы вы оценить эту идею?»
Наконец, спросите о готовности платить: если бы это стоило чашки кофе в месяц, вы бы купили? А если как обед?

Ловушки, которых следует избегать во время интервью

Избегайте «Как вы думаете…» – это провоцирует выдуманные ответы. Замените на «Когда вы в последний раз сталкивались с X? Что вы сделали?»
Не объясняйте логику продукта. Как только пользователь чувствует, что вы продаёте, он начнёт врать из вежливости.
Никогда не спорьте. Если пользователь говорит «мне это не нужно», кивните, запишите, а затем спросите «Можете привести пример?» Это ценнее любой защиты.
Каждое интервью не дольше 20 минут. После этого внимание падает, качество информации резко снижается.

Как извлечь сигналы для решений из записей

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

Один контр‑интуитивный момент: если пользователь на прямой вопрос отвечает «я бы заплатил», это почти бесполезно. Настоящие сигналы — когда пользователь спрашивает «Могу я уже использовать?» или «Как купить?» Другой сильный сигнал — если после звонка он сам добавляет вас в WeChat и спрашивает, когда будет запуск. Пассивное согласие не сигнал; активное действие — да.

Пример изменения предположений

Представьте, что мой AI-помощник для письма должен был «автоматически генерировать маркетинговые тексты». В первом раунде я опросил трёх владельцев малого бизнеса. Двое сказали: «Я пишу сам; у меня нет времени учить новый инструмент». Третий сказал: «Мне нужны настраиваемые шаблоны — общий результат недостаточно хорош». Это опрокинуло два предположения: 1) само написание не самая большая боль (хотя оно отнимает время), но редактирование под нужды — ещё больнее; 2) чистой генерации недостаточно — нужны редактируемые шаблоны. Я изменил направление: от чистой генерации к «полу‑генерации + библиотека шаблонов». Второй раунд интервью подтвердил это направление.

Я не использовал никаких инструментов аналитики, только семь интервью (три в первом раунде, два во втором, два в третьем), чтобы изменить ключевое направление. Если бы я сразу начал кодить, потерял бы как минимум два месяца.

Когда достаточно? Когда продолжать?

Волшебного числа нет. Моё эмпирическое правило:

Если после трёх раундов вы всё ещё не можете определить основную боль, вы либо набрали не тех людей, либо само определение проблемы ошибочно. Вернитесь к переписыванию гипотез.
Если большинство пользователей ведут себя, как вы предсказывали, и как минимум 2–3 проявляют сильные сигналы действия (спрашивают о покупке, активно рекомендуют), этого достаточно.
Никогда не ждите «статистической значимости», прежде чем принять решение. Время маленькой команды — деньги. Лучше двигаться с 70% уверенности и итерировать, чем ждать 95% и упустить рынок.

Заключительные мысли

Пользовательские интервью не должны быть разовой задачей; они становятся регулярным ритмом в итерации продукта. Всякий раз, когда на столе крупная функция или изменение направления, проводите два‑три раунда интервью. Затраты низкие, а отдача может сэкономить месяцы разработки.

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

PaxLee