🧭 Рубрикатор-навигатор

Выражение "И чтец, и жнец, и на дуде игрец, и всем капец" идеально описывает идеального продакта. Потому что выбрав для себя путь Product Manager придется быть скилловым товарищем и иметь высокий уровень экспертности во многих областях.

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

1. Идея
- #JTBD_AGIMA
- #value_prop_AGIMA
- #custdev_AGIMA
- #marketing_reseach_AGIMA
- #design_thinking_AGIMA
2. План
- #roadmap_AGIMA
- #business_model_canvas_AGIMA
- #lean_canvas_model_AGIMA
- #cashflow_AGIMA
- #frameworks_AGIMA
3. Разработка продукта
- #development_methodologies_AGIMA
- #MVP_AGIMA
- #agile_AGIMA
- #lean_startup_AGIMA
- #user_stories_AGIMA
- #managing_team_AGIMA
- #user_interviews_AGIMA
- #release_notes_AGIMA
4. Качество
- #user_testing_AGIMA
- #dogfooding_AGIMA
- #demo_AGIMA
5. Запуск
- #user_guides_AGIMA
- #monetisation_AGIMA
- #community_management_AGIMA
- #cx_ux_AGIMA
6. Улучшение продукта
- #cx_ux_research_AGIMA
- #ab_testing_AGIMA
7. Общее для всех этапов
- #product_analysis_AGIMA
- #product_metrics_AGIMA
- #product_marketing_AGIMA
- #product_design_AGIMA
- #PM_reading_AGIMA
- #case_AGIMA
- #video_AGIMA
- #conference_AGIMA
- #knowledge_AGIMA

Это оглавление будет дополняться новыми рубриками и хэштегами для них — во имя развития этого канала и вашей профессиональной насмотренности 💪

📊 DIBB: больше фреймворков богу фреймворков

DIBB — это ещё один фреймворк, и он хорош. Его в свое время Spotify придумали для фокуса и приоритизации в рамках системы NSM (метрики всевластия, помните?)
Но в итоге он получился довольно универсальным и масштабируемым, причем не только на развитие продукта, но и на его создание.
DIBB полезен, когда нужно:
- систематизировать идеи
- поставить цели
- оценить необходимые ресурсы
- сравнить косты запуска и потенциальный результат
- определиться с решением о судьбе продукта — запуск работ/крэп
- составить бэклог и т.д.

DIBB выглядит так:

◼️ (D)ata
Согласно результатам проведенного анализа (бенчмаркинг, статистика, мониторинг рынка, CX-исследования и т.п.). мы видим, что...
◼️ (I)nsights
Из этого следует, что... (выводы из предыдущего пункта, инсайты).
◼️ (B)elief
Основываясь на данных и инсайтах, мы верим, что если мы... (сделаем то-то и то-то), мы получим... (такой результат в такие сроки).
◼️ (B)et
Для проверки нашего предположения мы можем задействовать ресурсы... (финансы, время, человекочасы) и выполнить... (список действий. Этот список не является обязательным для фреймворка, но упрощает задачу определения объема ресурсов).

При этом нужно на берегу определиться с критериями успеха и последующими действиями. Формат такой: «Критерием успеха нашей ставки будем считать... (описание результата с метрикой) не менее... . В случае успеха наши следующие шаги будут такими... . В случае неуспеха ставки поступим так.... ».

Работа по DIBB, как правило, итеративная, и на практике не всегда начинается с данных — бывает, что сначала появляется гипотеза. А ещё последовательность DIBB может быть фреймворком для отличной презентации стейкхолдерам 😏

#frameworks_AGIMA

✨ From hell to heaven

Нет, это не название какого-то трека или фильма. Это фреймворк, который помогает презентовать ценность продукта как внутреннему, так и внешнему клиенту. Сегодня мы не будем растекаться мыслью по древу, рассказывая про достоинства такого шаблона — просто почитайте, как он работает, и сами всё поймёте 😉

👿 Ад
В этой части мы формулируем проблему нашей ЦА в контексте. То есть, последовательно отвечаем на вопросы Кто/Что/Где/Когда. По опыту — этот пункт нуждается в большем времени и фокусе, чем остальные.
Пример:
У людей, использующих наушники, постоянно путаются (а иногда и рвутся) провода; как при непосредственном использовании, так и при хранении наушников.

