От идеи до результата: Как создавать продукты, которые нужны людям
- -
- 100%
- +
И ещё важно различать пользователя и покупателя. В корпоративном продукте сотрудник может пользоваться сервисом каждый день, руководитель — выбирать поставщика, а финансовый отдел — оплачивать подписку. У каждого свои критерии успеха. Если смешать их в одну персону, продукт рискует удовлетворить плательщика на презентации и разочаровать пользователя в работе.
От наблюдения к проверяемой формулировке
Для описания задачи удобно использовать шаблон:
Когда [возникает ситуация или ограничение], я хочу [достичь прогресса или выполнить действие], чтобы [получить значимый результат].
В середине формулировки не стоит сразу называть функцию. Если написать «Когда я занят, я хочу получать пуш-уведомления», команда уже выбрала решение, не выяснив задачу. Человек может хотеть не уведомление, а уверенность, что важное не потеряется. Для этого иногда подойдёт напоминание, но иногда — передача дела другому, совместный список или изменение самого процесса.
Три истории из «Планки» можно выразить так:
Когда у меня несколько клиентских проектов с разными сроками и договорённостями, я хочу быстро видеть, что обещано и что требует моего внимания, чтобы выполнять обязательства и сохранять доверие клиентов.
Когда подготовка к экзамену кажется слишком большой и неопределённой, я хочу найти ближайший посильный шаг, чтобы начать заниматься и почувствовать, что продвигаюсь.
Когда я координирую заботу о пожилом отце вместе с родственниками, я хочу понимать, кто и что берёт на себя, чтобы важные дела не зависели только от моей памяти.
Такие формулировки не являются окончательной истиной. Это гипотезы, которые можно обсуждать и проверять. Они помогают увидеть, где задача общая, а где расходится. Возможно, у Ирины и Людмилы есть общий функциональный мотив — не терять договорённости, — но требования к приватности и совместному доступу будут разными. Возможно, Денису нужен совсем иной тип поддержки.
Важно также не превращать шаблон в магическую фразу. «Чтобы повысить эффективность» — слабое завершение, потому что не говорит, что именно изменится. Хорошая формулировка помогает представить наблюдаемый результат: успеть отправить макет до согласованного срока; начать подготовку в тот же вечер; договориться, кто заберёт лекарства. Наблюдаемость не означает, что все важные переживания можно измерить одним числом. Она означает, что команда понимает, по каким признакам человек сам распознаёт улучшение.
Практика: найдите первую точку входа
Первый целевой сегмент — не приговор и не обещание навсегда обслуживать только одну группу. Это осознанная точка входа: группа людей, у которых повторяется важная ситуация и для которых команда готова сначала создать надёжное решение.
Чтобы наметить такой сегмент, пройдите короткий маршрут.
1. Соберите недавние истории. Поговорите с людьми, которые недавно пытались решить похожую задачу. Просите рассказать о последнем конкретном случае, а не описать идеальный продукт.
2. Выпишите ситуации и триггеры. Например: «после получения срочного запроса от клиента», «когда до экзамена осталось две недели», «при распределении дел по уходу за родственником».
3. Сравните желаемый прогресс. Люди хотят одного и того же результата или лишь используют похожий инструмент? Не объединяйте их только потому, что все открывают список задач.
4. Запишите альтернативы и цену проблемы. Что уже работает? Что отнимает время, создаёт риск или вызывает переживания? Чем человек расплачивается, если ничего не меняет?
5. Сформулируйте несколько задач. Используйте шаблон «Когда…, я хочу…, чтобы…». Сравните формулировки и отметьте, где различаются обстоятельства, мотивы и критерии успеха.
6. Выберите фокус на первый цикл. Оцените, насколько задача важна для людей, как часто возникает, насколько доступна для исследования и можете ли вы реально помочь. Не обязательно выбирать самую многочисленную группу. Иногда разумнее начать с группы меньшего размера, чья проблема ясна и к которой команда может быстро получить доступ.
7. Назовите, что пока неизвестно. Например: «Мы предполагаем, что независимые дизайнеры готовы вести клиентские обязательства в одном месте, но не знаем, доверят ли они сервису данные о сроках». Это не слабость плана, а основа следующей проверки.
Проверьте итоговую формулировку несколькими вопросами. Можно ли по ней понять, в какой момент продукт становится нужен? Отличается ли она от простого описания функции? Видно ли, что человек считает успехом? Сможет ли команда найти людей, у которых такая ситуация действительно случается? Если ответы расплывчаты, сегмент пока тоже расплывчат.
Допустим, команда решит начать с независимых специалистов, которым нужно держать клиентские договорённости под контролем. Это не значит, что студентам или семьям приложение не подходит. Это значит, что в ближайшем цикле команда сначала будет проверять именно этот сценарий, его язык, препятствия и признаки успеха. Позже появятся новые данные — и фокус можно будет расширить или изменить.
От уважения к человеку — к сильному продукту
Понимание задачи требует любопытства и дисциплины. Любопытства — чтобы не считать собственные привычки универсальными. Дисциплины — чтобы не принимать первое объяснение за окончательное и не превращать яркую историю одного человека в описание целого рынка.
Люди приходят к продуктам не только с разными биографиями, но и с разными обстоятельствами. Один и тот же человек может в понедельник использовать сервис, чтобы не забыть обещание клиенту, а в воскресенье — чтобы составить список покупок для родителей. Продуктовая задача живёт не внутри неизменной категории людей, а на пересечении человека, ситуации, мотива и желаемого изменения.
Поэтому начните с вопроса не «Какой продукт нам сделать для нашей аудитории?», а «В какой важный момент человеку нужна помощь — и что для него будет означать, что она сработала?» Ответ не заменит исследования, но даст ему направление. Он позволит команде перестать угадывать и начать искать подтверждения: кто сталкивается с такой задачей, как часто, чем уже пытается справиться и почему прежние способы оказываются недостаточными.
Тогда аудитория перестанет быть туманным «всеми, кому пригодится». Она станет группой людей, связанных не ярлыком и не красивой персоной, а реальной ситуацией и общей потребностью в прогрессе. Именно с этой ясности начинается создание продукта, который нужен не в теории, а в жизни.
Исследование рынка и аудитории: как находить надёжные факты
Во вторник в 9:12 руководитель продаж Илья положил на стол распечатку с двумя отзывами.
— Клиенты хотят, чтобы система сама присылала им умную сводку за неделю. Один сказал: «Хочу одним взглядом понимать, что происходит с магазином». Другой попросил подсвечивать проблемы. Это очевидный спрос.
В компании продавали сервис для управления заказами интернет-магазина. Идея звучала убедительно: собрать данные, добавить немного искусственного интеллекта, отправлять владельцу короткий отчет. На планировании команда уже обсуждала сроки. Разработчики оценивали сложность, дизайнер набрасывал экран, маркетинг придумывал название.
Но между двумя отзывами и выводом «рынок хочет новую функцию» лежала пропасть. Через несколько недель выяснилось: оба клиента охотно говорили о сводке, но ни один не мог вспомнить, когда в последний раз регулярно читал отчеты, которые уже получал. Зато оба сталкивались с другой проблемой: не понимали, почему сумма выплат от платежного сервиса не совпадает с выручкой в магазине.
Команда услышала желание — и приняла его за доказательство спроса. Это обычная ошибка. Она происходит не потому, что люди не умеют исследовать, а потому, что убедительная история кажется короче и приятнее, чем честное признание: «Пока не знаем».
Исследование нужно не для того, чтобы собрать побольше мнений перед разработкой. Оно нужно, чтобы уменьшить неопределенность настолько, чтобы принять следующее разумное решение. Иногда этим решением будет разработка. Иногда — новый вопрос, другой сегмент или отказ от первоначальной идеи.
От мнения к проверяемому утверждению
Любая продуктовая гипотеза состоит как минимум из трех частей: кто сталкивается с ситуацией, что именно пытается сделать и какой результат для него важен. Если эти части не разделены, команда легко смешивает проблему с предложенным решением.
Фраза «клиентам нужна умная сводка» уже содержит трактовку. За ней могут стоять совсем разные факты:
• владелец магазина раз в неделю проверяет выручку;
• ему нужно понять, хватит ли денег на предстоящие выплаты;
• он не доверяет данным в сервисе;
• он хочет сократить время на подготовку отчета для партнера;
• он просто согласился с красивой идеей на встрече.
Это не одно и то же. Отчет может помочь в первом случае, оказаться бесполезным во втором и даже усилить недоверие в третьем. Пока мы не знаем, какой факт стоит за словами, мы исследуем не спрос, а собственную интерпретацию.
Полезно записывать выводы в трех колонках: что увидели или услышали, что это может значить и что нужно проверить дальше. Например:
Наблюдение
Интерпретация
Что проверить дальше
Пользователь говорит: «Да, я бы читал еженедельную сводку»
Возможный интерес к регулярной информации
Когда он в последний раз искал такую информацию? Что сделал?
Владелец выгружает заказы в таблицу в конце месяца
Он может выполнять ручную сверку
Что именно сверяет, сколько это занимает и к чему приводит ошибка?
Три участника не вспомнили письма с отчетами
Возможно, существующие отчеты не попадают в привычный сценарий
Открывали ли письма другие пользователи? Что показывают данные по доставке и переходам?
В поддержку поступают вопросы о расхождении сумм
Есть трудность с пониманием выплат
Как часто возникает проблема и в каких типах магазинов?
Важное слово здесь — «может». Интерпретация не становится фактом только потому, что ее произнес опытный руководитель. Таблица помогает не запрещать догадки, а помечать их как догадки.
Один ответ — два разных смысла
На первом интервью исследователь спросил владелицу магазина:
— Если бы сервис присылал вам умную сводку каждую неделю, вы бы ей пользовались?
— Конечно, — ответила она. — Это было бы очень удобно.
Команда уже приготовилась записать в заметки: «Спрос подтвержден». Но затем интервьюер задал вопрос о прошлом поведении:
— Вспомните последний раз, когда вам понадобилось понять, как дела у магазина. Что произошло?
— В пятницу я готовила выплаты. Скачала заказы, открыла таблицу и стала сверять суммы с тем, что пришло от платежного сервиса.
— Что было самым трудным?
— Я не понимала, почему сумма отличается. Пришлось писать бухгалтеру.
— А отчеты, которые сервис уже присылает, вы открываете?
— Редко. Там общие цифры, а мне нужно понять, откуда взялась конкретная сумма.
Первый ответ был не ложью. Сводка и правда могла показаться удобной. Но ответ о будущем не объяснил, как часто возникает задача, что пользователь делает сейчас и что именно ему нужно узнать. Разговор о конкретном прошлом случае дал гораздо больше материала для проверки.
Люди не всегда точно предсказывают собственное поведение. Будущее легко вообразить, особенно если собеседник описывает привлекательную функцию. Воспоминания тоже не идеальны: память не видеозапись, а пересказ, который может сглаживать детали. Поэтому вопросы о прошлом лучше задавать не в форме экзамена («Вы часто это делаете?»), а как приглашение восстановить эпизод:
• «Вспомните последний раз, когда вы…»
• «Что произошло непосредственно перед этим?»
• «Какие шаги вы сделали?»
• «Покажите, если можете, чем пользовались».
• «Что случилось после?»
• «Что было бы, если бы вы ничего не предприняли?»
Нейтральный вопрос не подсказывает ответ и не превращает интервью в презентацию идеи. «Как вы решаете, какую сумму выплатить?» полезнее, чем «Вам было бы удобнее получать отчет о выплатах каждую неделю?» Во втором вопросе уже спрятано предположение, что еженедельный отчет — хорошее решение.
Интервью — способ понять контекст, мотивы, последовательность действий и обходные пути. Оно не показывает, какой процент всего рынка столкнется с проблемой. Даже если десять собеседников описали похожую трудность, это веский повод исследовать ее дальше, но не основание объявлять ее распространенной среди всех клиентов.
Разные источники отвечают на разные вопросы
Надежное исследование редко строится на одном источнике. Не потому, что нужно собрать все доступные данные, а потому, что каждый источник освещает свой участок реальности.
Источник
На какие вопросы помогает ответить
Чего сам по себе не доказывает
Интервью
Как возникла задача? Почему человек действует именно так? Что пробовал раньше?
Насколько часто это происходит на рынке
Наблюдение за работой
Какие шаги, инструменты и обходные решения человек использует на деле?
Что поведение будет таким же везде и без исследователя рядом
Опрос
Как распределяются заранее определенные ответы среди опрошенной аудитории?
Что выборка представляет рынок или что заявленное намерение станет действием
Продуктовая аналитика
Что пользователи делают в измеряемых частях продукта, как часто и в какой последовательности?
Почему они это делают и что происходит за пределами продукта
Обращения в поддержку
С какими трудностями люди приходят за помощью, как они формулируют проблему?
Насколько проблема распространена среди тех, кто не обращался
Открытые данные
Как устроен рынок, какие есть категории, тенденции и внешние ограничения?
Что пользователи вашей аудитории купят конкретно ваше решение
Интервью и наблюдение особенно полезны, когда команда еще не понимает природу задачи. Это качественные методы: они помогают обнаружить объяснения, различия между сценариями и неожиданные факторы. Их цель — не посчитать долю рынка, а лучше понять, что именно считать и измерять.
Опрос уместнее, когда вопрос уже определен: например, как часто владельцы сверяют выплаты или какими способами пользуются. Но опрос не исправит плохую формулировку. Если спросить «Насколько вам нужна автоматическая умная сводка?», мы измерим реакцию на привлекательное описание, а не обязательно поведение. И даже хороший опрос зависит от того, кого пригласили, кто ответил и кто проигнорировал приглашение.
Аналитика покажет, сколько пользователей нажимают кнопку экспорта, если событие надежно записывается. Но она не скажет, почему они это делают. Возможно, готовят отчет бухгалтеру; возможно, исправляют ошибку; возможно, случайно нажали кнопку. А если активные магазины чаще пользуются панелью и одновременно показывают больший оборот, это еще не означает, что панель увеличивает оборот. И то и другое может объясняться тем, что у активных продавцов больше операций. Корреляция показывает, что события связаны, но сама по себе не доказывает причинную связь.
Обращения в поддержку особенно полезны как источник живых формулировок и сигналов о боли. Но люди, которым все работает, пишут туда реже. Пара десятков похожих тикетов может показать важный сценарий, но без понимания общей аудитории не позволяет утверждать, что он типичен для всех.
Ловушки, в которые попадает умная команда
Удобная выборка. Если поговорить только с лояльными клиентами, которых легко найти через менеджеров, можно услышать много полезного — и пропустить тех, кто ушел, не активировался или придумал обходной путь. Для исследования конкретного сценария ищите людей по поведению: тех, кто недавно выполнял задачу, пользуется другим решением или перестал пользоваться вашим продуктом. В качественном исследовании это обычно целевая выборка, а не случайная. Если же вы хотите оценить распространенность явления, требования к отбору будут другими.
Подтверждение ожиданий. После того как команда влюбилась в идею, она может замечать одобрение и объяснять скепсис «плохим настроением участника». Перед началом исследования запишите, какое свидетельство поддержит гипотезу, какое поставит под сомнение и что заставит изменить решение. Это не отменяет интерпретацию, но делает правила игры видимыми.
Вопросы о симпатии вместо поведения. «Вам бы понравилась такая функция?» обычно приглашает человека быть вежливым и представить удобное будущее. Спросите, что он делал в последний раз, сколько времени потратил, чем заменил отсутствующую возможность и чем завершился эпизод. Если проверяете прототип, наблюдайте, может ли человек выполнить задачу, а не только говорит ли он, что дизайн ему нравится.
Мало наблюдений — громкий вывод. Небольшая серия интервью может дать неожиданно полезную гипотезу. Она не превращается от этого в опрос рынка. Одна история — сигнал присмотреться; повторяющиеся истории — основание проверить общий рисунок; оценка распространенности требует подходящей количественной выборки и корректного измерения.
Причина, найденная в корреляции. Пользователи, которые часто заходят в панель, могут иметь более крупные магазины. Нельзя автоматически заключить, что частые заходы делают магазин крупнее. Чтобы утверждать причинное влияние, нужны дополнительные основания: например, корректный эксперимент или иной дизайн, который позволяет исключить альтернативные объяснения.
План исследования: маленький документ против больших заблуждений
Вернемся к идее сводки. Вместо вопроса «Делать ли отчет?» команда формулирует более полезный:
Что пытаются выяснить владельцы интернет-магазинов, когда проверяют показатели бизнеса, что запускает эту задачу и как они решают ее сейчас?
Теперь можно подобрать методы под неопределенность.
Исследовательский вопрос
Метод
Аудитория
Какой сигнал ищем
Ограничения
Что люди выясняют, когда сверяют выручку и выплаты?
Интервью о недавнем конкретном случае; по возможности — наблюдение за процессом
Владельцы магазинов, которые недавно сверяли суммы
Повторяющиеся задачи, шаги, ошибки, последствия и обходные решения
Небольшая целевая выборка не показывает распространенность
Как часто пользователи выгружают данные или открывают отчеты?
Анализ событий за выбранный период
Активные магазины разных размеров и типов
Частота экспорта, использование отчетов, различия между сегментами
Аналитика фиксирует только размеченные события и не объясняет мотив
Какие проблемы встречаются в обращениях?
Разбор тикетов и категорий поддержки
Обращения за несколько месяцев, включая разные каналы
Повторяющиеся темы, формулировки, типы затруднений
В поддержку чаще попадают люди с нерешенной проблемой
Насколько распространены обнаруженные сценарии?
Опрос с нейтральными вопросами о поведении
Выборка из определенной целевой группы пользователей
Доля тех, кто выполнял задачу, частота, используемые инструменты
Итог зависит от списка приглашенных, отклика и формулировок
Порядок здесь не ритуальный. Можно начать с поддержки и аналитики, чтобы понять, где искать, затем провести интервью, а после сформировать хороший опрос. Или сначала поговорить с пользователями, если команда почти ничего не знает о сценарии. Метод выбирают не по престижности, а по вопросу.
При наборе участников важно не ограничиваться теми, кто охотно отвечает на приглашения. В этой истории стоит включить владельцев магазинов с разным объемом заказов, тех, кто регулярно работает с отчетами, тех, кто выгружает данные в таблицы, и тех, кто недавно перестал пользоваться сервисом. Если решение о покупке принимает один человек, а со сводкой работает другой, нужно услышать обоих. Набор участников по разным ролям и сценариям не делает выборку статистически репрезентативной, зато помогает не принять опыт одной узкой группы за опыт всех.
Перед сбором данных определите, что будет считаться сигналом. Например: участники сами, без подсказки, описывают повторяющуюся задачу; в разных источниках обнаруживаются похожие обходные решения; аналитика подтверждает, что действие происходит регулярно. Это не универсальный порог и не обещание успеха. Это способ заранее решить, какие данные могут изменить ваш взгляд, а какие лишь сделают старое мнение убедительнее.
Честная уверенность лучше красивой определенности
После первого этапа команда может записать вывод так:
Наблюдение: некоторые владельцы вручную сверяют суммы выплат с данными заказов и обращаются за помощью, когда суммы не совпадают. Интерпретация: им может быть важно не получить еще одну сводку, а понять, из чего сложилась конкретная выплата. Что проверить дальше: насколько часто возникает этот сценарий в разных группах магазинов и какие компоненты суммы вызывают больше всего вопросов.
Обратите внимание на масштаб слов. «Некоторые владельцы» — не «рынок». «Может быть важно» — не «точно нужно». Если аналитика показывает частые выгрузки, а интервью объясняют, зачем они нужны, уверенность растет. Если поддержка говорит о расхождениях, но в аналитике нет события сверки, это не противоречие: возможно, продукт просто не измеряет нужное действие.
Полезно вести журнал выводов с тремя уровнями уверенности:
• Низкая: есть яркое мнение или единичный пример, но возможны другие объяснения.
• Средняя: похожий сценарий встретился в нескольких интервью или источниках, однако его масштаб и границы неясны.
• Высокая для конкретного вывода: независимые источники сходятся, аудитория определена, альтернативные объяснения рассмотрены, а количественные утверждения подкреплены подходящими данными.
Высокая уверенность — не гарантия, что продукт сработает. Это точное описание того, насколько хорошо подтвержден именно текущий вывод. Можно быть уверенным, что продавцы часто сверяют выплаты, и при этом не знать, станут ли они пользоваться новой функцией.
Практика: соберите план на одну страницу
Выберите решение, которое ваша команда сейчас обсуждает, и потратьте двадцать минут на короткий план:
1. Запишите один вопрос, ответ на который действительно может изменить решение. Не называйте в нем заранее выбранную функцию.
2. Укажите, чье поведение нужно понять: не только возраст или должность, но и недавний опыт выполнения задачи.
3. Подберите метод, подходящий вопросу. Чтобы узнать «почему и как» — начните с интервью или наблюдения. Чтобы оценить «как часто» — определите измерение и способ получить подходящую количественную выборку.
4. Назовите сигнал, который будете искать, и ограничение метода.
5. Запишите альтернативное объяснение. Если человек согласился с идеей, возможно, он выражает вежливость; если часто нажимает кнопку, возможно, исправляет ошибку.
6. До сбора данных отметьте текущую уверенность: низкая, средняя или высокая. После исследования объясните, что именно ее повысило или понизило.
Хороший план умещается на странице, но защищает от многих недель работы не над той задачей. Он не обязан дать окончательный ответ. Его задача — сделать следующий шаг осмысленным и показать, где знание заканчивается.
Когда команда в нашем примере перестала спрашивать «Понравится ли вам умная сводка?» и стала выяснять, что владельцы делают при расхождении выплат, вопрос изменился. Возможно, нужен отчет. Возможно, объяснение начислений прямо в интерфейсе. Возможно, проблема возникает только в одном типе платежной схемы. Исследование не выбрало решение за команду. Оно убрало часть тумана и помогло увидеть, какое решение стоит проверять следующим.
Надежные факты не всегда громкие и эффектные. Чаще они складываются из нескольких скромных источников: конкретного рассказа о прошлом действии, следа в аналитике, повторяющейся темы в поддержке и понимания ограничений каждого метода. Не нужно ждать полной уверенности — в продуктовой работе ее почти никогда не бывает. Нужно честно различать, что мы наблюдали, что предполагаем и какой факт способен изменить наш план. Так исследование становится не обязательным ритуалом перед разработкой, а способом принимать решения, за которые не стыдно отвечать.