Продуктовое мышление и пордуктовый подход позволяют компаниям делать продукты, которыми будут пользоваться. Чем больше членов продуктовой команды обладают продуктовым мышлением, тем больше шансов выпустить на рынок успешный продукт.
Содержание
- Зачем развивать продуктовый подход в команде, если есть менеджер продуктов
- Команды не понимают задачи других команд
- Проблемы с синхронизацией и межкомандной коммуникацией
- Искажение информации и долгое согласование
- Команды фокусируются на задачах, а не на продукте
- Как внедрять продуктовый подход в управлении
Зачем развивать продуктовый подход в команде, если есть менеджер продуктов
Вот несколько причин, почему всем членам команды важно развивать продуктовое мышление:
- Большую часть решений о продукте принимают продакт-менеджеры, которые тоже подвержены когнитивным искажениям: например, любят искать подтверждение своей точке зрения, игнорируя противоположные факты, часто защищают свои решения и гипотезы, Чем больше людей в компании обладают продуктовым мышлением, тем объективнее решения будут создаваться.
- Когда вся команда думает в одном направлении, она вырабатывает лучшие решения, обсуждает их, генерирует новые идеи. Так появляется большая вероятность сделать хороший продукт не для одного человека (собственника или продакта), а для большого платящего сегмента.
- Когда вся команда обладает продуктовым мышлением, с ней легче договориться. Например, не нужно объяснять, почему нельзя долго делать первый продукт с идеальной архитектурой, а лучше выкатить неидеальную рабочую версию. Не нужно объяснять, что интерфейс должен быть удобным, а не красивым. Команда, обладающая продуктовым мышлением, понимает не только продакта, но и пользователя.
- Исчезает конфликт между бизнесом и разработкой. Все члены команды понимают, зачем они выполняют задачу, почему именно таким образом и в такие сроки. У команд снижается уровень стресса, споры решаются быстрее.
По этим причинам бизнесу выгоднее нанимать людей с продуктовым мышлением, а специалисты, обладающие им, более востребованы на рынке, быстрее продвигаются по карьерной лестнице. Поэтому развивать продуктовых подход важно не только продакт-менеджерам, но и всем, кто создает и развивает продукт: дизайнерам, тестировщикам, разработчикам, маркетологам, владельцам бизнеса.
Мы пишем о менеджменте продуктов и развитии в телеграм-каналах make sense и Продуктовое мышление.
Команды не понимают задачи других команд
Часто бывает так, что в компании традиционно используется горизонтальная структура управления: есть отдел продаж, маркетинга, разработки. Специалисты разных департаментов плохо понимают специфику работы друг друга, хотя и работают над одной фичей. Чтобы команды работали сообща, их можно объединить общей целью и мышлением. Так, например, Антон Савченков из «Додо Пицца» на митапе Product Mindset рассказал, как в компании перестроили структуру: заменили горизонтальные отделы на автономные вертикальные юниты, в каждом из которых содержаться все компетенции, и внедрили продуктовый подход даже в операционку.
Теперь в каждой full-stack команде работают маркетологи, операционные специалисты, продуктовые аналитики — все, кто участвует в процессе создания определенной фичи. Заменить традиционные отделы на автономные кросс-команды нелегко, но это позволило углубить экспертизу специалистов, каждый из которых теперь понимает полный цикл создания ценности на каждом этапе.
Сложный процесс трансформации можно начать с эксперимента: не перестраивая все процессы в компании, собрать тестовую команду, в которую войдут все, кто участвуют в доставке фичи от момента разработки идеи до того, как она дойдет до пользователя. Если собрать отдельную тестовую команду сложно, можно регулярно звать представителей смежных отделов на общие митинги (например, на груминг или планинг).
Проблемы с синхронизацией и межкомандной коммуникацией
Еще одна проблема в компании, где нет продуктового подхода — отсутствие общей культуры коммуникации. Как правило, специалисты привыкли обсуждать задачи с менеджерами проектов, а не друг с другом. Проблемы с синхронизацией и коммуникацией в разных командах компании часто приводят к тому, что скорость доставки ценности до пользователей оставляет желать лучшего.
На конференции ProductSense в Москве Кира Матвеева из Lamoda поделилась опытом, как наладить межкомандную коммуникацию. Для этого в Lamoda создали дополнительные команды по трансформации, которые помогли департаментам находить общий язык. Команда по трансформации в компании состоит из руководителей разработки, руководителей QA и руководителей продукта. Они помогают командам на каждом этапе, отвечают на вопросы, организовывают общие встречи, где отделы совместно обсуждают процессы и продукт. С их помощью команды понимают, как эффективнее взаимодействовать друг с другом, говорить на одном языке и совместно работать над общей продуктовой целью.
Еще один способ подружить отделы – выстроить единое понимание проблем и потребностей клиентов — это станет связью для всех отделов и их ежедневных задач.
Например, можно описать их с помощью структуры use case, которая будет стоят в центре всех процессов. Это емкий и информативный шаблон, позволяющий командам целостно понимать продукт, его ценность, его аудиторию и так далее. Действия и задачи команд будут строиться, исходя из общего понимания что и для кого мы делаем.
Прописав структуру usecase, можно не только сформировать общее видение нового функционала продукта, решить проблемы с синхронизацией, но и найти новые инсайты.
Искажение информации и долгое согласование
Бывает, что после проведения исследования и изучения потребностей пользователей требуется время, чтобы инсайты и результаты дошли до разработчиков. Иногда в процессе передачи информация искажается. Как правило, классический цикл передачи информации в командах выглядит так:
Такой формат напоминает «сломанный телефон» и влияет на финальную разработку фичи, которая в итоге не отвечает потребностям пользователей. Поэтому стоит подумать о том, как разработчики могут напрямую получать информацию от пользователей.
На конференции ProductSense в Минске Research Lead Дмитрий Соловьев из Qiwi советовал развивать продуктовый подход в команде через возможность прямого общения клиентов и разработчиков. По его мнению, для непрерывного выпуска полезных фич нужно, чтобы команда разработки понимала пользователей. Для этого в Qiwi создали самостоятельные фичи-тимы и начали общаться с пользователями регулярно.
В идеале исследования должны становиться навыком каждого: уметь проводить их должны не только маркетологи и продакты, но и разработчики и дизайнеры.
Чтобы лучше понимать клиентов, можно регулярно проводить Product Backlog Refinement с пользователями и командой разработки. Product Backlog Refinement (grooming) — это активность, которая проводится на протяжении спринта для чистки бэклога и его подготовки к следующему спринт-планированию.
Product Backlog Refinement можно проводить в формате воркшопа и приглашать пользователей — они помогут выделить те фичи, которые по-настоящему им необходимы.
Это нужно не только для того, чтобы задачи, представленные в бэклоге, были актуальными и были готовы к планированию в спринте, реализации и релизу. Но и для того, чтобы вы могли экономить время на проведении исследований, а разработчики — получать актуальную информацию, пожелания и недовольства напрямую от пользователей, развивая продуктовое мышление.
Команды фокусируются на задачах, а не на продукте
Эффективное решение для построения правильного фокуса команд — проведение командных встреч с общими целями в конце спринта. На встречах стоит говорить о том, какой процент задач в новых условиях команды выполнили, какие фичи сделали, какую ценность получили пользователи — так сотрудники будут понимать важность внедрения продуктового подхода и безболезненно воспринимать трансформацию.
Кроме отслеживания результатов в конце спринта, команды будут ставить новые продуктовые цели и всей командой отслеживать, насколько их добились за спринт. Фокус команд со временем сместится с работы над задачами и проектами на создание ценности продукта для пользователей и для бизнеса.
Стоит отметить, что помощь и поддержка нужна до и после внедрения изменений. Недостаточно выстроить прозрачную коммуникацию и проводить командные встречи: на первых этапах стоит мониторить и корректировать процессы. С этим могут помочь тим-лиды.
Как внедрять продуктовый подход в управлении
Изменить мышление и подход к работе людей, которые длительное время работали по привычной схеме — сложная задача. Когда продакт призывает команду развивать продуктовое мышление, предлагает изменения в процессах и инструменты, это может быть воспринято с непониманием, возражениями и даже с протестом.
Как правило, это может стать основной причиной, которая помешает процессу внедрения продуктового подхода в компании.
Чтобы создать в командах комфортную обстановку, стоит на первых этапах трансформации донести, что вы хотите изменить, что это принесет бизнесу и пользователям. А самое главное — членам команд.
Здесь поможет единая система коммуникации, с помощью которой можно прозрачно объяснить всем департаментам, что такое продуктовый подход, что вы вкладываете в это понятие, какие цели ставите перед продуктом. Можно использовать анонимные опросы на случай, если у команд останутся вопросы, которые они не смогут задать публично.
На этапе погружения в продуктовых подход командам может быть дискомфортно работать «по новым правилам». Чтобы трансформация проходила безболезненно, можно придумать бонусы для команд или систему мотивации. Это дает командам уверенность в том, что вектор выбран правильно.
Внутренний рост — залог долгосрочной мотивации сотрудников. Важно объяснить, что сотрудник, обладающий продуктовым мышлением, будет быстрее расти в компании. Например, можно добавить элементы продуктового подхода в описание грейдов. Тогда сформируется понимание: чтобы стать тим-лидом, нужно обладать основами продуктового мышления.
Чтобы подробнее узнать, как внедрять изменения безболезненно, рекомендуем прочитать книгу Джона Коттера «Наш айсберг тает, или как добиться результата в условиях изменений». Десятилетиями наблюдая за организациями, пытающимися с помощью изменений повысить свои конкурентные преимущества, Коттер сделал вывод о том, что процесс изменений происходит в несколько последовательных этапов. Автор разработал алгоритм из восьми шагов управления изменениями в компании.