😇 Рай
Здесь мы рисуем картину того, как всё должно быть в идеальном мире.
Пример:
Представьте, что вы вытаскиваете наушники из кармана и не тратите всё время поездки в метро, чтобы их распутать.

🪄 Решение
А на этом шаге мы рассказываем о том, как попасть в рай из ада (или вообще избежать этого неприятного места).
Пример:
Для этого мы и разработали беспроводные наушники. Вам больше не придется распутывать провода или бежать в магазин за новыми наушниками, когда случайно «зажевали» провод молнией куртки.

В общем, ещё один очень простой и работающий фреймворк в копилку ваших фреймворков.
Всем системного мышления!

#frameworks_AGIMA

🌳 Opportunity solution tree

Кто про что, а мы — про фреймворки. Сегодня про фреймворк, который полезен на тех самых начальных этапах из постов выше (на самом деле, он полезен на любых этапах, но для начальных тоже подходит 🙃).
Дерево возможностей и решений — простой способ визуализировать наш план по достижению результата. Как обычно, не будем тратить время на PR фреймворка, просто зацени‌те, как это работает.

1️⃣ Определяем желаемый результат
Самые эффективные деревья вырастают при наличии одной цели. Она должна быть определена всеми ключевыми заинтересованными сторонами и соответствовать бизнес-целям.
Если мы используем OKR, то можно добавить ключевые результаты и рассматривать их как результат продукта.

2️⃣ Определяем возможности достижения результата
Любая боль или потребность клиента — это возможность (привет, CX-research!).
Когда разберемся c пространством возможностей, расставляем приоритеты исходя из наибольшего потенциального влияния на результат.

3️⃣ Определяем решения, соответствующие возможностям
Тут нужно побрейнштормить, и не стоит ограничиваться продуктовой командой. Идеи, которые не соответствуют ключевым возможностям, нужно игнорировать. А вот идеи, которые раскрывают возможности и влияют на результат, требуют особого внимания.

4️⃣ Тестируем решения и ищем лучшие
Если тест не пройден — можно попытаться усовершенствовать решение или просто перейти к тесту следующего.

Такой подход позволяет использовать ресурсы для достижения желаемого результата, без временны‌х потерь и случайных бесполезных для пользователя фич.

#frameworks_AGIMA

⚠️ ППО: что это и почему оно нужно

Прежде, чем мы беремся за новый продукт или развитие уже имеющегося, мы настаиваем на проведении ППО. ППО — это предпроектное обследование, которое помогает:
◾️ выявить целевую аудиторию продукта и «работы», на которые она готова наш продукт «нанять»
◾️ избавиться от неопределенности и получить формализацию процессов «as is»
◾️ определить функции, необходимые для MVP
◾️ сопоставить эти функции с реальными бизнес-процессами
◾️ разработать стратегию развития продукта
◾️ планировать ресурсы
◾️ подсветить потенциальные риски для всех участников.

ППО актуально не только для агентств — для запуска продукта самой компанией оно тоже необходимо. Знаем, что многие коллеги активно используют этот инструмент, и если вдруг вы не из их числа — настоятельно рекомендуем присмотреться. А чтобы это «присматривание» было более предметным, предлагаем познакомиться с нашим видением ☺️

Что включает в себя ППО в AGIMA:
1️⃣ Проведение серии интервью со стейкхолдерами, участниками связанных процессов, текущими/потенциальными пользователями
2️⃣ Анализ имеющихся регламентов, систем и любой документации, затрагивающей связанные процессы
3️⃣ Подготовка отчетного концепт-документа:
- цели и задачи
- схемы бизнес-процессов с их описанием
- реестр функциональных требований
- роли пользователей продукта
- ограничения
- среда функционирования
- предметная область
- требования к UI и UX
- взаимодействие между компонентами продукта и другими продуктами (опционально).
- etc. (список не закрыт, т.к. может видоизменяться в зависимости от целей и задач заказчика).

Думаем, важность ППО после того, что вы прочитали выше, очевидна. Так что пользуйтесь. Если будут вопросы — ждем в комментах, без знаний не оставим. Data-driven всем! ♥️

