Русский
Русский
English
Статистика
Реклама

Продуктовый менеджмент

Software Engineer Product Manager Product Engineer?

06.01.2021 16:04:08 | Автор: admin

TL;DR

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

Intro

Привет! Меня зовут Ил. И я работаю в стартапе. Нас около 20 человек половина команды (русскоязычная) занимается технологиями, вторая половина (англоязычная) занимается бизнесом. Официальный язык общения английский. Мы (как продукт, бизнес и команда) быстро растём, итерируемся, меняемся и развиваемся. Поэтому для нас критически важно чтобы было отличное взаимопонимание между бизнесом и технологиями. Обычно в компаниях эту функцию выполняют продуктовые менеджеры или аналитики. И у нас они тоже есть. Даже двое. Но каждый из них работает над продуктовыми задачами только 50% времени, совмещая эту роль с другими ролями. Поэтому суммируя, можно сказать что у нас в команде один Product Manager. А скорость изменений такая, что в полной мере формализовать, описать и декомпозировать задачи у PM-команды времени физически не хватает. Поэтому большинство задач у нас описываются достаточно высокоуровнево с акцентом на что хотим получить после того как задача будет выполнена. Процесс декомпозиции задачи, поиск возможных путей решения, выбор оптимального способа и более детальная проработка задачи (в том числе с точки зрения требований и продукта) обычно делегируется инженерам.

Погружаемся

Я бльшую часть времени занимаюсь бэкендом, но как часто бывает в стартапах по факту занимаюсь очень разными задачами. Несколько примеров задач из реальной жизни (которые инженеры обычно не решают):

  • Сделать research по barcodes (штрих-коды на товарах). Понять какие для них есть международные стандарты, как они различаются в раличных странах, какой у них формат, как их валидировать и прочее;

  • Создать план тестирования и/или миграции для большой фичи меняющей поведение в критически важном месте системы;

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

  • Поискать готовые 3rd party решения для той или иной задачи и оценить что в данный момент эффектнее взять один из них или написать самим.

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

  • звонки, обсуждения, обмен знаниями о продукте;

  • интервью кандидатов, участие в hiring-процессах;

  • изучение PRD (по русски ТЗ), поиск в нём "багов" заложенных ещё на уровне описания идеи и логики, выявление слабых мест, поиск мест которые можно сделать лучше, проще или оптимальнее, оценка времени необходимого на разработку;

  • эксперименты, проверка гипотез (продуктовых), POCи (proof-of-concepts);

  • написание спецификаций, инструкций и других документов для фрилансеров (часть задач мы аутсорсим) и коллег;

  • координация с другими командами и членами команд;

  • выявление слабых мест в процессах, и улучшение процессов;

  • поиск готовых решений для не mission critical задач (чтобы не изобретать велосипед) и анализ как прагматичнее поступить в конкретном случае запилить своё решение или взять готовое;

  • smoke-тестирование;

  • работа с продуктовыми метриками в Amplitude;

  • генерация кастомных отчётов.

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

  • понять чего хочет бизнес;

  • понять чего хочет бизнес на самом деле (обычно 20-50% требований меняется в процессе обсуждения, ещё до начала реализации);

  • уточнить неочевидные детали, краевые случаи;

  • проанализировать и найти оптимальное техническое решение.

При этом крайне желательно донести до всей команды особенности выбранного в итоге решения, в том числе его ограничения и недостатки. Потому что выбранный вариант решения задачи это почти всегда trade off (причём достаточно жёсткий): между скоростью разработки, качеством, масштабируемостью и расширяемостью.

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

Ещё одна важная культурная деталь нашей команды достаточно плоская структура и то, что каждый инженер лично отвечает за свою задачу, от момента её придумывания до user adoption. И написание кода это лишь один из этапов. Лично отвечает не значит что если что-то пойдёт не так, то человека уволят или лишат премии. Нет. Это значит что нужно будет вернуться назад и переделать. И прагматичное, рациональное, продуктовое мышления уменьшает кол-во таких итераций-переделок кардинально.

+/-

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

