Друзья, видео с Катей уже на канале: обсудили, как готовиться к интервью, развивать soft skills и почему в Долине нет проджектов 😱

Обязательно загляните в описание, там миллион полезных ресурсов. И, как обычно, одному из комментаторов подарю книжку, о которой так увлеченно рассказывала Катя, - "Гении и аутсайдеры" ❤️

https://www.youtube.com/watch?v=wiQXD542hTw

Всем привет!

Я к вам с двумя анонсами:

1. Напоминаю, что сегодня у нас бесплатный мастер-класс по публичным выступлениям - обязательно присоединяйтесь, чтобы задать вопросы https://t.me/proproduct/1021

2. На @hireproproduct - моем канале с продуктовыми вакансиями - сегодня можно поучаствовать в 3-минутном опросе и получить классные подарки 🙂

Друзья, запись мастер-класса по публичным выступлениям уже на канале https://www.youtube.com/watch?v=xEm55ew_yH0 - получилось очень живо и с множеством практических рекомендаций 🙂

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

1. От меня - поделитесь комментарием, какой из советов в трансляции вам запомнился больше всего; одному из комментаторов я подарю одну из лучших, на мой взгляд, книг по публичным выступлениям - “TED TALKS. Слова меняют мир. Первое официальное руководство по публичным выступлениям”.

2. От Артема - поделитесь в комментариях ссылкой на самое классное выступление (Артем в конце видео подробнее рассказывает условия). К лучшему комментатору отправится набор “Карточек спикера” с инструментами для подготовки к выступлениям (я сама такой теперь хочу 😍).

Подведем итоги 1го октября!

Друзья, мы с ребятами из TYPICAL (следить за ребятами можно в Телеграм) сделали очень классный проект про корпоративную культуру. Я, как вы знаете, работала и в стартапах, и в крупных компаниях – и это, безусловно, кардинально разный опыт. Куда идти, если ты только начинаешь карьеру? Где можно быстрее вырасти на руководящую должность? О каких аспектах стоит помнить, выбирая между несколькими предложениями о работе? Мы попытались рассмотреть эти вопросы через призму культуры в компании – прямых ответов в исследовании нет, зато есть множество крутых инсайтов, которые вам помогут в принятии решений.

В исследовании приняли участие продакты из таких компаний, как: Resume, BestDoctor, Flo, Aviasales, Skyeng, Wrike, Открытие, Мегафон, Сбербанк.

Прочитать исследование можно тут: https://vc.ru/hr/162214-issledovanie-korporativnoy-kultury-kompaniy-aviasales-skyeng-sberbank-i-drugie

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

Обязательно присоединяйтесь - будем так же брать вопросы из зала!

7 октября в 21-00 по Москве:
https://www.youtube.com/watch?v=g2wJdjSALOQ

Кстати! Ещё одна новость: я наконец-то придумала, зачем мне Инстаграм и что туда писать 😂 буду рефлексировать над своими целями и планами, вот первый заход: https://www.instagram.com/p/CFxBhtGjRBp/?igshid=3pbzpzm60m8j

Давайте на следующей неделе поднимем тему PRD - product requirements document. Как писать, чем отличается от ТЗ и one pager, кто за него должен отвечать, какие ошибки совершают чаще всего.

Если у вас есть вопросы по теме, присылайте тут - https://forms.gle/t8e8idaXEWoaxJip6

У нас в компании есть фишка - PM Circles: такие "кружки по интересам", где продакты знакомятся и обмениваются опытом. Я записалась в ML PM Circle и сегодня познакомилась с другими участниками - и у меня в очередной раз взрывается голова 😁 окей, давайте просто перечислю: один создал и руководил AI департаментом в NASA и участвовал в создании телескопа Хаббл; второй делал первую версию Kindle в Amazon; третья была Head of Recommender Systems в LinkedIn; четвертый продал стартап и сейчас делает Shops в Instagram - и так далее. Когда меня в следующий раз спросят, а зачем переезжать/ зачем идти работать в FAANG, буду скидывать им эту заметку 🙂

Друзья, в этот четверг у нас снова потрясающая гостья – мы встречаемся с Катей Текуновой, Director of Marketing Operations and Online Sales в Acronis.

С начала 2020 года Катя живет в Болгарии и ведет телеграм-канал «Живи там хорошо!». До Acronis работала в Rambler&Co, где сначала руководила сервисом Платформа, который включает в себя ряд инфраструктурных продуктов для всей группы компаний, а затем стала директором по продуктам. До этого возглавляла группу развития продуктов для разработчиков в Яндексе.

