За несколько лет работы и проведения
обучения в теме управления продуктами мы с коллегами составили подборку типичных ошибок, которые совершают начинающие, и не только, менеджеры продуктов.
Список будет полезен не только менеджерам продуктов, но и предпринимателям и стартаперам – попробуйте поучиться на чужих ошибках ????
Общее управление продуктом
1. Leap of Faith. Пускаемся в разработку без проверки идеи
Ещё 10 лет назад такую ошибку совершали все подряд. Менеджер продукта регистрирует красивый домен, пишет ТЗ, под это ТЗ ищет разработчика и поехали. Спустя в лучшем случае 3 месяца потрачены несколько тысяч долларов, выпито множество кружек кофе, запущено как-то работающее приложение. Пользователи приходят (если приходят вообще) и уходят, приложение «не цепляет».
Менеджер продукта пытается «допилить» приложение до какого-то одному ему понятного уровня качества, и/или нанять продажника или маркетолога, но денег особо нет и все попытки задействовать новые маркетинговые каналы проваливаются одна за другой.
Определение продукта
Рассмотрим несколько частных случаев предыдущей ошибки:
2. Синдром «визионера». Делаем собственные хотелки, не говорим с клиентом
Менеджер продукта восклицает «эврика» и с увлечением описывает свою замечательную фантазию о том, как бы пользователям было полезно и удобно. ТЗ или макеты получаются развесистыми, план работ содержит 50 крутых фич, требует полгода работы. Никаких исследований, переговоров, наблюдений, экспериментов, тестов в плане нет — и так же всё понятно! Итог — не взлетает ????
3. Делаем то, что просят клиенты
«Клиентоориентированность! Давайте будем решать проблемы клиентов, послушаем, что они скажут». Менеджер продукта собирает просьбы клиентов или одного клиента (в случае корпоративных продуктов), оформляет в ТЗ и поехали!
4. Слепое копирование конкурентов
Под лозунгами "great artists steal" и «давайте учиться на чужих ошибках» можно проанализировать конкурентов, собрать список фич, которые есть у всех из них и попытаться превратить в продукт.
Как ни странно, но в некоторых случаях и на некоторых рынках это иногда работает. Но если вам даже хватило денег запуститься, рынок за это время не уехал в плане развития за горизонт и вы заполучили какое-то количество пользователей, то неминуемо встают вопросы о том, как растить число пользователей и куда развивать продукт дальше и почему.
Когда копируешь у конкурента, то важно понимать, что действительно работает. Потому что можно скопировать то, что не работает.
Ошибки организации исследований
Когда наконец менеджер продукта понимает, что при создании продукта с нуля нельзя брать и реализовывать первую попавшуюся красивую идею, а стоит иметь под ней хоть какое-то основание, в ход идут исследовательские ошибки:
5. Опросы вместо интервью
Ок, выяснили, что мнение одного человека ничего не значит для продукта — давайте усредним! AVG (bullshit) != bullshit!
(Особенно этим грешат менеджеры продуктов с техническим бэкграундом. Мы делаем вывод, что зачастую они не ценят общение с людьми, считая его потерей времени и более того, боятся и избегают разговоров)
Основная проблема использования опросов в ходе исследования состоит в том, что они превращают процесс поиска проблемы, достойной решения, в процесс выбора одного из вариантов решений. В опросах самих по себе нет ничего плохого — они вполне могут быть полезны и эффективны для уточнения статистики, распределения мнений или опыта людей по разным вариантам.
Опросы — это количественное исследование, которое хорошо работает на массах, чтобы статистически что-то подтвердить или опровергнуть. Но прежде чем запускать опрос, надо понимать, что спрашивать. Поэтому нужно предварительно провести качественное исследование которое часто сводится к интервью.
Используя опросы как основной инструмент поиска ответа на вопрос «какой продукт создавать» или, точнее, «какие проблемы решать», вы вместе с водой (упрощением, удешевлением общения с людьми) выплёскиваете и ребёнка.
6. Фокус-группы вместо интервью
Другой, менее жёсткий вариант удешевления общения с выплёскиванием ребёнка — организация фокус-групп. Да, в этом случае вы можете услышать мнения конкретных людей и даже их реакции на мнения других. Но вы становитесь жертвой эффектов, таких, как Group Think, попросту говоря «стадного мышления» — люди с неохотой озвучивают свой личный опыт, говорят социально приемлемые вещи, соглашаются с мнением человека, который ведёт себя доминантно в группе (хотя сами думают по-другому).
Ещё одна проблема фокус-групп — невозможно подробно и глубоко разобраться в опыте, проблемах, представлениях конкретного человека, а именно это зачастую самое ценное в исследованиях на этапе поиска проблемы, достойной решения.
7. Спрашиваем клиентов, чего они хотят
Ещё не так давно спрашивать клиентов о том, чего они хотят, казалось правильным и разумным подходом (в конце концов, он работает(?) в заказной разработке).
Когда мы спрашиваем клиентов, чего они хотят, мы предлагаем клиентам сыграть в увлекательную игру и поделиться своими фантазиями.
Практика показала, что идеи клиентов о том, что будет полезно им, или, тем более, рынку, имеют очень мало общего с реальностью ????
8. Изучаем мнения клиентов о будущем (вместо фактов о прошлом и настоящем)
За последние годы мы узнали кое-что существенное о людях и их способностях предсказывать будущее — они оказались ужасающе плохи в предсказаниях:
— Купите ли вы наш продукт? — Да (ложь)
— Будете ли вы использовать наш продукт? — Да (ложь)
— Будет ли вам полезен такой продукт? Да (возможно правда, но не настолько, чтобы им пользоваться)
Есть несколько причин о том, почему люди говорят неправду о своём будущем:
- Они не знают наверняка
- Они дают социально приемлемые ответы, хотят поддержать собеседника
- Обстоятельства меняются, поведение людей зависит от контекста
Роб Фитцпатрик написал
целую книжку о том, как на самом деле полезно спрашивать потенциальных пользователей и клиентов.
9. Интервью вместо наблюдения
На самом деле это не совсем уж ошибка, но надо понимать, что интервью — это отфильтрованное воспоминание. Люди гораздо меньше ошибаются при рассказе о прошлом или настоящем, чем при рассказе о будущем, но при этом всё равно волей-неволей искажают — как минимум потому, что им сложно полноценно транслировать контекст и переживания в конкретной ситуации.
Наблюдения часто кажутся неочевидным и дорогим в организации подходом, но иногда это не так — в частности, если вы рискуете большими вложениями в продукт или речь идёт о развитии продукта с миллионами активных пользователей..
10. Защитная позиция при работе с фидбеком
Частный случай (пользовательских) исследований — приём, анализ, обработка фидбека. Если продукт, услуга уже запущены или даже если вы показываете прототип, очень часто в ответ на слова клиента возникает желание объяснить ему, почему он получил такой опыт, почему кнопка работает так или иначе, в какой версии браузера нет какой джавы, что цена на самом деле нормальная, что цвета не уродские и т.д.
Эта реакция вполне типовая для продажника, сотрудника техподдержки или SMM-менеджера — вы пытаетесь сгладить, выправить пользовательский опыт словами. Но реагируя подобным образом, вы, как менеджер продукта, в этот момент не получаете новой информации.
Более того, при работе с массовым рынком вы не сможете бегать за миллионом пользователей, объясняя, как на самом деле устроен интерфейс (впрочем, некоторые onboarding-механизмы пытаются это делать) или сценарий работы с вашим сервисом.
Клиент с фидбеком — это мощнейший инструмент, чтобы узнать, что в вашем продукте идёт не так, уточнить сценарии использования, выделить новую группу пользователей, узнать, что ещё оказывается важным для ваших клиентов и, самое главное, почему.
Тестирование идей
11. «Железный» MVP
Относительно свежий миф и ошибка — пытаться тестировать идею решения пользовательской проблемы через полноценную реализацию в коде и железе.
На самом деле зачастую достаточно оказать услугу, закладываемую в продукт, в ручном режиме, чтобы изучить и перепроектировать сценарий доставки ценности клиенту и опыт, который он получает.
Многие менеджеры боятся выпустить что-то некачественное, но для тестирования идеи не нужно добиваться определённого качества, т.к. цель тестирования — как можно быстрее получить знание о клиенте, а не добиться соответствия лучшим стандартам качества.
12. Продажа через откат
Некоторые менеджеры B2B-продуктов пытаются выдавать продажи, сделанные через «откат», за успешное тестирование гипотезы о востребованности продукта.
13. Бесплатные контракты
Когда ваш продукт бесплатно установили несколько корпоративных клиентов или на вашем сервисе зарегистрировались тысячи пользователей, легко впасть в состояние эйфории, считая, что вы смогли создать полезный продукт.
Однако при попытке продавать его за настоящие деньги вы можете получить совсем другие результаты.
Поэтому говорят, что единственным настоящим тестом востребованности продукта выступают деньги, которые заплачены клиентом и лежат на вашем счёте.
Продажи и экономика
14. Даём возможности, а не решаем проблему. Продажа фич, а не ценности
Эти ошибки наиболее наглядно видны на лендингах сервисов и в презентациях продуктов. Менеджер продукта увлёкся технологиями или интерфейсными фишечками и продаёт клиенту их: «Управление поставками», «Новый интерфейс», «Конструктор отчётов». Зачастую выясняется, что клиенты за такими словами не видят, какую конкретно пользу даст продукт и почему он вообще может быть интересен.
15. Не считаем экономическую модель
Парадоксально, но многие менеджеры продукта почему-то до поры до времени не считают, что продуктовый менеджмент как-то связан с бизнесом и экономикой. Такие менеджеры могут думать о глубине просмотров, количестве повторных покупок, рейтинге приложения, конверсии — метриках, безусловно, полезных в некоторых случаях, но не самых главных для бизнеса.
Часто оказывается, что стоимость привлечения клиента превышает фактическую прибыль с него и наш паровоз при всей внешней мощи несётся в экономическую пропасть.
Считать unit-экономику на практике — не сложнее, чем решать задачки по арифметике.
16. Создаём фантастические бизнес-планы без опоры на факты
Из мира традиционного бизнеса и MBA пришло понятие «бизнес-плана» как идеи о том, что можно и стоит заранее рассчитать статьи доходов и расходов продукта. Помесячно. Это действительно так для типового тиражируемого производства уже существующих товаров.
Но при создании нового цифрового продукта и услуги с 0 эти цифры опять-таки не имеют ничего общего с реальностью. Если вы отталкиваетесь от цифры 0 (или 1) — то все остальные цифры ничто иное, как цифровые галлюцинации.
Управление сроками и качеством
17. Строим звезду смерти
Люди, воспитанные в среде корпоративных систем, при переходе в рыночный контекст часто пытаются сделать первую версию продукта с большим количеством фич.
Помимо традиций заказной и внутренней разработки за этим часто кроется банальное неумение фокусироваться на ценности и обнаруживать её.
18. Золочение
Ещё один смежный грех, который часто ходит парой с предыдущим. Вместо выпуска на рынок прототипа или продукта для скорейшей проверки идеи, менеджер продукта пытается довести до совершенства отдельные фичи, интерфейса, функции, постоянно откладывая запуск и, как следствие, контакт с реальностью. Помимо неумения фокусироваться, ещё одной возможной причиной такого поведения является страх неудачи и ошибки, опасный в предпринимательской среде и блокирующий возможности менеджера-предпринимателя.
О том,
как стоит работать с продуктом, поговорим в следующий раз.
Денис Бесков, управляющий партнёр Product.Vision