Погружение в контекст пользователя
В продукт не приносят ценность снаружи. Её можно только вырастить из реального опыта пользователя. Получить представление о пользовательском опыте можно через интервью, опросы, аналитические отчёты или прочувствовать самому.
Регулярная практика customer discovery
Общение с пользователями — не разовый этап, а постоянная дисциплина. Это мышца, которую надо качать. Общение может быть и косвенным — через дашборды и метрики здоровья продукта. Но старое доброе интервью ничто не заменит.
Развитие кросс-функционального взгляда
Продуктовое мышление — на стыке бизнеса, технологий, дизайна, психологии. Изучение смежных дисциплин помогает шире видеть и глубже чувствовать. Продуктовый менеджер — это специалист широкого спектра знаний. Это позволяет не только лучше понимать коллег, но и помогает эффективнее искать зоны роста продукта, формулировать вопросы к пользователю и понимать влияние вносимых в продукт изменений. Будь чуть-чуть дизайнером, чуть-чуть аналитиком и сильно продактом.
Формулируя гипотезы, отталкивайся от пользовательского опыта. Вместо «разработать фичу» — говори «проверить гипотезу». Это переключает мышление с реализации на результат. Так твоей основной задачей будет не развивать функциональность продукта, а усиливать его ценность. Вроде бы небольшая разница, но фокус и отношение меняются кардинально.
Как определить ценность продукта для пользователя?
Ценность — это не то, что мы закладываем в продукт (фичи), а то, что пользователь из него извлекает. Другими словами, это «полезность» продукта для пользователя. Сами по себе фичи никому не нужны — необходима только их ценность. Задача продуктового менеджера — наращивать ценность для пользователей. Изменение ценности напрямую влияет на продуктовые метрики. Рост метрик — следствие роста ценности.
Важным критерием для определения и роста ценности является понимание контекста пользователя. Нужно знать не только, кто пользователь, но и в каких условиях он пользуется продуктом: условия его жизни, работы и мотивация для принятия решений. Чем больше мы знаем о пользователях, тем меньше неопределённость и эффективнее развитие продукта. Ценность напрямую зависит от контекста. Один и тот же продукт может быть полезен для одного пользователя и бесполезен для другого. А также одним и тем же продуктом могут успешно пользоваться 2–3 независимые друг от друга группы. Понимание контекста и мотиваций каждой из них не позволит «сломать» продукт.
Исследования: качественные и количественные
Интервью: что пользователь делает, чувствует, чего боится, к чему стремится? Правильно заданные вопросы дают понимание о мотивации и «болях».
Дневниковые исследования: помогают увидеть реальные сценарии использования. Сейчас всё чаще такой метод исследований заменяется разметкой ключевых действий в продукте специальными событиями, которые записываются (логируются) в систему аналитики. Фактически, это дневник каждого пользователя и его взаимодействия с продуктом.
Анализ пользовательских метрик: Retention (возвращаемость), Engagement (вовлечённость), Churn (отток) и другие — поведенческие показатели, отражающие восприятие ценности. По метрикам, как правило, нельзя определить ценность, но они дают понять, в какую сторону «копать».
Вебвизор: если для аналитики используется Яндекс.Метрика, обязательно включи запись сессий и периодически их просматривай. Там можно обнаружить много неожиданного и интересного. Вебвизор — это кладезь для генерации гипотез и поиска точек роста.
Опросы: почти как интервью (и структура вопросов может быть схожей), но используются для количественной валидации результатов интервью. Между интервью и опросами для качественных исследований всегда стоит выбирать интервью.
В рамках концепции фреймворка пользователь не покупает продукт и не просто им пользуется — он «нанимает» его для решения конкретной задачи (работы). Если понять, какую работу он хочет выполнить с помощью продукта, станет ясно, где ценность. Согласно JTBD, у продукта может быть несколько ценностей разных уровней.
Обратная связь и поведение
Люди голосуют за ценность не словами, а действиями: они возвращаются, рекомендуют, платят, интегрируют продукт в свою повседневную жизнь, пишут отзывы о продукте. Стоит быть особенно внимательным к изменениям в поведении «старых» пользователей. Если метрики таких пользователей ухудшаются — значит, что-то не так со старыми сценариями в продукте. Прежняя ценность изменена.
Как формулировать ценностное предложение продукта?
Ценностное предложение — это обещание, которое продукт транслирует пользователю при первом контакте. А иногда и до него — например, в рамках рекламной кампании. Это обещание того, какую задачу / проблему / работу продукт решит и какую трансформацию даст пользователю. Ценностное предложение является краткой формулировкой ценности продукта.
Ценностное предложение должно быть:
К примеру, вместо «наш сервис помогает управлять задачами» — «наш сервис помогает фрилансерам держать фокус и сдавать проекты вовремя без хаоса в голове и в почте».
Указывается, для кого продукт, какую проблему в жизни пользователя он решает и кратко затрагивает сферы влияния.
Нужно понимать, на какую аудиторию нацелено предложение. Разным людям нужно разное. Хорошее ценностное предложение всегда про кого-то конкретного. Не обязательно в формулировке указывать целевую группу, но важно самим понимать, для кого вы делаете продукт.
Через A/B-тесты, интервью, customer discovery, маркетинговые гипотезы — это не догадка, а обоснованная гипотеза. Нужно убедиться, что для вашего продукта существует рынок. Или, используя более распространённую формулировку, — на ваш продукт существует спрос.
Пример шаблона для формирования ценностного предложения:
«Для [сегмента пользователей], у которых есть [проблема / потребность], наш продукт — это [категория продукта], который даёт [основная выгода] в отличие от [альтернатива]».
Какие вопросы помогают выявить ключевые потребности пользователей?
Не все вопросы одинаково полезны. Цель во время интервью — докопаться до мотиваций, страхов, контекста, альтернатив. Нужно построить беседу так, чтобы по её итогам стали понятны контекст и логика принятия решений пользователя.
Примеры вопросов для интервью:
Расскажите о последнем разе, когда вы пытались решить эту задачу. Что вы делали?
Что в этом процессе вас больше всего раздражает или утомляет?
Чем вы пользовались до этого? Почему перестали?
Если бы это решение исчезло, что бы вы делали?
Что для вас самое важное при выборе такого продукта?
Есть ли у вас какие-то ожидания или опасения по поводу использования продукта?
Что вы пытаетесь достичь в итоге? Как поймёте, что у вас получилось?
Важно не искать ответы напрямую, а слушать истории, эмоции, образы — именно в них скрыты настоящие потребности. Не стоит перебивать и торопиться задавать следующий вопрос. Нужно дать пользователю выговориться. Не нужно позволять интервьюируемому галлюцинировать на тему и строить предположения — спрашивать следует об уже совершённом опыте и принятых решениях. Люди врут, чтобы казаться лучше.
Принципы проведения интервью и подходы к формулированию вопросов хорошо раскрываются в книге «Спроси маму».
Как решать конфликт ценностей между бизнесом и пользователем?
Бизнес — напрямую или косвенно — хочет от продукта денег, а пользователь — ценность. И работа продакта — постоянно поддерживать баланс между бизнес-интересами и интересами пользователей.
В контексте вопроса бизнес — это не конкретные люди, а бизнес как деятельность. Продуктовый менеджер — это тоже бизнес. Бизнес-представитель, отстаивающий интересы пользователя.
Сразу отвечу на поставленный вопрос: единственно правильный способ разрешить конфликт — не допустить его. Конфликт ценностей приводит к стагнации и больно бьёт по бизнесу.
Основные принципы для поддержания баланса и избежания конфликта ценностей:
Сначала — потребность, потом — монетизация
Продуктом, не решающим задачу, не будут пользоваться. Даже если его купят — не вернутся. Нет пользователей — нет дохода. Поэтому ценность первична, деньги — вторичны.
Продакт должен глубоко понимать, как бизнес зарабатывает, какие метрики важны, как устроена юнит-экономика. Тогда проще находить пересечение интересов. Экономика и модель монетизации закладываются в продукт на самом старте и сильно влияют на ценность. Бизнес-модель — часть контекста пользовательского опыта.
Часто конфликт интересов — результат попытки угодить всем. Чёткая фокусировка на сегмент решает это. Продукт не может быть для всех. Чаще всего у него будет одна понятная аудитория. Реже — 2–3 крупные группы. Выбери один сегмент и развивай ценность для него.
Создание прозрачности и доверия
Пользователи не против монетизации — они против обмана и злоупотребления. Прозрачная модель ценообразования, честные ограничения, объяснение ценности — это путь к балансу. Между продуктом и пользователем всегда должен быть диалог. Выстроить его — очень сложная задача. Но необходимая. Поверь, SMM и техподдержка — а часто именно они держат прямой контакт с пользователем — совсем не зря едят свой хлеб.
Анализ альтернативных путей
Иногда можно найти компромисс, который удовлетворяет и бизнес, и пользователя. Например, freemium-модель когда-то стала такой альтернативой и перевернула рынок. Альтернативному решению не обязательно быть таким глобальным. Его может и не быть вовсе. Но рассматривать разные варианты, а ещё и периодически их тестировать — крайне важно.
Системное мышление
Как выявлять связи и зависимости в продукте?
Вполне очевидно, что продукт существует в контексте. Это и политическая обстановка, и финансовое состояние компании, и атмосфера в коллективе, работающем над продуктом. Факторов, влияющих на развитие и производство, очень много. Продукт — это система. И развивать его нужно как систему.
Простой пример. Хотим добавить на сайт форму для отправки заявки. Само по себе это несложно. Но кто будет обрабатывать заявки? Как он их будет получать? По заявкам будут писать на почту или звонить? Заявки нужно сопровождать или достаточно одного контакта с клиентом? По заявке нужно готовить договоры и/или закрывающие документы? На все эти вопросы ответы должны быть ещё до появления формы для заявок в продукте. Простая форма может привести к найму сотрудников, к смене подхода работы отдела продаж, породить зависимости, на которые может не быть ресурсов. А это всего лишь несколько текстовых полей и кнопка “отправить”.
Удержать всю систему в голове крайне трудно, поэтому существуют способы её визуализации и формализации.
Карта системы (System Mapping)
Выпиши все элементы системы, с которыми работает продукт:
Пользователи и их сегменты (каждый сегмент отдельно)
Основные пользовательские сценарии
Каналы привлечения и возврата
Команды, работающие над продуктом, процессы их взаимодействия
Технические зависимости и ограничения
Внешние влияния: конкуренты, рынок, сезонность, законы
После того как всё будет выписано, нужно связать узлы стрелками влияния, показать, где, что и от чего зависит. Это особенно важно перед масштабированием или крупными изменениями.
Карта системы позволит найти точки для оптимизации процессов внутри компании, а также для оценки рисков.
Анализ потоков (Flow Thinking)
Каждый продукт — это система потоков: пользователей (воронка), данных, денег, задач / запросов.
Системное мышление включает понимание узких мест в этих потоках. Где теряем пользователей? Где задержка в данных? Где залипают фичи в разработке? Разбей большую систему на набор систем поменьше. Так будет проще разобраться и «тюнить» потоки.
Цепочки причин и следствий (Causal Loop Diagrams)
Любая фича приводит к последствиям, и полезно перед внедрением нового функционала записать причины внедрения и потенциальные последствия. Особенно для крупного функционала. Для уже существующих фичей такая диаграмма — тоже полезный инструмент. Запиши такие цепочки — и ты поймёшь, где можно усилиться, а где система может сломаться.
Это совсем поверхностные примеры, но, как видишь, даже у базовых вещей есть последствия.
Кросс-командное взаимодействие
Продукт живёт на пересечении команд: разработка, маркетинг, поддержка, аналитика, продажи. И у каждого отдела свои интересы и взгляды на продукт. Поговори с представителем каждой команды — и ты будешь удивлён, насколько разные взгляды на одну и ту же систему.
Узнай, какие цели на квартал или год стоят перед каждой командой. Это поможет выявлять зависимости и мотивации, которые не видны изнутри своей функции. Может оказаться, что в двух командах противоположные цели — а это риски, которые не сразу можно поймать. Конечно, это справедливо в первую очередь для больших компаний.
Фреймворки типа Impact Mapping, Wardley Maps
Impact Mapping помогает понять, какие действия реально влияют на бизнес-цель. Фреймворк предлагает ответить на вопросы: зачем, кто, как, что. Практически любую задачу можно решить разными способами, и карта влияния позволит расписать каждый из вариантов и найти самый оптимальный — с максимальным импактом. Хорошее объяснение — на ScrumTrek.
Wardley Maps показывают, как элементы продукта соотносятся по степени зрелости (стадии развития) и конкурентности. Что подтянуть? Какие элементы системы лишние? Карта Уордли подскажет. Подробнее.
Какие инструменты помогают смотреть на продукт в целом?
Если выше мы говорили об инструментах, позволяющих посмотреть на систему в целом — по компании и окружающей её среде, — то здесь обсудим подходы к продукту как к системе и методы управления этой системой.
Позволяет визуализировать путь создания ценности — от идеи до пользователя. Помогает понять, где потери времени, где дублируется работа, где тормозит поток ценности.
Используется не только в разработке, но и в анализе бизнес-процессов в продукте. Описывает все шаги, необходимые для «доставки» ценности до пользователя, включая шаги получения денег.
Определи шаги
Запиши ответственного за каждый шаг (кто занимается реализацией шага)
Оцени время, необходимое для перехода к следующему шагу
Посчитай итоговый Time To Market и какой процент от него занимает каждый шаг
Product/Market Fit Canvas / Lean Canvas
Эти подходы помогают увидеть весь продукт как систему:
Кто пользователь
Что он пытается сделать
Как мы решаем проблему
Как зарабатываем деньги
Это хорошая «карта территории» для начального системного анализа. Подробнее.
Unit-экономика и когортный анализ
Финансовая модель продукта — тоже система. Она показывает, где ценность создаётся, а где теряется. Юнит-экономика помогает понять, сколько в среднем денег приносит один пользователь.
Ключевые метрики Юнит-экономики:
Поток клиентов, Users. Тут всё просто: это количество пользователей, зашедших в продукт или на целевую страницу.
С1. Конверсия первого шага или конверсия в ключевую метрику. Чаще всего это покупка чего-либо.
Payments. Количество оплат. Тут могут быть не только оплаты, но и, например, просмотры рекламы.
Buyers. Количество платящих пользователей.
Средний чек. Сколько денег приносит один платёж в среднем
ARPPU или AMPPU. Первое — выручка на одного платящего пользователя, второе — доход (он же — маржа). Метрики равнозначны в большинстве случаев, но считается, что AMPPU — более правильный вариант, так как показывает количество заработанных денег продуктом и позволяет контролировать показатель маржинальности.
CAC. Стоимость привлечения пользователя. Сколько было потрачено на рекламу, заказные статьи, различный маркетинг в расчёте на одного пользователя.
ARPU или AMPU. Выручка/маржа на одного привлеченного пользователя.
Lifetime Value (LTV). Сколько пользователь принёс денег за время жизни в продукте.
Смотреть юнит-экономику нужно и в целом по продукту, и разбивая пользователей на когорты. Когорты могут быть самыми разными. Набор когорт зависит от конкретного продукта. Но всегда пользователей можно разбить на тех, кто уже давно с продуктом, и тех, кто только в него пришёл. Обычно за «новых» берут тех, кто пришёл первый раз в течение исследуемого месяца, а за «старых» — всех остальных.
Методология Systems Thinking
Если нравится учиться через учебники, то существует неплохая книга — «Системное мышление» Донеллы Медоуз. Там подробно описаны разные подходы к формированию системного мышления. Книга объясняет, как мыслить через обратные связи, рычаги влияния и динамику систем.
Технологические и архитектурные карты
Для полноты понимания продукта как системы обязательно нужно знать, как он технически устроен. Без этого системный взгляд неполон.
Какие сервисы от каких зависят? Что сломается при изменении API? Где лежат риски масштабирования? Какие есть технические ограничения? Ну или хотя бы банально нужно понимать, микросервисы или монолит используются в разработке продукта.
Просматривай дашборды не только по «продуктовым» метрикам, но и по инфраструктуре (время отклика, аптайм), по поддержке (время до ответа, повторные обращения), по финансам, по операционным метрикам. Продукт сильно шире, чем метрики «здоровья».
Рекомендую минимум раз в неделю просматривать дашборды или вообще начинать свой день с Яндекс.Метрики или Google Analytics. Пробегайся по основным отчётам и смотри на динамику самых разных метрик. Системный продакт собирает сигналы со всей системы.
Customer Journey Map (CJM)
Это считается инструментом дизайнеров, но рекомендую его использовать и для продуктовой работы. Сделай скриншоты всех экранов в продукте и построй из этого карту переходов с экрана на экран, указывая точки входа. Пройдись по карте и проставь комментарии к смущающим тебя моментам. Дай посмотреть карту коллегам и/или дизайнерам. Пусть они тоже оставят комментарии, вопросы и предложения.
CJM — хороший инструмент для поиска слабых мест в продукте. Он позволяет посмотреть на пользовательские сценарии с «вертолёта» и увидеть плюсы и минусы текущих решений в продукте.
Тоже самое в формате тг-канала: https://t.me/pm_faq. Сначала будет выходить там отдельным постами по чуть-чуть, потом здесь большой статьей.
