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

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

Как крупным, так и малым компаниям требуются фреймворки для создания продуктов, общения и перевода технических аспектов в «деловой язык», обеспечивая при этом соблюдение «дат и сроков». Эти аспекты имеют решающее значение для успеха запуска или улучшения продуктов, независимо от того, используете ли вы методологии Agile, SCRUM или водопада. В конце концов, есть инвестиции с ожидаемой отдачей для любого жизненного цикла разработки продукта, и компания и совет директоров имеют право знать, на каком этапе находятся эти инвестиции!

Учитывая мою склонность к небольшим/ориентированным на рост/инновациям компаниям, я взял некоторые из лучших практик и процессов, которые я изучил за годы работы в крупных компаниях, и адаптировал их для работы в небольших компаниях. Бывшая коллега по маркетингу недавно попросила меня прислать ей этот фреймворк, чтобы помочь отделу продуктов в ее компании, поэтому я думаю, что эта концепция нашла отклик у нее!

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

Вехи / этапы следующие:

РА = исследования и анализ

П = план

я = реализовать

Д = Доставка

S = стабилизация

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

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

1. Сколько мы инвестируем в этот продукт?
2. Как долго, пока это не будет сделано?
3. Классическое «мы уже на месте?» вопрос…
4. Какие показатели указывают на успех продукта?
5. Как мы будем монетизировать это решение?

РА = исследования и анализ

• Цель: пойти/не пойти на продукт/инициативу
• Сроки: цель — дни/недели.
• Ответы на ключевые вопросы:
  - Идентификация рыночных возможностей/экономического обоснования
  - Идеальный профиль клиента (ICP)
  - Предположения о раннем продукте или наборе функций
  - Предположения о раннем продукте или метрике KPI
  - Предположения о соответствующих поставщиках
  - Предположения об основных услугах/платформе (при построении на базе существующей платформы)

1-пейджеры

Одностраничный краткий обзор каждой инициативы включает следующее:

• Постановка возможности/проблемы — краткое изложение того, что решает инициатива, профиль идеального клиента и любое ожидаемое распределение.
• Масштаб — основные предположения и то, чего инициатива НЕ достигнет. Последнее является ключевым — возможно, это поэтапный подход или просто MVP.
• From → To - простой способ показать, что даст текущий результат по сравнению с будущим; сюда можно включить показатели успеха из бизнес-кейса
• Предположения : Требуются любые поставщики/партнеры, требуемые сроки, другие инициативы или зависимости от ресурсов.
• Усилия/воздействие — это быстрый способ увидеть, есть ли не требующие больших усилий действия, которые могут оказать большое влияние на бизнес-результаты (это «легко висящие плоды»).

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

П = план

• Цель: определить и определить потребности, затраты, сроки
• Сроки: недели/месяцы
• Ответы на ключевые вопросы:
  - Эпики продукта и прототипирование
  - Разработка ключевых рабочих процессов UX
  - Выбор и проверка поставщиков (при необходимости)
  - Обзоры основных услуг/платформ (при необходимости)
  - Завершение бизнес-кейса
  - Первоначальные операционные и внутренние обзоры

Моя мантра для этого этапа, которую понимают все, кто занимается ремонтом дома своими руками, звучит так: «Семь раз отмерь, один раз отрежь».

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

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

В зависимости от того, как вы строите и сообщаете свою дорожную карту, элементы, попадающие на стадию ПЛАН, должны быть включены в дорожную карту с неким подобием даты запуска.

я = реализовать

• Цель: сборка и подготовка к доставке продукта
• Сроки : обычно недели/месяцы
• Ответы на ключевые вопросы:
  - Разработка программного обеспечения
  - Завершение UX
  - Альфа/бета-релизы
  - Первоначальные операционные и внутренние обзоры
  - Начало выхода на рынок

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

Д = Доставка

• Цель: обеспечить беспрепятственный выход продукта на рынок
• Сроки : обычно недели
• Ответы на ключевые вопросы/выполненные работы:
  - Окончательное согласование потребностей в контрактах с клиентами
  - Внутреннее обучение и материалы
  - Обучение продажам и маркетингу
  - Окончательные операционные и внутренние обзоры

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

S = стабилизация

• Цель: убедиться, что продукт стабилен, итерировать следующий набор функций
• Сроки : обычно месяцы
• Ответы на ключевые вопросы/выполненные задачи:
  - Метрики и измерения
  - Версии продукта, обновления, новые функции
  - Анализы после вскрытия

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

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

ПОГРЕНЫ

В небольших компаниях я использовал 1-pager и получал вещи от RA до P в течение недели или двух, особенно когда мы, как компания, ставили цели. Тем не менее, даже наличие структуры для этого нормализует разговор, так что ВСЕ в компании могут его понять. Это также означает, что если вам нужно что-то добавить, скажем, для команды Ops, у вас теперь есть для этого место.

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

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