ProductDo: практика продакта

Привет, коммьюнити. Сегодня вечером (18:00 Амстердам/ 19:00 Москва) к нам в гости на эфир придет Ксения. Она не просто маркетолог, она продуктовый маркетолог: Product Marketing Manager. Я планирую обсудить с Ксенией: - что должен продакт менеджер знать о маркетинге - как выглядит эффективновное сотрудничество PM и PMM - что маркетологов раздражает в продактах - как Ксения относится к концепции Product Led Growth Если у вас есть вопросы, которые вы бы хотели задать компетентному маркетологу – пишите в комментариях, я задам их на эфире. Встречаемся на нашем YouTube канале! (https://www.youtube.com/@ProductDo/streams)

У компании Meta (Facebook) есть такой продукт, который называется Workplace ранее он был Facebook @ Work. По сути это такой маленький внутренний Facebook внутри компании. Так все как в социальной сеточке: есть профили пользователей, сообщества по интересам и, конено же, залипательная лента. Так вот, сегодня Meta объявила о том, что они закрывают этот продукт. По меркам любой другой компании он более чем успешный, но на игровом поле, где Metavervse и AI революция конкурируют за ресурсы – это непонятная B2B обуза с очень ограниченным потенциалом роста. Меня новость коснулась напрямую: booking использовал workplace в качестве основного иструмента внутренней коммуникации. Прочитав эту новость я со вздохом добавил в список задач "скачать все посты о запусках команды за последние три года". Придется сохранить их где-то еще. Внутренние социальные сеточки в больших компаниях я нежно люблю еще со времен самописной "этушки" Яндекса. Мне кажется, это очень важный элемнт культуры компании. Там рождаются мемы, там формируются горизонтальные команды под клевые проекты. В конце концов там можно легально думскроллить, продолжая считать что ты работаешь. 🙂 По слухам, в качестве преемника (единственный официальный маршрут для миграции) facebook называет Workvivo от Zoom. Я ее пока не видел, видимо, придется знакомится. Слава богу не Microsoft Teams.

Лучше вы узнаете от меня, чем из каких-нибудь мутных каналов в телеграме: OpenAI выпустил новую большую версию ChatGPT 4o. Смотрите демо: https://openai.com/index/spring-update/ До новой волны применения LLM в куче юзкейсов, где это ни коим образом не решает проблему пользователя осталось 3.. 2.. 1..

Какой продакт менеджер не согласится с тем, что очень важно поддерживать глубокое понимание контекста у команды? Разработчик, который: - хорошо понимает не только архитектуру своих систем, - но и то, какую проблему решает продукт для пользователей, - какие гипотезы мы сейчас тестируем, - и на какие метрики смотрим... будет гораздо эффективнее разработчика, который - ничем кроме кода не интересуется. Разработчикам с высоким контекстом требуется гораздо меньше информации, чтобы понять новую задачу. Они с гораздо меньшей вероятнотью поймут ее неправильно. Если таск будет противоречить тому контексту, который у них уже есть, девелоперы будут задавать уточняющие вопросы пока противоречие не будет разрешено. Я (конечно же)) считаю, что я поддерживаю у команды высокий контекст (ср. 90% водителей считают, что они водят лучше среднего). Я стараюсь на каждом планировании делать секцию "intelligence report", где рассказываю про тенды рынка, новости компании, и что делают соседние команды, чтобы мои разработчики тоже были в курсе. Точнее, я так считал, пока мне не пришло в голову сделать небольшой неформальный "тест". Я попросил разработчика рассказать мне о том, как он видит общую цель и текущий статус одного из проектов над которым мы работаем. Пока он отвечал ко мне пришло горькое осознание, что я далеко не так хорошо справляюсь с задачей поддержания общего контекста команды, как мне казалось... Поделитесь со мной, какие форматы вы используете чтобы команда владела полным контекстом работы? И как можно неформально "тестировать" наличие контекста, чтобы понимать, насколько эти усилия эффективны, или это совершенно безумная идея?

(2) Пример #2, плохой интерфейс. Это элемент некого B2B SaaS приложения, в котором я обязан время от времени писать тексты, потому что оно является частью рабочих процессов. Когда я пытаюсь вставить в текст ссылку мне предлагается… выбрать протокол в отдельном дропдауне, а потом вставить оставшуюся часть ссылки (без протокола!) в текстовый инпут. Почему? Because fuck you, that’s why. Потому что ты нам не платишь, нам платит директор совершенно другого департамента, он купил нас потому что мы закрываем какие-то его боли. А твое удобство никак не влияет на нашу выручку, так что заткнись, выбирай протокол и обрезай ссылку. С точки зрения рационального целеполагания это даже до какой-то степени оправданно, но я думаю что массовая ненависть пользователей безусловно аукается этому продукту в долгосрочной перспективе. А вы на какой стороне? Делать хорошие интерфейсы даже если на метрики это не влияет, или быть прагматичным продактом, забить на все второстепенное, и грести бабло лопатой?

