В этом цикле статей мы разберем процесс исследования и проработки потребностей клиентов и новых возможностей.

А также рассмотрим, как разбираться с проблемами, мешающим фичам работать:

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

Статьи будут полезны руководителям продукта, менеджерам продукта (CPO, PO, PM), аналитикам, маркетологам, основателям компаний и стартапов.

От Идеи к Реализации: что мешает достичь успеха?

Что бы ни говорили про проверку гипотез и толерантность к ошибкам, карьера менеджера продукта зависит от успеха продукта.

По статистике в хороших компаниях “выстреливает” 1 из 10 продуктов, а из 100 стартапов только 1 выходит на повторный раунд финансирования.

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

В какие ловушки попадают компании?

Несмотря на то, что продукт-менеджмент как дисциплина развивается уже более 50 лет, во многих компаниях и в России, и во всем мире болезни очень похожие.

Что такое фича?

Как один из элементов управления продуктом фича появилась со времен первых продуктовых команд в 60-е годы прошлого века.

В общем случае фича — это характеристика продукта, но со временем значение термина уточнялось и менялось:

• 2011 год: фича — это то, что дифференцирует продукт (Эрик Рис "Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели")

• 2014 год: фича — это способ, с помощью которого создается ценность для пользователя, с точки зрения Джеффа Паттона (Джефф Паттон "Пользовательские истории. Искусство гибкой разработки ПО")

• 2015 год: фича — это отражение потребностей и желаний на целевом для нас рынке — относительно современного понимания, в концепции Jobs To Be Done (Dan Olsen, The Lean Product Playbook: How to Innovate with Minimum Viable Products and Rapid Customer Feedback (2015) Саммари книги: https://sok.marketing/lean-product-playbook/)

• 2017 год: фича — это характеристика продукта, которая обеспечивает ценность для клиента (Марти Каган "Вдохновленные. Все, что нужно знать продакт-менеджеру"). Сейчас это актуальное понимание фичи.

Minimum Marketable Feature (MMF)
Все слышали что такое MVP, но мало кто слышал что такое MMF (Minimum Marketable Feature).

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

Мартин Кеган (Marty Cagan) в своей книге "Inspired: How To Create Tech Products Customers Love" подчеркивает, что MMF продукта должно содержать ни много ни мало, а инновацию, которая удовлетворяет определенные, жизненно важные потребности или ожидания пользователей. Оно должно быть способным не только привлечь внимание на рынке, но и создать основу для долгосрочных отношений с клиентами.

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

Примеры плохих MMF:
1. Веб-приложение для онлайн-бронирования гостиницы без функции бронирования: Это каталог доступных номеров без возможности совершить действие, которое является ключевым для потребителя.
2. Мобильное приложение для заказа еды без опции оплаты: Приложение ограничивается только предоставлением меню, что делает его бесполезным для окончательного пользователя.

Ловушка строительства (Build Trap).

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

Основные симптомы:

• Переполненный бэклог: Слишком много идей и предложений мешают команде сосредоточиться на том, что действительно важно для пользователя.
• Сложные и тяжеловесные продукты: Из-за чрезмерного функционала продукт становится перегруженным и сложным в использовании.
• Шокированные пользователи: Клиенты часто не понимают, как применять многочисленные функции и зачем они вообще нужны.

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

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

Ловушка эксперимента, или психбольница в руках пациентов

На первый взгляд, все хорошо. Компания загружает в команду исследователей все вопросы, по которым не может принять решение. Команда исследователей или даже разработки организует проверку гипотез. Если новая возможность продукта встречает положительное отношение пользователей, фича окрашивается в зеленый, если отрицательное — в красный, “ни рыба ни мясо” называются неокрашенными. "Зеленые" фичи идут в производство и масштабирование. Таким образом, команда может быть уверена, что разработанный функционал нужен и одобрен клиентами.

Симптомы проблемы:

• Переполненный бэклог исследований: приводит к замедлению вывода на рынок новых возможностей.
• Скучающая разработка — “Вы сначала докажите, что это нужно”.
• Многие эксперименты остаются "неокрашенными", что приводит к дефициту новых функциональных возможностей.
• Функционал часто подтверждается только после того, как похожие возможности появились у конкурентов, делая продукт морально устаревшим.
• Пользователи недовольны, чувствуя, что лучшие возможности всегда появляются сначала в других продуктах.

Пример

• Запрещенный в России Instagram, использующий подобную практику, по всем аналитическим отчетам, оценивающим динамику и потенциал, а также исследованиям обратной связи от пользователей, уступает TikTok …

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

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

Ловушка анализа: аналитический паралич в продуктовых командах

Попав в ловушку экспериментов, сложно поверить в то, что основа “продуктового подхода” может быть неверной, и команда решает, что она недостаточно старалась, что у нее плохая “аналитика”.

"Ловушка анализа" — это ситуация, в которой команда настолько увлекается Data Driven решения и данными, что это препятствует принятию оперативных и эффективных решений.

Симптомы:

• Сложная и постоянно дорабатываемая аналитическая система.
• Неуклонный рост показателей, преимущественно благодаря изменению методики расчета метрик:

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

• Большинство экспериментов также не окрашиваются:

Например: “Данные эксперимента показали, что родители не заинтересованы в функционале, отражающем успеваемость детей при обучении английскому языку” - цитата с ProductCamp).

