Друзья, хотела вам рассказать, что на следующей неделе буду разговаривать с Пашей Педенко и Ярославом Степаненко про 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) Повторный набор будет зависеть от того, как пройдет первый 🙂 если набор будет, обязательно напишу об этом на канале.

Всем привет! А у меня для вас новый анонс интервью на NFNG 🙂 нашей гостьей станет Евгения Куйда, со-основатель приложений Replika.ai и Luka. До этого Женя работала шеф-редактором журнала Афиша, главредом Afisha.ru, занималась банком для Мегафона, отучилась в London Business School, прошла в Y Combinator и запустила несколько с треском провалившихся стартапов.

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

Присоединяйтесь в этот четверг по ссылке https://youtu.be/Hd8PFzR8NCw

Когда нужно (и не нужно) писать PRD

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

PRD обычно требует серьезных инвестиций времени команды: в зависимости от технической сложности и предыдущей проработки проблемы (например, наличия исследований) может занять от 1 недели и больше. Инвестиции окупаются, когда сам проект должен занять от 3 раз больше: то есть, если на PRD вы тратите неделю, разработка самого проекта должна быть оценена в не меньше, чем три недели. Цифра 3 здесь никак научно не обоснована и, скорее, выведена эмпирическим путем 🙂

Но это не значит, что для маленьких проектов не нужна документация. У меня примерно такое правило:

⁃ до недели работы команды (от момента идеи до запуска): 1 абзац про проблему, которую решаем, и почему + пара часов дискуссии в команде;
⁃ 1-3 недели работы команды: 1 страница PRD с описанием проблемы, критериев успеха + дизайны и описание всех взаимодействий прямо в Figma + 3-5 встреч команды;
⁃ 3+ недели: многостраничный документ с ссылками на исследования, детальной дизайн- и технической проработкой + ежедневные встречи команды на протяжении этого процесса.

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

Еще несколько вопросов, которые прислали читатели по теме и еще не были освещены:

"Как сохранять актуальность PRD?"

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

"Что делать, если команда слабенькая и никто не хочет брать на себя дополнительную ответственность (кроме продакта)?" (это вопрос по предыдущей главе, где я рассказывала про делегирование PRD)

Тут важно понять: а почему не хотят? Чувствуют, что это "обязаловка" и переработка? Не понимают, как это им поможет в карьере? Естественно, если человеку, который хочет забить гвоздь в стену, вы будете предлагать купить пилу, никакого успеха не ждите. Для начала надо установить доверие и разобраться, в каком направлении ваши сокомандники хотят развиваться, - а уже потом помогать им находить эти возможности. Иногда могут быть какие-то внешние блокеры: например, некорректно сформулированные цели или ожидания от позиции на уровне руководства - в этом случае, надо общаться уже с ними. Крайний случай - если человек сам по себе не хочет расти и прекрасно чувствует себя на текущей позиции; но тут уже ничего не поделаешь 🙂

Ну что ж, кажется, мы разобрали все ваши вопросы - если вам понравился формат, пишите сюда предложения о новых темах для постов-неделек: https://forms.gle/t8e8idaXEWoaxJip6

@proproduct

Друзья, два анонса для вас:

1. Сегодня у нас будет очень классное интервью с Женей Куйдой - про AI, Y Combinator и Долину; обязательно присоединяйтесь и приходите с вопросами https://t.me/proproduct/1050

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

Материалы готовим вместе с Глебом Кудрявцевым и Пашей Шишкиным (Карьерный Цех), так что будет огонь 🔥