Небольшая рефлексия о том что такое хороший и плохой пользовательский опыт и о том, что мотивирует наших коллег делать качественные интерфейсы. Обратите внимание, что в обоих случаях речь не идет про то, как продукт решает проблему пользователя, а исключительно о техническом исполнении сценария. (1) Пример #1. Интерфейс для регистрации ребенка в программу дополнительных занятий по определенному предмету (дополнительные занятия языком). В программу направляет школа, поэтому я зарегистрировался бы в ней даже если бы пришлось заполнять бумажную форму, никакую метрику эта воронка не растит. И тем не менее, кто-то продумал: 1. Механизм сохранения сессии. Первым делом форма спрашивает email и тут же отправляет на него ссылку по которой можно будет вернуться к заполнению в будущем или с другого устройства. 2. Этот же механизм сессий позволяет принимающей организации внести какие-то исправления в форму и вернуть родителям “на подпись” новую версию. 3. Мелочь, но какая приятная: в формах про детей никогда не понятно про кого заполнять конкретное поле, про ребенка или про родителя. Чтобы путаницы не было, как только ты вписываешь имя ребенка, оно автоматически подставляется в лейблы всех последующих полей, где речь про него. Хотя у продакта явно не было прямой коммерческой мотивации, он очень круто сделал свою работу, продумав кучу мелочей. Честно говоря, я не уверен, что я исполнил бы этот интерфейс также качественно (в том числе потому, что не считал бы это важным).

Empowered: Ordinary People, Extraordinary Products Недавно мы обсуждали выступление Марти Кагана на продуктовой конференции, а я сейчас как раз дочитываю его книгу "Empowered: Ordinary People, Extraordinary Products". Книга представляет собой готовый набор best practices из больших продуктовых компаний по организации процессов и выстраиванию работы с продуктовыми командами. Возможно, для матерых продактов из биг теха там не будет много откровений, но для всех остальных она будет полезна. По моим наблюдениям, именно в больших устоявшихся компаниях действительно хорошо выстроены и формализованы процессы, которые в компаниях поменьше попросту отсутствуют. И если вы планируете расти карьерно и проходить собеседования уже как people manager или директор, то эту книгу можно использовать как готовый набор приемов, применимых к действию. Ниже некоторые моменты, которые мне понравились. Важность проведения регулярных "One-to-one" со своими сотрудниками Регулярный диалог со своей командой и ведение квартальных и годовых ревью является ключевой вещью для формирования сильной команды. В фидбеке очень важный момент – это "nothing should be a surprise". Его нужно давать вовремя! Для продакта не должно быть сюрпризом в конце года, что он делал что-то не так. Если тебе не удалось донести до человека вовремя его косяки и успехи, то это прежде всего твоя ошибка как руководителя, а не его. Работа продакта не для всех Она предполагает, что человек сможет самостоятельно принимать решение и вести разработку. А не делать каждый день только то, что ему говорят. При этом продактом все же не рождаются, а становятся. Если человек хочет стать продактом, то в этом ему надо активно помогать. В Google есть отдельная программа "APM: Associate Product Manager". По ней находят потенциально крутых продактов среди разных специальностей и учат их 2 года, чтобы они стали крутыми продуктовыми лидерами. Часто бывает, что продакту в руководители попадается не профильный человек (например, уровня VP). Если такое случается, то такой менеджер должен найти себе коуча и сам расти как продакт, чтобы разговаривать со своими коллегами на одном языке. Учиться никогда не поздно, даже если ты уже забрался высоко! Я думаю, что тоже самое вполне релевантно и для фаундеров стартапов. Ну и последнее... Для продуктового лидера его команда и есть его продукт Директор так же не обязан быть самым скилованным в команде, но при этом должен стараться нанимать максимально скилованных людей. А затем помогать им раскрываться. Вроде простые вещи, но на мой взгляд про них достаточно мало пишут. И часто грамотному проведению 1-1, прозрачным квартальным ревью и понятной карьерной лестнице уделяется крайне мало внимания. Возможно это удел исключительно больших компаний, но в компаниях поменьше по моему опыту этого часто не хватает. При этом при собеседованиях в компании побольше от вас будут ожидания понимания всех этих процессов. А как у вас обстоят дела с этими процессами на работе? Обязательно делитесь в комментах!

Привет, если вы не копаате картошку на даче, то это Владимир со статьей про SLI (SLO/SLA - потом). В пост не влезло, поэтому вот ссылка на vc: https://vc.ru/hr/1136732-prodakt-menedzher-i-sli-slo-sla Приятного чтения! Отметьте 👍, если интересно еще понять про SLO/SLA (не SLI!) и такие более тонкие темы продакт менеджмента, и поставьте 😎, если и так все знаете/не интересно.