Кто пишет 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 в течение следующей недели будут выходить классные материалы про найм и трудоустройство продактов: например, завтра будет лекция про типы интервью для продактов и как их проходить.

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

Начинаем!

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

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

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

Прямо сейчас: Паша Шишкин, ex Head of Product в Авито, рассказывает про найм продактов на сеньорные позиции и отвечает на вопросы на @hireproproduct

На днях очень классно пообщались с Юрой Агеевым в рамках подкаста make sense: я рассказала про руководство командой, необходимые навыки для people managers и карьерный рост продактов. Буду рада услышать ваш фидбэк и мысли на тему - делитесь в комментариях!

Послушать можно тут:

https://sense23.com/podcast/make-sense-119-o-people-management-navykah-neobhodimyh-rukovoditelyam-i-karernom-roste-menedzherov-produktov

Прямо сейчас: Глеб Кудрявцев, руководитель продуктов в Skyeng, рассказывает про найм продактов на джуниор и миддл позиции и отвечает на вопросы на @hireproproduct

Друзья, всем привет!

Давайте с вами пообщаемся на тему валидации гипотез. Обсудим:

1) валидация проблемы != валидация решения
2) как формулировать гипотезы
3) какие есть методы валидации гипотез

Докидывайте вопросы по теме сюда, как обычно:

https://forms.gle/t8e8idaXEWoaxJip6

Начнем с самых основ - "валидация проблемы != валидация решения".

Одна из ошибок, которую я часто вижу у джуниоров, - это объединение этапов валидации проблемы и валидации решения, тогда как это два критически разных шага.

Что происходит на этапе валидации проблемы:

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

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

Что происходит на этапе валидации решения:

1) мы пытаемся понять, решает ли предложенный продукт/фича нашу проблему;

2) мы пытаемся оценить, насколько эффективно он решает проблему.

Почему эти два этапа важно разводить:

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

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

Какие опасности такого подхода:
- на выходе получаем feature factory - команду, которая фигачит, казалось бы, без продыха, но для бизнеса мало что меняется;
- делаем то, что проще и быстрее, не делаем то, что может быть более долгосрочной инвестицией;
- особенно в b2b (но и в b2c тоже) - пользователи раздражаются на большое количество мелких апдейтов, которые не складываются в понятную историю.

А как тогда надо?

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

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

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

@proproduct

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

Поэтому я придумала новый формат - ежемесячный закрытый Q&A стрим, где буду отвечать на ваши вопросы во всех подробностях. Можно присылать описание своей проблемы/ задачи/ вопроса, и я буду разбирать их в прямом эфире.

Чтобы записаться, надо стать Патроном - по ссылке вот тут https://www.patreon.com/buldakova
Там есть еще одна интересная опция, на которую можно подписаться, - рассылка про переезд и работу за границей.

Присоединяйтесь! Первый Q&A стрим состоится уже 4 декабря, а рассылка отправится к вам 5го декабря.

Ну и еще одна классная новость: эксперимент с коучингом прошел превосходно, поэтому я готова переводить его на постоянную основу 🙂 еще раз напомню, что это:

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

Все детали по записи вот тут:
https://nfng.pro/coaching/

Прошла наконец-то MBTI тест для общего развития 😁

Что хочу по этому поводу сказать (и всяких других тестов - например, StandOut)

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

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

3) несмотря на то, что я написала выше, проходить тесты, на мой взгляд, полезно - это такой классный повод для саморефлексии. В MBTI мне понравились аспекты, которые они рассматривают для определения личности, в StandOut был новый взгляд на “что считать своими сильными сторонами”. Мне интересно поразмыслить: а в какой точке я нахожусь сейчас? Где я вижу возможности для роста? Соответствуют ли результаты моему внутреннему самоощущению и почему? Отражено ли это в моем личном и карьерном плане? Многие аспекты можно изменить и проработать - но для этого необходимость изменения сначало надо осознать.

@proproduct

Да, и все сразу спросили ссылку:

1) MBTI - лучше погуглите, их много, есть бесплатные версии. Я брала платную вот тут mbtionline.com, но соотношение цена-качество было так себе.

2) StandOut - если купить книжку StandOut 2.0: Assess Your Strengths, Find Your Edge, Win at Work, то там идет промокод на бесплатное прохождение теста. Плюс, кажется, сейчас у автора теста можно пройти его бесплатно даже без покупки книжки - https://www.marcusbuckingham.com/

Эти два теста мне пока что понравились больше всего - пишите в комментариях, если вы проходили еще какие-то классные тесты!

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

Как часто отвечают на вопрос про плохой (или хороший) продукт?

Самый джуниорский ответ - «мне не понравился продукт Х, потому что у него плохой UX”. У человека нет нужного вокабуляра, чтобы описать, что именно было не так. Какое-то чутьё, возможно, есть, но преобразовать его в слова не получается.

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

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

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

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

И да, маленькое примечание: именно поэтому кейсы типа «как бы я улучшил Uber” (это когда человек берет и разносит какую-то фичу и затем предлагает своё решение) - в большинстве случаев полная фигня. Ни один продукт не существует в вакууме, и вам со стороны никогда не видно тех trade offs и ограничений, с которыми работает команда. Продукт не состоит только из UX, большая часть айсберга, как обычно скрыта под водой. Не демонстрируйте поверхностность, всегда смотрите глубже.

@proproduct