Разберём плюсы. Почему это круто:

  1. Ты намного лучше понимаешь приоритеты, чётко знаешь что важно, а что второстепенно (в мире стартапов "второстепенно" и "не важно" по сути синонимы). Следовательно, понимаешь каким частям кода следует уделять больше внимание, а в каких в данный момент можно на*****кодить

  2. Ты начнёшь понимать мотивы продуктовых решений, почему решили сделать так, а не иначе. Соответственно ты будешь в курсе дальнейших планов на проект/фичу. Это поможет выстроить более адекватную архитектуру

  3. Тебе будут чаще давать более глубокие, сложные, интересные задачи. Ты получишь больше свободы. И больше ответсвенности

  4. Это интересно. Понимать продуктовые метрики и особенности поведения пользователей это увлекательно. И это затягивает

  5. Когда начнёшь думать не только о коде, но и о продукте, у тебя постепенно начнёт меняться мышление. Ты заметишь, что тебе станет проще коммуницировать с коллегами, которые занимаются продуктовым менеджментом, проектным менеджментом, аналитикой. Тебе будет проще их понимать. А им тебя. Работа станет менее стрессовой и более продуктивной

  6. Качество твоих фич и решений будет увеличиваться. Как следствие, качество всего продукта тоже будет расти. Вместе с продуктом, твоя ценность в команде тоже будет становится всё больше

  7. Тебе откроются новые возможности это может стать первым шагом к своему стартапу, или крутой карьере в FAANG, или повышению на текущем месте, или удачному exit-у (если у тебя есть опционы)

Почему это не круто:

  1. Частые смены контекста вредят здоровью. Они не только значительно повышают уровень стресса, но и могут пагубно влиять на мозг. Многочисленные исследования подтверждают это злоупотребление многозадачностью может привести в снижению общего IQ и негативным изменениям в мозге на физическом уровне, таким как уменьшение плотности нейронов (1, 2). А тебе придётся менять контекст очень часто. Твои дни станут более рваными. Ты будешь заниматься несколькими задачами одновременно и минимум 10/20/30 разными задачами в течении дня. Ты скорее всего станешь более нервным и раздражительным. У тебя могут начаться головные боли, даже если раньше ты был им не подвержен

  2. Тебе придётся делать то, что раньше ты скорее всего никогда не делал, потому что это делали за тебя твои коллеги. Например: работать с системами продуктовой аналитики, системами для рекламы, маркетинга, сервисами для мокапов, прототипирования, дизайна. Тебе придётся разбираться с множеством смежных областей и инструментов в этих областаях. Быть проактивным. Пушить других людей, если они не реагируют вовремя (в том числе твоих менеджеров). Назначать встречи/звонки. И это не вместо кодинга, а вместе с кодингом

  3. Ты начнёшь замечать конфликты в своём мышлении, а возможно и в решениях. За хорошее решение принятое тобой как инженером, твой внутренний PM может на тебя косо посмотреть или даже обидеться (привет, биполярочка!)

  4. Определённости и чётких ответов в твоей жизни станет ещё меньше, чем сейчас

Интегрируем

Вот мы и подходим к тому, с чего начали в заголовке статьи.

Термин Product Engineer пока ещё не очень популярен, но я думаю что в скором времени его популярность будет расти. Возможно для этой роли придумают другие названия, но суть не поменяется.

Драйверов развития этой роли несколько:

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

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

В таких условиях, с учётом того что продуктовый менеджмент будет усложняться, вполне гармонично может появиться новая роль на стыке между инженерами и менеджерами продуктовый инженер. Примеров появления новых профессий на стыке двух других уже было очень много:

  • Сисадмин/программист DevOps;

  • Программист/бизнесмен Product Manager;

  • Рекламщик/веб-мастер SEO-шник.

Достаточно отважен и хабр храбр?

Успей запрыгнуть в поезд! Но помни тормозов у этого поезда, похоже, нет.

Подробнее..

Из песочницы Product Manager amp Product Designer поиск сходств и отличий

16.08.2020 00:12:08 | Автор: admin
Меня зовут Ростислав Салата, я работаю в киберспортивной организации без малого три года. Пришел в компанию на должность проектировщика интерфейсов, дорос до UX-лида, и в настоящее время являюсь продуктовым менеджером.

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

Почему я поднял эту тему? Мы провели очень много собеседований с продуктовыми дизайнерами. Опираясь на свой опыт и опыт коллег, могу смело сказать, что вопрос о круге обязанностей задает каждый претендент. Разное понимание зон ответственности может впоследствии привести к конфликтам, которые пагубно повлияют на продукт.

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

Часть 1. Я и мой продакт-менеджер выполняем похожие задачи. Получается я продакт-менеджер?


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

1. Из твоего лексикона пропадают фразы это не моя работа или это не моя зона ответственности


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

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

Кто говорит, что продуктовый дизайнер несет меньшую ответственность за продукт, чем продуктовый менеджер? Продуктовым дизайнерам никто не запрещает (даже наоборот!) замечать глюки, давать советы, помогать строить или дополнять командные процессы. Хорошего продуктового дизайнера и отличают те модели поведения, которые я описал ниже.

2. Начинаешь самостоятельно искать инсайты и их источники


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

3. Понимаешь, что внедряемая фича влияет не только на пользователя


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

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

