Я обещала больше рассказывать про любимые каналы, которые сама читаю, - хочу сегодня поделиться с вами 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
Друзья, мне каждый день прилетает от вас по 5-7 вопросов - я просто физически не успеваю отвечать каждому, хоть и очень хочу.
Поэтому я придумала новый формат - ежемесячный закрытый Q&A стрим, где буду отвечать на ваши вопросы во всех подробностях. Можно присылать описание своей проблемы/ задачи/ вопроса, и я буду разбирать их в прямом эфире.
Чтобы записаться, надо стать Патроном - по ссылке вот тут https://www.patreon.com/buldakova
Там есть еще одна интересная опция, на которую можно подписаться, - рассылка про переезд и работу за границей.
Присоединяйтесь! Первый Q&A стрим состоится уже 4 декабря, а рассылка отправится к вам 5го декабря.
Поэтому я придумала новый формат - ежемесячный закрытый Q&A стрим, где буду отвечать на ваши вопросы во всех подробностях. Можно присылать описание своей проблемы/ задачи/ вопроса, и я буду разбирать их в прямом эфире.
Чтобы записаться, надо стать Патроном - по ссылке вот тут https://www.patreon.com/buldakova
Там есть еще одна интересная опция, на которую можно подписаться, - рассылка про переезд и работу за границей.
Присоединяйтесь! Первый Q&A стрим состоится уже 4 декабря, а рассылка отправится к вам 5го декабря.
Patreon
Patreon logo
Patreon is empowering a new generation of creators.
Support and engage with artists and creators as they live out their passions!
Support and engage with artists and creators as they live out their passions!
Ну и еще одна классная новость: эксперимент с коучингом прошел превосходно, поэтому я готова переводить его на постоянную основу 🙂 еще раз напомню, что это:
Коучинг-сессии для продакт лидеров (от 5 лет опыта работы; позиция: Lead PM/ Director/ основатель стартапа). Готова помогать вам прокачиваться в области продуктовой стратегии, коммуникации, перестроения процессов и орг структуры, организационного дизайна – это моя экспертиза, наработанная за годы собственного опыта и менторства, в стартапах и крупных компаниях.
Это индивидуальные 1-1 сессии с почасовой оплатой; прежде чем стартовать, мы созваниваемся на 15 минут и обсуждаем, какую задачу вы хотели бы решить и могу ли я с ней помочь.
Все детали по записи вот тут:
https://nfng.pro/coaching/
Коучинг-сессии для продакт лидеров (от 5 лет опыта работы; позиция: Lead PM/ Director/ основатель стартапа). Готова помогать вам прокачиваться в области продуктовой стратегии, коммуникации, перестроения процессов и орг структуры, организационного дизайна – это моя экспертиза, наработанная за годы собственного опыта и менторства, в стартапах и крупных компаниях.
Это индивидуальные 1-1 сессии с почасовой оплатой; прежде чем стартовать, мы созваниваемся на 15 минут и обсуждаем, какую задачу вы хотели бы решить и могу ли я с ней помочь.
Все детали по записи вот тут:
https://nfng.pro/coaching/