Разбор 20 вредных советов для менеджеров проекта

20 вредных советов менеджерам по продукту

20 вредных советов менеджерам по продукту

Помните «Вредные советы» Остера? Мы тоже так можем (почти). Вернитесь в детство и прочитайте 20 рекомендаций менеджерам по продукту. Запоминайте каждый из них и никогда не повторяйте в офисе.

Кто такой продакт-менеджер? Это почти великий и многорукий бог Шива, который должен успеть и поработать с оценкой, и позвонить заказчику, и обсудить работу с командой, да и, вообще, ещё много всего. Чтобы облегчить им жизнь, мы подготовили 20 отборных вредных советов:

1. Идею проверяют только неуверенные в себе слабаки. Даже если задумка клиента кажется неактуальной, вы уже согласились, а значит этот продукт наверняка будет востребован. Ведь вы — мидас от продуктового менеджемента.

НА САМОМ ДЕЛЕ

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

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

НА САМОМ ДЕЛЕ

Если проект нуждается в дополнениях, предупреждайте клиента сразу. Не важно, когда вы обнаружили это: до первого спринта или в течение работы. Никогда не вписывайте в задачи то, что не оговорено с клиентом, даже если это критически важно для разработки. Уведомьте человека, дождитесь его решения и лишь потом приступайте к оптимизации. Обязательно внесите все дополнения в договор!

3. Вообще не общайтесь с заказчиком. Просто ответьте заказчику «да» и наслаждайтесь жизнью. Она сама всё организует. Увидели несостыковку или ошибку в требованиях? Какая разница, кто платит деньги, тот всегда прав. 

НА САМОМ ДЕЛЕ

Умейте говорить клиентам с неадекватными идеями «нет», даже если они давят на вас. И, вообще, говорите со всеми заказчиками (по работе). Предупреждайте их о возможных или возникших проблемах, старайтесь объяснить, что происходит и над чем работает ваша команда сейчас. 

4. Велосипед уже изобрели, поэтому просто копируйте конкурентов. Особенно этот совет актуален при рядовой идее. Она и так не выдержит конкуренции, поэтому тратить время и силы на разработку очередного мусорного ПО просто не стоит. 

НА САМОМ ДЕЛЕ

Любое копирование будет замечено и негативно скажется на репутации вашей компании. Анализировать конкурентов можно и нужно, однако перенимать код, дизайн или какие-то фишки полностью — нет.

5. Интервью надо брать у Тарантино, пользователям хватит опроса Вконтакте. Вы менеджер по продукту, а не какой-то там журналист. Подойдёт быстрый опрос. Например, «В приложениях главное…. а) удобство б) контент в) низкая цена».

НА САМОМ ДЕЛЕ

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

6. Когда пообщаться хочется, а работать — не очень, или используйте фокус-группы из «своих». Конечно, вы знаете о Group Think (по-русски: стадном мышлении), но с вами этого просто не может случиться. 

НА САМОМ ДЕЛЕ

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

7. Если клиент настаивает на обсуждении проекта, поговорите о перспективах. Можете спросить, купил бы сам клиент такой продукт? Будьте оптимистичны  и настраивайте заказчика на позитив в любом случае.

НА САМОМ ДЕЛЕ

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

8. Не воспринимайте фидбек серьёзно. Обидеть менеджера по продукту может каждый. Позже, когда продукт будет уже запущен, клиент увидит, что всё работает. А результат — именно то, что он на самом деле хотел. 

НА САМОМ ДЕЛЕ

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

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

НА САМОМ ДЕЛЕ

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

10. Лайфхак для тех, кто работает с B2B-продуктами. За успешное тестирование гипотезы о востребованности разработки всегда можно выдать продажи через «откат».

НА САМОМ ДЕЛЕ

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

11. Доверяйте, но не проверяйте (для тех, кто верит в лучшее в людях). Деньги — это мерило успеха дьявола. Ориентируйтесь только на то, сколько людей или компаний установило продукт бесплатно.

НА САМОМ ДЕЛЕ

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