Многие дизайнеры знакомы с понятием омниканальности. В работе над продуктом стоит отталкиваться от этого понятия и тщательно продумывать предложенные пользовательские фичи. Почему же дизайнер не должен думать о влиянии внедряемых решений на продукт во всех точках его контакта с пользователями? Если ты продуктовый дизайнер, то это просто must have. Консистентность, детализация и продуманность дизайн-решений на всех уровнях это топ-скилы дизайнера.

4. Смещение фокуса с дизайна в привычном для всех понимании


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

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

5. Появляется ощущение, что предлагаемые фичи не несут пользу продукту


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

Хорошо уметь анализировать фичи с точки зрения пользы для продукта или компании. Как это сделать? Провалидировать и аргументировать идею. Занимаются ли этим только продуктовые менеджеры? Хороший вопрос.

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

6. У тебя меняется отношение к продуктовым метрикам


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

Смотреть на продуктовые показатели под другим углом хороший навык. Но говорит ли наличие этого навыка о том, что ты на пути к продуктовому менеджменту? Скорее нет, чем да. Будучи продуктовым дизайнером, ты можешь (должен?) проверять свои решения на соответствие метрикам, и, вероятнее всего, научишься смотреть на показатели эффективности шире.

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

И правда, получается, что обязанности продуктового дизайнера и продуктового менеджера во многом пересекаются. Чем тогда на самом деле занимается продуктовый менеджер?

Часть 2. Какие задачи решает продуктовый менеджер в реальной жизни?


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

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

1. Фокус, консолидация, коммуникация.


Фокус. Продуктовый менеджер должен быть сфокусирован на получении прибыли от своего продукта. Другими словами, на заработке денег для компании. Стремление сделать проект прибыльным должно быть здравым, а не фанатичным.

Фанатизм рассмотрим на примере вывода нового продукта на рынок. Менеджер должен понимать: если его продукт нестабилен и не покрывает базовых потребностей своего рынка, то ни о какой монетизации не может быть и речи. Почему? Если требовать с пользователей плату лишь за отличительные ценности, не покрывая их базовые потребности, высока вероятность напортачить в самый важный момент.

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

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

Коммуникация. В моем идеальном мире работа продуктового менеджера должна распределяться так:

  • 30%: свои задачи;
  • 40%: коммуникация с командой;
  • 30%: one-to-one встречи с сотрудниками.

Как видим, 70% времени составляет коммуникация, хотя первые 30% задач тоже так или иначе с ней связаны.

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

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

2. Сотрудничество с отделом продаж (Business Development)


Большинство продуктов рано или поздно выходят на стадию монетизации. Так как главная задача продуктового менеджера создание прибыли, общение с отделом продаж поможет лучше понять продукт и рынок в целом. Некоторые компании не всегда дают возможность общаться с отделом Business Development, но мне повезло.

Совместная работа с менеджерами по развитию бизнеса создает условия для более качественной продажи вашего продукта. Sales менеджеры должны понимать продукт, знать сильные и слабые стороны, а также болевые точки пользователей. Тогда они сделают upsell в нужный момент.

3. Организация кросс-командных процессов


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

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

4. Правильная постановка целей и задач для команды


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

Задачи. Как продуктовый менеджер ты должен быть уверен, что тебя понимают так же, как ты понимаешь себя сам. Достаточно часто я сталкивался с тем, что мои ожидания не всегда очевидны для команды. Поэтому перед постановкой задачи стоит удостовериться, все ли понимают, что должно получиться в итоге, и зачем вообще делать эту работу. Такой себе definition of done, отвечающий на вопрос что? со стороны продукта. Команда же ответит на вопрос как?.

5. Аргументация и навязывание


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

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

6. Управление продуктовой командой


Важно не теоретическое понимание процесса разработки, наличие сертификата по Agile от Coursera, а то, готов ли ты организовать команду и взять ответственность за эффективность и результат её работы.

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

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

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

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

6.2. Кадровая эффективность
В некоторых компаниях продуктовый менеджер участвует в регулярных ревью членов команды. По объективным причинам обсуждение технических скилов на уровне ревью находится вне зоны влияния менеджера (если ты, конечно, не Technical Product). А вот оценка персональной эффективности и ее влияния на работу в команде самое то.

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

Для оценки и обсуждения факторов, влияющих на эффективность работы сотрудника, можно использовать следующие подходы:

  • регулярные one-to-one встречи;
  • наблюдение при решении спорных моментов;
  • предрелизная реакция;
  • коммуникация с коллегами из других команд.

Не создавай вибрации. Создавай ценность

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

