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

В “плохих продуктах” задачи касательно продукта поступают ежедневно незамедлительными к исполнению. В таком потоке - “хаосе”, невозможно говорить о продуктовом подходе в развитии продукта или группы продуктов, которые находятся в ведении product manager.

Для примера, в компании Wildberris в одном из направлений, руководство говорило терминами Agile, Scram и тд однако на практике сверху к ним, а зачастую и на уровне этих руководителей направления, формировались странные задачи, о замысле влияния которых было известно - никому. Как итог постоянные отмены и переделки только что реализованных задач, а виноват - product manager.

Как с этим справлялись? Для начала внедрили принцип по ведению доски фич/задач - внедрили Kanban. Это когда задачи сыпятся как из рога изоблия однако добавили туда оценку и приоритезацию от “Сделать как можно скорее” (ASAP) до “надо бы вероятно сделать когда-нибудь" (низкий приоритет). Это помогло просто переворить поток. После чего объяснили и договорились как правильно оценивать и расставлять приоритет.

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

Низкий уже ранее рассказал, а вот другие два - это:

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

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

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

Удобнее делать так: есть год и 4 квартала в нем, отдельно сущность “Ассайны”. Ассайны содержат в себе все задачи, которые идут параллельно с роадмапом развития продукта. Например, то что было выявлено на совещании или переговорах или при общении с другими отделами (продажами, маркетингом, юристами, финансистами и т.д.)

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

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