Блог Productstar
Как Product Framework помогает ускорить разработку нового продукта?

Быстрая реализация продукта невозможна без предварительного создания структуры работы (плана). Опытные продакт-менеджеры для организации рабочего процесса создают продуктовые фреймворки.

Наверно, вы уже сталкивались с этим понятием, но до сих пор не знаете, как создать product framework. Из этой статьи вы узнаете, что это такое, основные ценности, зачем он нужен и посмотрите пример готового продуктового фреймворка.
Что такое продуктовый фреймворк
Product Framework — наглядное описание создания нового продукта, нормализующее управление деятельностью и получившимися в результате нее артефактами (документами). Продуктовый фреймворк адаптируют под конкретную компанию или команду (обычно этим занимаются HR, CPO или группа продакт оунеров).

Иными словами — это проверенный шаблон, описание последовательности действий, из которых состоит цикл работы над продуктом. Четкая организация рабочего процесса позволяет продуктовой команде добиться максимальной эффективности.
Ценность product framework

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

  • Целостное видение. Позволяет посмотреть на продукт как на систему и понять, что уже делается, а до чего еще руки не дошли.
  • Формализация. Показывает, какие артефакты и модели существуют и могут быть использованы для управления продуктом.
  • Процесс и границы. Определяет границы между разными областями управлениям продуктом и процессами, связанными с ними.
  • Ролевая модель. Дает рекомендации по распределению ролей специалистов, участвующих в создании и развитии продукта.
  • Масштабирование опыта. Помогает определить структуру, чтобы в будущем была возможность перенести опыт управления одним продуктом на другой.
  • Эволюция. Показывает последовательность запуска и развития продукта, помогает сфокусироваться на чем-то одном.
Зачем в работе нужен product framework
Продакт-менеджеры часто задаются вопросом: как управлять продуктом в разных разрезах? Да, есть Jira, Trello, Notion и другие платформы, но что в них фиксировать? И что понимать под управлением продуктом в разных разрезах? Вопросов может быть очень много, а ответы на них спорные и неоднозначные.

Формирование продуктового фреймворка отвечает на следующие вопросы:

  • Как в целом организовать работу над продуктом?
  • Какие артефакты для управления нужны?
  • На какие области развития продукта еще не обращали внимание?
  • Где границы между отдельными активностями?
  • Как лучше всего разделить управление продуктом по разным ролям?

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

Например, есть популярная методология создания нового бизнеса, развития продуктов и их дальнейшее выведения на рынок — Lean Startup. В ней четко указано, что первая стадия — Discovery, затем — все остальное. Но многие компании почему-то начинают с конца и заканчивают исследованием клиентов. Большинство новых продуктов проваливаются, потому что нет систематичности.

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

Нужно помнить, что product framework должен быть гибким. В первом продукте один список составляющих, в во втором — другой и т.д.. Копирование одного фреймворка без адаптации под конкретные условия и команды — путь с высокой вероятностью неудачи. Поэтому к созданию product framework подходят с максимальной ответственностью.
Пример продуктового фреймворка
От правильности создания продуктового фреймворка зависит эффективность работы команды и результат запуска нового продукта. Мы предлагаем познакомиться с универсальным product framework, состоящим из 7 шагов:

  1. Ideation.
  2. Discovery.
  3. Design.
  4. Development.
  5. Deploy.
  6. Scale.
  7. Management.

Далее подробно рассмотрим каждый этап.
Шаг 1. Ideation

Idention — 1 этап разработки нового продукта, в ходе которого цифровые инициативы проверяют на валидность, то есть отвечают на вопрос: «Что делать, а что не делать?».

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

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

После первого шага появляются следующие документы (артефакты):

  • бизнес-идея с оценкой эффектов;
  • список команды исследования;
  • Lean Canvas;
  • гипотеза о проблеме;
  • договор с подрядчиком (если планируется делегирование реализации какого-либо функционала или задачи);
  • гипотеза о решении;
  • карта дизайн-сессии;
  • скоринговая модель инициатив;
  • и другие.