12. Ставьте акценты правильно. Продавайте фичи, а не ценности. В конце концов, зря вы их что ли придумывали? Не объясняйте смысл, не всем дано понять гениальное. Повезёт — разберутся на практике.

НА САМОМ ДЕЛЕ

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

13. Даже не начинайте считать экономическую модель. Рассчитывать unit-экономику сложно и, вообще, вы не математик. Если случится так, что стоимость приложения в итоге превысит доход от него — проблема в клиенте.

НА САМОМ ДЕЛЕ

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

14. Помните: новое — это хорошо забытое старое(для тех, кто ценит себя и своё время). Поэтому если идея заказчика напоминает проект, который у вас уже был, то можно просто «поднять» его и слегка изменить.

НА САМОМ ДЕЛЕ

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

15. Боритесь за идеал до конца (даже если вас умоляют остановиться). Любой продукт пытайтесь довести до совершенства. Тщательно выискивайте в разработке все, что можно исправить и исправляйте. Если не можете ничего отыскать, ломайте и отправляйте на доработку. 

НА САМОМ ДЕЛЕ

Перфекционизм — это неплохо в том случае, когда он не мешает другим. Поэтому будьте разумны в своём стремлении к идеалу (идеал всё равно недостижим). Если тестирования проходят без нареканий, значит продукт в порядке и его нужно оставить в покое.

16. Игнорируйте сопроводительную документацию. Заказчик уже всё объяснил при переписке или звонке. Можете даже не открывать техническое задание, особенно если работаете по SCRUM (вам всё равно придётся писать другой бэклог).

НА САМОМ ДЕЛЕ

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

17. Дайте полную свободу команде. Хватит названивать и писать разработчикам. Уже не маленькие, сами справятся. Команду, вообще, можно не беспокоить вплоть до дня сдачи продукта. Да, вы ответственный за проект, но всегда может быть человеческий фактор.

НА САМОМ ДЕЛЕ

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

18. Откажитесь от бесполезных task-менеджеров. Вам же ещё не 92, и у вас нет склероза. Поэтому каждый проект можно держать в голове. А если кто-то из членов команды отвлёкся и упустил задачу — это не ваша проблема. Просто поиздевайтесь над ним на ретроспективе.

НА САМОМ ДЕЛЕ

Необходимо отмечать каждую задачу и своевременно переносить её из столбика «Нужно сделать» в «В работе», а затем в «В сделано». 3 этих колонки — необходимый минимум для нормальной работы команды и профилактики несвоевременной седины продукт-менеджера.

19. Не обращайте внимание на конкурентов. Вообще. Вы выше этого. Те, кто настаивают на обязательном изучении и анализе рынка, просто хотят привлечь внимание к своим продуктам (или, возможно, им заплатили. Нативочка!).

НА САМОМ ДЕЛЕ

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

20. Идите только вперёд. Даже если во время тестирования нашёлся какой-то баг, вы уже слишком далеко зашли в работе. В конце концов, будет ещё итоговый тест, там и проверите наверняка. Ничего страшного не произойдёт.

НА САМОМ ДЕЛЕ

Пожалуйста, не спешите. Если во время тестирования нашёлся баг, нужно отдать продукт на доработку, а потом снова на тест. Да, это требует времени. Да, это будет снова и снова, пока команда не устранит проблему. Это позволит избежать завала в будущем, в том числе — на предрелизном тестировании.

Вывод

Это были все 20 вредных советов, которые точно помогут менеджеру по продукту… Теперь серьёзно. Если вы продукт-менеджер, перечитайте пункты ещё раз и никогда так не делайте, это непродуктивно. Создать хороший продукт с такими советами не получится ни у кого. Даже удача здесь не поможет.

Вот небольшая памятка полезных советов, их применять в работе можно и нужно:

1. Говорите с клиентом и пользователями.

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

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

2. Общайтесь с командой и контролируйте её работу.

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

3. Анализируйте рынок и читайте документацию.

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

4. Выявляйте потребность и решайте проблемы при создании продукта.

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