Лучше познакомиться с рекрутерами и узнать об их tips and tricks. Если перенять опыт не от кого, остается только учиться на своих ошибках. Наём человека это процесс: онбординг, адаптация, испытательный срок. За 23 месяца нужно убедиться, что это именно тот человек, поскольку ответственность на ну, сами знаете, на ком.

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

7. Общение с топ-менеджментом (уровень С, executives, founders, investors)


Для себя я определил, что данный пункт был и порой до сих пор является сложнейшей из задач продуктового менеджера. Сложность заключается в мышлении и принятии решений на совсем другом уровне абстракции. Говоря на языке agile, это общение на уровне тем (themes) или инициатив (initiatives).

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

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

Выводы


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

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

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

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

Готов ли ты как дизайнер или любой другой специалист менять контекст в течение дня по несколько раз? Готов ли ты к тому, что 7080% твоего времени составляет коммуникация? Готов ли ты к тому, что результаты твоей работы не всегда сразу можно увидеть и пощупать?

Тогда, если есть цель, к ней стоит стремиться. Главное учитывать все нюансы.
Подробнее..

Масштабируем продакт-менеджмент как управлять продуктом, который разрабатывают 50 команд

24.02.2021 20:16:16 | Автор: admin
Всем привет!

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

image

Интересующимся и желающим пообщаться на эту тему добро пожаловать под кат.

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

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

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

Знакомая картина?

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

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


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

Не похоже на историю выше, верно?

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

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

  • Пользователей кастдевил продакт? Теперь ваши владельцы продукта о них не вспоминают, они носятся от одного стейкхолдера к другому, пытаясь понять за какие требования хвататься в первую очередь;
  • Была ясная и прозрачная юнит-экономика? Теперь владельцы продукта не считают даже PnL, загружая всю команду на пол спринта сторями с сомнительной пользой;
  • Были job story, customer journey map и прочие персоны? Теперь в сторе пишут Как продакт оунер я хочу чтобы это было сделано, потому что это нужно департаменту Operation and Maintanence;
  • Было понимание ответственности за результат и сроки? Теперь каждая команда сама за себя, ваши фичи доставят на релиз-другой позже.

Сложность управления разработкой для масштабных продуктов растет по экспоненте. Что же делать?

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

Списочком

Являются ли они серебряной пулей?

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

И могу сказать следующее:

  • это дорого;
  • это не быстро;
  • это очень рискованно;
  • конечный успех сильно зависит от культуры компании. Если люди понимают и верят успех вероятен.

Единственно ли верен подобный подход? Давайте посмотрим, что еще можно сделать.

image

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

Продукт. Продукт должен приносить ценность. Рассмотрите зоопарк ваших систем и компонент с точки зрения ценности. Выделите все потоки ценности (value streams) для конечных клиентов, контрагентов или третьих лиц и разделите карту систем по таким потокам. Каждый владелец продукта должен иметь в управлении полную цепочку систем, имеющих ценность. Дайте ему пару аналитиков, если объем ответственности слишком велик.

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

Пользователи. В сторону стейкхолдеров. Только пользователи могут дать верное представление о ценности продукта. Владелец продукта должен ориентироваться на результаты интервью и анализ тикетов поддержки в своих гипотезах.

Гипотезы. Никаких больше имплементаций функционала в слепую. У каждого эпика или фичи должны быть ожидания по влиянию на метрики. Реализуя фичи и проверяя их А/B тестами, владельцы продукта должны понимать успешна была гипотеза или нет.

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

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

Масштабируем продакт-менеджмент, часть 2 продукт

01.03.2021 16:18:41 | Автор: admin

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

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

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

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

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

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

Чем это грозит?

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

Как же тогда определить, что такое продукт?

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

Ценность понятие субъективное. В процессе взаимодействия с решением у покупателя возникнет некоторое собственное ощущение того, насколько простым, приятным, удобным и полезным это взаимодействие. Именно за это покупатель и платит.

Оплата в свою очередь это самый просто маркер для выделения продукта. То, за что пользователь готов платить, и называется продуктом. В данном случае это некоторый набор из систем, людей и процессов, обеспечивающий поток ценности пользователю (operational value stream).

В таком случае владельцу продукта с методологической точки зрения более правильно было бы реализовать разработку сразу нескольких систем, участвующих в потоке ценности. Такие команды разработки называются продуктовыми или функциональными (feature teams или cross-component teams).

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

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

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

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

И еще раз о том, зачем выделять продукт.

В случае, когда продукт выделен правильно, владелец продукта имеет возможность:

  1. Влиять на все компоненты, составляющие поток ценности;

  2. Видеть реальные метрики продукта, а не косвенные, отраженные в компоненте;

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

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

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

Спасибо за внимание, в следующей статье поговорим про метрики.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru