Список замечаний не равен списку решений
После выпуска люди приходят с разными словами: «не понял, для кого это», «нужна ещё одна функция», «у вас дорого», «готов купить, если...», «зашёл, но не дошёл до результата»
Каждый комментарий может быть честным. Поэтому рука тянется собрать их в бэклог и начать исправлять всё по очереди
Но продукт редко упирается сразу в десять проблем. Обычно десять комментариев подсвечивают одну развилку, которую основатель ещё не назвал. Пока она не названа, команда улучшает детали и сохраняет прежнюю неопределённость
Замечание о регистрации может быть технической помехой. А может означать, что человек не увидел достаточно ценности, чтобы преодолеть даже небольшое усилие на входе
Просьба о новой функции может быть сигналом реальной недостающей возможности. А может быть вежливым способом сказать: «Я не понимаю, зачем мне начинать с тем, что уже есть»
Вопрос о цене тоже не всегда про цену. Иногда человек сравнивает не два тарифа, а два представления о результате
Три слоя, в которых живёт обратная связь
Чтобы не спорить с каждым комментарием по отдельности, разложи обратную связь на три слоя
| Что услышал | Какой слой проверить | Что это может означать |
|---|---|---|
| «Не понял, что это даёт» | Обещание | Пользователь не видит конкретного результата продукта |
| «Не смог начать или запутался» | Первый опыт | Человек не получает первый полезный результат достаточно быстро |
| «Нужна функция X» | Граница продукта | Неясно, какой сценарий и для кого продукт обязан закрыть первым |
Это не классификация ради порядка. Она нужна, чтобы не лечить сообщение вместо причины
Если три человека разными словами говорят о первом опыте, не надо сразу рисовать новые функции. Сначала стоит проверить путь от первого экрана до первого результата
Если люди хвалят механику, но не могут пересказать ценность, возможно, продукт ещё пытается быть полезным всем сразу и не выбрал свой первый сценарий
Не ищи самый громкий комментарий
Самый громкий комментарий редко оказывается главным. Он может быть самым подробным, самым эмоциональным или лучше всего совпадать с тем, что ты уже хотел сделать
Главной становится та проблема, после решения которой изменится ответ на один из трёх вопросов
- Кто наш первый человек, для которого продукт становится нужным прямо сейчас
- Какой результат он должен увидеть до того, как просить больше функций
- Как мы поймём, что он получил этот результат, а не просто посмотрел интерфейс
Если ответ не меняется, перед тобой доработка. Она может быть полезной, но не должна занимать место развилки
Если ответ меняется, перед тобой решение
Человек приходит не за платформой с десятком возможностей. Он приходит, чтобы сегодня провести первое обучение, проверить один документ, разобраться с одной закупкой, получить первую заявку или увидеть, почему сайт теряет клиента
Как превратить обратную связь в проверяемое решение
Не начинай с вопроса «что добавить?» Начни с короткой карточки решения
Какое решение я должен принять: Какое предположение за ним стоит: Какие три факта его подтверждают: Какой факт опровергнет его за ближайшие семь дней: Что я перестану делать, если предположение не подтвердится:
Здесь важна последняя строка. Если после проверки ничего не меняется, это не проверка. Это ещё одна активность вокруг продукта
Допустим, ты выбираешь первый сценарий для продукта. Предположение может звучать так: «Клиенту важнее быстро запустить один готовый сценарий, чем получить доступ ко всем возможностям»
Тогда проверка не выглядит как «улучшим онбординг». Она выглядит конкретнее: показать человеку один готовый путь, довести его до первого результата и посмотреть, начал ли он сам следующий шаг. Если нет, не прятать вывод за новым дизайном. Вернуться к предположению
Где основатель обычно застревает
После хорошего запуска комментариев много, продукт живой, люди поддерживают. Кажется, что нужно лишь быстрее собрать все разумные предложения
В этой точке сложно признать, что часть хороших советов пока не нужна
Но отказ от части идей не означает, что они плохие. Он означает, что у продукта появился порядок
Сначала решается вопрос, без которого остальные улучшения не дадут эффекта. Затем проверяется результат. Потом открывается следующая развилка
Не наоборот
Когда нужен внешний взгляд
Внешний взгляд полезен не тогда, когда основатель хочет услышать «добавьте вот это». Для этого есть пользователи, команда и рынок
Он нужен, когда ты уже видишь несколько разумных направлений, но не можешь понять, на каком предположении держится каждый выбор. Внутри своей рамки это почти всегда трудно заметить
В «МетаРешении» мы не выбираем продуктовую стратегию вместо основателя и не выдаём советы по отрасли. Мы смотрим, как устроена сама ситуация выбора: что в ней уже названо, что считается фактом, какой риск нельзя признать и какой вопрос подменён списком действий
Иногда после такого разбора решение остаётся прежним. Но оно перестаёт быть интуитивным. У него появляются основания, проверка и понятный следующий шаг
Что сделать после чтения
Возьми три последних содержательных комментария к своему продукту. Не самые приятные и не самые громкие. Те, после которых тебе захотелось что-то срочно переделать
Для каждого ответь на два вопроса
- Это замечание про обещание, первый опыт или границу продукта
- Какое моё предположение станет неверным, если человек прав
Если три ответа ведут к одному предположению, у тебя уже есть главная проблема. Не список работ, а решение, которое стоит проверить первым
Источники контекста
Частые вопросы
Почему нельзя просто сделать все разумные доработки? Потому что хорошие доработки могут относиться к разным решениям. Сначала нужно выбрать предположение, которое проверяется раньше остальных
Как отличить проблему первого опыта от запроса на новую функцию? Посмотрите, получил ли человек пользу от уже существующего продукта. Если нет, просьба о функции может скрывать неясность ценности или первый опыт
Когда нужен внешний разбор решения? Когда у основателя есть несколько разумных направлений, но неясно, на каком предположении держится каждое из них