Представьте, что вы создаёте продукт, который люди покупают с удовольствием, потому что он идеально решает их задачи. Такое действительно возможно, но для этого нужно поменять акценты в работе, сконцентрироваться на пользе продукта для клиентов. В этом помогает продуктовый подход в управлении проектами. Рассказываем, что это такое и как его внедрять. Разобраться в такой сложной теме нам помогли эксперты:
- Артем Салютин, директор по развитию организации Work Solutions, руководитель ИТ-кластера ARDA
- Владимир Афанасьев, основатель системного интегратора ICE Partners, эксперт ФРИИ и трекер МТS Startup Hub
- Юлия Цибизова, руководитель департамента маркетинга и коммуникаций Magnetto.pro
Что такое продуктовый подход
Продуктовый подход в управлении проектами — это метод, который фокусируется на ценности продукта для клиентов. Представьте, что вы разрабатываете приложение для просмотра погоды. Вы собираете самую простую версию приложения, а затем дорабатываете его, основываясь на том, как новые функции могут помочь пользователям.
Например, сначала вы добавляете возможность отслеживать изменение погоды по часам, потому что опросы показали — это самое важное, что нужно пользователям. Затем запускаете фичу оповещения о смене погоды — резком похолодании или потеплении, приближающейся грозе или снегопаде. В опросах эта функция была на втором месте по значимости. Так вы постепенно делаете приложение удобным для конечного пользователя. Хорошо и людям, и бизнесу.
Такие функции нужны людям, значит именно на них сосредотачивается команда. Это полезно и для бизнеса — если приложение будет популярным, оно принесёт много денег.
Разница с традиционными методами проектного управления заключается в том, что этот способ фокусируется на итеративной работе, постоянной обратной связи и гибкости. Здесь важно не просто завершить работу в срок и в рамках бюджета, а создать продукт, который решает реальные проблемы пользователей.
В центре этого метода — метрики, связанные с ценностью продукта, например, индекс лояльности, конверсия в оплату, процент возвращающихся пользователей. Этим он отличается от традиционных проектных систем управления, где ключевыми показателями часто становятся соблюдение сроков, бюджета и объема работ.
Особенности продуктового подхода
Есть стандартная проектная модель управления — каскадная или Waterfall. Она предполагает, что этапы работы идут последовательно один за другим, их определяют заранее и вносить правки в процессе работы никак не получится.
В каскадной модели заказчик составляет техзадание, ориентируясь на свои знания рынка или ощущения. Команда работает по ТЗ, а результат должен соответствовать прописанному в задании. Не факт, что при этом получится сделать продукт, который полезен пользователям.
Продуктовый подход более гибкий. Работа ведётся итерациями: разработали функцию → запустили в релиз. Сделали следующую функцию → снова в релиз. К примеру, вот так может выглядеть работа итерациями на канбан-доске в OkoCRM, где сотрудники будут составлять список задач, а потом брать оттуда задачи в работу в порядке приоритета ↓
Канбан-доски — один из инструментов для работы циклами. Подойдёт для разных команд: для отдела продаж, HR, маркетингового отдела, да хоть для продовольственного магазина.
Разница заключается и в другом. У такого проектного метода основная задача — удовлетворить потребности клиентов. То есть в центре создания продукта — потребитель, а не техзадание, придуманное заказчиком. Да, цель менеджмента — деньги, но прийти к этому можно по-разному, в данном случае через пользу для клиентов.
Основные принципы продуктового подхода
Принципы продуктового подхода:
1. Ориентация на пользователя. Продуктовый подход начинается с глубокого анализа потребностей целевой аудитории. Команде важно понять, какие проблемы решает продукт. Сначала строят гипотезы, затем тестируют их, по ним разрабатывают новые функции. Команда постоянно собирает обратную связь, чтобы улучшать продукт.
2. Работа итерациями. В отличие от каскадной проектной модели, где этапы следуют строго друг за другом, такая модель предполагает работу короткими циклами. Их называют спринтами. Спринт в среднем длится от одной до четырёх недель, за это время команда успевает разработать новую функцию или минимально жизнеспособный продукт — MVP.
3. Постоянное улучшение. В каскадной модели создают готовый продукт и отдают его заказчику. Продуктовый подход предполагает, что продукт дорабатывают постоянно, причём не просто так, а основываясь на мнении покупателей.
Преимущества продуктового подхода
Увеличивается удовлетворенность клиентов
Люди любят, когда продукт развивают, особенно, если при этом учитывают их мнение. Представьте, что пользователи пишут в техподдержку, просят добавить какую-то функцию и через пару месяцев её получают. Вопрос: вырастет ли уровень удовлетворённости пользователей? Безусловно. Такая забота о людях предотвращает их недовольство.
Повышается гибкость и адаптивность команды
При таком методе управления изменения внедряют быстро, здесь нет места долгим обдумываниям и утверждениям идей. Поэтому постепенно команда привыкает быстро реагировать на изменения, внедрять новые функции.
Допустим, по обратной связи от пользователей стало понятно, что новая система оценок видеоуроков не такая удобная, как предыдущая. Тогда команде нужно откатить настройки и разобраться, что именно не устроило учеников. Проработав какое-то время в таком режиме, команда становится более гибкой.
Улучшается качество продукта и сокращается время его вывода на рынок
Если команда сосредоточена на пользе для клиентов, конечно, продукт получается лучшего качества. Например, есть бизнес в сфере образования — школа, которая продаёт курсы английского. Клиенты хотят учить язык, но без сложных уроков, а легко и играючи. Есть два варианта, каким создать продукт:
- Обычный курс обучения английскому. Основа обучения — уроки, тестирование, словари, обратная связь
- Интерактивный курс обучения английскому. Основа обучения — известные фильмы и сериалы. Времена ученики разбирают с помощью сериала «Friends», а новые слова учат с помощью песен
Различия у этих программ значительные. Какой продукт будет качественнее: обычный или заточенный под аудиторию? Конечно, второй. Такая забота о потребностях учеников завоёвывает их любовь, предотвращает недовольство.
Так как сразу понятно, как именно должен выглядеть процесс образования и как выстроить программу обучения, курс можно создать и вывести на рынок быстрее.
Снижаются риски, эффективнее используются ресурсы
Продукт создают, ориентируясь на пользователей, благодаря этому нет рисков, что он не будет востребован. Так как часто бывает: что-то выпускают, а это людям вообще не нужно.
Как внедрить продуктовый подход в компанию
Шаг 1. Проанализировать текущие процессы
Чтобы выстроить эффективную проектную модель управления, важно понимать, как устроена работа сейчас. Это помогает определить узкие места, понять, что можно изменить, чтобы сфокусироваться на ценности для клиента.
Допустим, сейчас команда работает по схеме «делаем, что сказал заказчик». Чтобы перестроить работу на «делаем, что нужно клиентам», придётся донести важность изменений и заказчику, и команде. А ещё нужно будет иначе выстроить бизнес-процессы:
- внедрить тестирование гипотез
- выстроить работу итерациями, спринтами
- проводить собрания: дейли, ретроспективы спринта
- пересобрать команду, нанять проектного менеджера
- научиться гибкости: быстро менять приоритеты
Шаг 2. Подготовить и сформировать команду
Команда должна не просто выполнять задачи, а топить за результат и ценность для клиента. Поэтому важно, чтобы сотрудники умели анализировать потребности пользователей, разрабатывать гипотезы и предлагать решения, которые сделают продукт востребованным. Возможно, придётся каждого сотрудника перестраивать на новый образ мышления.
Обычно по такой модели работают кросс-функциональные команды — сотрудники с разным опытом и навыками. В таких проектных командах много ролей:
- Менеджер продукта — отвечает за стратегию развития продукта, приоритизацию задач, связь между бизнесом и командой
- Аналитик — собирает данные, чтобы команда могла принимать решение, востребован ли продукт, и какую функцию нужно реализовать следующей
- Разработчики — создают продукт, пишут код
- Тестировщики — проверяют продукт на наличие ошибок
- UX/UI-дизайнер — создает удобный интерфейс, опираясь на потребности клиентов
В команде может быть маркетолог, который помогает продвигать продукт, или scrum-мастер, помогающий сотрудникам работать по Agile. В небольших командах один человек может совмещать несколько ролей, но важно, чтобы он мог выполнять все ключевые функции.
Шаг 3. Разработать бэклог продукта и внедрить инструменты управления
Бэклог — это список задач, функций, улучшений и исправлений, которые команда планирует сделать. Команда по-очереди берёт задачи из бэклога в работу, выполняет их. Суть бэклога в том, что он не статичен: в процессе работы в него добавляют задачи.
Так выглядит бэклог в OkoCRM.
Например, нашли баг → добавили в бэклог → исправили ошибку в первом же спринте. Это удобно, так как не нужно долго ждать, чтобы поправить баги. В этом одна из главных фишек данного метода — всё получается сделать быстро за счёт гибкости.
Как составить бэклог. В бэклог добавляют не просто задачи, а крупные цели, исправления багов, пользовательские истории.
Из чего чаще всего состоит бэклог:
- Эпики — крупные задачи, которые состоят из нескольких задач. Например, у команды в бэклоге есть эпик «Оптимизация базы данных», в нём задачи: доработка схем, кэширования и улучшение индексов
- Пользовательские истории — задачи, которые ориентированы на потребности клиента. Например, «Как клиент я хочу совершать оплату в приложении, не переходя в приложение банка». Такая история означает, что команде нужно разработать функцию оплаты в приложении
- Баги — ошибки, которые нужно исправить
Чтобы добавить все эти задачи в бэклог, исследуют потребности клиентов. Опросы и интервью помогают создать пользовательские истории и эпики. Баги обычно находят после тестирования функций.
Где вести бэклог. Вести бэклог удобно на канбан-доске. Например, в OkoCRM в модуле «Проекты» вы можете добавлять баги, пользовательские истории и эпики в бэклог. Для каждой задачи в OkoCRM создают карточку, в неё можно добавить всю важную информацию: исполнителей, сроки, подзадачи, описание задачи. В карточке команда может общаться по задаче, ставить напоминания, контролировать прогресс.
Пример карточки задачи из бэклога в OkoCRM. Такой инструмент полезен для менеджмента и бизнеса: здесь легко вести работу и контролировать её. Причём это можно делать в разных сферах, хоть в HR, хоть при производстве мебели.
Когда команда берёт задачу в работу, из колонки «Бэклог» её перемещают в колонку «В работе». Когда задача готова, её переносят в колонку «Выполнено». Это очень удобно, так как помогает визуализировать и контролировать работу команды.
Шаг 4. Договориться о встречах
Команда должна четко понимать, для чего нужен продукт и какую проблему он решает. Для этого регулярно проводят встречи, на которых менеджер продукта объясняет видение его функций или команда обсуждает текущие задачи.
Есть несколько типов встреч, которые проводят в рамках гибких методов проектного управления:
- Daily meetings — ежедневные встречи, на которых обсуждают текущие шаги и планируют работу на день
- Планирование спринта — встречу проводят перед началом спринта, ставят цели, составляют бэклог
- Ретроспектива спринта — на таком созвоне подводят итоги спринта
Шаг 5. Адаптироваться и улучшать процесс работы
Успех такой проектной методики зависит от того, насколько хорошо вы понимаете потребности пользователей и команды. Регулярно собирайте обратную связь от клиентов через опросы, интервью или анализ поведения в продукте.
Также важно учитывать мнение сотрудников. Для этого проводите ретроспективы, обсуждайте, что работает, а что нужно исправить, улучшить. Для оценки качества работы используйте метрики: NPS — индекс лояльности клиентов, скорость доставки фич или LTV — доход с клиента за всё время.
Сложности при внедрении продуктового подхода
Одна из главных сложностей — сопротивление переменам. Сотрудникам, которые привыкли к классическим методам работы, тяжело перестроиться работать иначе. Например, чтобы перестать работать по ТЗ и начать генерировать гипотезы, команде нужно брать на себя больше ответственности.
Не все готовы тратить время и деньги на то, чтобы изучать потребности клиентов, проводить опросы, тесты, интервью. Часто команды фокусируются на своём видении продукта, игнорируя его ценность для клиента.
Метрики успеха продуктового подхода
Retention Rate. Это процент удержания пользователей. Показывает количество людей, которые продолжают использовать продукт в течение определенного периода, например, в течение месяца после регистрации в приложении. Высокий уровень удержания говорит о том, что продукт решает задачи пользователей.
Нормы Retention Rate будут отличаться в зависимости от сферы и вида бизнеса:
- SaaS B2B — нормальным считается показатель 80–90% в течение года
- SaaS B2C — 60–80% в течение года
- Мобильные приложения — 25–40% через месяц после установки, 10–20% через 3 месяца
- Подписки на контент — 55–70% в течение года
LTV. Это пожизненная ценность клиента. Показатель позволяет оценить общий доход, который компания получает от клиента за весь период его взаимодействия с продуктом. Самая простая формула для расчета LTV:
LTV = Средний чек × Частота покупок × Средний срок жизни клиента
LTV позволяет оценивать, окупаются ли затраты на привлечение клиентов, и определять, какие сегменты аудитории приносят наибольшую прибыль. LTV помогает разрабатывать функции, которые увеличивают количество продаж, частоту покупок или продлевают срок взаимодействия с продуктом.
NPS. Индекс потребительской лояльности показывает, готовы ли клиенты рекомендовать продукт. Для этого проводят опрос, люди должны оценить по десятибалльной шкале, готовы ли они рекомендовать продукт. Высокий NPS указывает на то, что продукт соответствует ожиданиям пользователей. Низкий NPS говорит о том, что какие-то потребности клиентов неудовлетворены.
Примеры успешного внедрения продуктового подхода
Кейсы Ice Partners
1. Курсы для подростков «АйДаКодить». В Ice Partners сделали 12-часовой курс «Юный разработчик Telegram-ботов». Первая версия — 6 модулей, много текста, домашних заданий. Курс прошли 9 человек из 30. 70% клиентов слились.
Команда выбрала гипотезу «Дети не хотят читать, а хотят делать». Курс переделали в «конструктор», добавили короткие видео, сделали проект вместо тестов.
Результаты:
- 24 ученика из 30 завершили курс
- 15 оплатили следующий курс
- Коэффициент удержания — 80%
- Upsell — 62%
2. Корпоративные системы видеоконференций. Для заказчика из сферы B2B внедряли переговорные с видеоконференциями. 18 корпоративных клиентов.
Сначала выполнили классическое проектное внедрение «под ключ». Был долгий запуск, документация на 140 страниц. Потом переключились на продуктовый цикл: сделали 3 типовых сценария, инструкции, провели интервью с пользователями, урезали функционал.
Результаты:
- Цикл монтажа сократился с 15 дней до 4
- Маржа выросла на 17% — потому что ушли от кастомизации к управляемому набору типовых решений
Кейс Magnetto.pro
В Magnetto.pro внедрили новую систему управления для fintech-стартапа. Используя продуктовый подход, получилось:
- Перестроить команду по кросс-функциональному принципу
- Внедрить еженедельные A/B-тесты всех изменений
- Настроить систему мониторинга ключевых метрик (Retention, LTV, NPS)
Результат:
- За 9 месяцев средний чек вырос на 40%
- Конверсия в повторные покупки увеличилась на 28%
Часто задаваемые вопросы
В чём отличие продуктового подхода от проектного? Проектный подход ориентирован на достижение конечной цели — например, «сделать сайт» или «запустить рекламную кампанию». После выполнения задачи команда распускается. Продуктовый подход — это непрерывная работа над улучшением продукта, где фокус смещён с результата «сделать» на результат «давать ценность пользователю постоянно».
Подходит ли продуктовый подход для малого бизнеса? Да, особенно если вы работаете с цифровыми продуктами, сервисами или регулярно взаимодействуете с клиентами. Продуктовый подход помогает выстраивать системную работу: выявлять болевые точки клиентов, проверять гипотезы, собирать обратную связь и развивать продукт на основе данных, а не интуиции.
Кто входит в продуктовую команду? В классике — продакт-менеджер, дизайнер, аналитик, разработчики и маркетолог. В малом бизнесе эти роли могут совмещать 1–2 человека. Главное — не названия должностей, а умение мыслить категориями ценности для клиента и цикла постоянных улучшений.
Как начать внедрять продуктовый подход в компании?
- Назначьте человека, ответственного за продукт (продакт или основатель).
- Зафиксируйте, кто ваш клиент и какую ключевую проблему вы решаете.
- Определите метрики успеха.
- Начните с малого: выберите одну гипотезу, проверьте её, сделайте выводы.
- Введите ритм — например, еженедельные встречи команды для обсуждения инсайтов и прогресса.
Как измерять эффективность продуктового подхода?
С помощью продуктовых метрик: Retention — сколько клиентов возвращается, NPS — насколько довольны продуктом, Time to value — сколько времени нужно клиенту, чтобы получить первую ценность, конверсии, поведение пользователей в воронке и т.д.. Чем быстрее вы видите, что работает, а что нет — тем эффективнее продуктовый подход.
