Итак, наша тема на неделю – 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. Иерархия примерно такая:
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
Google Docs
Спроси Аню!
Основные составляющие хорошего 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) если в дальнейшем вы решите сделать итерацию или перепридумать продукт, у вас был доступ ко всем нужным материалам.
Погнали дальше - начало тут 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) если в дальнейшем вы решите сделать итерацию или перепридумать продукт, у вас был доступ ко всем нужным материалам.
Telegram
No Flame No Game
Итак, наша тема на неделю – PRD или product requirements document. Внимательно прочитала ваши вопросы и попытаюсь все охватить, но если что - форма для вопросов всегда открыта https://forms.gle/t8e8idaXEWoaxJip6
Для начала разберемся, в какой момент у нас…
Для начала разберемся, в какой момент у нас…
Парочка анонсов:
1. Вот тут я рассказываю про AI в продакт-менеджменте (SoundCloud, Apple) и делюсь карьерными новостями 🙂 получилась очень толковая беседа, спасибо Паше и Ярику!
2. Сегодня мы уже на NFNG встречаемся с Катей Текуновой - Катя сделала блестящую карьеру в продакт-менеджменте и выросла до директора по продуктам в Rambler&Co, но затем решила сменить профессию и переехала в Болгарию. Почему - спросим у нее сегодня в 20-30 по Москве https://t.me/proproduct/1033
В этом же выпуске будут объявлены победители розыгрыша книг https://t.me/proproduct/1027 - еще можете успеть поучаствовать!
1. Вот тут я рассказываю про AI в продакт-менеджменте (SoundCloud, Apple) и делюсь карьерными новостями 🙂 получилась очень толковая беседа, спасибо Паше и Ярику!
2. Сегодня мы уже на NFNG встречаемся с Катей Текуновой - Катя сделала блестящую карьеру в продакт-менеджменте и выросла до директора по продуктам в Rambler&Co, но затем решила сменить профессию и переехала в Болгарию. Почему - спросим у нее сегодня в 20-30 по Москве https://t.me/proproduct/1033
В этом же выпуске будут объявлены победители розыгрыша книг https://t.me/proproduct/1027 - еще можете успеть поучаствовать!
YouTube
АМА: AI в продуктовой разработке с Анной Булдаковой
Слушать на SoundCloud: https://soundcloud.com/productandgrowthshow/51-ai-v-produktovoy-razrabotke-s-annoy-buldakovoy
На Apple Podcasts: https://podcasts.apple.com/ua/podcast/product-growth-show/id1477971944#episodeGuid=tag%3Asoundcloud%2C2010%3Atracks%2F906715603…
На Apple Podcasts: https://podcasts.apple.com/ua/podcast/product-growth-show/id1477971944#episodeGuid=tag%3Asoundcloud%2C2010%3Atracks%2F906715603…
Я обещала больше рассказывать про любимые каналы, которые сама читаю, - хочу сегодня поделиться с вами requires more research. Много прекрасного про UX-исследования, ментальные модели, HCI, дизайн и accessibility; мне очень нравятся факты "на подумать" и отдельные отрывки из разнообразных исследований.
А вот здесь Лена рассказывает, как можно получить бесплатную получасовую консультацию у рисечеров, дизайнеров, менеджеров и ux-писателей из всех известных тех-компаний (Google, Facebook, WhatsApp, Airbnb и так далее).
P.S. напоминание, что реклама на канале больше не размещается; единственный способ попасть в эту рубрику - быть в моем списке регулярно читаемых каналов на протяжении нескольких лет 🙂
А вот здесь Лена рассказывает, как можно получить бесплатную получасовую консультацию у рисечеров, дизайнеров, менеджеров и ux-писателей из всех известных тех-компаний (Google, Facebook, WhatsApp, Airbnb и так далее).
P.S. напоминание, что реклама на канале больше не размещается; единственный способ попасть в эту рубрику - быть в моем списке регулярно читаемых каналов на протяжении нескольких лет 🙂
Telegram
olena requires more research
Олена Булигіна. Пишу про речі, які не повністю розумію. Під час війни займаюся волонтерською діяльністю в zeilen van vrijheid. Будую сервіс-дизайн агенцію в Лондоні. Complexity, emergence and extensive design practice.
user research + founder = this
user research + founder = this
Начинаем! https://youtu.be/A7fRnrK6GEM
YouTube
Переезд в Болгарию, смена профессии и менеджмент // Катя Текунова
Катя - Director of Marketing Operations and Online Sales в Acronis.
С начала 2020 года Катя живет в Болгарии и ведет телеграм-канал «Живи там хорошо!». До Acronis работала в Rambler&Co, где сначала руководила сервисом Платформа, который включает в себя ряд…
С начала 2020 года Катя живет в Болгарии и ведет телеграм-канал «Живи там хорошо!». До Acronis работала в Rambler&Co, где сначала руководила сервисом Платформа, который включает в себя ряд…
Всем привет!
Последний месяц я делала пилот для нового проекта - индивидуальных консультаций - и сейчас готова открыть их для всех желающих.
Два варианта:
1. Коучинг-сессии для продакт лидеров (от 5 лет опыта работы; позиция: Lead PM/ Director). Готова помогать вам прокачиваться в области продуктовой стратегии, коммуникации, перестроения процессов и орг структуры, организационного дизайна – это моя экспертиза, наработанная за годы собственного опыта и менторства, в стартапах и крупных компаниях.
Это индивидуальные 1-1 сессии с почасовой оплатой; прежде чем стартовать, мы созваниваемся на 15 минут и обсуждаем, какую задачу вы хотели бы решить и могу ли я с ней помочь.
2. Групповые карьерные сессии для начинающих продактов (первая группа: нет опыта или до 1 года; вторая группа: 1-3 года опыта). Что будем делать: встречаться 1 раз в 2 недели на 1 час, в группе из 7 человек со схожим опытом; обсуждать топик, который выберет группа (развитие карьеры, подготовка к интервью, работа с продуктом, прокачка soft skills и так далее). На данный момент, будет всего 2 группы; я просмотрю все заявки, на основе ответов сформирую группы и напишу всем участникам.
🖤🖤🖤
UPD Ребята, заявок уже пришло в 15 раз больше, чем я могу сейчас потянуть, поэтому пока что запись закрываю. На группы, вероятно, будет новый набор через 2 месяца, поэтому следите за анонсами на канале.
Последний месяц я делала пилот для нового проекта - индивидуальных консультаций - и сейчас готова открыть их для всех желающих.
Два варианта:
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
Начало тут 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
Егор руководит командой продактов языка программирования Kotlin, ведет IT-подкаст Podlodka и развивает стартап в нише онлайн-конференций. Последний год он работает в JetBrains, а до этого – руководил развитием платформенных сервисов и инструментов для разработчиков в Авито.
На встрече мы обсудим, как из разработки перейти в продакт-менеджмент, зачем идти на MBA и чему можно научиться благодаря публичным выступлениям.
Присоединяйтесь к трансляции 29 октября в 21-30 по Москве! https://www.youtube.com/watch?v=erK7JqRzCfc&feature=youtu.be
YouTube
Смена работы, MBA в Сколково и продукты для разработчиков // Егор Толстой
Егор руководит командой продактов языка программирования Kotlin, ведет IT-подкаст Podlodka и развивает стартап в нише онлайн-конференций. Последний год он работает в JetBrains, а до этого – руководил развитием платформенных сервисов и инструментов для разработчиков…
Друзья, я начала формировать группы для Групповых карьерных сессий и поняла, что забыла включить сбор email :facepalm - если вы не оставили резюме, мне никак с вами не связаться. Если вы оставляли заявку, пожалуйста, дозаполните ее (по сути, надо создать новую, просто не заполняйте опциональные поля): https://forms.gle/FAZAiJwPUxbXDsMi8
Приношу извинения за неудобства! Весь контекст - тут https://t.me/proproduct/1042
Приношу извинения за неудобства! Весь контекст - тут https://t.me/proproduct/1042
Telegram
No Flame No Game
Всем привет!
Последний месяц я делала пилот для нового проекта - индивидуальных консультаций - и сейчас готова открыть их для всех желающих.
Два варианта:
1. Коучинг-сессии для продакт лидеров (от 5 лет опыта работы; позиция: Lead PM/ Director). Готова…
Последний месяц я делала пилот для нового проекта - индивидуальных консультаций - и сейчас готова открыть их для всех желающих.
Два варианта:
1. Коучинг-сессии для продакт лидеров (от 5 лет опыта работы; позиция: Lead PM/ Director). Готова…
Друзья, запись интервью с Егором Толстым уже на канале, и это пушка 🙂 обсудили MBA, переход из разработки в продукт, а также на примере Kotlin поговорили про валидацию гипотез, когда нельзя проводить эксперименты, - Егор поделился классными кейсами из своей работы.
Смотрите и делитесь фидбэком - как обычно, одному из комментаторов достанется в подарок книга по рекомендации от Егора: “Джедайские техники конструктивного общения”.
https://youtu.be/erK7JqRzCfc?t=42
Смотрите и делитесь фидбэком - как обычно, одному из комментаторов достанется в подарок книга по рекомендации от Егора: “Джедайские техники конструктивного общения”.
https://youtu.be/erK7JqRzCfc?t=42
YouTube
Смена работы, MBA в Сколково и продукты для разработчиков // Егор Толстой
Егор руководит командой продактов языка программирования Kotlin, ведет IT-подкаст Podlodka и развивает стартап в нише онлайн-конференций. Последний год он работает в JetBrains, а до этого – руководил развитием платформенных сервисов и инструментов для разработчиков…
Друзья, много вопросов про групповые сессии https://t.me/proproduct/1042, отвечу здесь сразу всем:
1) Группы сформированы, если вы не получили письмо, то, к сожалению, не попали в первый набор.
2) Повторный набор будет зависеть от того, как пройдет первый 🙂 если набор будет, обязательно напишу об этом на канале.
1) Группы сформированы, если вы не получили письмо, то, к сожалению, не попали в первый набор.
2) Повторный набор будет зависеть от того, как пройдет первый 🙂 если набор будет, обязательно напишу об этом на канале.
Telegram
No Flame No Game
Всем привет!
Последний месяц я делала пилот для нового проекта - индивидуальных консультаций - и сейчас готова открыть их для всех желающих.
Два варианта:
1. Коучинг-сессии для продакт лидеров (от 5 лет опыта работы; позиция: Lead PM/ Director). Готова…
Последний месяц я делала пилот для нового проекта - индивидуальных консультаций - и сейчас готова открыть их для всех желающих.
Два варианта:
1. Коучинг-сессии для продакт лидеров (от 5 лет опыта работы; позиция: Lead PM/ Director). Готова…
Всем привет! А у меня для вас новый анонс интервью на NFNG 🙂 нашей гостьей станет Евгения Куйда, со-основатель приложений Replika.ai и Luka. До этого Женя работала шеф-редактором журнала Афиша, главредом Afisha.ru, занималась банком для Мегафона, отучилась в London Business School, прошла в Y Combinator и запустила несколько с треском провалившихся стартапов.
Мы поговорим про то, зачем учить AI эмпатии, стоит ли идти в Y Combinator и как избежать выгорания на проектах с высокой степенью риска и неопределенности.
Присоединяйтесь в этот четверг по ссылке https://youtu.be/Hd8PFzR8NCw
Мы поговорим про то, зачем учить AI эмпатии, стоит ли идти в Y Combinator и как избежать выгорания на проектах с высокой степенью риска и неопределенности.
Присоединяйтесь в этот четверг по ссылке https://youtu.be/Hd8PFzR8NCw
YouTube
Y Combinator, conversational AI и жизнь в Долине // Евгения Куйда
В новом выпуске наша гостья – Евгения Куйда, со-основатель приложений Replika.ai и Luka. До этого Женя работала шеф-редактором журнала Афиша, главредом Afisha.ru, занималась банком для Мегафона, отучилась в London Business School, прошла в Y Combinator и…
Когда нужно (и не нужно) писать 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
Начало тут 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
Telegram
No Flame No Game
Итак, наша тема на неделю – PRD или product requirements document. Внимательно прочитала ваши вопросы и попытаюсь все охватить, но если что - форма для вопросов всегда открыта https://forms.gle/t8e8idaXEWoaxJip6
Для начала разберемся, в какой момент у нас…
Для начала разберемся, в какой момент у нас…
Друзья, два анонса для вас:
1. Сегодня у нас будет очень классное интервью с Женей Куйдой - про AI, Y Combinator и Долину; обязательно присоединяйтесь и приходите с вопросами https://t.me/proproduct/1050
2. На @hireproproduct в течение следующей недели будут выходить классные материалы про найм и трудоустройство продактов: например, завтра будет лекция про типы интервью для продактов и как их проходить.
Материалы готовим вместе с Глебом Кудрявцевым и Пашей Шишкиным (Карьерный Цех), так что будет огонь 🔥
1. Сегодня у нас будет очень классное интервью с Женей Куйдой - про AI, Y Combinator и Долину; обязательно присоединяйтесь и приходите с вопросами https://t.me/proproduct/1050
2. На @hireproproduct в течение следующей недели будут выходить классные материалы про найм и трудоустройство продактов: например, завтра будет лекция про типы интервью для продактов и как их проходить.
Материалы готовим вместе с Глебом Кудрявцевым и Пашей Шишкиным (Карьерный Цех), так что будет огонь 🔥
Telegram
No Flame No Game
Всем привет! А у меня для вас новый анонс интервью на NFNG 🙂 нашей гостьей станет Евгения Куйда, со-основатель приложений Replika.ai и Luka. До этого Женя работала шеф-редактором журнала Афиша, главредом Afisha.ru, занималась банком для Мегафона, отучилась…
Forwarded from No Flame No Game
Всем привет! А у меня для вас новый анонс интервью на NFNG 🙂 нашей гостьей станет Евгения Куйда, со-основатель приложений Replika.ai и Luka. До этого Женя работала шеф-редактором журнала Афиша, главредом Afisha.ru, занималась банком для Мегафона, отучилась в London Business School, прошла в Y Combinator и запустила несколько с треском провалившихся стартапов.
Мы поговорим про то, зачем учить AI эмпатии, стоит ли идти в Y Combinator и как избежать выгорания на проектах с высокой степенью риска и неопределенности.
Присоединяйтесь в этот четверг по ссылке https://youtu.be/Hd8PFzR8NCw
Мы поговорим про то, зачем учить AI эмпатии, стоит ли идти в Y Combinator и как избежать выгорания на проектах с высокой степенью риска и неопределенности.
Присоединяйтесь в этот четверг по ссылке https://youtu.be/Hd8PFzR8NCw
YouTube
Y Combinator, conversational AI и жизнь в Долине // Евгения Куйда
В новом выпуске наша гостья – Евгения Куйда, со-основатель приложений Replika.ai и Luka. До этого Женя работала шеф-редактором журнала Афиша, главредом Afisha.ru, занималась банком для Мегафона, отучилась в London Business School, прошла в Y Combinator и…
Прямо сейчас: Паша Шишкин, 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
Послушать можно тут:
https://sense23.com/podcast/make-sense-119-o-people-management-navykah-neobhodimyh-rukovoditelyam-i-karernom-roste-menedzherov-produktov
Блог ProductSense
make sense #119: О people management, навыках, необходимых руководителям, и карьерном росте менеджеров продуктов
«Лидер и менеджер — разные вещи, но ты не можешь быть хорошим менеджером, не будучи лидером». «Чтобы вырасти, тебе нужно думать, как твой руководитель может вырасти». iTunes | SoundCloud | You…
Прямо сейчас: Глеб Кудрявцев, руководитель продуктов в Skyeng, рассказывает про найм продактов на джуниор и миддл позиции и отвечает на вопросы на @hireproproduct