Какие фреймворки должен знать продакт-менеджер

Product Management требует глубокого понимания рынка, конкуренции, болевых точек и потребностей клиентов. Задачи, которые решает продакт менеджер очень разнообразны — от принятия важных решений по продукту до сотрудничества с маркетологами, приходится часто переключаться на контекст и посещать множество встреч. Вот почему продакт менеджеры обычно полагаются на разные фреймворки для оптимизации рабочих процессов, создания повторяемых процессов и поддержки устойчивого развития продукта. В этой заметке я постараюсь описать лучшие фреймворки и объясню, как получить максимальную отдачу от каждого из них.

Гибкие методологии и фреймворки

Вот несколько Agile- структур и подходов, которые можно использовать в циклах разработки продуктов.

Lean Canvas

Lean Canvas был разработан, чтобы помочь стартапам проанализировать сильные и слабые стороны их бизнес-модели. Он был разработан Эшем Маурья как вариант бизнес -модели Canvas (первоначально созданной Александром Остервальдером).

Технически говоря, Lean Canvas — это одностраничный документ, разделенный на девять блоков. Каждый сегмент ставит перед вами задачу определить области риска и возможностей, устранить болевые точки клиентов и создать действенный план для запуска и развития бизнеса. Они имеют следующие заголовки и описания:

Сегменты клиентов – перечислите своих целевых клиентов и пользователей.
- Ранние последователи – перечислите характеристики ваших идеальных клиентов.
Проблема – перечислите 3 основные проблемы вашего клиента.
- Существующие альтернативы – перечислите, как эти проблемы решаются сегодня.
Потоки доходов – перечислите источники доходов.
Решение – обрисуйте возможное решение для каждой проблемы.
Уникальное ценностное предложение – единое, ясное и убедительное сообщение, которое превращает ничего не подозревающего посетителя в заинтересованного потенциального клиента.
- Концепция высокого уровня – опишите свою идею простыми словами. Вы даже можете привести аналогию X вместо Y (например, YouTube = Flickr для видео).
Каналы – укажите свой путь к клиентам.
Ключевые показатели – перечислите ключевые цифры, которые говорят вам, как идет ваш бизнес.
Структура затрат – перечислите свои постоянные и переменные затраты.
Несправедливое преимущество – то, что невозможно легко скопировать или купить.

Lean Canvas — это не просто статический лист со всей информацией о вашей бизнес-модели. Это живой документ, который регулярно обновляется заинтересованными сторонами согласно отзывам клиентов. Рекомендую заполнять эти поля в том порядке, в котором они указаны выше: это проще и, по опыту, требует меньше времени.

Lean Canvas помогает визуализировать предлагаемую бизнес-модель и подумать о том, как мы можем решить реальную проблему, а не просто создавать функции ради функций.

Разработка, основанная на функциях

Разработка на основе функций (FDD) — это ключевая концепция Agile, которую необходимо знать менеджерам по продуктам, уже использующим другие гибкие методы. В последнее время этот подход стал более распространенным.

Разработка на основе функций состоит из пяти основных процессов, а именно:

Разработайте общую модель. Рассмотрите все требования проекта и посмотрите на картину в целом: что должен делать ваш новый продукт? Как будет работать система и как будут связаны разные ее части? Эта архитектура послужит основой для последующих шагов процесса разработки.
Создайте список функций. Определите и расставьте приоритеты в списке функций, которые необходимо разработать с участием заинтересованных сторон (например, маркетологов, дизайнеров, руководителей высшего звена и даже клиентов).
Планируйте по функциям. Допустим, вы создаете систему здравоохранения, и одна из функций в вашем списке — «назначение встреч». Чтобы повысить эффективность, эту эпопею следует разбить на ряд более мелких задач, например, изменение встречи, настройка уведомлений и т. д.
Дизайн по характеристикам. Здесь команда разработчиков создаст подробный пользовательский интерфейс и UX для каждой функции, возможно, даже прототип.
Создавайте по функциям. Как только этот дизайн будет одобрен командой продукта/заинтересованными сторонами, эта функция будет создана и реализована вместе с другими в рамках спринта. И цикл повторяется.

FDD хорош, потому что он поддерживает быстрое развитие (что является обязательным условием в этой конкурентной среде) и позволяет команде разработчиков сосредоточиться на ценности, которую они могут принести клиентам. Функции должным образом планируются, разрабатываются, тестируются и проверяются, что гарантирует, что ресурсы разработки не будут потрачены зря.

Минимально жизнеспособный продукт (MVP)