#roadmap_AGIMA
#managing_team_AGIMA
#JTBD_AGIMA
#frameworks_AGIMA

🧭 Продуктовая стратегия

Что-то давно у нас фреймворков не было. Соскучились, поди, по ним, родимым😉
Давайте про продуктовую стратегию сегодня поговорим. Что это за зверь такой и из чего он состоит. На зеленой стрелке видно, какое место продуктовая стратегия занимает в общей картине успеха продукта.

Стратегия продукта берёт наш вижн и воплощает его в жизнь, связывая его с работой продуктовой команды. И состоит стратегия из трёх обязательных элементов.Что же должно быть в каждом?

🔘 Проблемы
Какие проблемы мы пытаемся решить?
Какие сложности (внутренние или внешние) нужно преодолеть?

🔘 Решение
Какой продукт для решения проблем клиентов мы им предлагаем?
Какой сегмент ЦА является ключевым?
Какие особенности есть у продукта и в чем его конкурентное преимущество?

🔘 Действия
Что потребуется выполнить для реализации нашего решения?
Что мы считаем успехом?
Что необходимо добавить в наш роадмэп?

И помним, что наша стратегия не может быть статичной, ее составление — не разовая активность 💚

#frameworks_AGIMA

📊 Приоритизируй это!

Сегодня снова про фреймворки — обсудим приоритизацию. Вариантов много, мы активно используем разные, так что будет серия постов про наиболее популярные и любимые 💚

Но прежде чем начать погружение в тот или иной фреймворк, имеет смысл понять, как нам выбрать наиболее подходящую систему расстановки приоритетов. Для этого нужно ответить на три вопроса:

🔘Что будем приоритизировать?
Первый шаг для выбора фреймворка — понимание того, что именно нуждается в приоритизации — потребности, фичи, данные и т.д.

🔘Что нам даст приоритизация?
Какой смысл от расстановки приоритетов? В чем ценность и влияние на нашу работу? Полезно будет освежить в памяти KPI/OKR.

🔘Сколько у нас есть времени?
Для выбора наиболее релевантного фреймворка нужно знать сколько заложено времени на все этапы проекта.

Каждый фреймворк имеет свои достоинства и недостатки, и ответы на вопросы выше позволят выбрать наиболее подходящий вам, вашей команде и проекту.

Итак, фреймворк Кано.
Помогает приоритизировать цели и потребности пользователя. Измеряет их и классифицирует по пяти категориям качества на основании соотношения удовлетворенности пользователя и уровня функциональности той или иной фичи.

Плюсы
Вы смотрите через призму восприятия пользователя. С точки зрения управления продуктом, когда вы ориентированы на потребителя, важно убедиться, что продукт соответствует его требованиям.

Минусы
Не учитываются «хардовые» количественные данные, н-р, затраты и доход.

Категории/качества модели Кано

◼️ Обязательные атрибуты (Must-be, M)
Из названия понятно, что это те функции, без которых продукт не сможет работать ожидаемым образом. Например, наличие экрана у ноутбука. Очевидно, но чуть сложнее, чем кажется на первый взгляд.
Наличие Must-be-функций необходимо, но не приводит к высокому уровню удовлетворенности пользователя — вряд ли вы будете в восторге только от того, что у вашего нового ноутбука есть экран.

Остальные 4 атрибута/качества/категории и пример построенной модели рассмотрим в следующем посте, оставайтесь с нами 🤗

А если вы хейтер или поклонник этого фреймворка — ждем в комментах, расскажите о вашем опыте!

#frameworks_AGIMA

Модель приоритизации Кано, pt.2
(начало здесь)

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

◼️ Одномерные атрибуты (One-Dimensional, O)
Уровень удовлетворенности одномерной категорией напрямую зависит от уровня его функциональности (в комментах есть график 😉).
Например, оперативная память ноутбука. Определение одномерных атрибутов — более сложная задача, чем определение атрибутов обязательных. Нужно учитывать:
- число пользователей, готовых платить за улучшение этого качества
- добавочную ценность => отстройку от конкурентов за счет этого атрибута
- влияние улучшений на стоимость для пользователя и ее соответствие ожиданиям.

