15 советов по управлению продуктом

Управление продуктом - это всегда компромисс между классическим менеджментом, техническими знаниями, аналитикой и маркетингом. Спросите любого продакт менеджера (далее для упрощения - PM), чем он занимается, и каждый ответит по своему, наверное в этом и есть вся прелесть работы.

Быть PM нелегко: изо дня в день нужно улучшать и демонстрировать свои навыки в области исследований, планирования, расстановки приоритетов и прогнозирования (и это далеко не все). PM'ы определяют стратегию продукта, но не могут делать это в одиночку. Им нужна помощь множества различных заинтересованных сторон - коллег и клиентов.

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

1. Напишите список ключевых функций

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

Итак, представьте: перед вами чистый, новенький, совсем нетронутый проект, который назначили именно вам. Страшновато, не так ли? В голове роятся мысли, все неструктурированно и вообще не понятно, с чего лучше начать и за что взяться в первую очередь.

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

2. Всегда составляйте план

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

В настоящее время люди делятся на два типа: те, кто с гордым выражением лица заявляют о своей гениальности и могут держать каждую секунду, каждое действие в своей голове 24/7 и те, кто планирует свой день по секундам, планируя точное время, когда они пойдут чистить зубы и сколько времени они могут потратить в социальных сетях. В нашем деле важно найти золотую середину.

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

3. Тщательно выбирайте команду

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

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

4. Рассказывайте команде о новом продукте/новой фиче

Итак, я вас поздравляю: команда собрана, что дальше? Кивнуть им, добавить в группу в Телеграмме и все? Нет! Сделайте встречу со всей командой и расскажите, о новом продукте/новой фиче до её старта. Важно донести проблему, которая будет решаться командой. Показать данные статистики или макеты с примерами решения в других командах/компаниях.

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

5. Открыто демонстрируйте прототип

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

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

6. Используйте инструменты раннего прототипирования

Кроме того, не нужно тратить 100 часов разработчика, чтобы собрать первый прототип, используйте Figma и покажите прототип вашей целевой аудитории.

7. Найдите способы еще уменьшить объем

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

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

8. Используйте проверенные инструменты

Новаторство всегда поддерживается, однако в старте нового проекта, не стоит экспериментировать с новым таск-трекером или git-репозиторием.

9. Определите формат работы с командой

Пандемия принесла нам неожиданные приятные фичи в виде дистанционной работы и учебы. Несмотря на то, что все на нее злились, многие отказались возвращаться в офис, и это нормально. Дома комфортнее, и не надо в пробках стоять. А пунктуальность чаще всего - враг 90% работников.

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

Запомните, никому не хочется стоять по 10-15 минут каждое утро, просто потому что так в книге написано. Всегда можно найти компромисс.

10. Акцентируйте внимание на самых сложных функциях продукта

Не оставляйте самые сложные задачи на конец. Сделайте несколько исследований на этапе проектирования продукта для самых сложных фич. Такой подход снизит количество неизвестных и минимизирует риск провалить релиз первой/новой версии.

11. Назначьте хотя бы одно еженедельное совещание по статусу продукта

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

12. Возьмите на вооружение git-flow

Обычно он включает в себя ветки c фичами, регулярные коммиты и обратное слияние с основной веткой.

13. Набирайте обороты как можно быстрее

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

14. Продолжайте следить за тем, чтобы по всем незакрытым таскам были оценки

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

15. Следите за скоростью вашей разработки

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

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

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