Многие стартапы терпят неудачу, потому что тратят месяцы – даже годы – пытаясь создать «идеальный» продукт, вместо того, чтобы прислушиваться к мнению своих клиентов. Но при разработке новых продуктов победа не может быть достигнута медленными и постоянными усилиями, а адаптируемыми, быстро обучающимися командами.

И вот здесь на помощь приходит MVP. Минимально жизнеспособный продукт , или MVP, — это создание базовой версии идеи вашего продукта, обмен ею с целевой аудиторией, сбор отзывов клиентов и повторение вашей идеи. Эта концепция, впервые предложенная Эриком Райсом, является фундаментальной концепцией его методологии бережливого стартапа.

MVP включает в себя только основные функции и возможности, необходимые для решения проблемы клиента или предоставления пользы пользователю . Вместо того, чтобы гоняться за совершенством, команды работают над достижением соответствия продукта рынку быстрее, чем конкуренты, и улучшением пользовательского опыта на каждом этапе.

CustDev

Как и MVP, CustDev — это скорее стратегический подход, чем структура, но это все же концепция, с которой должен ознакомиться каждый менеджер по продукту.

CustDev предполагает раннее и частое взаимодействие с клиентами, чтобы получить представление об их болевых точках, потребностях, предпочтениях и поведении. Этот процесс состоит из четырех ключевых этапов: обнаружение клиентов, проверка клиентов, создание клиентов и построение компании.

Вот некоторые из наших главных советов для проведения CustDev:

Подготовка имеет решающее значение. Заранее проведите большое исследование. Выстраивайте гипотезы для проверки ваших предположений о вашем новом продукте, целевой аудитории, компании и т. д. И тщательно выбирайте участников – выбирайте потенциальных платящих пользователей, а не просто любопытных людей.
Задавайте открытые вопросы. Не просите собеседника сказать вам, является ли подход X хорошей идеей, будет ли он использовать функцию X и так далее. Вместо этого спросите, как они относятся к X или когда они в последний раз его использовали. Пусть ваши клиенты скажут вам, что они на самом деле думают.
Практикуйте эмпатию. Постарайтесь сразу же успокоить собеседника – объясните цель звонка и как отвечать на вопросы. Сохраняйте легкую атмосферу и плавный ход разговора, но слушайте больше, чем говорите.
Запишите интервью. Скорее всего, ваше собеседование пройдет онлайн. Рекомендуем записать его, чтобы не перефразировать ответы клиентов. Их точная формулировка может дать подсказку о том, что следует улучшить.

Механизмы расстановки приоритетов

Вот две наиболее эффективные структуры для планирования продукта, управления рабочей нагрузкой и организации приоритетов проекта.

MoSCoW

MoSCoW — одна из самых популярных систем расстановки приоритетов, и это правильно. Это просто, практично, легко запоминается и может использоваться в самых разных контекстах. MoSCoW был разработан в 90-х годах Даем Клеггом, который в то время работал в Oracle.

Каждая заглавная буква в MoSCoW обозначает уровень приоритета, от высокого к низкому. Буквы означают « должен иметь», «должен иметь», « мог бы иметь» и «не иметь».

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

Must-have— это требования высшего приоритета. Приложение позволять клиентам просматривать каталог товаров и совершать покупки онлайн.
Should-haves — это требования второстепенного приоритета. Приложение позволять клиентам создавать учетную запись и сохранять информацию о доставке и оплате.
Could-haves — желательные дополнения. Было бы здорово, если бы в приложении оставлять отзывы о товарах.
Won’t-haves — это второстепенные функции, которые не обязательно включать в первоначальный выпуск. На данный момент приложение рекомендовать клиентам новые продукты на основе их прошлых покупок.

Не попадайтесь в ловушку, отмечая каждую функцию или задачу как обязательную. MoSCoW работает только тогда, когда команда честно и реалистично оценивает важность требований к продукту.

Модель оценки RICE

RICE — еще одна надежная система определения приоритетов, которую всегда можно иметь под рукой. Это изобретение Шона Макбрайда, бывшего менеджера по продукту компании Intercom, который хотел облегчить задачу определения приоритетов в дорожной карте продукта.

RICE — это аббревиатура от Reach, Impact, Confidence и Effort — четырех ключевых факторов, с помощью которых можно измерить каждую функцию, гипотезу или пользовательскую историю.

Чтобы продемонстрировать, как RICE работает на практике, предположим, что вы разработали приложение для социальных сетей и решаете, какие улучшения продукта реализовать в первую очередь. Одним из вариантов является инструмент перевода, который автоматически переводит сообщения и комментарии на разные языки, делая платформу более доступной для пользователей, не говорящих по-английски.