Поговорим про переход из продакт-менеджмента в маркетинг, переезд в Болгарию и особенности работы с инфраструктурными продуктами.

8 октября, 20-30 по Москве - как обычно, нажимайте на “колокольчик”, чтобы не пропустить начало: https://youtu.be/A7fRnrK6GEM

Итак, наша тема на неделю – PRD или product requirements document. Внимательно прочитала ваши вопросы и попытаюсь все охватить, но если что - форма для вопросов всегда открыта https://forms.gle/t8e8idaXEWoaxJip6

Для начала разберемся, в какой момент у нас должен появляться PRD. Иерархия примерно такая:
1. Сначала идет видение и миссия
2. Затем стратегия
3. Затем цели и роадмап
4. И только после этого PRD.

Не забываем, что это итеративный процесс: то есть, после написания PRD можно возвращаться на шаг назад и обновлять роадмап, если понадобится.

Что же такое PRD? Сразу дисклеймер - одного правильного ответа тут нет. Я спросила 5 продактов из разных компаний и получила 5 кардинально разных ответов. Мой ответ может не совпадать с политикой партии и основан на личном опыте с конкретными компаниями и командами. Рекомендую не следовать советам вслепую, а пробовать и экспериментировать. Вот вам сразу подборка шаблонов и примеров: https://nfng.pro/templates/

Еще одно уточнение: помимо PRD, есть понятия BRD/MRD (погуглите ;)) и one pager – я кощунственно объединяю все это в одну сущность. Главное, чтобы решало задачу, а там пусть хоть фикусом называется 🙂
ТЗ (техническое задание) - согласно официальному определению, это спецификация, которая содержит набор требований и по сути является частью контракта между заказчиком и исполнителем. Это артефакт проектной разработки, поэтому в контексте этих заметок мы ТЗ трогать не будем.

Хороший PRD решает несколько задач:

1. Помочь команде договориться, что, как и зачем мы делаем.
САМЫЙ критичный пункт. Здесь важен даже не столько документ, а процесс, который запускает создание этого документа:

⁃ мы не бросаемся делать, а сначала тратим время на “подумать”. Это позволяет ЗАРАНЕЕ обсудить риски и ограничения, скорректировать сроки, продумать критерии успеха.
⁃ мы достигаем единого понимания контекста. Даже если вы обсуждали эту идею раньше, я с 99% гарантией могу сказать, что у всех людей в команде будет разное понимание ее воплощения, изначального скоупа, метрик и так далее. Такое недопонимание может очень дорого стоить, если не починить его в самом начале, - особенно в том случае, когда команда работает удаленно.
⁃ иногда работа над PRD может привести к решению не делать проект – и это очень круто! Вместо того, чтобы осознать это через 2 месяца разработки, мы потратили неделю и уже сейчас поняли, что не взлетит.

2. Коммуницировать внешним стейкхолдерам, что, как и зачем мы делаем.

⁃ Стейкхолдерами могут быть другие команды, ваше руководство, кроссфункциональные партнеры, например, саппорт или legal.
⁃ Очень частая практика - писать для внешней аудитории one pager: по сути, краткое и более доступное содержание внутреннего документа. Мне такое разделение не нравится по двум причинам: 1) у самой команды тоже должен быть доступ к краткой версии - это облегчает запоминание. Мы начинаем каждую встречу по проекту с беглого взгляда на вот эту короткую часть; под конец проекта она должна быть просто выжжена у всей команды на подкорке; 2) у внешних команд часто возникает потребность посмотреть на детали проекта. Плюс, меньше документов, меньше нагрузки на мозг, где что искать и какой документ для чего 🙂

3. Документировать ключевые параметры продукта/фичи для будущего использования.

⁃ Не так важно, когда вы стартап и полагаетесь на tribal knowledge; проблемы начинают возникать, когда уходят люди или компания кратно растет. Безусловно, можно посмотреть на код и техническую документацию (если она есть ;)); но это не поможет понять, почему и как были приняты определенные продуктовые решения и избежать прошлых ошибок.


В следующей заметке поговорим про основные составляющие PRD.

@proproduct

Основные составляющие хорошего PRD

Погнали дальше - начало тут https://t.me/proproduct/1034