Когда определен список валидных инициатив, переходят к следующему шагу — исследование идей (Discovery).
Шаг 2. Discovery

В рамках исследования валидной идеи необходимо ответить на ряд вопросов:

  • как сделать?
  • кто будет делать?
  • какие инструменты и решения использовать в работе?

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

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

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

После второго шага появляются следующие документы (артефакты):

  • бэклог проблем и гипотез;
  • customer journey map (CJM) — то, как клиент будет проходить по бизнес процессу, что он будет испытывать, где его работа станет более эффективной и т.п.;
  • карта AS-IS на данный момент;
  • готовые решения;
  • ключевые метрики;
  • и другие.

На этом шаге проверяют поставленные в ходе Ideation гипотезы. Например, компания решила выпустить новый банковский продукт для выдачи ипотеки за 10-15 минут и привлечь новых клиентов. Проводятся интервью с целевой аудиторией, составляется карта AS-IS (как получают ипотеку в данный момент) и формируется вывод: какую пользу принесет идея бизнесу.

Второй шаг заканчивается после окончания исследования последней идеи и фиксации списка валидных идей.
Шаг 3. Design

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

Приступают к созданию, но пока что в виде дизайн-проекта, а не в цифровом виде. Формируют первый интерфейс, технологическое описание, фирменный стиль и так далее.

После третьего шага появляются следующие документы (артефакты):

  • описание метрик успешности продукта;
  • бизнес процессы «to-be», то есть как они должны выглядеть после проектирования, успешного внедрения и использования продукта;
  • дизайн-система;
  • бэклоги проблем клиента и решений;
  • требования к разработке;
  • первый MVP (например, нарисованный на бумаге).

Цифровой прототип продукта создают на четвертом шаге — Development.
Шаг 4. Development

На четвертом шаге приступают к реализации программного обеспечения будущего продукта. Опытные команды применяют гибкие методы разработки, например, Agile, Scrum, LeSS, SAFe и другие.

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

Обратная связь важна в разработке любого продукта. Важно понять, что думают потенциальные потребители. Ранее мы рассказывали, почему в рамках создания продукта важно достичь соответствия ожиданиям целевой аудитории (product market fit).

После четвертого шага появляются следующие документы (артефакты):

  • бэклоги продукта и спринтов;
  • MVP;
  • прикладная архитектура;
  • репозиторий;
  • release notes;
  • и другие.

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

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

После пятого шага появляются следующие документы (артефакты):

  • пройденный pipeline;
  • протокол приема сдаточных испытаний;
  • технологическая архитектура;
  • пользовательские инструкции;
  • результаты тестов программного обеспечения;
  • инструкция администратора;
  • и другие.
Шаг 6. Scale

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

Кстати, мы уже рассказывали про стратегию взрывного роста growth hacking. Ее реализацию можно внедрить в product framework и получить десятки тысяч пользователей за минимальный период. Главное — подобрать оптимальную связку для взрывного роста своего продукта.

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

После шестого шага появляются следующие документы (артефакты):

  • технологическая архитектура;
  • дорожная карта масштабирования;
  • инструкция для подготовки инфраструктуры для стабильной работы софта;
  • логирование;
  • мониторинг;
  • и другие.
Шаг 7. Management

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

После седьмого шага появляются следующие документы (артефакты):

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

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

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

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

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

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

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

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

Предлагаем начинающим продакт-менеджерам сразу приступить к практике: разработайте product framework для какого-нибудь гипотетического продукта.
Еще больше о фреймворках можно узнать на нашем годовом курсе «‎Профессия: Продакт-менеджер». Присоединяйся!
Получить консультацию по курсу Продукта
Мы расскажем детали курса, а также забронируем для вас текущую цену курса