Product Management 101
В университетах США есть традиция нумеровать курсы в пределах направления. Номер 101 — так часто обозначают вводный курс для новичков.
В статье перечислю перечислил то, из чего состоит управление продуктом (PM). Этот список не может быть одним общепринятым и полным. Воспринимайте его как набор терминов, отправную точку для дальнейшего исследования.
По тексту есть ссылки на отдельные методы, подходы, фреймворки.
Даны термины на английском языке. Раньше я не любил включать иностранные слова в русскую речь. Но дело в том, что англоязычные эквиваленты как раз общеприняты. Если вы скажете user story, epic то и вы поймете, о чем речь, и ваш собеседник тоже. Русские эквиваленты (истории пользователей, эпики) не так однозначно понимаемы.
Содержание
- Жизненный цикл продукта (PLC). Разработка продукта (NPD)
- Идеи (Ideas & User Needs)
- Анализ конкурентов и рынка (Competitors & Market analysis)
- Развитие на клиентах, клиентоориентированное развитие (Customer Development)
- Эксперименты (Experiments) и Минимально жизнеспособный продукт (MVP)
1. Жизненный цикл продукта (PLC). Разработка продукта (NPD)
Жизненный цикл продукта (Product Life Cycle, PLC) часто представлен как последовательность 4-х стадий. Каждая из стадий отличается своими особенностями с точки зрения развития продукта и его маркетинга.
Процесс разработки продукта (New Product Development, NPD) включает 7 стадий.
2. Идеи (Ideas & User Needs)
Сбор идей
Сбор идей происходит на разных стадиях развития продукта: в момент планирования, создания MVP, поддержки уже готового продукта. Распространенные источники идей собраны в аббревиатуру EMUC (Employees, Metrics, Users, Clients), то есть сотрудники, показатели, пользователи, клиенты.
Отличие пользователей от клиентов в том, что пользователи непосредственно работают с продуктами (например, SMM-менеджер с агрегатором статистики), а клиент оплачивает использование продукта (руководитель отдела маркетинга). У этих двух категорий могут быть разные оценки продукта и идеи по улучшению.
Оценка идеи
Не все идеи достойны того, чтобы быть принятыми в работу. При анализе идеи полезно задать вопросы:
Оценка идеи 2
Альтернативный и дополняющий подход состоит в том, что хорошая идея приводит к одному или нескольким позитивным результатам:
3. Анализ конкурентов и рынка (Competitors & Market analysis)
Оценка рынка
Оценка рынка не обязательно должна быть точной, но хорошая оценка верно отражает порядок, а самое главное — динамику.
Объем рынка, на который выводится продукт, можно оценивать «сверху» (Top Down) и «снизу» (Bottom Up).
Оценка сверху отталкивается от расчета возможного спроса, емкости. Например, для оценки рынка мужской обуви в РФ можно идти от того, что мужчины составляют треть населения страны (50 млн чел.) и покупают новую пару раз в год — 50 млн пар обуви в год. Дальше можно уточнять по демографии, виду продукции и т. п.
Оценку снизу получают суммированием известных показателей участников рынка. Если в России работают пять производителей мужской обуви, каждый производит по 10 млн пар в год, то при условии нулевой внешней торговли и нулевых складских запасов получается та же оценка — 50 млн пар в год.
Поиск конкурентов
Если у вашего продукта нет конкурентов, то это признак того, что:
Кроме прямых (предлагают схожий продукт) на рынке могут быть следующие группы конкурентов:
Оценка конкурентов
Один из возможных подходов к оценке компаний-конкурентов:
По каждому параметру конкуренту присваивают оценку. Шкала может быть какой угодно (от 0 до 5, от 0 до 10 и т.д). Итоговая оценка — это сумма оценок по пяти параметрам.
Таблица свойств (Feature Table)
По аналогии с оценкой конкурентов оценивают их продукты. Это делают с помощью таблицы свойств (Feature Table). В таблице принято откладывать по горизонтали сравниваемые компании, по вертикали — сравниваемые свойства. На основании сравнения, задав веса свойствам можно получить суммарную оценку продуктов конкурентов.
4. Развитие на клиентах, клиентоориентированное развитие (Customer Development)
Концепцию Customer Development предложил Стив Бланк (S. Blank). Это подход к построению продукта, в соответствии с которым от клиентов и пользователей постоянно получается обратная связь: идеи, гипотезы, пожелания. Акцент именно на постоянном характере обратной связи.
В этом фреймворке разработка продукта, а скорее уже процесс создание стартапа на основе продукта, состоит из четырех циклов:
Виды интервью
Разделение на виды очень условно. В пределах одного интервью могут быть вопросы разного характера. Интервью до выпуска продукта (pre-product) серьезно отличаются от интервью после выпуска (post-product).
- Исследовательское (Exploratory). Наиболее свободное по форме интервью: открытые вопросы для того, чтобы понять боли, контекст использования продукта, конкурирующие продукты и технологии и уйти с интервью с новыми идеями.
- Подтверждающее (Validation). Целью является подтверждение или опровержение гипотезы. В ходе интервью нужно стараться объективно понять особенности поведения респондента, не подталкивая его к желаемому ответу. Озвучить решение проблемы можно в завершении, также важно получить объективную оценку.
- Оценка удовлетворенности (Satisfaction oriented). В чем продукт хорош, а в чем плох.
- Эффективность (Efficiency interview). Здесь обратная связь используется для изменения продукта с целью повышения выбранных показателей эффективности (с точки зрения бизнеса, клиентов)
5. Эксперименты (Experiments) и Минимально жизнеспособный продукт (MVP)
Термин MVP (Minimal Viable Product) был предложен Эриком Ризом (E.Ries) во фреймворке Lean Startup. MVP — это такая версия продукта, которая позволяет собрать максимальный объем данных от пользователей при минимальных затратах.
👆Хорошая практика: за один MVP тестировать один функционал. Если одновременно тестируете несколько функционалов, нужно понимать, как эти тесты могут повлиять друг на друга.
Подготовка MVP состоит из семи шагов:
Допущения ранжируют по степени влияния на продукт, то есть, насколько велики будут отрицательные последствия для продукта в случае, если допущение окажется ложным. Обычно самое рисковое допущение — предположение о наличии потребности у потенциального клиента.
Второй измерение для ранжирования — сложность проверки допущения.
На основании комбинации риск-сложность определяют приоритет проверки допущений через MVP:
— Большой риск — Маленькие затраты
— Большой риск — Большие затраты
— Маленький риск — Маленькие затраты
— Маленький риск — Большие затраты (обычно не проверяют)
a. Мы думаем, что (пользователь, цель) будут (ожидаемое действие), потому что (причина).
b. Если мы (действие), то это приведет к тому, что (пользователь, цель) будут (ожидаемое действие), потому что (причина).
с. Мы думаем, что (пользователь цель) имеют (боль, потребность), потому что (причина). Если мы (действие), это приведет к тому, что метрика (ожидаемое состояние).
Во всех случаях причины лучше описывать в терминах болей и потребностей; хуже — в терминах ценностей и преимуществ.
10% результатов экспериментов носят однозначно бинарный характер: мы провели эксперимент и наша гипотеза однозначно подтвердилась или однозначно не подтвердилась.
В 90% случаев результат где-то посередине, поэтому нужно фиксировать MCS — рубеж, по достижению которого гипотеза будет считаться принятой.
Этот рубеж опирается на одну или несколько метрик. Как правило, в качестве MCS стараются выбирать такую точку, начиная с которой потенциальный доход превышает ожидаемые затраты на разработку.
Метрикой может быть процент пользователей, выполнивших действие, или соответствующих определенным условиям (провели в приложении столько-то времени, просмотрели столько-то страниц).
- Выбрать тип MVP-эксперимента.
Протестировать интерес пользователей в цифровой среде можно разными способами.
a. Email-анонс. Разослать письма с анонсом нового функционала и собрать обратную связь
b. Кнопка (Shadow Button). Разместить на сайте кнопку для доступа к новому функционалу и отслеживать клики. Клики могут переводить на страницу «Скоро».
c. 404 / Скоро (Coming soon). При интересе пользователя и переходе пользователя на страницу нового функционала показывать сообщение о скором создании раздела. Так часто делает Amazon.
d. Видео (Explainer video). В видео рассказать о новом функционале и выгодах для пользователя. Так стартовал Dropbox.
e. Лендинг (Landing page). Аналогично видео, но рассказать о преимуществах функционала на отдельной странице.
f. Консьерж (Concierge service). В случае интереса пользователя прикрепленный менеджер помогает пользователю выполнить те действия, которые потом будут реализованы в функционале.
g. Частичный MVP (Piecemeal). Часть функциональности MVP закрывается с помощью существующих сервисов автоматизации, таких как Google Docs, Zapier и проч.
h. Волшебник Изумрудного города (Wizard of Oz). Продукт притворяется, в то время как все действия новой функциональности выполняются вручную.
Типы MVP-экспериментов — подробное описание
- Провести MVP-эксперимент.
- Подвести результаты и сделать выводы.
MVP возвращают численные результаты. Для этого в начале допущения переводили в форму гипотез. На их основании данных PM принимают решение о том, стоит ли делать тот или иной функционал.
👆Хорошая практика: дополнить численные результаты качественными данными из интервью. Чтобы понять, почему пользователи сделали так, а не по-другому.
6. Моделирование (Conceptualizing)
Тут все несложно. Самое главное — принято различать три уровня моделей. Их лучше не путать.
Схема (Wireframe) — схематический рисунок, в котором картинки обозначаются перечеркнутыми прямоугольниками, рыбный текст, показано существование и размещение блоков. По мере обсуждения функционала команды уточняют схемы. Схемы обычно делает PM.
Как составить схему:
- нарисовать браузер
- в браузере нарисовать лого и основное навигационное меню
- понять цель страницы
- выписать сценарии, которые пользователи проходят на странице
Мокап (Mockup) — схема в цвете. В мокапе уже фиксируются места элементов и добавляются элементы дизайна. Точность мокапа выше, чем у схемы.
Прототип (Prototype) — модель, цель которой показать, как пользователь будет взаимодействовать с продуктом. Это самая точная модель, после согласования идет на разработку.
👆Взаимодействие с продуктом может быть показано уже на схеме.
7. Метрики (Metrics)
Метрики показывают, что происходит с продуктом, они свидетельствуют о достижении целей, а также дают базу для проведения экспериментов. Важные метрики входят в число KPI (Key Performance Indicator).
Метрики принято разделять:
— Метрики роста (Growth&Activation). Они показывают рост вашего продукта.
Примеры: число новых пользователей, их структура по источнику трафика, число активаций (пользователей, которые не только установили приложение, но и зарегистрировались и выполнили определенные действия).
— Метрики удержания (Retention). Показывают, как часто пользователи возвращаются к продукту.
Примеры: число пользователей ежедневно использующих продукт, восстановленные пользователи (не использовали некоторое время, но вернулись)
— Метрики вовлечения (Engagement). Показывают, насколько пользователи привязаны к продукту.
Примеры: среднее число визитов, проведенное время, страниц за сессию, число написанных постов или социальных действий.
— Метрики счастья (Happiness). Показывают удовлетворенность пользователей
Примеры: NPS, число жалоб, рейтинг в сторах.
— Денежные метрики (Revenue). Показывают, сколько продукт зарабатывает.
Примеры: LTV, стоимость привлечения новых пользователей, месячный постоянный доход (Monthly recurring revenue, MRR), годовой постоянный доход (Annual recurring revenue, ARR)
Фреймворк HEART
Фреймворк AARRR
Фреймворк И.Красинского
Метрики бывают:
— Исследовательские метрики (Exploratory). Показывают специфическую информацию, важную в определенный момент времени. Например, это метрики, связанные с экспериментами (стоимость привлечения и уровень вовлеченности в определенный раздел продукта). Список исследовательских метрик гибкий, он периодически обновляется.
— Отчетные метрики (Reporting). Стабильный список глобальных метрик, по которым из месяца в месяца оценивается динамика продукта.
👆 Хорошие отчетные метрики:
- понятны, однозначны;
- представляют собой относительную или среднюю величину, не абсолютны;
- не взаимосвязаны между собой;
- учитывают внешние факторы и их можно улучшить (бесполезно работать над длительностью сессии, если у характерного пользователя есть только 2 часа в день на работу с продуктом)
8. Создание продукта
Epics, Prioritization, Roadmapping
Как писать User Stories