Зрелые менеджеры продукта мыслят иначе
Разбираемся как именно и почему именно так
Перевод статьи Debbie Widjaja
Поговорим про менеджеров продукта. Новичкам обычно интересно, как получить повышение (будем честными — не только новичкам). Обычно это не так просто — задача комплексная и зависит не только от вас. Однозначно, важны ваши навыки и достижения. Но есть и другие факторы, например, насколько ваш руководитель заботится о карьерном треке подчиненных, насколько хороши и опытны ваши коллеги, какая политика компании и т. д.
Эта статья не о том, как вырасти до старшего продукт-менеджера. Поговорим, как прокачать свое мышление и стать лучшим в профессии, как бы пафосно это не звучало. Любой может мыслить как зрелый менеджер продукта, независимо от должности. Но, к сожалению, крутая должность не означает по умолчанию, что человек умеет мыслить правильно.
На диаграмме ниже показаны различные способы «создания продукта» в зависимости от того, насколько чётко вы представляете проблему и решение. Чтобы стать мастером, вы должны научиться работать на всех уровнях ясности. Важно знать, какие инструменты можно использовать в каждой ситуации.
Эта статья не о том, как вырасти до старшего продукт-менеджера. Поговорим, как прокачать свое мышление и стать лучшим в профессии, как бы пафосно это не звучало. Любой может мыслить как зрелый менеджер продукта, независимо от должности. Но, к сожалению, крутая должность не означает по умолчанию, что человек умеет мыслить правильно.
На диаграмме ниже показаны различные способы «создания продукта» в зависимости от того, насколько чётко вы представляете проблему и решение. Чтобы стать мастером, вы должны научиться работать на всех уровнях ясности. Важно знать, какие инструменты можно использовать в каждой ситуации.
Как узнать, ясна ли проблема? Есть ряд признаков:
В статье рассмотрим инструменты, которые можно использовать в различных ситуациях, а в конце поговорим о подводных камнях, на которые следует обратить внимание.
- Вы можете сформулировать, как она повлияет на бизнес и пользователей,
- Вы хорошо понимаете первопричину проблемы,
- Вы решили, что именно эта проблему, а не какие-либо ещё, надо решать сейчас.
- Вы уверены, что это решение действительно подходит, чтобы решить проблему,
- Вы рассмотрели множество решений, и это выигрывает по соотношению цена/выгода.
- Ваша команда знает, как прийти к решению.
В статье рассмотрим инструменты, которые можно использовать в различных ситуациях, а в конце поговорим о подводных камнях, на которые следует обратить внимание.
Начинаем с основ: добиваемся идеального качества
Когда проблема чётко определена и решение согласовано, вы сосредоточиваетесь на том, чтобы оно было реализовано с максимальным качеством. Это основа основ для начинающих менеджеров продукта. «Взрослые» продукт-менеджеры это должны уметь по умолчанию, но могут позволить себе быть менее практичными.
«Как мы можем быстро это отгрузить?»
Вопрос решается управлением бэклогом: убедитесь, что тикеты написаны чётко, имеют оптимальный размер, приоритеты расставлены правильно и исполнители над задачами работают эффективно. Сюда же относим проведение мероприятий, которые позволяют команде достичь всего вышеперечисленного, например: планирование спринтов, актуализация бэклога и ретроспективы.
В традиционной Scrum-команде управление бэклогом – обязанность Владельца Продукта. В более официальных организациях этим часто занимается техлид. Если вам повезло с хорошим техлидом в команде, не переживайте (работать все равно придется). Как менеджер продукта, вы можете:
В традиционной Scrum-команде управление бэклогом – обязанность Владельца Продукта. В более официальных организациях этим часто занимается техлид. Если вам повезло с хорошим техлидом в команде, не переживайте (работать все равно придется). Как менеджер продукта, вы можете:
- Убедиться, что разработчики понимают видение и контекст работы, и то, как она способствует достижению бизнес-целей.
- Помочь им декомпозировать работу на части, которые можно будет отгружать независимо.
«Как убедиться, что все сделано круто?»
Тестирование и эксперименты в помощь. Возможно, вы решите провести юзабилити-тестирование прототипа, прежде чем просить разработчиков писать код. Можно попробовать постепенное внедрение фичи или провести A/B-тестирование перед внедрением выбранной версии.
Различные типы тестов и экспериментов — те же инструменты в вашем инструментальном ящике. Вы должны понимать, что делает каждый из них, чтобы иметь возможность выбрать правильный инструмент для конкретной ситуации.
Различные типы тестов и экспериментов — те же инструменты в вашем инструментальном ящике. Вы должны понимать, что делает каждый из них, чтобы иметь возможность выбрать правильный инструмент для конкретной ситуации.
1
Юзабилити-тестирование прототипа
Что позволяет: проверить, знают ли пользователи, как использовать ваше решение.
Чего не позволяет: проверить, хотят ли пользователи использовать ваше решение.
Как происходит: вы показываете кликабельный прототип и просите кого-нибудь выполнить задачу, связанную с вашим продуктом. Например: «Пожалуйста, покажите, как загрузить фотографию?»
Ваша задача — молча наблюдать и делать заметки. Понятно ли интуитивно, какую кнопку нажать? Понимают ли пользователи, что произойдет, если выполнить определенное действие? А может, что-то сбивает их с толку?
Такой тест — быстрый и недорогой способ убедиться, что вы не тратите ценные ресурсы впустую. Есть множество сервисов, которые позволяют быстро и относительно недорого проводить подобные тесты.
Если вы работаете в очень маленьком стартапе, можно протестировать прототип вообще бесплатно. Просто поймайте в коридоре кого-нибудь (важно: не ловите людей, которые уже хорошо знакомы с продуктом) и проведите живой тест.
Что позволяет: проверить, знают ли пользователи, как использовать ваше решение.
Чего не позволяет: проверить, хотят ли пользователи использовать ваше решение.
Как происходит: вы показываете кликабельный прототип и просите кого-нибудь выполнить задачу, связанную с вашим продуктом. Например: «Пожалуйста, покажите, как загрузить фотографию?»
Ваша задача — молча наблюдать и делать заметки. Понятно ли интуитивно, какую кнопку нажать? Понимают ли пользователи, что произойдет, если выполнить определенное действие? А может, что-то сбивает их с толку?
Такой тест — быстрый и недорогой способ убедиться, что вы не тратите ценные ресурсы впустую. Есть множество сервисов, которые позволяют быстро и относительно недорого проводить подобные тесты.
Если вы работаете в очень маленьком стартапе, можно протестировать прототип вообще бесплатно. Просто поймайте в коридоре кого-нибудь (важно: не ловите людей, которые уже хорошо знакомы с продуктом) и проведите живой тест.
1
Постепенное внедрение фичи
Означает, что вместо внедрения этой функции сразу для 100% ваших пользователей вы делаете это постепенно. Несколько кейсов, когда это может быть полезно:
Когда так не следует делать: Когда ваши пользователи требуют данную фичу, и когда она не может ухудшить ситуацию. Тут стоит даже пожертвовать возможностью измерить ее влияние.
Означает, что вместо внедрения этой функции сразу для 100% ваших пользователей вы делаете это постепенно. Несколько кейсов, когда это может быть полезно:
- Вы хотите убедиться, что эта фича ничего не сломает. Как менеджер продукта, вы должны понимать, какие у вас «контрольные метрики». Контрольные метрики — это то, что не должно ухудшаться при выпуске новых фич. Например, частота сбоев приложения или количество жалоб клиентов.
- Вы хотите измерить влияние новой фичи. Выпустив ее на некоторое время только для одной группы пользователей (или наоборот, оставив небольшую группу, которая не получит эту фичу), вы можете отследить влияние этой фичи на те метрики, которые вы хотели бу улучшить. Важно: убедитесь, что выборка релевантная. PS: Технически это также считается A/B-тестом, но в этой статье термин A/B-тест используется только при сравнении двух или более разных решений.
Когда так не следует делать: Когда ваши пользователи требуют данную фичу, и когда она не может ухудшить ситуацию. Тут стоит даже пожертвовать возможностью измерить ее влияние.
1
A/B тестирование
Смысл A/B-теста очень простой — протестировать решение A и решение B и посмотреть, какое из них работает лучше. Можно провести A/B-тестирование прототипа или A/B-тестирование в реальной среде. Можно сделать это тестом A/B/C/D или использовать комбинацию разных компонентов в каждой версии и т. д.
Цель — определить наиболее выигрышную версию решения. Возможно, вы читали, как Google экспериментировал с 41 оттенком синего и добился увеличения дохода на 200 миллионов баксов. Но пока у вас нет миллионов/миллиардов пользователей и крошечный процентный прирост какой-либо метрики не даст значительного прироста в деньгах, не стоит усердствовать с A/B-тестами.
Да, есть пользовательские сценарии, которые всегда можно улучшить, например, пути привлечения и активации. В этих точках взаимодействия вы превращаете посетителя в платящего пользователя, а влияние изменений легко измерить. Для остальных же сценариев, например, когда пользователи просто используют продукт для выполнения какой-либо задачи, обычно достаточно простого A/B-теста.
Смысл A/B-теста очень простой — протестировать решение A и решение B и посмотреть, какое из них работает лучше. Можно провести A/B-тестирование прототипа или A/B-тестирование в реальной среде. Можно сделать это тестом A/B/C/D или использовать комбинацию разных компонентов в каждой версии и т. д.
Цель — определить наиболее выигрышную версию решения. Возможно, вы читали, как Google экспериментировал с 41 оттенком синего и добился увеличения дохода на 200 миллионов баксов. Но пока у вас нет миллионов/миллиардов пользователей и крошечный процентный прирост какой-либо метрики не даст значительного прироста в деньгах, не стоит усердствовать с A/B-тестами.
Да, есть пользовательские сценарии, которые всегда можно улучшить, например, пути привлечения и активации. В этих точках взаимодействия вы превращаете посетителя в платящего пользователя, а влияние изменений легко измерить. Для остальных же сценариев, например, когда пользователи просто используют продукт для выполнения какой-либо задачи, обычно достаточно простого A/B-теста.
Критическая оценка (и умение говорить нет)
Именно тут начинается разница между менеджером продукта и менеджером проектов. Задача менеджера проекта — успешно запустить проект. Кто-то за него определил проблему, решил, что она достаточно важна, и выбрал способ, которым необходимо действовать.
Критическая оценка решения («Есть ли лучший способ решить эту проблему?») и оценка проблемы («Стоит ли решать эту проблему?») — вот что выводит продуктовое мышление на новый уровень. Сюда же входит умение отказывать стейкхолдерам.
Иногда это разница между проджект-менеджером у вас в штате и менеджером агентства. Агентство обычно нанимают для реализации конкретного проекта. Очевидно, что агентство не будет радо, если их менеджер проекта придет к выводу, что проект не нужен.
Критическая оценка решения («Есть ли лучший способ решить эту проблему?») и оценка проблемы («Стоит ли решать эту проблему?») — вот что выводит продуктовое мышление на новый уровень. Сюда же входит умение отказывать стейкхолдерам.
Иногда это разница между проджект-менеджером у вас в штате и менеджером агентства. Агентство обычно нанимают для реализации конкретного проекта. Очевидно, что агентство не будет радо, если их менеджер проекта придет к выводу, что проект не нужен.
«Есть ли лучший способ решить проблему?»
Есть разные способы определения «лучшего» решения. «Лучше» может означать более быстрый запуск, более дешевую интеграцию, ценную для бизнеса в долгосрочной перспективе, или более эффективное решение краткосрочных проблем.
Ваша задача как менеджера продукта — понять стратегическую важность проблемы, которую вы решаете. Это позволит задать правильные ограничения для решения. Затем вам надо обратиться к опыту членов команды (т. е. разработчиков, специалистов по данным, аналитиков и дизайнеров), чтобы найти различные решения, удовлетворяющие всем ограничениям.
Ваша задача как менеджера продукта — понять стратегическую важность проблемы, которую вы решаете. Это позволит задать правильные ограничения для решения. Затем вам надо обратиться к опыту членов команды (т. е. разработчиков, специалистов по данным, аналитиков и дизайнеров), чтобы найти различные решения, удовлетворяющие всем ограничениям.
1
Понять стратегическую важность проблемы
Бывают менеджеры продукта, которые при управлении командой придерживаются единственного принципа. Это может быть скорость («Я просто хочу, чтобы было готово побыстрее») или лучший пользовательский опыт («Наш продукт должен быть мирового класса») или что-то другое. Только не все проблемы и решения одинаковы.
Как продукт-менеджер, вы должны быть способны сформулировать:
- Какую из целей компании вы пытаетесь достичь, работая над задачей?
- Какие проблемы пользователей вы решаете? (И дополнительный вопрос на миллион: откуда вы знаете, что это проблема?)
- Как вы поймете, что решили проблему? Какие метрики для этого будете использовать? Какие показатели вы будете измерять и как определите влияние на метрики?
1
Донести контекст и ограничения вашей команде
Не надо быть поклонником многостраничных технических заданий, и тем более не стоит передавать эти ТЗ разработчикам «как есть». Вы должны доносить до них контекст (цели компании, проблемы пользователей, показатели и т. д.) и ограничения. Ограничениями могут быть:
Помните, цель не всегда в том, чтобы создать что-то идеальное для всех. Иногда можно сказать: «Нужно быстрое черновое решение для пользовательского сегмента X, а пограничные случаи Y и Z нас не волнуют», при условии, что вы тщательно их рассмотрели и компромисс вас устроил.
Не надо быть поклонником многостраничных технических заданий, и тем более не стоит передавать эти ТЗ разработчикам «как есть». Вы должны доносить до них контекст (цели компании, проблемы пользователей, показатели и т. д.) и ограничения. Ограничениями могут быть:
- Ресурсы (время и количество разработчиков)
- Пользовательские сегменты
- Пограничные случаи, которые следует (или не следует) учитывать
Помните, цель не всегда в том, чтобы создать что-то идеальное для всех. Иногда можно сказать: «Нужно быстрое черновое решение для пользовательского сегмента X, а пограничные случаи Y и Z нас не волнуют», при условии, что вы тщательно их рассмотрели и компромисс вас устроил.
Чрезмерно разжевывать не стоит, но убедитесь, что все всё поняли правильно
1
Накопить экспертизу для генерации решений
Пришло время вам отойти в сторонку. На первый план выходит команда. Дайте членам команды время — подумать, разработать технические решения и создать каркас. Вы все равно должны быть рядом, чтобы давать указания, подталкивать в нужном направлении и объяснять непонятное. Ваша задача в конце этого процесса — принять решение, если найдено несколько хороших решений.
Один из форматов, который хорошо подходит для этого процесса — дизайн-спринт. Либо можно внедрить такой процесс в свой обычный спринт, такой подход иногда называют двухполосным agile. Первый вариант хорош для большого или нового проекта, когда нужна небольшая встряска для команды. Это позволяет не зацикливаться на привычных способах думать и работать. Второй вариант — удобнее и не такой разрушительный, особенно если у вашей команды есть жесткие цели по отгрузке.
Пришло время вам отойти в сторонку. На первый план выходит команда. Дайте членам команды время — подумать, разработать технические решения и создать каркас. Вы все равно должны быть рядом, чтобы давать указания, подталкивать в нужном направлении и объяснять непонятное. Ваша задача в конце этого процесса — принять решение, если найдено несколько хороших решений.
Один из форматов, который хорошо подходит для этого процесса — дизайн-спринт. Либо можно внедрить такой процесс в свой обычный спринт, такой подход иногда называют двухполосным agile. Первый вариант хорош для большого или нового проекта, когда нужна небольшая встряска для команды. Это позволяет не зацикливаться на привычных способах думать и работать. Второй вариант — удобнее и не такой разрушительный, особенно если у вашей команды есть жесткие цели по отгрузке.
«Стоит ли вообще решать эту проблему?»
Вопрос «Стоит ли решать проблему» может оказаться непростым. Зависит от того, насколько компания ориентирована на продукт. Запросы могут исходить от очень серьезных стейкхолдеров, даже от генерального директора, и менеджеру продукта, возможно, придется повоевать.
Если мы «предполагаем, что даже если человек недостаточно компетентен, но у него добрые намерения», значит все идеи и запросы по продукту имеют какие-то достоинства. Возможно, ничто из предложенного нельзя считать совсем уж мусором. Поэтому сопротивляться предложениям труднее.
Вот некоторые инструменты, которые могут помочь вам разобраться:
Если мы «предполагаем, что даже если человек недостаточно компетентен, но у него добрые намерения», значит все идеи и запросы по продукту имеют какие-то достоинства. Возможно, ничто из предложенного нельзя считать совсем уж мусором. Поэтому сопротивляться предложениям труднее.
Вот некоторые инструменты, которые могут помочь вам разобраться:
1
Количественная оценка воздействия
Это самый очевидный вариант, но не лишним будет про него напомнить. Вы можете количественно оценить влияние ряда факторов, а затем перевести оценку в деньги:
По возможности приводите точные данные и цифры, чтобы оценка была максимально объективной.
Это самый очевидный вариант, но не лишним будет про него напомнить. Вы можете количественно оценить влияние ряда факторов, а затем перевести оценку в деньги:
- Охват: количество затронутых пользователей;
- Интенсивность: насколько некомфортно текущее состояние для этих пользователей;
- Сегмент пользователей: насколько ценен этот сегмент пользователей для компании (иногда охват может быть минимальным, но эта горстка пользователей может приносить вам половину дохода)
По возможности приводите точные данные и цифры, чтобы оценка была максимально объективной.
1
Понимание реальной стоимости фичи
Обычно довольно просто оценить стоимость разработки фичи. Попросите разработчиков оценить, сколько им потребуется времени, и умножьте на их зарплаты. Правда, кроме стоимости разработки есть и другие виды затрат:
Обычно довольно просто оценить стоимость разработки фичи. Попросите разработчиков оценить, сколько им потребуется времени, и умножьте на их зарплаты. Правда, кроме стоимости разработки есть и другие виды затрат:
- Стоимость содержания. После запуска фичи команда будет нести ответственность за ее поддержку и устранение возникающих проблем.
- Стоимость набора массы. Из-за новой фичи ваша кодовая база станет сложнее, а создание следующих фич займет чуть больше времени из-за возросшей сложности. Новому разработчику потребуется больше времени, чтобы разобраться в проекте.
- Стоимость улучшений. Вы можете надеяться, что фича идеально решит проблему, но будем честны — так случается редко. Возможно, вам придется с ней повозиться — доработать интерфейсы, поколдовать с настройками и т. д.
- Стоимость согласований. Вам и вашей команде придется участвовать в собраниях, писать письма, презентовать обновления, держать в курсе смежные команды и т. д.
1
Понимание чувствительности ко времени
Вопрос не всегда стоит как «Стоит ли решать эту проблему?». Вопрос может быть «Почему именно сейчас?»
Тонкая трещина в стене, возможно, сейчас не кажется достойной внимания. Но если ее игнорировать, однажды стена может обрушиться. Понимание цены бездействия или промедления поможет вам четче сформулировать проблему и оценить ее актуальность.
Некоторые проблемы подобны пожару — их нужно или решать немедленно, или придется всё строить с нуля. Другие больше похожи на протекающую крышу: ситуация становится всё хуже и хуже, пока крыша не рухнет. А есть проблемы напоминающие лужу на тротуаре — они раздражают, но никому не причиняют вреда, ведь каждый может её обойти.
Вопрос не всегда стоит как «Стоит ли решать эту проблему?». Вопрос может быть «Почему именно сейчас?»
Тонкая трещина в стене, возможно, сейчас не кажется достойной внимания. Но если ее игнорировать, однажды стена может обрушиться. Понимание цены бездействия или промедления поможет вам четче сформулировать проблему и оценить ее актуальность.
Некоторые проблемы подобны пожару — их нужно или решать немедленно, или придется всё строить с нуля. Другие больше похожи на протекающую крышу: ситуация становится всё хуже и хуже, пока крыша не рухнет. А есть проблемы напоминающие лужу на тротуаре — они раздражают, но никому не причиняют вреда, ведь каждый может её обойти.
1
Умение обоснованно говорить «Нет»
Итак, вы проделали все эти упражнения и твердо убеждены, что проблему действительно не стоит решать, по крайней мере сейчас. Дать отпор — необходимая часть вашей работы. Как сказал Уоррен Баффет: «Разница между просто успешными людьми и действительно успешными в том, что действительно успешные люди говорят „нет“ почти всегда».
Не ходите вокруг да около. Если вы не собираетесь выполнять просьбу, скажите об этом заранее и прямо. Покажите, что просьбу вы внимательно рассмотрели. Расскажите как именно пришли к этому выводу. Продемонстрируйте, чем вместо этого сейчас занята команда. Они же создают что-то более ценное! Вы должны уметь это формулировать.
Итак, вы проделали все эти упражнения и твердо убеждены, что проблему действительно не стоит решать, по крайней мере сейчас. Дать отпор — необходимая часть вашей работы. Как сказал Уоррен Баффет: «Разница между просто успешными людьми и действительно успешными в том, что действительно успешные люди говорят „нет“ почти всегда».
Не ходите вокруг да около. Если вы не собираетесь выполнять просьбу, скажите об этом заранее и прямо. Покажите, что просьбу вы внимательно рассмотрели. Расскажите как именно пришли к этому выводу. Продемонстрируйте, чем вместо этого сейчас занята команда. Они же создают что-то более ценное! Вы должны уметь это формулировать.
1
Делать что должны, даже если не согласны с этим
Каждый был в ситуации, когда HiPPO высказал свое мнение, а вам неймется сказать о чем-то, с чем вы не согласны. Такой соблазн поворчать и выговориться перед командой.
Каждый был в ситуации, когда HiPPO высказал свое мнение, а вам неймется сказать о чем-то, с чем вы не согласны. Такой соблазн поворчать и выговориться перед командой.
HiPPO — аббревиатура от highest paid person’s opinion, то есть «мнение самого высокооплачиваемого сотрудника».
Джефф Безос из Amazon популяризировал концепцию «не соглашаться и соглашаться». Она хороша. Да, возможно, вы лично не согласны с тем, что говорит руководитель, но как менеджер продукта и лидер команды вы должны выступить с ним единым фронтом.
Поиск стратегических возможностей
Сейчас мы говорим о максимальной неопределенности: неясны и проблема, и решение. Это прекрасная возможность сделать шаг назад и посмотреть на картину целиком.
На какую из проблем следует обратить внимание?
Ответ на вопрос требует глубокого понимания, как и почему пользователи используют продукт, а также факторов, которые они учитывают при переходе на ваш продукт или отказе от него. Профессор Гарварда Клейтон Кристенсен впервые представил этот фреймворк в 2016 году, и с тех пор он стала одним из самых популярных для разработки продуктов.
1
Понимание реальных задач пользователей (JTBD)
Главный принцип JTBD (jobs to be done) — понимание, чего именно пользователь пытается достичь, когда «нанимает» ваш продукт. Ответ обычно глубже, чем самый очевидный. Представьте, что продукт, которым вы управляете, — это программа MBA. Люди получают степень MBA по разным причинам: чтобы сменить карьеру, продвинуться по карьерной лестнице, начать собственный бизнес и т. д.
Все эти причины можно еще раскопать. Например, что это на самом деле означает для людей, которые сказали, что получают степень MBA, чтобы продвинуться по карьерной лестнице? Что им сейчас мешает? Им не хватает уверенности? Есть ли у них пробелы в знаниях? Нужна ли им просто степень, подтверждающая полномочия?
Понимание корневой причины позволяет определить те возможности улучшения, которые можно реализовать в продукте, чтобы лучше удовлетворять потребности пользователей.
Главный принцип JTBD (jobs to be done) — понимание, чего именно пользователь пытается достичь, когда «нанимает» ваш продукт. Ответ обычно глубже, чем самый очевидный. Представьте, что продукт, которым вы управляете, — это программа MBA. Люди получают степень MBA по разным причинам: чтобы сменить карьеру, продвинуться по карьерной лестнице, начать собственный бизнес и т. д.
Все эти причины можно еще раскопать. Например, что это на самом деле означает для людей, которые сказали, что получают степень MBA, чтобы продвинуться по карьерной лестнице? Что им сейчас мешает? Им не хватает уверенности? Есть ли у них пробелы в знаниях? Нужна ли им просто степень, подтверждающая полномочия?
Понимание корневой причины позволяет определить те возможности улучшения, которые можно реализовать в продукте, чтобы лучше удовлетворять потребности пользователей.
1
Понимание, почему пользователи переходят на ваш продукт
Когда пользователи решают использовать ваш продукт, они переключаются с чего-то, что использовали раньше. Даже если они ранее не использовали никакой «продукт»: бездействие — реальная альтернатива.
В решении о переходе на продукт играют роль:
Задача менеджера по продукту — выявить эти факторы, влияющие на переключение на продукт. Это позволит предпринимать осмысленные действия, чтобы уменьшить барьеры при переходе на него.
Когда пользователи решают использовать ваш продукт, они переключаются с чего-то, что использовали раньше. Даже если они ранее не использовали никакой «продукт»: бездействие — реальная альтернатива.
В решении о переходе на продукт играют роль:
- Подталкивающие факторы: уязвимые места текущего решения и неудовлетворенность им.
- Притягивающие факторы: преимущества и выгоды нового решения.
- Тревога: опасения и неуверенность по поводу нового решения.
- Инерция: привычка и хорошее знание текущего решения.
Задача менеджера по продукту — выявить эти факторы, влияющие на переключение на продукт. Это позволит предпринимать осмысленные действия, чтобы уменьшить барьеры при переходе на него.
Давайте еще раз рассмотрим эти четыре фактора на примере MBA.
Пример: четыре фактора, влияющие на решение поступить на программу MBA
Как мы можем гарантировать будущее продукта?
Улучшение продукта не всегда ограничивается вашим текущим игровым полем. Радикальные инновации обычно возникают в результате взгляда вовне, а не постепенных улучшений.
1
Понимание конкурентной среды вашего продукта
У каждого продукта есть не только очевидные конкуренты. Университет X не просто конкурирует с университетами Y и Z при продвижении своей программы MBA. Он конкурирует также с семинарами, онлайн-курсами, подкастами, коучингом для руководителей и даже с Netflix.
Чтобы найти эти альтернативы и сравнить их с вашим продуктом, можно взять за основу потребности клиентов и оценить, насколько хорошо каждый из вариантов удовлетворяет эти потребности. Простой пример:
У каждого продукта есть не только очевидные конкуренты. Университет X не просто конкурирует с университетами Y и Z при продвижении своей программы MBA. Он конкурирует также с семинарами, онлайн-курсами, подкастами, коучингом для руководителей и даже с Netflix.
Чтобы найти эти альтернативы и сравнить их с вашим продуктом, можно взять за основу потребности клиентов и оценить, насколько хорошо каждый из вариантов удовлетворяет эти потребности. Простой пример:
PS: Полезно также выделить сегменты пользователей, поскольку у каждого сегмента будут свои потребности, и не все сегменты одинаково ценны для вашего бизнеса.
А теперь представьте, что вам, как менеджеру по продукту программы MBA, поручено разработать совершенно новый продукт, который перевернет представление об MBA. Вы сможете взять карту потребностей клиентов, определить, какие потребности не удовлетворяются доступными в настоящее время решениями, и создать новую уникальную программу с сильными ценностными предложениями.
1
Определение возможностей расширения цепочки ценности вашего продукта
Вашему продукту угрожают не только старые или новые конкуренты. Есть и другие факторы, их описал Майкл Портер в анализе пяти сил. Там он говорит о признании «переговорной силы» ваших клиентов и поставщиков. Если ваши поставщики могут поднять цену, а у вас не остается выбора — вы облажались. Если ваши клиенты могут без проблем отказаться от вашего продукта или обрушить цену — у вас проблемы.
Так что, если вы хотите повысить вероятность долгосрочного успеха вашего продукта, вам придется уменьшить их «переговорную силу», увеличив свою.
Наверное, он прав, но такая формулировка может заставить чувствовать себя неуютно. Концепция подразумевает драку за власть, в которой одна сторона должна проиграть. Можно думать об этом по-другому: как мы можем расширить цепочку ценности нашего продукта?
Давайте возьмем для примера Shopify. Все началось с создания маркетплейса: владелец бизнеса может загрузить логотип, выбрать оформление витрины, добавить свои товары, и вуаля, у него появится собственный интернет-магазин за 15 минут. Целевой аудиторией были люди, у которых уже был бизнес и товары для продажи, им просто нужно было присутствие в Интернете.
Затем Shopify увидели возможность: начинающие предприниматели. Те, кто хочет начать собственный онлайн-бизнес, но еще не знает, что продавать? Для них запустили оптовый рынок и дропшиппинг.
Вашему продукту угрожают не только старые или новые конкуренты. Есть и другие факторы, их описал Майкл Портер в анализе пяти сил. Там он говорит о признании «переговорной силы» ваших клиентов и поставщиков. Если ваши поставщики могут поднять цену, а у вас не остается выбора — вы облажались. Если ваши клиенты могут без проблем отказаться от вашего продукта или обрушить цену — у вас проблемы.
Так что, если вы хотите повысить вероятность долгосрочного успеха вашего продукта, вам придется уменьшить их «переговорную силу», увеличив свою.
Наверное, он прав, но такая формулировка может заставить чувствовать себя неуютно. Концепция подразумевает драку за власть, в которой одна сторона должна проиграть. Можно думать об этом по-другому: как мы можем расширить цепочку ценности нашего продукта?
Давайте возьмем для примера Shopify. Все началось с создания маркетплейса: владелец бизнеса может загрузить логотип, выбрать оформление витрины, добавить свои товары, и вуаля, у него появится собственный интернет-магазин за 15 минут. Целевой аудиторией были люди, у которых уже был бизнес и товары для продажи, им просто нужно было присутствие в Интернете.
Затем Shopify увидели возможность: начинающие предприниматели. Те, кто хочет начать собственный онлайн-бизнес, но еще не знает, что продавать? Для них запустили оптовый рынок и дропшиппинг.
Упрощенная цепочка ценности при управлении интернет-магазином
Следующий шаг в управлении интернет-магазином — выполнение заказа, то есть его отправка покупателю. Shopify решили также поучаствовать в этом процессе, создав собственный фулфилмент.
Так Shopify делает себя незаменимым, предлагая ценные сервисы. Это усложняет переход продавцов к конкурентам. Это хорошо для Shopify, но не плохо и для продавцов на площадке.
Вывод: попробуйте воспроизвести процесс, через который проходят ваши клиенты для решения своей задачи. Есть ли способ повысить вашу ценность, помогая им в этом процессе до или после того, как они воспользуются вашим продуктом?
Так Shopify делает себя незаменимым, предлагая ценные сервисы. Это усложняет переход продавцов к конкурентам. Это хорошо для Shopify, но не плохо и для продавцов на площадке.
Вывод: попробуйте воспроизвести процесс, через который проходят ваши клиенты для решения своей задачи. Есть ли способ повысить вашу ценность, помогая им в этом процессе до или после того, как они воспользуются вашим продуктом?
Резюме
Не существует единого инструмента, который работал бы всегда. Вы можете улучшить свое мастерство управления продуктом, 1) увеличив количество инструментов в своем арсенале и 2) разобравшись, когда использовать каждый из них.
Есть две ловушки:
Если вы не уверены, насколько ясно понимаете проблему или решение, есть одна хитрость: попробуйте записать ее. В форме пресс-релиза, благодарственного письма клиенту или просто повествования, описывающего проблему и решение.
Есть две ловушки:
- Избыток вопросов о проблеме и ее решении. Вам не всегда нужно использовать самый продвинутый инструмент. Не надо пытаться произвести впечатление или доказать, что вы действуете как зрелый менеджер по продукту. Если стоимость анализа выше, чем стоимость разработки, просто разработайте и отгрузите. Рынок подскажет, насколько это было правильно.
- Недостаток вопросов о проблеме и решении. Ошибка новичков (они думают, что кто-то другой выполнил работу по разъяснению проблемы и решения) или ветеранов (они слишком хорошо знакомы с компанией, пользователем и областью, поэтому воспринимают все как должное). Под «новичками» и «ветеранами» имеем в виду стаж работы в компании, а не возраст.
Если вы не уверены, насколько ясно понимаете проблему или решение, есть одна хитрость: попробуйте записать ее. В форме пресс-релиза, благодарственного письма клиенту или просто повествования, описывающего проблему и решение.