• Проекты разработки методологии анализа, улучшающие NPS, CSI и т.д., так как они не соответствуют уникальности продукта.
• Продукт не выпущен на рынок или устарел, так как команда не может выпустить новые Фичи, ведь они “не окрашиваются”.
• Потеря интереса со стороны пользователей, которым надоел устаревший продукт (как Jira).

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

Компании стремятся выстроить хорошую аналитику, получить все данные и начать принимать Data Driven решения. На самом деле ловушка анализа и ловушка эксперимента - это две части одного целого: в ловушке анализа люди пытаются найти и заранее продумать все связи, а в ловушку эксперимента попадают, когда привлекают данные для анализа.

Заключение
Ловушка анализа — одна из ключевых проблем, с которой может столкнуться продуктовая команда. Чаще всего в нее попадают команды, ориентирующиеся на “лучший” индустриальный опыт и путающие корпоративную культуру избегания риска, в целом негативно влияющую на развитие компаний, с передовыми продуктовыми практиками.
Чтобы избежать ловушки, необходимо необходимо четко понимать границы и эффективность аналитического подхода (data driven design).
Довольно часто, осознав ограниченность принятия решений на основе данных, команды делают ставку на всесторонний анализ и обсуждение новых инициатив.

Ловушка совещаний (Consensus Trap).

На самом деле эту ловушку стоило бы разместить первой:

• большинство новых продуктов так и не увидели свет из-за того, что команды не смогли договориться между собой;
• часто происходит ситуация, в которой вместе с достижением успеха и ростом команды приходит желание все делать “правильно” и согласованно. Этого 1, 2, 3 ... не случилось, если бы вы со мной посоветовались.

Симптомы:

• Постоянные совещания без четко поставленных задач.
• Отсрочки исследований, разработки, запуска или обновлений продукта.
• Недовольство пользователей, которые чувствуют, что о них забыли.

Эту ловушку легко узнать, когда вы слышите: «Давайте мы все вместе обдумаем, обговорим, всех соберем». При бесконечных совещаниях продукт не выпускается или не обновляется. Когда основатель это осознает, то начинает снова усиленно «пилить» продукт. Круг ловушек замкнулся.

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

Как не попадать в эти ловушки

Описанные 4 ловушки отлично коррелируют с кодом Адизеса — концепцией, где функции управления делятся на 4 области компетенций:

• Разработка (производство) — достижение конечного результата, создание результата любой ценой. (Краткосрочные результаты);

- Гибкая разработка хорошо работает на этапе создания MVP, но на остальных этапах разработки продукта превращается в ловушку экспериментов;
- Кроме того, эксперименты прекрасно работают в Growth team (каналы, сообщения и т.д.), но плохо переносятся на создание Features, т.к. согласно модели диффузии инноваций, новые возможности хорошо воспринимает не более чем 12,5 % аудитории. Для того чтобы “раскрыть” функционал на раннее большинство, нужно проектировать “feature onboarding” и много других нюансов;

• Администрирование (управление) — обеспечение соответствия работ бизнес-процессам и философии компании. (Краткосрочная эффективность);

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

• Предпринимательство — создание будущего компании, внедрение изменений, фокус на глобальной долгосрочной перспективе. (Долгосрочные результаты);

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

• Интеграция — объединение людей для достижения общих целей компании, моральная помощь сотрудникам и построение гармоничных межличностных отношений в команде. (Долгосрочная эффективность);

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

Успех продукта — также как в коде Адизеса — зависит от совмещения эффективного управления в каждой из областей. Перекос внимания в отдельную область приводит к дисфункции продуктового управления.

Итоги:

• Так же как путь в 1000 километров начинается с первых 100 шагов, создание ценности для каждого клиента начинается с конкретных результатов и ценности в моменте (feature), которые получает клиент;
• Чтобы фича получилась и команда смогла выбраться из порочного круга ловушек, команде нужно научиться объединять усилия по всем направлениями:

- Строительство (разработка — долгосрочные результаты),
- Эксперименты (краткосрочные результаты),
- Аналитика (краткосрочная эффективность),
- Командная работа (интеграция — долгосрочная эффективность).

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


Этот цикл мини-статей основан на вебинаре «Как разблокировать рост продукта. От хаотичных исследований к системе работы с возможностями», который посвящен Feature Discovery — процессу проектирования возможностей продукта от исследования до коммуникации.