Предыдущие статьи:
Продуктовое мышление
Какие методы помогают формировать продуктовое мышление?
Формирование продуктового мышления — это постоянная тренировка взгляда на продукт как на инструмент ценности, а не на объект разработки. И это очень важно понимать. Продукт делается для пользователей и существует только благодаря им. Фичи сами по себе не несут никакого смысла в отрыве от пользовательского опыта. Ты делаешь продукт не для себя и не для владельца компании. Всё крутится вокруг пользователя и его интересов.
Кратко о методах, позволяющих сформировать и закрепить продуктовое мышление:
Работа через фреймворки мышления.
Например:
Jobs To Be Done
Value Proposition Canvas
Product/Market Fit Pyramid
The Lean Canvas / Business Model Canvas
Всё это — готовые подходы к созданию продуктов, отражающие разный взгляд на продуктовое мышление и видение. Но все фреймворки так или иначе строятся на основе интересов конечного пользователя.
Погружение в контекст пользователя
В продукт не приносят ценность снаружи. Её можно только вырастить из реального опыта пользователя. Получить представление о пользовательском опыте можно через интервью, опросы, аналитические отчёты или прочувствовать самому.
Регулярная практика customer discovery
Общение с пользователями — не разовый этап, а постоянная дисциплина. Это мышца, которую надо качать. Общение может быть и косвенным — через дашборды и метрики здоровья продукта. Но старое доброе интервью ничто не заменит.
Развитие кросс-функционального взгляда
Продуктовое мышление — на стыке бизнеса, технологий, дизайна, психологии. Изучение смежных дисциплин помогает шире видеть и глубже чувствовать. Продуктовый менеджер — это специалист широкого спектра знаний. Это позволяет не только лучше понимать коллег, но и помогает эффективнее искать зоны роста продукта, формулировать вопросы к пользователю и понимать влияние вносимых в продукт изменений. Будь чуть-чуть дизайнером, чуть-чуть аналитиком и сильно продактом.
Работа с гипотезами
Формулируя гипотезы, отталкивайся от пользовательского опыта. Вместо «разработать фичу» — говори «проверить гипотезу». Это переключает мышление с реализации на результат. Так твоей основной задачей будет не развивать функциональность продукта, а усиливать его ценность. Вроде бы небольшая разница, но фокус и отношение меняются кардинально.
Как определить ценность продукта для пользователя?
Ценность — это не то, что мы закладываем в продукт (фичи), а то, что пользователь из него извлекает. Другими словами, это «полезность» продукта для пользователя. Сами по себе фичи никому не нужны — необходима только их ценность. Задача продуктового менеджера — наращивать ценность для пользователей. Изменение ценности напрямую влияет на продуктовые метрики. Рост метрик — следствие роста ценности.
Важным критерием для определения и роста ценности является понимание контекста пользователя. Нужно знать не только, кто пользователь, но и в каких условиях он пользуется продуктом: условия его жизни, работы и мотивация для принятия решений. Чем больше мы знаем о пользователях, тем меньше неопределённость и эффективнее развитие продукта. Ценность напрямую зависит от контекста. Один и тот же продукт может быть полезен для одного пользователя и бесполезен для другого. А также одним и тем же продуктом могут успешно пользоваться 2–3 независимые друг от друга группы. Понимание контекста и мотиваций каждой из них не позволит «сломать» продукт.
Исследования: качественные и количественные
Интервью: что пользователь делает, чувствует, чего боится, к чему стремится? Правильно заданные вопросы дают понимание о мотивации и «болях».
Дневниковые исследования: помогают увидеть реальные сценарии использования. Сейчас всё чаще такой метод исследований заменяется разметкой ключевых действий в продукте специальными событиями, которые записываются (логируются) в систему аналитики. Фактически, это дневник каждого пользователя и его взаимодействия с продуктом.
Анализ пользовательских метрик: Retention (возвращаемость), Engagement (вовлечённость), Churn (отток) и другие — поведенческие показатели, отражающие восприятие ценности. По метрикам, как правило, нельзя определить ценность, но они дают понять, в какую сторону «копать».
Вебвизор: если для аналитики используется Яндекс.Метрика, обязательно включи запись сессий и периодически их просматривай. Там можно обнаружить много неожиданного и интересного. Вебвизор — это кладезь для генерации гипотез и поиска точек роста.
Опросы: почти как интервью (и структура вопросов может быть схожей), но используются для количественной валидации результатов интервью. Между интервью и опросами для качественных исследований всегда стоит выбирать интервью.
Jobs To Be Done
В рамках концепции фреймворка пользователь не покупает продукт и не просто им пользуется — он «нанимает» его для решения конкретной задачи (работы). Если понять, какую работу он хочет выполнить с помощью продукта, станет ясно, где ценность. Согласно 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 показывают, как элементы продукта соотносятся по степени зрелости (стадии развития) и конкурентности. Что подтянуть? Какие элементы системы лишние? Карта Уордли подскажет. Подробнее.
Какие инструменты помогают смотреть на продукт в целом?
Если выше мы говорили об инструментах, позволяющих посмотреть на систему в целом — по компании и окружающей её среде, — то здесь обсудим подходы к продукту как к системе и методы управления этой системой.
Value Stream Mapping
Позволяет визуализировать путь создания ценности — от идеи до пользователя. Помогает понять, где потери времени, где дублируется работа, где тормозит поток ценности.
Используется не только в разработке, но и в анализе бизнес-процессов в продукте. Описывает все шаги, необходимые для «доставки» ценности до пользователя, включая шаги получения денег.
Определи шаги
Запиши ответственного за каждый шаг (кто занимается реализацией шага)
Оцени время, необходимое для перехода к следующему шагу
Посчитай итоговый 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 — хороший инструмент для поиска слабых мест в продукте. Он позволяет посмотреть на пользовательские сценарии с «вертолёта» и увидеть плюсы и минусы текущих решений в продукте.
Работа с неопределенностью
Как не бояться "не знать"?
Нам с детства внушают, что не знать — стыдно
Это приводит к тому, что мы начинаем избегать ошибок или, ещё хуже, — прикрывать ошибки, чтобы никто вдруг не подумал, что мы чего-то не знаем. Люди, в том числе из-за неудобства показаться глупыми, не задают вопросов. Ведь уточнения и вопросы — о, ужас! — могут показать, что я чего-то не знаю или не понимаю.
Незнание — часть работы продуктового менеджера и будничное состояние
В каком-то смысле именно незнание толкает нас работать над продуктом и искать пути его развития. И первое, что нужно принять: «не знать» — это нормально. Мы не всё знаем, потому что работаем в меняющейся среде: рынок, пользователи, команда, технологии — всё динамично.
Меняй мышление с «я должен знать» на «я должен разобраться»
Сильный продакт — не тот, кто даёт все ответы, а тот, кто умеет задавать правильные вопросы и находить решения. Одно вовремя заданное «зачем» может сохранить кучу времени и нервов.
Не бойся публично признаваться, что ты чего-то не знаешь
Попробуй хотя бы раз сказать: «Знаете, не знаю, как это решить». Это вызывает уважение, но только в случае, если за этим следует: «Но я выясню». Команда начнёт тебе доверять. Они поймут, что ты с ними честен.
Не старайся всё сделать сам
Ты не обязан быть экспертом в UX, фронте и маркетинге одновременно. Но ты можешь создать процессы и обстоятельства, при которых эксперты смогут донести свои знания. Пользоваться чужой экспертизой, к слову, — тоже не стыдно.
Как принимать решения в условиях неопределённости?
Мы редко знаем, что точно сработает. Но это не значит, что мы не можем принять хорошее решение. Хорошее решение всегда имеет обоснование, основанное на какой-то информации. Эту информацию нужно получить — это поможет уменьшить неопределённость и, соответственно, принять хорошее решение.
Для принятия решения следует чётко разделять факты и гипотезы (предположения). Определи, что ты точно знаешь, а что — нет. Поначалу можно выписывать в два столбца для наглядности. Со временем начнёшь отделять одно от другого «на автомате».
Не стоит искать сразу идеальное решение — его может попросту не существовать. Разбей проблему на шаги и начни понемногу воплощать этот план в жизнь. Скорее всего, ты работаешь не над ПО для атомных станций, и у тебя есть возможность ошибиться и всё вернуть, как было. Используй эту возможность. Если не знаешь, что за углом — просто загляни туда: делай MVP, прототипы, исследования на реальных пользователях.
Лучше быстрее выйти с решением на рынок и получить обратную связь, чем долго разрабатывать идеальный продукт. В нашем быстро меняющемся мире «идеальное решение» может устареть в процессе разработки. Гибкость крайне важна, и скорый релиз поможет сохранить её.
Если решение можно отменить — действуй быстро. Если нет — потрать время на более серьёзное обоснование. Это принцип обратимых решений Amazon. По духу он близок к концепции Lean Startup.
Откуда взять чёткие требования?
Начни с «зачем». Опиши, какую задачу решаем, какую ценность создаём, в каком контексте эта ценность важна для пользователя. Это важнее, чем «что делать». Менеджеров часто троллят вопросом «чтобы что», но это база продуктового менеджмента. Любая ценность должна иметь ответ на этот вопрос.
Собери кусочки из разных источников: пользовательские боли, цели бизнеса, метрики, ограничения. На их основе можно выстроить требования.
Разговаривай с командой и стейкхолдерами. Через совместную работу можно быстро прояснить ожидания и прийти к общему результату. Не бойся сделать черновик решения и принести его на обсуждение. Опиши драфт требований, покажи заинтересованным лицам, собери фидбэк и уточни требования, учтя обратную связь. К слову, это всё — часть методологии Scrum по управлению проектами.
Как принимать решения при ограниченных данных?
Продакт почти всегда работает с недостатком данных. Полной картины не будет. С этим следует смириться. Но всё знать и не требуется. Нужно знать столько, чтобы можно было сформулировать уверенную гипотезу, которую дальше нужно проверить на реальных пользователях.
Фокусируйся на том, что критично. Найди 1–2 ключевые метрики или сигнала, которые дадут направление.
Опирайся на аналоги. Скорее всего, кто-то уже сталкивался с такой проблемой. Посмотри, как решали подобные задачи в других продуктах или командах.
Используй экспертное мнение. Проведи быстрые интервью или консультации, поищи отчёты от аналитических агентств или экспертизу внутри компании.
Приоритизируй быстрые эксперименты. Вместо долгого сбора данных — проведи A/B-тест, юзабилити-тест, запусти лендинг.
Оцени стоимость ошибки. Если цена ошибки низкая — действуй. Если высокая — ищи способ снизить риски: поищи больше информации, разбей решение на задачи поменьше, сделай релиз только на часть пользователей.
Какие техники помогают структурировать неизвестное?
Assumption Mapping
Расположи гипотезы на координатной плоскости. По горизонтальной оси располагай гипотезы относительно их важности для пользователя (слева от центра — самые неважные, справа — самые важные), а по вертикальной оси — насколько они проверены. Это поможет определить, что проверить в первую очередь, а что уже можно взять на реализацию.
Opportunity Solution Tree
В корне находится некая проблема, и в разные стороны расходятся пути её решений. Помогает не зацикливаться на одном подходе. Подробнее. Очень похоже на подход JTBD с графом работ.
Customer Journey Map
Набор экранов продукта с указанием пользовательских путей. Даёт понимание, где в опыте пользователя есть пробелы или болевые точки.
Pre-mortem
Командная сессия: представьте, что проект провалился — почему? Позволяет заранее выявить слабые места.
Рамка “Knowns / Unknowns / Assumptions / Risks”
Простая матрица, которая даёт видимость текущего состояния неопределённости. Разбей лист на 4 части и в каждый угол по отдельности выпиши: что известно, что неизвестно, какие есть предположения и какие риски.
Эмпатия и коммуникация
Как развивать эмпатию к пользователям и команде?
Вопреки расхожему мнению, эмпатия — это навык. Я бы даже сказал, это привычка. Её можно и нужно развивать. Для продакт-менеджера важно уметь поставить себя на место как пользователя, так и разработчика, дизайнера, аналитика и других членов команды. Важно уметь понимать «ту сторону».
Развиваем эмпатию к пользователям
Регулярно общайся с пользователями. Интервью, наблюдения (по метрикам, вебвизору или своими глазками), общение с поддержкой или работа в ней, чтение отзывов о продукте, участие в чатах комьюнити и чтение комментариев в соцсетях — это окно в мир пользователей. Не нужно скрываться от обратной связи. Чем больше ты слышишь «живых» историй — тем легче понять настоящие мотивации и боли.
Customer Journey Mapping. Попробуй пройти путь пользователя от начала до конца: от первой рекламы или магазина приложений до отказа от продукта. Это помогает обнаружить слабые места и барьеры, которые иначе остаются невидимыми. Старайся делать это регулярно, но не слишком часто. Продукт меняется, и пользовательский путь тоже меняется вслед за ним. Особенно важен первый контакт с продуктом. И начинается он зачастую не с самого продукта.
Работа с жалобами и обратной связью. Это настолько важно, что вынесу отдельно и повторю. Именно в негативной обратной связи рождаются инсайты. Эмпатичный PM умеет слушать, а не защищаться. Но зацикливаться на негативе не нужно. Действительно, именно в негативных отзывах больше правды, но и позитивное тоже нужно «обрабатывать». Если есть возможность связаться с автором отзыва — вообще прекрасно. Делай это. Пригласи человека на разговор, послушай все его боли, постарайся найти причины.
Вообще-то это люди. Работай с профилями пользователей не как с сухими аватарами, а как с реальными людьми — со своими болями, ограничениями, контекстом. Да, в дашбордах это выглядит как просто набор цифр. Но за цифрами скрываются люди. Помни об этом и старайся к цифрам относиться как к людям — ведь именно они их генерируют. Поначалу может показаться, что это шизофрения какая-то, но для развития эмпатии важно помнить про людей в любом аспекте работы над продуктом.
Эмпатия к команде:
Встречи один на один. Регулярные и искренние разговоры позволяют понять внутренние мотивации, проблемы и амбиции коллег. Ван-ту-ваны полезны даже если ты не руководитель. Это просто инструмент, который позволяет в функции, которую коллега выполняет, увидеть человека. Просто так приглашать на разговор может быть странно, но если появляется возможность созвониться — не избегай её.
Погружение в контекст. Попробуй понять, как коллеги принимают решения и на чём основана их экспертиза. И всегда доверяй решениям команды в их области. Если тебе не дали повод сомневаться — не сомневайся. Доверие и понимание сути профессии каждого члена команды помогает формировать эмпатию.
Принцип «люди стараются». Если что-то идёт не так или работа сделана, на твой взгляд, плохо — начни с предположения, что человек хочет как лучше, просто у него может быть другой контекст или ограничение. Сначала поищи причины, почему вышло как вышло, и постарайся помочь. Также стоит придерживаться принципа: «ругай лично, хвали публично». То есть инициировать разговор о «косяке» коллеги лучше в личных сообщениях или звонке на двоих — и там всё обсудить. Это поможет сохранить атмосферу в коллективе.
Совместное празднование успехов. Эмпатия — это не только про поддержку в сложностях, но и про умение искренне разделить радость. Продукт побил рекорд по трафику? Расскажи об этом команде! Получили позитивный фидбек в отзывах о последнем обновлении? И об этом расскажи. Любые успехи нужно «шерить» команде.
Какие приёмы помогают улучшить коммуникацию?
Коммуникация — это мост между людьми. А в роли продакта ты — архитектор этого моста. Да, пафосно. Часто только продуктовый менеджер заинтересован в эффективной коммуникации, потому что только ему виден эффект от взаимодействия членов команды, других команд и между отделами компании. Но прежде чем начать выстраивать межкомандное взаимодействие, начать нужно даже не со своей команды, а с себя самого. Ты, как PM, должен эффективно взаимодействовать с коллегами в первую очередь.
Активное слушание
Звонки и встречи нужны для коммуникации. Не нужно на встречах работать и отвлекаться. Будь в диалоге. Раз уж ты на встрече — слушай, вникай, участвуй. Непонятно — уточняй, задавай вопросы. Будь участником коммуникации, не будь массовкой. А если на встрече тема тебя не касается, то, вероятно, стоит на такие встречи не ходить совсем. Отказываться от ненужных встреч — тоже очень полезный навык.
Контекст > команда > ты
Рассказывая что-то команде (например, объясняя задачу): сначала объясни, почему это важно, затем — что требуется от команды, и только потом — какую часть делаешь ты. Или если кратко: дай контекст, расскажи цель, объясни, какую часть возьмёшь на себя. И именно в таком порядке.
Прозрачность и предсказуемость
Командные процессы должны быть понятными и очевидными. Делись апдейтами и спрашивай изменения у других. Например, философия Scrum построена именно на этом. Дейлики (ежедневные встречи) позволяют синхронизироваться с достаточной частотой и быстро обнаруживать проблемы и находить для них решения. Но делиться изменениями можно и реже — например, раз в неделю. Ещё реже не рекомендуется.
Единая терминология
Убедитесь, что все понимают одинаково. Терминология в команде должна быть одинаковой. Вы должны говорить на одном языке и называть одни и те же вещи одинаковыми именами. Это часто источник недопонимания. Можно даже словарик завести по основным терминам и сущностям в продукте.
Асинхронная коммуникация
Документы, заметки, структурированные обсуждения в Slack, Mattermost или Notion позволяют сократить количество встреч и дают всем время подумать. Не нужно созваниваться по любому вопросу. Если обсуждение текстом не занимает больше 2–3 сообщений, то можно обойтись только перепиской. Но созвоны — эффективнее. И пиши документацию. Подобные артефакты сильно облегчат жизнь тебе самому в будущем.
Спор — это нормально
Главное, чтобы спор оставался обсуждением, а не атакой на людей. Споры обычно возникают между вовлечёнными людьми. И если у тебя в команде спорят — значит, коллегам не плевать на результат. А это здорово!
Как распознавать скрытые потребности пользователей?
Пользователь редко говорит правду. И врёт он не намеренно. Пользователь просто не может объяснить своих желаний и мотивацию. Это нормально. Его слова — это только верхушка айсберга. Чтобы распознать глубинные потребности, нужно уметь копать глубже.
Метод «5 почему»
Когда пользователь говорит: «Сделайте кнопку больше», — спрашивай «почему» до тех пор, пока не дойдёшь до корневой причины. Возможно, он просто не замечает кнопку из-за перегруженного интерфейса. Конечно, не нужно напрямую доставать пользователя этими «почему». Ищи вариации вопроса.
Наблюдение
Смотри, как пользователь взаимодействует с продуктом, а не только что он говорит. Часто действия и слова не совпадают. Если у вас интервью, попроси пользователя показать, как он решает задачу. Прямо вот пройтись по шагам, комментируя свои действия. Ты можешь сделать удивительные открытия.
Спрашивай о прошлом опыте
«Расскажи, как ты последний раз решал эту задачу» — такой вопрос раскрывает реальные сценарии, а не гипотетические желания. Не нужно строить вопрос из предположения — «Расскажи, как бы ты поступил в такой ситуации». Тебе соврут, потому что на самом деле не знают ответа. Признаться в незнании тяжело, поэтому тебе что-то ответят из вежливости.
Поиск неудобства
Всё, что вызывает раздражение, фрустрацию, обходные пути, — маркеры скрытых потребностей. Если пользователи используют продукт не так, как ты это задумал, — это не они «дураки», а ты не так решаешь их задачу. Поищи, почему вышло так, что пользователи используют продукт иначе. Люди не всегда умеют сформулировать, что их бесит, — но это поле для улучшения.
Сегментация по мотивациям, а не демографии
Пользователи могут быть разного возраста и пола, но иметь схожие мотивы. Изучай не кто они, а зачем они приходят в продукт. Пол, возраст и география — абсолютно вторичные вещи. Это важно для маркетинга, а для развития продукта важна мотивация и цели пользователя.
Итог третьей главы
Продуктовое мышление — это умение видеть продукт как способ создать ценность, а не просто как набор фичей.
Пользователь — центр всего. Продукт существует ради решения его задач, а не ради бизнес-идей или технологий.
Пользователи не всегда осознают свои потребности — важно уметь копать глубже, слушать, наблюдать, разбираться «почему».
Конфликт между интересами бизнеса и пользователя решается фокусом на ценности. Сначала — польза, потом — деньги.
Системное мышление — важнейший навык PM. Нужно видеть связи, потоки, последствия изменений.
Смотри на продукт целостно: от идеи до денег, от архитектуры до эмоций пользователей.
Быстрое тестирование решений и MVP-итерации важнее «идеального» плана.
Развивай эмпатию — к пользователям и к команде. Это укрепляет доверие и даёт инсайты.
Коммуникация — ключевая зона ответственности PM. Будь понятным, открытым и предсказуемым.
Сегментируй пользователей по мотивациям, а не по демографии.
Не бойся признаться, что не знаешь. Главное — быть тем, кто может найти ответ и повести за собой.
Тоже самое в формате тг-канала: https://t.me/pm_faq. Сначала будет выходить там отдельным постами по чуть-чуть, потом здесь большой статьей.