Можно очень легко проверить, хороший ли PRD: дайте его вашему CEO, разработчику из другой команды и уборщице тете Глаше, а затем спросите:
1. Что делает команда
2. Зачем она это делает
3. Как она это делает.

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

Первое, с чего начинается PRD, это указание стадии проекта. Я выделяю Exploration (движение от 0 к 1, с миллионом неизвестных и 50:50 шансом на успех) и Execution (четкое понимание рисков, подводных камней и успеха).
Почему это важно: у вашего читателя сразу создаются правильные ожидания. От проектов в исследовательской стадии не стоит ждать точного соблюдения сроков или конкретики в метриках.

Следующая часть – проблема, которую мы хотим решить. Кто наша целевая аудитория? В чем их "боль" или задача? Откуда мы знаем, что это реальная проблема и ее стоит решать? Почему она важна для бизнеса?
Почему это важно: в PRD это один параграф, но в реальности требуется большой объем работы, чтобы его написать, - иногда "просто" прошерстить предыдущие исследования, чтобы найти необходимые данные; иногда организовать дополнительное исследование или анализ, чтобы валидировать некоторые аспекты проблемы.
Этот параграф нужно зачитывать на каждой встрече, у команды он должен отскакивать от зубов. Удивительно, но в процессе работы над решением определение проблемы начинает трансформироваться в неожиданные формы - если его не зацементировать изначально в головах коллег.

Третья часть - определение успеха и цели.
В какой момент мы поймем, что решили проблему? Что изменится с точки зрения пользователя? Какие метрики лучше всего выразят это изменение?
Почему это важно: опять же, позволяем команде договориться об общем понимании успеха и подумать, что и как мы будем измерять. Не должно быть такого, что фича уже почти готова, и тут команда спохватывается: а что нам нужно мерить. Это приводит к: 1) конфликтам в команде из-за разного видения; 2) неточности (а иногда и невозможности) измерения ценности; 3) микроменеджменту в процессе.

Четвертая часть - наше предлагаемое решение. Я люблю делать так:
⁃ сначала one sentence pitch - описание решения одним предложением;
⁃ затем 3-4 ключевых аспекта пользовательского опыта;
⁃ открытые вопросы и риски;
⁃ дальше ссылка на дизайн-файл, где подробно прописаны пользовательские stories/flows и все аспекты взаимодействия на разных платформах;
⁃ ссылка на техническое исследование.

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

Пятая часть: ключевые этапы и даты.
Условно это может выглядеть так: M0 - какая-то подготовительная работа; M1 - MVP; M2 - закрытая бета; и так далее. На каждом этапе должны быть прописаны критерии перехода на следующий этап: что мы меряем, на что смотрим, за каким фидбэком следим.

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

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

В следующей заметке поговорим, а кто все-таки пишет PRD.

Парочка анонсов:

1. Вот тут я рассказываю про AI в продакт-менеджменте (SoundCloud, Apple) и делюсь карьерными новостями 🙂 получилась очень толковая беседа, спасибо Паше и Ярику!

2. Сегодня мы уже на NFNG встречаемся с Катей Текуновой - Катя сделала блестящую карьеру в продакт-менеджменте и выросла до директора по продуктам в Rambler&Co, но затем решила сменить профессию и переехала в Болгарию. Почему - спросим у нее сегодня в 20-30 по Москве https://t.me/proproduct/1033

В этом же выпуске будут объявлены победители розыгрыша книг https://t.me/proproduct/1027 - еще можете успеть поучаствовать!

Я обещала больше рассказывать про любимые каналы, которые сама читаю, - хочу сегодня поделиться с вами requires more research. Много прекрасного про UX-исследования, ментальные модели, HCI, дизайн и accessibility; мне очень нравятся факты "на подумать" и отдельные отрывки из разнообразных исследований.

А вот здесь Лена рассказывает, как можно получить бесплатную получасовую консультацию у рисечеров, дизайнеров, менеджеров и ux-писателей из всех известных тех-компаний (Google, Facebook, WhatsApp, Airbnb и так далее).

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

Начинаем! https://youtu.be/A7fRnrK6GEM

Всем привет!

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

Два варианта:

1. Коучинг-сессии для продакт лидеров (от 5 лет опыта работы; позиция: Lead PM/ Director). Готова помогать вам прокачиваться в области продуктовой стратегии, коммуникации, перестроения процессов и орг структуры, организационного дизайна – это моя экспертиза, наработанная за годы собственного опыта и менторства, в стартапах и крупных компаниях.
Это индивидуальные 1-1 сессии с почасовой оплатой; прежде чем стартовать, мы созваниваемся на 15 минут и обсуждаем, какую задачу вы хотели бы решить и могу ли я с ней помочь.

