Product Management 101
В университетах США есть традиция нумеровать курсы в пределах направления. Номер 101 — так часто обозначают вводный курс для новичков.
В статье перечислю перечислил то, из чего состоит управление продуктом (PM). Этот список не может быть одним общепринятым и полным. Воспринимайте его как набор терминов, отправную точку для дальнейшего исследования.
Часть 1. Жизненный цикл продукта (PLC)
Часть 2. Идеи (Ideas & User Needs)
Часть 3. Анализ конкурентов и рынка (Competitors & Market analysis)
Часть 4. Развитие на клиентах (Customer Development)
Часть 5. Эксперименты (Experiments) и Минимально жизнеспособный продукт (MVP)
Часть 6. Моделирование (Conceptualizing)
Часть 7. Метрики (Metrics)
По тексту есть ссылки на отдельные методы, подходы, фреймворки.
Даны термины на английском языке. Раньше я не любил включать иностранные слова в русскую речь. Но дело в том, что англоязычные эквиваленты как раз общеприняты. Если вы скажете user story, epic то и вы поймете, о чем речь, и ваш собеседник тоже. Русские эквиваленты (истории пользователей, эпики) не так однозначно понимаемы.
Часть 1. Жизненный цикл продукта (PLC)
Жизненный цикл продукта (Product Life Cycle, PLC)
PLC часто представлен как последовательность 4-х стадий. Каждая из стадий отличается своими особенностями с точки зрения развития продукта и его маркетинга.
Процесс разработки продукта (New Product Development, NPD)
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 млн пар в год.
Поиск конкурентов
Если у вашего продукта нет конкурентов, то это признак того, что:
— нет спроса на продукт или сервис,
— анализ проведен недостаточно хорошо и вы искали только прямых конкурентов и забыли про косвенных, потенциальных и конкурентов с «продуктами-заменителями»;
— вы нашли свой голубой океан ?.
Кроме прямых (предлагают схожий продукт) на рынке могут быть следующие группы конкурентов:
— косвенные. Их продукт решает те же проблемы пользователей, но иным способом и/или для иной целевой аудитории;
— потенциальные. Работают с вашей целевой аудиторией, но решают другие проблемы... пока;
— конкуренты с продуктами-заменителями. Решают те же проблемы, но иным способом.
?Для нового сервиса каршеринга прямыми конкурентами будут Яндекс Драйв, Делимобиль; косвенными — службы такси, доставки городского транспорта.
Оценка конкурентов
Один из возможных подходов к оценке компаний-конкурентов:
— насколько хороша продуктовая команда;
— число пользователей;
— качество дизайна (в широком смысле, включая UX);
— бренд;
— скорость изменений.
По каждому параметру конкуренту присваивают оценку. Шкала может быть какой угодно (от 0 до 5, от 0 до 10 и т.д). Итоговая оценка — это сумма оценок по пяти параметрам.
Таблица свойств (Feature Table)
По аналогии с оценкой конкурентов оценивают их продукты. Это делают с помощью таблицы свойств (Feature Table). В таблице принято откладывать по горизонтали сравниваемые компании, по вертикали — сравниваемые свойства. На основании сравнения, задав веса свойствам можно получить суммарную оценку продуктов конкурентов.
Часть 4. Развитие на клиентах (Customer Development)
Концепцию Customer Development предложил Стив Бланк (S. Blank). Это подход к построению продукта, в соответствии с которым от клиентов и пользователей постоянно получается обратная связь: идеи, гипотезы, пожелания. Акцент именно на постоянном характере обратной связи.
В этом фреймворке разработка продукта, а скорее уже процесс создание стартапа на основе продукта, состоит из четырех циклов:
Виды интервью
Разделение на виды очень условно. В пределах одного интервью могут быть вопросы разного характера. Интервью до выпуска продукта (pre-product) серьезно отличаются от интервью после выпуска (post-product).
Часть 5. Эксперименты (Experiments) и Минимально жизнеспособный продукт (MVP)
Термин MVP (Minimal Viable Product, MVP) был предложен Эриком Ризом (E.Ries) во фреймворке Lean Startup. MVP — это такая версия продукта, которая позволяет собрать максимальный объем данных от пользователей при минимальных затратах.
?Хорошая практика: за один MVP тестировать один функционал. Если одновременно тестируете несколько функционалов, нужно понимать, как эти тесты могут повлиять друг на друга.
Подготовка MVP состоит из семи шагов:
Шаг 1. Определить, в чем состоит боль/потребность потребителей.
Шаг 2. Зафиксировать принятые допущения.
Допущения удобно фиксировать в формате «Продукт будет успешен при условии, что... ». Например, «...при условии, что у моих потенциальных клиентов есть потребность x, за которую они готовы заплатить z, и при этом нет сильных альтернатив».
Допущения ранжируют по степени влияния на продукт, то есть, насколько велики будут отрицательные последствия для продукта в случае, если допущение окажется ложным. Обычно самое рисковое допущение — предположение о наличии потребности у потенциального клиента.
Второй измерение для ранжирования — сложность проверки допущения.
На основании комбинации риск-сложность определяют приоритет проверки допущений через MVP:
— Большой риск — Маленькие затраты
— Большой риск — Большие затраты
— Маленький риск — Маленькие затраты
— Маленький риск — Большие затраты (обычно не проверяют)
Шаг 3. Сформулировать гипотезы.
Для проверки в MVP допущения должны быть переведены на язык гипотез. Гипотеза — это письменно зафиксированное утверждение, которое можно подтвердить или опровергнуть результатами теста. Варианты формулировки гипотез (от худшего к лучшему):
a. Мы думаем, что (пользователь, цель) будут (ожидаемое действие), потому что (причина).
b. Если мы (действие), то это приведет к тому, что (пользователь, цель) будут (ожидаемое действие), потому что (причина).
с. Мы думаем, что (пользователь цель) имеют (боль, потребность), потому что (причина). Если мы (действие), это приведет к тому, что метрика (ожидаемое состояние).
Во всех случаях причины лучше описывать в терминах болей и потребностей; хуже — в терминах ценностей и преимуществ.
Шаг 4. Зафиксировать минимальный порог успеха (Minimal Criteria for Success, MCS).
10% результатов экспериментов носят однозначно бинарный характер: мы провели эксперимент и наша гипотеза однозначно подтвердилась или однозначно не подтвердилась.
В 90% случаев результат где-то посередине, поэтому нужно фиксировать MCS — рубеж, по достижению которого гипотеза будет считаться принятой.
Этот рубеж опирается на одну или несколько метрик. Как правило, в качестве MCS стараются выбирать такую точку, начиная с которой потенциальный доход превышает ожидаемые затраты на разработку.
Метрикой может быть процент пользователей, выполнивших действие, или соответствующих определенным условиям (провели в приложении столько-то времени, просмотрели столько-то страниц).
Шаг 5. Выбрать тип MVP-эксперимента.
Протестировать интерес пользователей в цифровой среде можно разными способами.
— Email-анонс. Разослать письма с анонсом нового функционала и собрать обратную связь
— Кнопка (Shadow Button). Разместить на сайте кнопку для доступа к новому функционалу и отслеживать клики. Клики могут переводить на страницу «Скоро».
— 404 / Скоро (Coming soon). При интересе пользователя и переходе пользователя на страницу нового функционала показывать сообщение о скором создании раздела.
? Так часто делает Amazon.
— Видео (Explainer video). В видео рассказать о новом функционале и выгодах для пользователя.
? Так стартовал Dropbox.
— Лендинг (Landing page). Аналогично видео, но рассказать о преимуществах функционала на отдельной странице.
— Консьерж (Concierge service). В случае интереса пользователя прикрепленный менеджер помогает пользователю выполнить те действия, которые потом будут реализованы в функционале.
— Частичный MVP (Piecemeal). Часть функциональности MVP закрывается с помощью существующих сервисов автоматизации, таких как Google Docs, Zapier и проч.
— Волшебник Изумрудного города (Wizard of Oz). Продукт притворяется, в то время как все действия новой функциональности выполняются вручную.
Типы MVP-экспериментов — подробное описание (скоро)
Шаг 6. Провести MVP-эксперимент.
Шаг 7. Подвести итоги и сделать выводы.
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)
Метрики бывают:
— Исследовательские метрики (Exploratory). Показывают специфическую информацию, важную в определенный момент времени. Например, это метрики, связанные с экспериментами (стоимость привлечения и уровень вовлеченности в определенный раздел продукта). Список исследовательских метрик гибкий, он периодически обновляется.
— Отчетные метрики (Reporting). Стабильный список глобальных метрик, по которым из месяца в месяца оценивается динамика продукта.
? Хорошие отчетные метрики:
— понятны, однозначны;
— представляют собой относительную или среднюю величину, не абсолютны (пользователи за день, процент довольных пользователей и т. п.);
— не взаимосвязаны между собой (нет смысла одновременно мерить число визитов за день и за месяц);
— учитывают внешние факторы и их можно улучшить (бесполезно работать над длительностью сессии, если у характерного пользователя есть только 2 часа в день на работу с продуктом)
— относятся к «причинным» метрикам, реже следствиям. Причинная метрика — баланс калорий за день, следственная — изменение веса.
По фреймворку HEART работа над созданием метрик выглядит следующим образом:
— определяете, что хотите измерить. Например, денежные метрики (обычно одна из групп того или иного фреймворка);
— определяете цель, чего конкретно хотите добиться. Например, увеличить выручку и продавать больше;
— определяете сигналы; по сигналам можно определить, что цели достигаются. Увеличение числа заказов и рост выручки;
— определяете метрику. Метрика показывает, как измерить сигнал. Среднее число заказов в день на пользователя, средняя выручка за день.
? Пример: составить метрику, связанную с удовлетворенностью пользователей.
— Цель: обеспечить максимальную удовлетворенность от продукта и сервиса;
— Сигналы: рейтинг в сторе, оценки NPS.
— Метрики: динамика NPS к предыдущему месяцу; число оценок 10 при опросе NPS.
Часть 8. Создание продукта
Пирамида продукта
Части пирамиды продукта:
— Глобальное видение отрасли (Global vision) — живая картинка будущего отрасли;
— Видение компании (Company Vision) — место компании в будущем отрасли с учетом глобального видения;
— Цели (Goals) — видение компании, описанное метриками;
— Инициативы (Initiatives) — крупные направления, которые помогут достичь намеченных целей;
— Элементы бэклога (Product Backlog Items): Релизы (Releases) / Эпики (Epics) / Фичи (Features) / Темы (Themes) / Пользовательские истории (User Stories / Tasks) / Баги (Bugs). В описании Scrum задачи, связанные с разработкой продукта, называются элементами бэклога. Такой подход позволяет каждой команде по-своему создавать свою структуру задач и направлений. У кого-то это только эпики и истории, у кого-то релизы, фичи и истории. Однако большинство команд используют пользовательские истории.
Спецификации
Спецификации пишут на крупные задачи (эпики). Их пишут простым языком, чтобы любой сотрудник мог понять их суть. Состав спецификации:
- Введение. Во введении указывают:
- — какие фичи входят в эпик и почему решено их реализовать;
- — на какие метрики повлияют изменения;
- — ссылки на дополнительные документы;
- — согласование эпика с планом маркетинга, юридические тербования;
- — схемы.
- Требования к продукту (Product requirements). Какие изменения должны произойти в продукте, чтобы эпик считался успешным.
- Требования к дизайну (Design requirements). Специфические ограничения по дизайну: использование гайдов, UI-китов и т. п.
- Требования к разработке (Engineer requirements). Что должно быть сделано с точки зрения бэкенда и фронтэнда.
Оценки
Оценки в IT сложно давать, поскольку каждая новая задача уникальна. Из SCRUM пришел подход, связанный с оценкой в условных и абстрактных единицах — очках (story point).
На покере планирования (planning poker) команда присваивает пользовательским историям оценку в очках. Со временем команда понимает, сколько очков она способна в среднем закрыть за один спринт. Допустим, вы знаете «скорость» разработки. С этим знанием вы сможете более уверенно набирать задачи на спринт в пределах этого объема, и у вас будет большая уверенность, что они будут выполнены.
Приоритеты
Некоторые способы расставить приоритеты пользовательским историям/фичам/эпиками.
Метод похож на описанный в разделе про MVP способ расставить приоритеты допущениям. А именно мы закрываем первыми такие истории, которые позволяют проверить наиболее рисковые допущения и которые одновременно мы считаем важными для пользователей. Таким образом для каждой истории мы ставим оценку от 1 до 5 или 10 по критериям:
— насколько велик риск допущения, которое связано с историей. Напомню, что риск допущения — это насколько велики будут отрицательные последствия для продукта в случае, если допущение окажется ложным
? У нас осталось непроверенным допущение, что люди пожилого возраста будут пользоваться нашим облачным фотохранилищем. Мы рассчитываем на эту аудиторию, поэтому истории, в которой пользователь может использовать номер пенсионного удостоверения для скидки, дадим 10 баллов по допущениям
— насколько важна задача с точки зрения бизнеса, пользователей.
Суммируя две оценки получаем одно число. Чем оно выше, тем быстрее истории уходит в разработку.
Метод также дает одну оценку. Она складыается из трех факторов, которые оцифровываются по любой шкале (1-5, 1-10):
— выгоды бизнеса: рост выручки, упрощение процессов, привлечение новых пользователей;
— выгоды пользователей: удобство использования, дополнительный функционал;
— затраты: насколько сложно историю закрыть.
В результате число получается сложением выгод и вычитанием затрат.
Этот метод впервые начали применять в 1994 году в Oracle. Истории распределяются по четырем корзинам:
- обязательно нужно сделать. Если историю не закрыть, последствия могут быть значимыми негативными.
- следует сделать. Не самые важные требования, но которые стоит закрыть после обязательных.
- могли бы сделать. Желательные требования, которые сделаем, если останутся ресурсы.
- можем и не делать. Требования зафиксированы, но можно их отложить на следующий спринт, поскольку они не повлияют серьезным образом на бизнес или пользователей.