Мы можем оценить уровень приоритета функции по следующим факторам:

Reach — это количество людей, которые будут использовать эту функцию в течение определенного периода времени. Вы можете подсчитать, что половина вашей текущей ежемесячной базы активных пользователей будет использовать функцию перевода каждый квартал. Таким образом, охват составляет 10 тысяч клиентов в квартал.

Impact количественно определяет ценность, которую новая функция добавит вашему продукту. Чтобы помочь в этом, Intercom разработала « шкалу с множественным выбором : 3 для «массивного воздействия», 2 для «высокого», 1 для «среднего», 0,5 для «низкого» и 0,25 для «минимального». Допустим, вы решаете. что функция перевода имеет оценку влияния 1 на основе результатов ваших недавних проверок гипотез.

Confidence. Если у вас нет всех данных, подтверждающих ваш энтузиазм по поводу какой-либо функции, вы можете дать ей оценку уверенности. Измерьте это в процентах: 20% — это «высокая уверенность», 50% — «низкая уверенность», 80% — «средняя уверенность», а 100% — «высокая уверенность».

Effort . Это оценка количества времени и ресурсов, которые потребуются для реализации новой функции. Intercom рекомендует делать это, рассчитывая «человеко-месяцы» — сколько членов команды будут заниматься этой функцией каждый месяц до завершения.

Итак, формула определения приоритета: (Reach х Impact х Confidence) / Усилия = Оценка RICE.

Системы показателей продукта

Две надежные системы для точного измерения производительности продукта.

AARRR

Система показателей AARRR построена по образцу конверсионной или маркетинговой воронки . Впервые его разработал Дэйв МакКлюр, венчурный капиталист и основатель 500 Startups. Для облегчения произношения он назвал эту структуру «Пиратскими метриками».

Аббревиатура расшифровывается как «Привлечение», «Активация», «Удержание», «Доход» и «Реферал». Каждая метрика соответствует этапу пути клиента. Изучая изменения (или их отсутствие) в поведении пользователей на каждом этапе, PDM могут выявить области спада и измерить вовлеченность или неудовлетворенность пользователей. Вооружившись этими данными, они будут лучше подготовлены к целевому улучшению продукта.

AARRR:

Привлечение означает, сколько людей мы привлекли на платформу через такие каналы, как социальные сети, SEO или оплата за клик (PPC). Его можно измерить по рейтингу кликов, запросам на обслуживание и активности сайта.
Активация— это количество людей, которые создали учетную запись и начали использовать функции продукта.
Удержание — это количество пользователей, которые остались после регистрации.
Выручка — определяется ежемесячным регулярным доходом (MRR) или годовым регулярным доходом (ARR).
Рефералы — это количество пользователей, рекомендующих продукт другим.

OKR

OKR не сразу стал популярным, когда его впервые представил Эндрю Гроув из Intel в 1970-х годах. Фактически, он получил широкое распространение только тогда, когда Джон Дорр представил его Google в конце 90-х. Но с тех пор бесчисленное количество организаций выбирают эту систему постановки целей и показателей.

Цели и ключевые результаты, или OKR, помогают менеджерам по продукту устанавливать цели, соответствующие видению компании и стратегии продукта . В основном это позволяет командам сосредоточиться на результате, а не на задачах, необходимых для достижения цели. OKR обычно внедряется ежеквартально (проверки каждые 3 месяца).

Чтобы эффективно использовать эту структуру, начните с выбора амбициозной и измеримой цели продукта. Затем установите 3–5 ключевых результатов , которые помогут вам отслеживать прогресс в достижении этой цели.

Вот пример.

Цель: мы хотим увеличить вовлеченность пользователей вдвое в течение следующего квартала.

Ключевые результаты:

Увеличение ежемесячных активных пользователей на 20 %
Увеличьте количество функций, используемых каждым пользователем, на 10 %.
Увеличьте среднюю продолжительность сеанса на 15 %.

Ключевые результаты должны быть конкретными, привязанными ко времени (крайний срок – конец квартала) и подкреплены планом действий. Например, чтобы увеличить количество активных пользователей в месяц, ваша команда разработчиков может улучшить процесс адаптации и/или поэкспериментировать с новым текстом UX. Чтобы не сбиться с пути, вы можете организовать эти задачи в дорожной карте продукта.

Избегайте постановки слишком простых целей, таких как «Увеличение продаж». Будьте как можно более конкретны, потому что если вы достигнете своей цели слишком быстро, это признак того, что она недостаточно амбициозна.

Выводы

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

Share it