◼️ Привлекательные атрибуты (Attractive, A)
Привлекательные качества не являются существенными для выполнения основной функции продукта, но при этом влияют на его ценность, например, бесплатная доставка нашего ноутбука.
Однако следует понимать, что с развитием технологий некоторые атрибуты могут переходить в разряд обязательных или одномерных.

◼️ Неважные атрибуты (Indifferent, I)
Те функции продукта, которые мало волнуют нашего пользователя или вовсе ему безразличны, например, цвет корпуса ноутбука (однако для определенной категории покупателей и он может иметь значение).
Определение таких качеств даст возможность избежать лишних затрат на оптимизацию этих функций.

◼️ Нежелательные атрибуты (Reverse, R)
Противоположность одномерным атрибутам. Те качества продукта, которые по мере своего роста снижают уровень пользовательской удовлетворенности. Например, избыточное количество кнопок у того самого ноутбука.

А теперь к самому интересному. Чтобы провести анализ Кано, нам нужен опрос. И для него надо:
1️⃣ Подготовить список функций, который нуждается в приоритизации

2️⃣ Определить сегменты пользователей

3️⃣ Разработать анкету
Кано-опросы состоят всего из двух вопросов:
- как бы вы себя чувствовали, если бы у продукт была эта функция?
- как бы вы себя чувствовали, если бы продукт не имел этой функции?
С вариантами ответов:
- Мне бы понравилось
- Я ожидаю этого
- Мне все равно
- Мне бы это не понравилось, но я могу с этим смириться
- Мне бы это не понравилось, из-за этого я бы не использовал продукт.
К каждой паре вопросов полезно добавить один дополнительный:
«По шкале от 1 до 9 (где 9 — «невероятно важен», а 1 — «совсем не важен») как много значит для вас эта функция?». Это упростит процесс приоритизации.

4️⃣Анализ результатов. В комментариях есть диаграмма распределения функций в зависимости от ответов респондентов, она поможет корректно определить атрибут. Также на этом этапе нужно рассчитать средний уровень важности, который указали респонденты, если мы использовали дополнительный вопрос.

Фреймворк приоритизации Кано дает возможность понять ожидания пользователей от продукта, и это понимание поможет развивать те функции, которые наиболее востребованы конечным потребителем.

#frameworks_AGIMA

🌇 MoSCoW calling!
Фреймворки приоритизации, pt.3

Надеемся, что новогодние каникулы зарядили вас положительными эмоциями, и вы (как и мы) с новыми силами врываетесь в трудовые будни. А мы начинаем год с еще одним фреймворком для приотизации — MoSCoW.

Как и Кано, MoSCoW является клиентоцентрированной моделью, приоритеты отвечают запросам пользователей. Название фреймворка — это аббревиатура, которая означает:

◼️Must have — Необходимо — функции, обязательные для удовлетворения основных потребностей пользователя в продукте для решения ключевых проблем/болей/«работ».
◼️Should have — Должно быть — функции, ожидаемые пользователем, превращающие решение в комплексное.
◼️Could have — Могло бы быть — функции, которых не ожидал пользователь, но он им рад (аналогично привлекательным атрибутам в Кано).
◼️Won’t have — Не будет — функции, которые не требуются. Они замедлят процесс разработки и необоснованно затянут срок релиза.

Плюсы
Легко и быстро реализуется на практике.
Можно приоритизировать, не имея технического и исследовательского бэкграунда.
Подходит не только для фич и частей продукта, но и для задач, и для всевозможных активностей — в рамках преисполнения тайм-менеджментом тоже можно использовать.

Минусы
Риск смещения приоритетов в сторону переоценки функций для Must have из-за субъективности оценки (Кано в этом плане ощутимо надежнее из-за элемента CX-исследований).

Если вы еще не пробовали этот фреймворк — самое время потестить на своих задачках, дабы продуктивно вкатиться в новый рабочий год 😏

#frameworks_AGIMA

RICE
Фреймворки приоритизации, pt.4

