Управление продуктом. Российская практика

Существует каноническое определение MVP по Эрику Рису.

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

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

MVP должен в первую очередь сосредоточиться на проверке самых рискованных предположений. Пример, который всегда вдохновляет меня: MVP DropBox Video Explainer. В то время у DropBox не было продукта. Вместо этого они создали простое видео для сообщества первых пользователей, чтобы продемонстрировать, как должно работать решение. В результате их список ожидания бета-тестирования увеличился с 5000 до 75 000 человек за одну ночь.

Еще один вариант MVP – лендинг с описанием ценностного предложения, затем запуск рекламы на небольшой объем целевого рынка и отслеживание конверсии в целевые действия на лендинге, чтобы ответить на вопрос, сколько пользователей можно конвертировать в заявку и оплату. Так когда-то давно поступил Джефф Безос. Он рассказывал, что ключевое рискованное предположение, которое он хотел проверить в самом начале, заключалось в том, сможет ли Amazon конкурировать с книжными магазинами. Вместо того чтобы купить гору книг и арендовать склад, он создал сайт и выставил на нем книги, которых у него не было. Когда клиенты заказывали товар, он покупал книги в магазине и отправлял их по почте.

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

Глава 2. Продуктовый подход в компаниях

ОТ ФУНКЦИОНАЛЬНЫХ КОМАНД К ПРОДУКТОВЫМ

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

ПРИТЧА О СЛОНЕ

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

Первый слепой человек трогает бок слона и говорит: «Слон похож на стену».

Второй слепой чувствует бивень и заявляет: «Нет, слон похож на копье».

Третий слепой, держа хобот, настаивает: «Вы все неправы. Слон похож на змею».

Четвертый слепой трогает ногу и говорит: «Очевидно, что слон похож на дерево».

Пятый слепой, ощупывая ухо, заключает: «Слон похож на веер».

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

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

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

Основные характеристики продуктовых команд следующие.

Долгосрочность и стабильность

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

Назначение бизнес-проблем и клиентов

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

Мультифункциональность

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

Фокус на клиентов и продукт

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

Разработка не передается на аутсорсинг

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

ПРОЦЕСС УПРАВЛЕНИЯ ПРОДУКТОМ

Ни один план не выдерживает первого контакта с клиентами.

Стив Бланк

Работа в продуктовых командах представляет собой процесс, который часто делят на два этапа: исследования (Discovery) и разработка (Delivery). Это так называемый двойной ромб или алмаз. Нередко команды хотят внедрить этап исследований из-за усталости от разработки большого количества функций, которые никому не нужны и не способствуют достижению бизнес-целей. Этот подход фокусируется на изучении рынка, быстром тестировании гипотез, проверке концепций продуктов (как минимум с помощью интервью, создания прототипов и юзабилити-тестов с реальными пользователями). Процесс заранее отфильтровывает менее жизнеспособные решения, позволяя сосредоточиться на наиболее ценных функциях, которые нужны клиентам и бизнесу. А вот процесс разработки концентрируется на воплощении проверенных идей в продуктах.

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

Вы когда-нибудь сталкивались с подобными ситуациями?

• «Да, мы проводим ежеквартальные опросы удовлетворенности клиентов (CSAT) и Net Promoter Score (NPS), но кажется, что на их основе мы не предпринимаем никаких действий».

Конец ознакомительного фрагмента.

Текст предоставлен ООО «Литрес».

Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.

Notes

1

career.habr.com/salaries?spec_aliases[]=product_manager.

2

Кирцнер И. Конкуренция и предпринимательство. Челябинск: Социум, 2023.

3

mckinsey.com/industries/technology-media-and-telecommunications/our-insights/miros-andrey-khusid-product-led-growth-in-tech-and-beyond.

4

agilemanifesto.org/iso/ru/manifesto.html.

5

zenexmachina.com/agile-as-a-mindset-agile-as-behaviour/.