Вредные советы для продактов и их решения 1. Когда хочется | Fresh Product Manager

Вредные советы для продактов и их решения

1. Когда хочется общаться, а не работать — используйте фокус-группы из своих друзей и знакомых. Не бойтесь: Groupthink (по-русски: стадное мышление) с вами просто не может случиться.
Нет! : если у вас нет возможности проводить полноценное интервью, работать с фокус-группой можно. Однако не стоит набирать её из своих друзей. Лучше всего пригласить независимых представителей потенциальной аудитории. Приглашайте разных людей, ведь пользователи тоже будут отличаться. Так у вас получится собрать максимум информации.

2. Не воспринимайте фидбек серьёзно. Обидеть менеджера по продукту может каждый. Позже, когда продукт будет уже запущен, клиент увидит, что всё работает. А результат — именно то, что он на самом деле хотел.
Нет!: Воспринимайте фидбек серьёзно. Даже если он кажется вам глупым, подобное может написать технически неграмотный пользователь в дальнейшем. Конечно, если отзыв неадекватный, это следует обсудить с заказчиком. Однако постарайтесь найти причину такого фидбека в любом случае. Определите истинную проблему клиента.

3. Тестируйте все проблемы на полноценном MVP. Только полная реализация в железе и коде, только хардкор. Ручной режим не покажет всех ошибок, а вы ведь проводите тесты наверняка.
Нет!: тестируйте мелкие добавления вручную. Это сэкономит время и силы команды намного больше, чем создание MVP каждый раз. Нужно только найти в команду нормального тестировщика, тогда проблем не возникнет.

4. Лайфхак для тех, кто работает с B2B-продуктами. За успешное тестирование гипотезы о востребованности разработки всегда можно выдать продажи через «откат».
Нет!: никогда не подавайте результаты от продаж через «откат» как успехи в тестировании. Это непрофессионально и незаконно. Когда-нибудь всё раскроется, в лучшем случае — вылетите с работы.

5. Ставьте акценты правильно. Продавайте фичи, а не ценности. В конце концов, зря вы их что ли придумывали? Не объясняйте смысл, не всем дано понять гениальное. Повезёт — разберутся на практике.
Нет!: За каждой фичей должна стоять какая-то ценность. Важно делать акцент именно на второе. Вы предлагаете не просто функционал, код или дизайн, а решение какой-то проблемы. Заказчику не всегда очевидно, для чего нужна кнопка, скрипт и т. д., поэтому объясняйте ему с помощью таких понятий, как ценность, проблема, решение и действие.

6. Даже не начинайте считать экономическую модель. Рассчитывать unit-экономику сложно и, вообще, вы не математик. Если случится так, что стоимость приложения в итоге превысит доход от него — проблема в клиенте.
Нет!: считать unit-экономику нужно. К вам обращаются за услугой и доверяют проект, поэтому невнимательно относиться к нему нельзя. Особенно — к финансовой части. Важно рассчитать потенциальную прибыль, доход от одного пользователя или продажи. Это поможет правильно распределить ресурсы команде и грамотно вложить средства клиенту.

7. Дайте полную свободу команде. Хватит названивать и писать разработчикам. Уже не маленькие, сами справятся. Команду, вообще, можно не беспокоить вплоть до дня сдачи продукта. Да, вы ответственный за проект, но всегда может быть человеческий фактор.
Нет!: продукт-менеджер обязан контролировать команду. Для этого не обязательно стоять с палкой возле двери (хотя, если ваши вкусы специфичны…), можно использовать Jira, рабочие столы на общем сервере или флипчарты. Это необходимо, чтобы координировать каждого члена команды в рамках спринтов: не давать зарабатываться, опаздывать, делать что-то не то.

На этот пост вдохновил доклад руководителя разработки из X5 Tech с конференции YaTalks.В подкасте описываются любимые (и не всегда очевидные) способы, которыми технические специалисты способны сильно испортить жизнь себе и коллегам, и которыми они наверняка продолжат пользоваться в 2023 году. В основе — собственный практический опыт, наблюдения и полезные кейсы других команд. Рекомендую к прослушиванию.