Пожалуй, самый популярный фреймворк приоритизации. Традиционно, это аббревиатура из первых букв критериев этого метода:
◼️ Reach (Охват) — количество пользователей, на которых повлияет та или иная фича.
◼️ Impact (Влияние) — например, низкий, средний и высокий уровни воздействия на пользователя.
◼️ Confidence (Уверенность) — число в процентах, которое отражает уровень вашей уверенности в оценке других критериев фреймворка — например, 90-100% — высокий, 60-80% — средний, 0-50% — низкий.
◼️ Effort (Усилия) — то есть трудозатраты, которые оцениваются в человеко-часах/неделях/месяцах, в зависимости от рассматриваемых фичей.

В итоге каждая функция будет иметь свою определяющую RICE-оценку, и, сравнивая эти оценки между собой, можно расставить приоритеты.

Плюсы
Это просто. Всего четыре критерия, доступных для количественного измерения.

Минусы
Основано на общих предположениях. Не учитывает зависимости (а они почти всегда есть).

#frameworks_AGIMA

🃏 Planning Poker | Scrum Poker

Нет, это мы не предлагаем вам стрит собрать. Всего лишь еще одна модель приоритизации, которая нам нравится 👌

Для этого метода вам потребуется:
- список фич, который нуждается в расстановке приоритетов
- модератор, не участвующий в обсуждении, но отслеживающий тайминг
- несколько колод карт (по числу участников встречи)/App в Miro «Planning Poker»

1️⃣ Продакт представляет обзор фичи из списка, отвечает на вопросы команды, которая обсуждает фичу и возможные риски.
2️⃣ После обсуждения участники выбирают по одной карте (рекомендуем использовать не больше 6 карт на участника, наборы должны быть одинаковыми) и кладут их рубашкой вверх.
3️⃣ Каждый участник называет свою карту и переворачивает её.

Если оценка совпадает у всей команды, то это и становится итоговым приоритетом. Если нет — цикл обсуждений повторяется.

Плюсы
В первой итерации нет искажения из-за оценки другого участника команды.
Нет ограничений по критериям сравнения.
Хороший тамада, и конкурсы интересные. Процесс приоритизации получается с элементами тимбилдинга.

Минусы
Часто решаем за пользователя.

#frameworks_AGIMA

📈 PMF как фреймворк: достигаем

Процесс достижения соответствия продукта рынку всегда будет итеративным, а не линейным. Его можно рассмотреть как фреймворк со следующими шагами:

1️⃣ Бизнес-модель
Если продукт уже запущен и выяснилось, что рынку он не соответствует, то первым шагом нужно вернуться назад и пересмотреть свою идею. Для этого можно использовать Lean Canvas.
Помните, что ни один бизнес-план не справляется с первым взаимодействием с пользователями.

2️⃣ Валидация идеи
Когда вы — автор идеи, всегда есть риск в нее «влюбиться» и проигнорировать этот шаг. Но прежде чем приступить к созданию продукта важно ответить на ключевые вопросы рынка — действительно ли:
- проблема, которую будет решать ваш продукт, существует?
- можно привлечь пользователей с минимальными/приемлемыми затратами?
- пользователи готовы платить за ваш продукт?

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

3️⃣ Интервью с пользователями
Независимо от того, хотим ли мы теперь запускать продукт или наши мечты уже не выдержали столкновения с суровой реальностью, важно извлечь максимум пользы из сделанного.
Пообщаться стоит хотя бы с зарегистрированными (будет достаточно 7 человек) и обязательно спросить:
- Как они нашли продукт?
- Почему зарегистрировались?
- Платят ли за альтернативу нашего продукта?

4️⃣ Разработка продукта и привлечение пользователей
После интервью у нас уже должно быть представление о необходимых фичах в MVP. А в части выбора и оптимизации каналов привлечения будет полезен фреймворк Bullseye.

5️⃣ Аналитика
Хорошая новость — мы запустились.
Плохая новость — это только начало.
На этом этапе мы строим воронки AARRR, замеряем конверсии, Retention и другие релевантные нашему продукту метрики.
Аналитика поможет лучше понять поведение пользователей и выявить «бутылочные горлышки», отвечая на большинство вопросов, которые могут у нас возникнуть.
Кроме вопроса «Почему?» 😏

Так что теперь повторяем шаги 3-5, пока не достигнем 40% (в опросе), следим за соотношением LTV/CAC.
Улучшаем продукт, оптимизируем каналы привлечения.
И делаем это на основании количественных и качественных данных.
Потому что data-driven!

#frameworks_AGIMA