Вообще минусы публичных (но внутри команды) апдейтов понятны — их написание отнимает время. А часть команда считает их мудой, которая не приносит пользы (“зачем писать, надо копать”).
Плюсы же не только в том, что они структурируют мышление и подсвечивают проблемы. Один из других плюсов — увеличение прозрачности продуктовой команды, что убирает лишние вопросы.
Представим уже более-менее подросшую компанию. Продуктовая команда будет получать много вопросов:
- А что вы делаете? А зачем?
- А когда будет сделана моя штука? А почему не скоро?
- А что интересного планируете выпускать? Нам надо для плана анонсов.
- А пишите нам, когда выпускаете новые штуки — мы будем партнёров оповещать.
- А расскажите про это вот изменение, нам надо маркетинговые материалы по ней готовить.
- А давайте каждое изменение в фичах, доступных на линейке планов, обсуждать с командой. Приходите к нам с каждым изменением для аппрува.
И так далее. У каждого отдела есть вопросы к продуктовой команде и это нормально. Если продукт в сердце компании, то любые изменения продукта влияют на всех. Отсюда вопросы. Проблема не в вопросах, проблема в том, что 1) это одинаковые вопросы от разных людей 2) у вас будут просить заранее ответы с детализацией, которая не нужна
Публичный ежемесячный апдейт снимает множество этих вопросов. Вместо подхода “приходите — я каждому расскажу” применяется подход “вся информация в известном месте — придите и возьмите”.
- А что вы делаете? А зачем? → Вот документ со свежим списком и объяснением, не согласны — пишите в комментариях к документу.
- А когда будет сделана моя штука? А почему не скоро? → Вот тут список того, над чем мы собираемся работать, почему и какой прогноз по датам. Если вы считаете, что надо делать что-то другое — давайте обсуждать, почему ваша штука приоритетней текущего плана.
- А что интересного планируете выпускать? Нам надо для плана анонсов → А вот план.
- А пишите нам, когда выпускаете новые штуки — мы будем партнёров оповещать → Мы будем публиковать ссылку на документ в публичном канале, который все читают. Это наш публичный чейндждог, используйте его как хотите.
- А расскажите про это вот изменение, нам надо маркетинговые материалы по ней готовить → А вот тут в документе описано что, зачем и почему.
- А давайте каждое изменение в фичах, доступных на линейке планов, обсуждать с командой. Приходите к нам с каждым изменением для аппрува. → Вот документ с описанием изменений. Читайте, обсуждайте внутри, если с чем-то не согласны — приходите обсуждать конкретную штуку.
Паттерн один и тот же (“push/pull стратегии” или “тянитолкай” это всё примерно про то же). Такой подход не убирает вопросы на 100%(особенно если в деле завязаны игры статуса — “нет, пусть ВЫ ко мне придёте”), но всё же облегчает жизнь. И самое интересное, что на практике мало кому нужно столько информации, сколько они запрашивают. Человек, который с радостью будет хотеть учавстовать в обсуждение каждого изменения (“хочу всё знать”) на деле может не читать публичный документ и не обсуждать ничего (то есть не так уж это было ему/ей важно).