2. Групповые карьерные сессии для начинающих продактов (первая группа: нет опыта или до 1 года; вторая группа: 1-3 года опыта). Что будем делать: встречаться 1 раз в 2 недели на 1 час, в группе из 7 человек со схожим опытом; обсуждать топик, который выберет группа (развитие карьеры, подготовка к интервью, работа с продуктом, прокачка soft skills и так далее). На данный момент, будет всего 2 группы; я просмотрю все заявки, на основе ответов сформирую группы и напишу всем участникам.

🖤🖤🖤

UPD Ребята, заявок уже пришло в 15 раз больше, чем я могу сейчас потянуть, поэтому пока что запись закрываю. На группы, вероятно, будет новый набор через 2 месяца, поэтому следите за анонсами на канале.

Кто пишет PRD

Начало тут https://t.me/proproduct/1034 и тут https://t.me/proproduct/1037

Вспомним структуру PRD из прошлой заметки:

⁃ стадия проекта;
⁃ проблема, которую решаем;
⁃ определение успеха и цели;
⁃ one sentence pitch - описание решения одним предложением - и 3-4 ключевых аспекта пользовательского опыта;
⁃ открытые вопросы и риски;
⁃ ссылка на дизайн-файл, где подробно прописаны пользовательские stories/flows и все аспекты взаимодействия на разных платформах;
⁃ ссылка на техническое исследование.

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

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

2. В команде покруче продакт описывает следующее:

⁃ стадия проекта;
⁃ проблема, которую решаем;
⁃ определение успеха и цели (с помощью дата аналитика).

Дальше команда обсуждает возможные решения и выбирает лучшее по соотношению impact/effort. Продакт документирует:
⁃ one sentence pitch - описание решения одним предложением - и 3-4 ключевых аспекта пользовательского опыта, -

и заводит дискуссию на тему возможных рисков и открытых вопросов.

Последние два пункта ложатся на дизайнера, который детально продумывает UX (все аспекты пользовательского взаимодействия) и обсуждает техническое воплощение с тех лидом, и, соответственно, тех лида, который изучает риски и ограничения с технической стороны и создает проектный план.

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

Нужно помнить, что написание документа - не самоцель. Наша задача - объединить команду, создать общее понимание, что, зачем и как мы делаем. Успех PRD: каждый из членов команды понимает задачу, мотивирован ее решить и привнес свою экспертизу в решение, чтобы сделать его 10х лучше. Абсолютнейший провал PRD - это выбрать одного “спекописца”, который написал 10 страниц (и которые никто больше никогда не прочитал) и не задействовал ни одного другого члена команды в процессе.

В последней заметке расскажу, когда нужно, а когда не нужно писать PRD.

Если остались еще вопросы, пишите сюда: https://forms.gle/t8e8idaXEWoaxJip6

@proproduct

Друзья, в этот четверг у нас очень крутой гость - Егор Толстой, Lead Product Manager в JetBrains.

Егор руководит командой продактов языка программирования Kotlin, ведет IT-подкаст Podlodka и развивает стартап в нише онлайн-конференций. Последний год он работает в JetBrains, а до этого – руководил развитием платформенных сервисов и инструментов для разработчиков в Авито.

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

Присоединяйтесь к трансляции 29 октября в 21-30 по Москве! https://www.youtube.com/watch?v=erK7JqRzCfc&feature=youtu.be

Друзья, я начала формировать группы для Групповых карьерных сессий и поняла, что забыла включить сбор email :facepalm - если вы не оставили резюме, мне никак с вами не связаться. Если вы оставляли заявку, пожалуйста, дозаполните ее (по сути, надо создать новую, просто не заполняйте опциональные поля): https://forms.gle/FAZAiJwPUxbXDsMi8

Приношу извинения за неудобства! Весь контекст - тут https://t.me/proproduct/1042

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

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

https://youtu.be/erK7JqRzCfc?t=42

Друзья, много вопросов про групповые сессии https://t.me/proproduct/1042, отвечу здесь сразу всем:

1) Группы сформированы, если вы не получили письмо, то, к сожалению, не попали в первый набор.

2) Повторный набор будет зависеть от того, как пройдет первый 🙂 если набор будет, обязательно напишу об этом на канале.