Парочка анонсов:
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
Друзья, всем привет!
Давайте с вами пообщаемся на тему валидации гипотез. Обсудим:
1) валидация проблемы != валидация решения
2) как формулировать гипотезы
3) какие есть методы валидации гипотез
Докидывайте вопросы по теме сюда, как обычно:
https://forms.gle/t8e8idaXEWoaxJip6
Давайте с вами пообщаемся на тему валидации гипотез. Обсудим:
1) валидация проблемы != валидация решения
2) как формулировать гипотезы
3) какие есть методы валидации гипотез
Докидывайте вопросы по теме сюда, как обычно:
https://forms.gle/t8e8idaXEWoaxJip6
Google Docs
Спроси Аню!
Начнем с самых основ - "валидация проблемы != валидация решения".
Одна из ошибок, которую я часто вижу у джуниоров, - это объединение этапов валидации проблемы и валидации решения, тогда как это два критически разных шага.
Что происходит на этапе валидации проблемы:
1) мы пытаемся понять, важна ли проблема, которую мы пытаемся решить: сила пользовательской "боли", потенциальный охват, стратегическая важность и ценность для бизнеса;
2) мы пытаемся оценить, а можем ли мы эту проблему решить в нашем контексте (с нашими ресурсами, на нашем рынке) и решить уникально (сделать одной из сильных сторон по сравнению с конкурентами).
Что происходит на этапе валидации решения:
1) мы пытаемся понять, решает ли предложенный продукт/фича нашу проблему;
2) мы пытаемся оценить, насколько эффективно он решает проблему.
Почему эти два этапа важно разводить:
Предположим, вы работаете над конкурентом Гугл карт и пытаетесь оценить, что делать в первую очередь: инструмент для добавления новых точек для бизнесов или инструмент для добавления новых точек для пользователей.
Если мы пропускаем шаг с проблемой, как будет выглядеть оценка:
- обе фичи важны;
- но добавление точек для пользователей сделать проще + это больший сегмент нашей аудитории, поэтому начинаем с него.
Какие опасности такого подхода:
- на выходе получаем feature factory - команду, которая фигачит, казалось бы, без продыха, но для бизнеса мало что меняется;
- делаем то, что проще и быстрее, не делаем то, что может быть более долгосрочной инвестицией;
- особенно в b2b (но и в b2c тоже) - пользователи раздражаются на большое количество мелких апдейтов, которые не складываются в понятную историю.
А как тогда надо?
Делаем шаг назад и начинаем с оценки проблемы. Допустим, инструмент для бизнеса решает проблему точности данных на картах; а инструмент для пользователей решает проблему генерации данных (расширения нашего инвентаря). Какая проблема сейчас важнее и почему? Если мы решим эту проблему, изменится ли состояние бизнеса, выиграем ли мы позиции в конкурентной борьбе?
Если данных у вас и так хватает, и основная проблема с точностью, без разницы, что второе решение можно сделать быстрее. Я адепт подхода, что надо выбрать самую важную проблему и фокусироваться на ее решении, а не палить из всех пушек и пытаться решить все и сразу.
Еще один важный бонус: приоритизация становится проще, так как вы перестаете сравнивать верблюдов с лошадьми. Когда вы четко определили, что проблема - в точности данных, а успех решения проблемы мы определим по метрике Х, и генерация идей, и их оценка займет в разы меньше.
@proproduct
Одна из ошибок, которую я часто вижу у джуниоров, - это объединение этапов валидации проблемы и валидации решения, тогда как это два критически разных шага.
Что происходит на этапе валидации проблемы:
1) мы пытаемся понять, важна ли проблема, которую мы пытаемся решить: сила пользовательской "боли", потенциальный охват, стратегическая важность и ценность для бизнеса;
2) мы пытаемся оценить, а можем ли мы эту проблему решить в нашем контексте (с нашими ресурсами, на нашем рынке) и решить уникально (сделать одной из сильных сторон по сравнению с конкурентами).
Что происходит на этапе валидации решения:
1) мы пытаемся понять, решает ли предложенный продукт/фича нашу проблему;
2) мы пытаемся оценить, насколько эффективно он решает проблему.
Почему эти два этапа важно разводить:
Предположим, вы работаете над конкурентом Гугл карт и пытаетесь оценить, что делать в первую очередь: инструмент для добавления новых точек для бизнесов или инструмент для добавления новых точек для пользователей.
Если мы пропускаем шаг с проблемой, как будет выглядеть оценка:
- обе фичи важны;
- но добавление точек для пользователей сделать проще + это больший сегмент нашей аудитории, поэтому начинаем с него.
Какие опасности такого подхода:
- на выходе получаем feature factory - команду, которая фигачит, казалось бы, без продыха, но для бизнеса мало что меняется;
- делаем то, что проще и быстрее, не делаем то, что может быть более долгосрочной инвестицией;
- особенно в b2b (но и в b2c тоже) - пользователи раздражаются на большое количество мелких апдейтов, которые не складываются в понятную историю.
А как тогда надо?
Делаем шаг назад и начинаем с оценки проблемы. Допустим, инструмент для бизнеса решает проблему точности данных на картах; а инструмент для пользователей решает проблему генерации данных (расширения нашего инвентаря). Какая проблема сейчас важнее и почему? Если мы решим эту проблему, изменится ли состояние бизнеса, выиграем ли мы позиции в конкурентной борьбе?
Если данных у вас и так хватает, и основная проблема с точностью, без разницы, что второе решение можно сделать быстрее. Я адепт подхода, что надо выбрать самую важную проблему и фокусироваться на ее решении, а не палить из всех пушек и пытаться решить все и сразу.
Еще один важный бонус: приоритизация становится проще, так как вы перестаете сравнивать верблюдов с лошадьми. Когда вы четко определили, что проблема - в точности данных, а успех решения проблемы мы определим по метрике Х, и генерация идей, и их оценка займет в разы меньше.
@proproduct