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

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

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

Ценность 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 для какого-нибудь гипотетического продукта.