Друзья, привет!
Послезавтра, 21 декабря в 17:00 по Амстердаму / 19:00 по Мск наш последний в этом году стрим. Тема супер актуальная, судя по реакциям на предыдущий пост.
Как построить систему, которая спасет от завала и будет держать в фокусе каждый день
Кто:
Дмитрий Цепелев
Founder at Hyperfocus / Ex. Yandex
• 6 лет в продакт менеджменте и построении продуктов с нуля
• Руководил Яндекс.Кассой (7 продуктовых команд)
• Научил продакт менеджров из Miro, Intuit, Booking, Wise, Яндекс, ЦИАН, МТС фокусироваться каждый день
• Последние два года изучал neuroscience и ставил эксперименты, чтобы понять “что такое фокус” и как его исправить
Александр Поваров
Head of product Payments, Wolt / Founder at ProductDo
• PdD, 8 лет в продакт-менеджменте
• Запускал Яндекс.Кассу и Request Money в Wise
• Автор симуляторов ProductDo
Когда:
21 декабря в 17:00 по Амстердаму / 19:00 по Мск
Где:
Ссылку на трансляцию пришлем в этот канал. Или подписывайтесь на наш YouTube канал, стрим можно будет найти в разделе Трансляции.
Для кого:
Для продактов и не только. Для тех, кто много работает, отвечает за продукты и/или других людей.
О чем поговорим:
1. Что такое перегруз и почему он происходит
2. Какие регулярные ритуалы помогут избежать перегруза и будут держать в фокусе
3. Почему нельзя полагаться на силу воли и что использовать вместо (спойлер – привычки! Читайте предыдущий пост ;))
4. Как дизайнить расписание, среду и ритуалы, чтобы делать их регулярно.
5. (Бонус) Как сохранять энергию и восстанавливаться
Save the date!
Послезавтра, 21 декабря в 17:00 по Амстердаму / 19:00 по Мск наш последний в этом году стрим. Тема супер актуальная, судя по реакциям на предыдущий пост.
Как построить систему, которая спасет от завала и будет держать в фокусе каждый день
Кто:
Дмитрий Цепелев
Founder at Hyperfocus / Ex. Yandex
• 6 лет в продакт менеджменте и построении продуктов с нуля
• Руководил Яндекс.Кассой (7 продуктовых команд)
• Научил продакт менеджров из Miro, Intuit, Booking, Wise, Яндекс, ЦИАН, МТС фокусироваться каждый день
• Последние два года изучал neuroscience и ставил эксперименты, чтобы понять “что такое фокус” и как его исправить
Александр Поваров
Head of product Payments, Wolt / Founder at ProductDo
• PdD, 8 лет в продакт-менеджменте
• Запускал Яндекс.Кассу и Request Money в Wise
• Автор симуляторов ProductDo
Когда:
21 декабря в 17:00 по Амстердаму / 19:00 по Мск
Где:
Ссылку на трансляцию пришлем в этот канал. Или подписывайтесь на наш YouTube канал, стрим можно будет найти в разделе Трансляции.
Для кого:
Для продактов и не только. Для тех, кто много работает, отвечает за продукты и/или других людей.
О чем поговорим:
1. Что такое перегруз и почему он происходит
2. Какие регулярные ритуалы помогут избежать перегруза и будут держать в фокусе
3. Почему нельзя полагаться на силу воли и что использовать вместо (спойлер – привычки! Читайте предыдущий пост ;))
4. Как дизайнить расписание, среду и ритуалы, чтобы делать их регулярно.
5. (Бонус) Как сохранять энергию и восстанавливаться
Save the date!
❤46👍10🔥8🦄3
Forwarded from Victoria Mende
Вы планируете свой рабочий день?
Anonymous Poll
19%
День расписан, большую часть дня занимаюсь тем, что запланировал на это время с утра
52%
Запланированы только созвоны, в остальное время я ловко жонглирую делами в стиле agile
28%
Пытаюсь планировать, но чаще приходится реагировать на ситуацию, чем действовать по плану
1%
У меня своя система, расскажу в комментариях
🔥8❤2👍2
Две интересные вакансии, где продакту/проджекту нужны технические навыки
Привет, это Владимир. Я редко пишу про вакансии, и делаю это скорее, чтобы подчеркнуть какую-то особенность роли (и важно - мы не берём денег за размещение). Сегодня вакансий две: Sr. Tech PM в мессаджинг Авито и Tech PjM в их же инфру.
Первый интересный момент: инфраструктурой в Авито занимаются не продакты (как у нас в booking), а проджекты – они помогают раскатывать большие технические изменения на всю компанию. Плюс такого подхода – централизованная вертикаль управления и внедрения, минус – отсутствие возможности сделать даже из кастрюли продукт, а всякие базы данных, датацентры и прочие железки будут посложнее кастрюли, а значит хранят тонны возможностей для бизнеса. Пример: алгоритм базы данных, ускоренный на 10% с большой вероятностью увеличит доходы всего бизнеса, потому всё (например, приложение поиска) станет работать быстрее.
Если ты – проджект, мечтающий перейти в продукт и уже прокачавший тех.скиллы, то у тебя есть козырь: «зацепиться» за роль в большой компании, и дальше – либо расти в роли, либо совершить «фазовый переход» будет проще.
Вторая вакансия чисто продуктовая: мессенджер между покупателем и продавцом (чат, бот, in-app звонки, маркетинг). Представьте 10+ команд внутри огромного Авито: разные вертикали (недвижимость, машины, мелочи и тд), горизонтали (саппорт, маркетинг, секьюрити, аналитики) – всех надо связать сетью сервисов коммуникаций и ответить на критические вопросы бизнеса: как быстро доставлять, где и как долго хранить, как защищать, как проверять и (мое любимое!) как добавлять интересные фичи сверху (например, спец предложение от продавца «вот тебе супер скидка»).
Поскольку мессаджинг – один из канонических тех. продуктов (почти всем B2C компаниям приходится его решить на определенном этапе скейла), этот кейс (и еще 5: такси, стриминг музыки, доставку, проверки документов, аренду самокатов) мы разбираем в симуляторе «Технологии для продакта/проджекта». В конце января будет «редкий» живой интенсив с групповым разбором еще трех кейсов: соц. сети авто, умного дома и погружения в… мессаджинг. До 31 декабря действует ранняя цена, группа почти полная.
Множество отзывов можно почитать тут (оценка курса за все время 4.92/5.0) и спросить в комментах наших «бывших» учеников - вас, друзья, тут много 🦾🦾
Привет, это Владимир. Я редко пишу про вакансии, и делаю это скорее, чтобы подчеркнуть какую-то особенность роли (и важно - мы не берём денег за размещение). Сегодня вакансий две: Sr. Tech PM в мессаджинг Авито и Tech PjM в их же инфру.
Первый интересный момент: инфраструктурой в Авито занимаются не продакты (как у нас в booking), а проджекты – они помогают раскатывать большие технические изменения на всю компанию. Плюс такого подхода – централизованная вертикаль управления и внедрения, минус – отсутствие возможности сделать даже из кастрюли продукт, а всякие базы данных, датацентры и прочие железки будут посложнее кастрюли, а значит хранят тонны возможностей для бизнеса. Пример: алгоритм базы данных, ускоренный на 10% с большой вероятностью увеличит доходы всего бизнеса, потому всё (например, приложение поиска) станет работать быстрее.
Если ты – проджект, мечтающий перейти в продукт и уже прокачавший тех.скиллы, то у тебя есть козырь: «зацепиться» за роль в большой компании, и дальше – либо расти в роли, либо совершить «фазовый переход» будет проще.
Вторая вакансия чисто продуктовая: мессенджер между покупателем и продавцом (чат, бот, in-app звонки, маркетинг). Представьте 10+ команд внутри огромного Авито: разные вертикали (недвижимость, машины, мелочи и тд), горизонтали (саппорт, маркетинг, секьюрити, аналитики) – всех надо связать сетью сервисов коммуникаций и ответить на критические вопросы бизнеса: как быстро доставлять, где и как долго хранить, как защищать, как проверять и (мое любимое!) как добавлять интересные фичи сверху (например, спец предложение от продавца «вот тебе супер скидка»).
Поскольку мессаджинг – один из канонических тех. продуктов (почти всем B2C компаниям приходится его решить на определенном этапе скейла), этот кейс (и еще 5: такси, стриминг музыки, доставку, проверки документов, аренду самокатов) мы разбираем в симуляторе «Технологии для продакта/проджекта». В конце января будет «редкий» живой интенсив с групповым разбором еще трех кейсов: соц. сети авто, умного дома и погружения в… мессаджинг. До 31 декабря действует ранняя цена, группа почти полная.
Множество отзывов можно почитать тут (оценка курса за все время 4.92/5.0) и спросить в комментах наших «бывших» учеников - вас, друзья, тут много 🦾🦾
👍18❤11🔥3👏3
Привет, друзья! С вам Вика. Сегодня подводим итоги года для ProductDo.
Нетворкинг
Выступили на семи конференциях:
ProductCamp Cyprus
HeyGrowth Yerevan
Epic Growth x2
EPAM conf
EpicHey Lisbon
YooMoney Meetup
Обучение
Запустили 3 новых курса:
Большой курс Machine Learning для продакта от ML-продактов Booking & MAANG
Симулятор SQL для продакта
Симулятор Основы ML для продакта
Существенно обновили:
Технические знания для продакта
Базовая аналитика для продакта
Попробуй себя продактом (бесплатный симулятор!)
SMM (присоединяйтесь тоже ;))
Вырастили YouTube на 802 подписчика (было 181, стало 983)
Вырастили LinkedIn на 553 подписчика (было 37, стало 586)
Вырастили телеграм на ~7К (было ~9К, стало ~ 16К)
Провели 12 бесплатных вебинаров
1. Учимся задавать правильные вопросы к данным
2. Cегментации / персонализации в web
3. Что продакт должен знать про A/B эксперименты
4. Будущее Travel Tech, нейросети, AI и успешные стартапы в индустрии путешествий
5. Зачем большие компании строят свои системы аналитики?
6. Счастье VS Деньги. Что должен растить продакт: прибыль или продуктовые метрики
7. Карьерный путь продакта
8. Разбор кейса на главную метрику маркетплейса
9. Карьерный путь продакта: переезды
10. Стрим с Ильей Красинским. AB тесты и юнит-экономика
11. Почему люди покупают? Иван Замесин и Андрей Менде
12. Как построить систему, которая спасет от завала и будет держать в фокусе каждый день?
А вы как? Уже готовите оливье? Или тоже еще подводите итоги?
Нетворкинг
Выступили на семи конференциях:
ProductCamp Cyprus
HeyGrowth Yerevan
Epic Growth x2
EPAM conf
EpicHey Lisbon
YooMoney Meetup
Обучение
Запустили 3 новых курса:
Большой курс Machine Learning для продакта от ML-продактов Booking & MAANG
Симулятор SQL для продакта
Симулятор Основы ML для продакта
Существенно обновили:
Технические знания для продакта
Базовая аналитика для продакта
Попробуй себя продактом (бесплатный симулятор!)
SMM (присоединяйтесь тоже ;))
Вырастили YouTube на 802 подписчика (было 181, стало 983)
Вырастили LinkedIn на 553 подписчика (было 37, стало 586)
Вырастили телеграм на ~7К (было ~9К, стало ~ 16К)
Провели 12 бесплатных вебинаров
1. Учимся задавать правильные вопросы к данным
2. Cегментации / персонализации в web
3. Что продакт должен знать про A/B эксперименты
4. Будущее Travel Tech, нейросети, AI и успешные стартапы в индустрии путешествий
5. Зачем большие компании строят свои системы аналитики?
6. Счастье VS Деньги. Что должен растить продакт: прибыль или продуктовые метрики
7. Карьерный путь продакта
8. Разбор кейса на главную метрику маркетплейса
9. Карьерный путь продакта: переезды
10. Стрим с Ильей Красинским. AB тесты и юнит-экономика
11. Почему люди покупают? Иван Замесин и Андрей Менде
12. Как построить систему, которая спасет от завала и будет держать в фокусе каждый день?
А вы как? Уже готовите оливье? Или тоже еще подводите итоги?
🔥50❤18👍8👻4👏1😁1🦄1
С наступающим, друзья!
Хо-хо-хо! ProductDo значительно вырос за этот год: нас уже больше 16 тысяч. Пусть у всех подписчиков OKR-ы закрываются от 0.7, сервисы не падают дольше чем на 5 минут, а юнит экономика выходит в плюс. Желаем вам крутой команды, с которой интересно развивать бизнес и двигать мир вперед!
И конечно же подарки — применяйте и прокачивайтесь 🙂
1. Интерактивная инструкция «Как перейти из разных ролей в продакты».
2. Таблица навыков PM: как повысится от Junior до Core, от Core до Senior.
P.S. Любой симулятор можно купить в подарок и/или в рассрочку!
До скорых встреч!
Команда ProductDo
Хо-хо-хо! ProductDo значительно вырос за этот год: нас уже больше 16 тысяч. Пусть у всех подписчиков OKR-ы закрываются от 0.7, сервисы не падают дольше чем на 5 минут, а юнит экономика выходит в плюс. Желаем вам крутой команды, с которой интересно развивать бизнес и двигать мир вперед!
И конечно же подарки — применяйте и прокачивайтесь 🙂
1. Интерактивная инструкция «Как перейти из разных ролей в продакты».
2. Таблица навыков PM: как повысится от Junior до Core, от Core до Senior.
P.S. Любой симулятор можно купить в подарок и/или в рассрочку!
До скорых встреч!
Команда ProductDo
❤16🔥9👍5👏2👻1
Всем привет! С наступившим!
С вами Константин.
Один из самых крутых платных сервисов по экспериментированию Optimizely опубликовал отчет за 2023 год, собранный на основании 127 тысяч (!) экспериментов, проведенных на их платформе. Я собрал самые интересные тезисы на этот счет.
==
Экспериментирование сильно изменилось за последние 5 лет
- 88% тестов проваливаются.
- Только треть экспериментов проверяют более одного варианта.
- Топ 3% компаний проводят более 500 экспериментов в год.
- На 41 % больше ожидаемого эффекта благодаря персонализированным экспериментам.
Эксперименты с самым высоким аплифтом по всему миру имеют две общие черты:
1. Они вносят более крупные изменения в код, оказывая большее влияние на пользовательский опыт (значимость >99,9%).
2. Они одновременно тестируют большее количество вариантов (значимость >99,9%).
Забудьте о “низко висящих фруктах”
Получение доступа к инженерным ресурсам для внесения более масштабных изменений имеет решающее значение. Изменять цвет кнопки конечно легко и просто, но серьезного прироста по метрикам такими экспериментами как правило не получить. А проведение сложных экспериментов над серьезными изменениями в продукте требует инженерных ресурсов. Поэтому делается вывод, что нужно отходить от косметических изменений и отдавать больше предпочтений вещам вроде редизайна и переосмысления customer journeys в своем приложении/вебсайте.
Не стоит зацикливаться исключительно на деньгах
Цифровая коммерция в подавляющем большинстве отдает приоритет доходам. Мы согласны, что это самый ценный показатель бизнеса. Тем не менее, масштабные оптимизации ранней воронки продаж, такие как поиск и добавление в корзину, недостаточно изучены.
Компании, как правило, получают больший эффект от тестирования, фокусируя эксперименты на улучшении микроконверсий, например, привлекая больше пользователей к поиску, добавлению в корзину и регистрации учетных записей.
Скорость поиска — самая недооцененная цель эксперимента. Несмотря на то, что он используется в 1% случаев, он имеет самый высокий ожидаемый эффект — 2,3%. Важно отметить, что те, кто ищет, обычно конвертируют в 2-3 раза больше, чем все остальные пользователи.
Платформа данных клиентов (CDP) работает
Компании с интегрированной CDP, по-видимому, гораздо успешнее экспериментируют и видят на 80% больший ожидаемый эффект. Интересно, как это все при этом совмещается с требованиями по GDPR и CCPA 🙂.
Больше тестов ≠ больше эффекта
Чтобы масштабировать процесс экспериментирования в своей компании, вам необходимо тщательно инвестировать в ресурсы разработчиков. Проведение дополнительных тестов – это не выход. Вот почему:
- Наивысшее качество эксперимента достигается при проведении 1-10 тестов в год на одного инженера.
- Как только разработчик переходит на 11-30 тестов в год, ожидаемое влияние на каждый тест падает на 40%.
- Если вы выйдете за пределы 30 тестов, ожидаемый эффект упадет на целых 87%.
==
Если я правильно понял их выводы и прилагаемую статистику, то основной смысл в том, что количество НЕ равно качество. Очевидно, что увеличение нагрузки на команды с требованием повысить количество проводимых экспериментов на ровном месте в какой-то момент приводит к резкому возрастанию количества багов и общему падению положительных эффектов от экспериментов. Я сам это уже неоднократно наблюдал, и чтобы избегать этой ошибки нужно инвестировать больше ресурсов в различные внутренние системы автоматизаций и масштабирования процессов экспериментирования.
Интересный отчет получился. Согласны?
Мы напоминаем, что у нас на платформе есть шикарный курс, который научит вас А/Б тестированию 🥷. Курс можно купить в подарок.
Ссылка на оригинальный отчет:
https://www.optimizely.com/the-evolution-of-experimentation/
С вами Константин.
Один из самых крутых платных сервисов по экспериментированию Optimizely опубликовал отчет за 2023 год, собранный на основании 127 тысяч (!) экспериментов, проведенных на их платформе. Я собрал самые интересные тезисы на этот счет.
==
Экспериментирование сильно изменилось за последние 5 лет
- 88% тестов проваливаются.
- Только треть экспериментов проверяют более одного варианта.
- Топ 3% компаний проводят более 500 экспериментов в год.
- На 41 % больше ожидаемого эффекта благодаря персонализированным экспериментам.
Эксперименты с самым высоким аплифтом по всему миру имеют две общие черты:
1. Они вносят более крупные изменения в код, оказывая большее влияние на пользовательский опыт (значимость >99,9%).
2. Они одновременно тестируют большее количество вариантов (значимость >99,9%).
Забудьте о “низко висящих фруктах”
Получение доступа к инженерным ресурсам для внесения более масштабных изменений имеет решающее значение. Изменять цвет кнопки конечно легко и просто, но серьезного прироста по метрикам такими экспериментами как правило не получить. А проведение сложных экспериментов над серьезными изменениями в продукте требует инженерных ресурсов. Поэтому делается вывод, что нужно отходить от косметических изменений и отдавать больше предпочтений вещам вроде редизайна и переосмысления customer journeys в своем приложении/вебсайте.
Не стоит зацикливаться исключительно на деньгах
Цифровая коммерция в подавляющем большинстве отдает приоритет доходам. Мы согласны, что это самый ценный показатель бизнеса. Тем не менее, масштабные оптимизации ранней воронки продаж, такие как поиск и добавление в корзину, недостаточно изучены.
Компании, как правило, получают больший эффект от тестирования, фокусируя эксперименты на улучшении микроконверсий, например, привлекая больше пользователей к поиску, добавлению в корзину и регистрации учетных записей.
Скорость поиска — самая недооцененная цель эксперимента. Несмотря на то, что он используется в 1% случаев, он имеет самый высокий ожидаемый эффект — 2,3%. Важно отметить, что те, кто ищет, обычно конвертируют в 2-3 раза больше, чем все остальные пользователи.
Платформа данных клиентов (CDP) работает
Компании с интегрированной CDP, по-видимому, гораздо успешнее экспериментируют и видят на 80% больший ожидаемый эффект. Интересно, как это все при этом совмещается с требованиями по GDPR и CCPA 🙂.
Больше тестов ≠ больше эффекта
Чтобы масштабировать процесс экспериментирования в своей компании, вам необходимо тщательно инвестировать в ресурсы разработчиков. Проведение дополнительных тестов – это не выход. Вот почему:
- Наивысшее качество эксперимента достигается при проведении 1-10 тестов в год на одного инженера.
- Как только разработчик переходит на 11-30 тестов в год, ожидаемое влияние на каждый тест падает на 40%.
- Если вы выйдете за пределы 30 тестов, ожидаемый эффект упадет на целых 87%.
==
Если я правильно понял их выводы и прилагаемую статистику, то основной смысл в том, что количество НЕ равно качество. Очевидно, что увеличение нагрузки на команды с требованием повысить количество проводимых экспериментов на ровном месте в какой-то момент приводит к резкому возрастанию количества багов и общему падению положительных эффектов от экспериментов. Я сам это уже неоднократно наблюдал, и чтобы избегать этой ошибки нужно инвестировать больше ресурсов в различные внутренние системы автоматизаций и масштабирования процессов экспериментирования.
Интересный отчет получился. Согласны?
Мы напоминаем, что у нас на платформе есть шикарный курс, который научит вас А/Б тестированию 🥷. Курс можно купить в подарок.
Ссылка на оригинальный отчет:
https://www.optimizely.com/the-evolution-of-experimentation/
🔥26❤6👍6👏3
Привет! Это Владимир.
Обещал ответ на этот коментарий:
"Расскажите как преодолеть пропасть в карьере между стартапами и крутыми компаниями, куда не получается устроиться, может быть потому, что стартапы не считают легитимными(("
👇👇👇
Обещал ответ на этот коментарий:
"Расскажите как преодолеть пропасть в карьере между стартапами и крутыми компаниями, куда не получается устроиться, может быть потому, что стартапы не считают легитимными(("
👇👇👇
🔥6❤2👏2
Привет, это Владимир.
Еще два дня есть возможность купить участие в интенсиве "Технические знания для продакта" по ранней цене.
В пятницу стоимость станет выше.
Что входит?
• 13 уроков на симуляторе
• ∞ доступ к материалам
• Цифровой сертификат
• Чат для вопросов с ответами от Group PM Booking
• Три воркшопа:
22.01 19-21 (МСК)
25.01 19-21 (МСК)
27.01 10-12 (МСК)
Кто ведет?
Владимир Калмыков
Действующий Lead Technical PM в Booking .com
• PhD, 7 лет в продакт менеджменте
• один из первых Tech PM в Booking .com
• ведет 4 команды в качестве менеджера продактов
• вырастил 9 Tech PM-ов внутри компании
• обучил 1000+ Tech PM-ов на разных образовательных платформах
Программа и отзывы на странице курса.
Например:
"Курс реально бомба. Все начинается с банального - "это я знаю", "это я понял", "это где-то читал", НО ПОТОМ Я КАК ВСЕ ПОНЯЛ и, более того, запомнил так, что разбуди меня в два ночи - смогу сделать 1-page для CEO=))
Ребята умудрились непонятно как запихать в мою голову то, за чем я пришел. Все просто и понятно разложено по полкам, и все повторяется ровно столько раз, сколько и надо запомнить. Причем уровень погружения ты определяешь для себя сам. Симуляторы - это просто бомба, а атмосфера на воркшопах заставляет плавиться мозги.»
"Обучающий курс, у которого есть автор и душа. Это его ключевое преимущество перед остальными программами, составленными анонимными методистами без реальной практики в глобальных IT компаниях. Было интересно и полезно! Мне не хотелось пропустить ни одну часть программы, ни одну статью из доп литературы. На семинаре в zoom я встретилась с умными заинтересованными людьми. Вместе проектировать архитектуру продуктов было задорно. Разнообразный бэкграунд участников подпитывал дискуссию.»
"Курс реально стоящий, потому что действительно прививает скилл и умение применить полученные навыки к разным сферам через работу над кейсами. Мне курс помог разобраться с технической составляющей, начать управлять командой поддержки и понять, какие есть пути выхода из ситуации, когда аварии случаются каждую неделю, а поддержка разводит руками и говорит, что мониторинги показывают, что все стабильно. Также курс помог системно посмотреть на продукт и его архитектуру и начать думать с более верхнего уровня над архитектурой смежный продуктов и продуктовой стратегией!"
Запрыгивай!
Еще два дня есть возможность купить участие в интенсиве "Технические знания для продакта" по ранней цене.
В пятницу стоимость станет выше.
Что входит?
• 13 уроков на симуляторе
• ∞ доступ к материалам
• Цифровой сертификат
• Чат для вопросов с ответами от Group PM Booking
• Три воркшопа:
22.01 19-21 (МСК)
25.01 19-21 (МСК)
27.01 10-12 (МСК)
Кто ведет?
Владимир Калмыков
Действующий Lead Technical PM в Booking .com
• PhD, 7 лет в продакт менеджменте
• один из первых Tech PM в Booking .com
• ведет 4 команды в качестве менеджера продактов
• вырастил 9 Tech PM-ов внутри компании
• обучил 1000+ Tech PM-ов на разных образовательных платформах
Программа и отзывы на странице курса.
Например:
"Курс реально бомба. Все начинается с банального - "это я знаю", "это я понял", "это где-то читал", НО ПОТОМ Я КАК ВСЕ ПОНЯЛ и, более того, запомнил так, что разбуди меня в два ночи - смогу сделать 1-page для CEO=))
Ребята умудрились непонятно как запихать в мою голову то, за чем я пришел. Все просто и понятно разложено по полкам, и все повторяется ровно столько раз, сколько и надо запомнить. Причем уровень погружения ты определяешь для себя сам. Симуляторы - это просто бомба, а атмосфера на воркшопах заставляет плавиться мозги.»
"Обучающий курс, у которого есть автор и душа. Это его ключевое преимущество перед остальными программами, составленными анонимными методистами без реальной практики в глобальных IT компаниях. Было интересно и полезно! Мне не хотелось пропустить ни одну часть программы, ни одну статью из доп литературы. На семинаре в zoom я встретилась с умными заинтересованными людьми. Вместе проектировать архитектуру продуктов было задорно. Разнообразный бэкграунд участников подпитывал дискуссию.»
"Курс реально стоящий, потому что действительно прививает скилл и умение применить полученные навыки к разным сферам через работу над кейсами. Мне курс помог разобраться с технической составляющей, начать управлять командой поддержки и понять, какие есть пути выхода из ситуации, когда аварии случаются каждую неделю, а поддержка разводит руками и говорит, что мониторинги показывают, что все стабильно. Также курс помог системно посмотреть на продукт и его архитектуру и начать думать с более верхнего уровня над архитектурой смежный продуктов и продуктовой стратегией!"
Запрыгивай!
🔥11👍4🦄3👏1
Карьерный путь из проджекта в продакты
Привет, друзья!
Какое-то время назад мы анонсировали серию практических вебинаров по карьерному росту и переходу из разных ролей в продакта. Ссылки на записи уже состоявшихся вебинаров ищите ближе к концу этого поста.
Мы продложаем в новом сезоне. Это бесплатно и очень полезно.
На следующей встрече поговорим о переходе из проджектов в продакты.
Для кого будет полезно и что обсудим:
- Проджектам, которые только собираются - какие скиллы подтянуть и что выпячивать на собеседовании
- Молодым продактам, кто только-только перешел из проджектов - как ощущения (не захотелось обратно?), чего опасаться и как закрепиться
- Матерым продактам, которые когда-то начинали проджектами - приходите хвалиться и помогать новичкам советом
Кто ведет?
Андрей Менде, Sr PM ML Booking. com (Ex Project Manager)
Мы ищем спикеров!
Если вы уже (давно или только что) совершили переход "проджект -> продакт" и хотите поделиться опытом с комьюнити – напишите мне в личку @victoriamende.
Готовьте вопросы!
Ну и поскольку мы любим все практическое и полезное: вот вам табличка перехода из разных ролей (маркетолог, аналитик, дизайнер, программист, проджект) в разные типы продактов (обычный PM, Tech PM, Data PM, Payments PM, ML PM, Growth PM, UX PM). Во время лайва мы на нее тоже посмотрим.
Когда и где:
25 января 17:00 Амстердам / 19:00 Мск
Наш канал на YouTube. Вкладка Live / Трансляции
Уже сосотоявшиеся вебинары по теме:
Карьерный путь продакта https://youtube.com/live/9RfhXY9yhGo
Релокация https://youtube.com/live/2hlGZCiwfGk
Привет, друзья!
Какое-то время назад мы анонсировали серию практических вебинаров по карьерному росту и переходу из разных ролей в продакта. Ссылки на записи уже состоявшихся вебинаров ищите ближе к концу этого поста.
Мы продложаем в новом сезоне. Это бесплатно и очень полезно.
На следующей встрече поговорим о переходе из проджектов в продакты.
Для кого будет полезно и что обсудим:
- Проджектам, которые только собираются - какие скиллы подтянуть и что выпячивать на собеседовании
- Молодым продактам, кто только-только перешел из проджектов - как ощущения (не захотелось обратно?), чего опасаться и как закрепиться
- Матерым продактам, которые когда-то начинали проджектами - приходите хвалиться и помогать новичкам советом
Кто ведет?
Андрей Менде, Sr PM ML Booking. com (Ex Project Manager)
Мы ищем спикеров!
Если вы уже (давно или только что) совершили переход "проджект -> продакт" и хотите поделиться опытом с комьюнити – напишите мне в личку @victoriamende.
Готовьте вопросы!
Ну и поскольку мы любим все практическое и полезное: вот вам табличка перехода из разных ролей (маркетолог, аналитик, дизайнер, программист, проджект) в разные типы продактов (обычный PM, Tech PM, Data PM, Payments PM, ML PM, Growth PM, UX PM). Во время лайва мы на нее тоже посмотрим.
Когда и где:
25 января 17:00 Амстердам / 19:00 Мск
Наш канал на YouTube. Вкладка Live / Трансляции
Уже сосотоявшиеся вебинары по теме:
Карьерный путь продакта https://youtube.com/live/9RfhXY9yhGo
Релокация https://youtube.com/live/2hlGZCiwfGk
👍24🔥7❤6🦄1
Мне очень обидно, когда я вижу коллегу, который отлично умеет читать данные, делает из них интереснейшие выводы, но начисто лишен способности придумывать действия, которые можно предпринять основываясь на них.
Он с гораздо большей охотой закопается еще глубже в данные, потому что пока он работает над анализом, он стоит на твердой почве фактов, а выходить на скользкий неверный лёд гипотез ему страшно. Это состояние еще называется "аналитический паралич" (analysis paralysis).
И получается такой вот склад ума (aka data refrigerator). А могла бы быть фабрика...
Он с гораздо большей охотой закопается еще глубже в данные, потому что пока он работает над анализом, он стоит на твердой почве фактов, а выходить на скользкий неверный лёд гипотез ему страшно. Это состояние еще называется "аналитический паралич" (analysis paralysis).
И получается такой вот склад ума (aka data refrigerator). А могла бы быть фабрика...
👍36❤12😁10🤯6🔥2👏1😢1
Мне кажется, одна из самых больших продуктовых ошибок в истории информационных технологий – это то, как было реализовано управление cookies (данными о пользователях, которые хранят сайты).
Да-да, я про эти ужасные баннеры и попапы, которые вы видите почти на всех сайтах при первом (и не только) посещении, которые подавляющее большинство пользователей прокликивают не глядя, потому что они мешают им увидеть контент, за которым они пришли на сайт.
Человек, который придумывал этот механизм, пытался добиться достаточно понятной и даже благородной цели – дать пользователям какие-то механики управления тем, какие данные о них хранят сайты, которые они посещают.
Но я до сих пор не могу поверить, что никто не мог предугадать, во что это выльется. Какова фактическая эффективность этого механизма? Издержки для разработки и функционала колоссальные, но стал ли веб безопаснее? Очевидно, что большинство пользователей не готовы принимать решение о том, какие именно куки разрешить каждому посещаемому сайту. Не говоря уже о том, что они, скорее всего, даже не могут адекватно понять, что именно означают разные уровни разрешений.
Может быть кто-то из вас знает, почему не получилось договориться о каком-то стандарте управление cookies на уровне браузера?
Да-да, я про эти ужасные баннеры и попапы, которые вы видите почти на всех сайтах при первом (и не только) посещении, которые подавляющее большинство пользователей прокликивают не глядя, потому что они мешают им увидеть контент, за которым они пришли на сайт.
Человек, который придумывал этот механизм, пытался добиться достаточно понятной и даже благородной цели – дать пользователям какие-то механики управления тем, какие данные о них хранят сайты, которые они посещают.
Но я до сих пор не могу поверить, что никто не мог предугадать, во что это выльется. Какова фактическая эффективность этого механизма? Издержки для разработки и функционала колоссальные, но стал ли веб безопаснее? Очевидно, что большинство пользователей не готовы принимать решение о том, какие именно куки разрешить каждому посещаемому сайту. Не говоря уже о том, что они, скорее всего, даже не могут адекватно понять, что именно означают разные уровни разрешений.
Может быть кто-то из вас знает, почему не получилось договориться о каком-то стандарте управление cookies на уровне браузера?
🔥19❤8👏5😢3👍2
Самая большая опасность состоит в том, что ты долгое время будешь вести бизнес в неверном направлении!
Привет, это Константин.
Недавно прочитал прикольный пост Ron Kohavi по поводу опасности ложно-положительных а/б тестов.
Воспроизводимость экспериментов – это на самом деле большая проблема, и присутствует она везде. Особенно остро она стоит в той же психологии. Помните такую великолепную (а книга действительно крутая) книгу “Думай медленно, решай быстро” нобелевского лаурета Канемана? В 2015 году в журнале *Science* опубликовали статью о том, как 270 человек пытались воспроизвести 100 психологических экспериментов. Им это удалось — но только в 39% (!) случаев. Что не так уж и много, согласитесь? Сам Канеман, судя по всему, ошибку признал и сказал, что “в прошлом опирался на исследования со слабой доказательной базой и назвал это «ошибкой»”.
Если переносить этот опыт на нашу с вами сферу, то это касается как самих а/б тестов, так и их отсутствия. На мой взгляд, многие неправильно понимают ценность и практическое применение а/б тестов. Эксперименты не дают тебе абсолютной гарантии того, что ты прав или не_прав в своих гипотезах. Но зато гарантировано увеличивают твои шансы на успех путем статистически подсчитываемых рисков (не)правоты твоих гипотез. Более того, в отличии от экспериментов в психологии, эксперименты в ИТ бизнесе можно легко воспроизводить! Например, запустив повторный эксперимент с выигрышным вариантом в случае каких-то сомнений.
Многие часто удивляются: почему в больших компаниях так много запускают а/б тесты? Да потому что:
- во-первых много пользователей,
- во-вторых это достаточно дешево.
Построение нового варианта онбординга, раскатка новой фичи в продакшен, тестирование через а/б тест и т.д. – это всё построено на множестве внутренних тулов, которыми занимаются другие команды по разработке и сопровождению внутренних продуктов. Поэтому провести десятки экспериментов подряд, где надо будет поменять кнопки и элементы онбординга местами - это обычно относительно автоматизированная операция. Несмотря на то, что для реализации этого процесса были задействованы иногда десятки других команд. Всё для того, что на масштабе компании гипотезы было проверять быстро и приятно!
Ну и последня причина почему это делают (о ней очень часто забывают) – это потому, что ничего лучше и мощнее с точки зрения доказательств сейчас не придумали. И это чистая правда. Даже в ставшей уже классической шкале ICE скоринга а/б тесты всегда стоят на самой вершине по степени надежности доказательной базы.
И при всем при этом... шанс нарваться на ложно-положительный результат (т.н. False Positive Rate) невероятно велик. Даже в крупных компаний, где всё отточено до идеала. Он сильно зависит не только от параметров тестирования, но и от процента успешных экспериментов в компании. Посмотрите в табличку 👆 с данными по ложно-положительным результатам крупных компаний и представьте, какой бы там был процент, если бы а/б тестов не проводилось вовсе.
Привет, это Константин.
Недавно прочитал прикольный пост Ron Kohavi по поводу опасности ложно-положительных а/б тестов.
Воспроизводимость экспериментов – это на самом деле большая проблема, и присутствует она везде. Особенно остро она стоит в той же психологии. Помните такую великолепную (а книга действительно крутая) книгу “Думай медленно, решай быстро” нобелевского лаурета Канемана? В 2015 году в журнале *Science* опубликовали статью о том, как 270 человек пытались воспроизвести 100 психологических экспериментов. Им это удалось — но только в 39% (!) случаев. Что не так уж и много, согласитесь? Сам Канеман, судя по всему, ошибку признал и сказал, что “в прошлом опирался на исследования со слабой доказательной базой и назвал это «ошибкой»”.
Если переносить этот опыт на нашу с вами сферу, то это касается как самих а/б тестов, так и их отсутствия. На мой взгляд, многие неправильно понимают ценность и практическое применение а/б тестов. Эксперименты не дают тебе абсолютной гарантии того, что ты прав или не_прав в своих гипотезах. Но зато гарантировано увеличивают твои шансы на успех путем статистически подсчитываемых рисков (не)правоты твоих гипотез. Более того, в отличии от экспериментов в психологии, эксперименты в ИТ бизнесе можно легко воспроизводить! Например, запустив повторный эксперимент с выигрышным вариантом в случае каких-то сомнений.
Многие часто удивляются: почему в больших компаниях так много запускают а/б тесты? Да потому что:
- во-первых много пользователей,
- во-вторых это достаточно дешево.
Построение нового варианта онбординга, раскатка новой фичи в продакшен, тестирование через а/б тест и т.д. – это всё построено на множестве внутренних тулов, которыми занимаются другие команды по разработке и сопровождению внутренних продуктов. Поэтому провести десятки экспериментов подряд, где надо будет поменять кнопки и элементы онбординга местами - это обычно относительно автоматизированная операция. Несмотря на то, что для реализации этого процесса были задействованы иногда десятки других команд. Всё для того, что на масштабе компании гипотезы было проверять быстро и приятно!
Ну и последня причина почему это делают (о ней очень часто забывают) – это потому, что ничего лучше и мощнее с точки зрения доказательств сейчас не придумали. И это чистая правда. Даже в ставшей уже классической шкале ICE скоринга а/б тесты всегда стоят на самой вершине по степени надежности доказательной базы.
И при всем при этом... шанс нарваться на ложно-положительный результат (т.н. False Positive Rate) невероятно велик. Даже в крупных компаний, где всё отточено до идеала. Он сильно зависит не только от параметров тестирования, но и от процента успешных экспериментов в компании. Посмотрите в табличку 👆 с данными по ложно-положительным результатам крупных компаний и представьте, какой бы там был процент, если бы а/б тестов не проводилось вовсе.
👍18🔥6👏3❤2🤯1
Что делать с false-positives на практике?
Привет, на связи Владимир, и я люблю практические примеры. Есть два вида FP экспериментов: «сделал всё, что мог» и «решил схитрить».
Давайте возьмем кейс, на нем будет понятнее. Вот продаем мы тортики, и решили сделать акцию «при покупке двух тортов пирожное в подарок». Гипотеза в том, что это увеличит продажи.
Главной метрикой берём «общая прибыль», поддерживающей – «продажи тортов». Запустили эксперимент, ждём.
1) Вариант 1: прибыль значимо выросла, торты – выросли (ну и экономика сошлась). Странностей в других метриках нет. Тут надо хвалить себя за победу и выкатывать изменение «навсегда».
Может ли тут закрасться FP? Конечно, это ж все вероятности. В большинстве e-commerce confidence interval ставят 90%, так что остаётся 10% ошибиться, что немало.
Прошел год, как быть уверенным, что акция еще работает? Для этого есть техника blackout experiments: в А у нас акция, а в Б - ее нет. В идеале такой тест должен показать ухудшение – без акции значимое падение продаж. Если нет, то либо рынок поменялся, либо… с самого начала это был FP.
2) Второй способ попасть на FP: быть к себе «нестрогим».
Предположим, что в начальном тесте общие продажи выросли, но именно продажи тортиков по два – нет. Тут ОЧЕНЬ хочется все равно похлопать себя по плечу и открыть шампанское. Но если быть строгим, то гипотеза провалилась – мы думали продажи вырастут из-за двойных покупок, а они либо: (1) выросли из-за чего то еще (и надо запускать другой тест), либо (2) - это тот самый FP и акцию раскатывать нельзя.
Побеждает тот продакт, который выбирает не «сердцем», а данными - в долгосрочной перспективе их FP rate будет ниже. Как научиться? Решить 10 кейсов 🙂
Привет, на связи Владимир, и я люблю практические примеры. Есть два вида FP экспериментов: «сделал всё, что мог» и «решил схитрить».
Давайте возьмем кейс, на нем будет понятнее. Вот продаем мы тортики, и решили сделать акцию «при покупке двух тортов пирожное в подарок». Гипотеза в том, что это увеличит продажи.
Главной метрикой берём «общая прибыль», поддерживающей – «продажи тортов». Запустили эксперимент, ждём.
1) Вариант 1: прибыль значимо выросла, торты – выросли (ну и экономика сошлась). Странностей в других метриках нет. Тут надо хвалить себя за победу и выкатывать изменение «навсегда».
Может ли тут закрасться FP? Конечно, это ж все вероятности. В большинстве e-commerce confidence interval ставят 90%, так что остаётся 10% ошибиться, что немало.
Прошел год, как быть уверенным, что акция еще работает? Для этого есть техника blackout experiments: в А у нас акция, а в Б - ее нет. В идеале такой тест должен показать ухудшение – без акции значимое падение продаж. Если нет, то либо рынок поменялся, либо… с самого начала это был FP.
2) Второй способ попасть на FP: быть к себе «нестрогим».
Предположим, что в начальном тесте общие продажи выросли, но именно продажи тортиков по два – нет. Тут ОЧЕНЬ хочется все равно похлопать себя по плечу и открыть шампанское. Но если быть строгим, то гипотеза провалилась – мы думали продажи вырастут из-за двойных покупок, а они либо: (1) выросли из-за чего то еще (и надо запускать другой тест), либо (2) - это тот самый FP и акцию раскатывать нельзя.
Побеждает тот продакт, который выбирает не «сердцем», а данными - в долгосрочной перспективе их FP rate будет ниже. Как научиться? Решить 10 кейсов 🙂
❤21👍12🔥4👏2
Запрещенная соцсеть с когда-то квадратными картинками сокращает всех проджект менеджеров
(но разрешает им попробовать пройти интервью на продакта)
Доброго утра, это Андрей. На выходных мне попалась на глаза интересная статья (не нужно прятать ссылку в коммент, спасибо Паше).
В одной известной компании решили сократить целиком роль проджект менеджеров (они назывались technical program manager, но это по сути та же должность).
Что мы думаем: раньше проджектов было довольно много, они появились в IT индустрии даже раньше продактов. Но сейчас действительно есть такой тренд, что таких позиций становится все меньше и меньше. Должностные обязанности проджекта обычно "размазаны" по смежным ролям, никто не хочет нанимать отдельного человека.
Мой недавний опыт это подтверждает: я помогал нескольким знакомым искать работу, и те, кто до сих пор позиционирует себя именно как проджект, сталкиваются с тем, что вакансий очень мало. Гораздо выше вероятность устроиться продакт менеджером или тим лидом, если навыки и опыт позволяют.
Давайте в этот четверг в 17:00 CET (19:00 Мск) обсудим переход из проджекта в продакты на живом вебинаре.
→ мы пригласили несколько человек, которые недавно совершили этот переход, они поделятся опытом
→ обсудим какие навыки нужно качать в первую очередь, чтобы сконвертироваться
→ придет также один "убежденный" проджект, который ни за какие коврижки не готов становиться продактом, узнаем почему
Где?
Наш канал на YouTube. Вкладка Live / Трансляции
Подпишись, чтобы не потеряться.
(но разрешает им попробовать пройти интервью на продакта)
Доброго утра, это Андрей. На выходных мне попалась на глаза интересная статья (не нужно прятать ссылку в коммент, спасибо Паше).
В одной известной компании решили сократить целиком роль проджект менеджеров (они назывались technical program manager, но это по сути та же должность).
Что мы думаем: раньше проджектов было довольно много, они появились в IT индустрии даже раньше продактов. Но сейчас действительно есть такой тренд, что таких позиций становится все меньше и меньше. Должностные обязанности проджекта обычно "размазаны" по смежным ролям, никто не хочет нанимать отдельного человека.
Мой недавний опыт это подтверждает: я помогал нескольким знакомым искать работу, и те, кто до сих пор позиционирует себя именно как проджект, сталкиваются с тем, что вакансий очень мало. Гораздо выше вероятность устроиться продакт менеджером или тим лидом, если навыки и опыт позволяют.
Давайте в этот четверг в 17:00 CET (19:00 Мск) обсудим переход из проджекта в продакты на живом вебинаре.
→ мы пригласили несколько человек, которые недавно совершили этот переход, они поделятся опытом
→ обсудим какие навыки нужно качать в первую очередь, чтобы сконвертироваться
→ придет также один "убежденный" проджект, который ни за какие коврижки не готов становиться продактом, узнаем почему
Где?
Наш канал на YouTube. Вкладка Live / Трансляции
Подпишись, чтобы не потеряться.
👍22🔥14❤7🤯3
Есть такое понятие: expected value of information (EVI). Получение любой информации требует времени и ресурсов. Нам приходится постоянно соизмерять
- затраты на получение информации
- с ее потенциальной ценностью для решений, которые мы собираемся принять.
Допустим, мы хотим улучшить экран X в нашем продукте. Хммм, а сколько человек вообще посещают экран X? А что это за сегмент пользователей? А какая у них конверсия в сравнении с остальными? Упс, мы только что потратили 8 часов на анализ задачи, которая (в лучшем случае) даст нам прирост 0.1% целевой метрики.
Если мы хотим проверять свою гипотезу A/B экспериментом, то уравнение становится еще сложнее. Далеко не все гипотезы и далеко не всегда разумно проверять тестами.
Если помнить про ожидаемую ценность информации (EVI), то нужно каждый раз задавать себе вопрос “А какие решения я ожидаю принять на основании того исследования, которое я собираюсь провести?”
→ Иногда придется признать, что лучше принять решение без дополнительной информации, потому что потенциальная выгода не окупит затрат на исследование.
→ В остальных случаях придется сильно экономить, и выбирать самый дешевый способ проверки гипотезы. Часто это будет означать, что мы будем использовать не настолько точные методы исследования, как нам (data driven людям) бы хотелось.
Конечно, провести A/B эксперимент гораздо приятнее, чем простое коридорное исследования… но если коридорка стоит вам 30 минут, а запуск теста – несколько дней, то даже если коридорный тест дает 60% точности (против 90-95% в A/B), это часто будет рациональным решением.
Ну или другой пример. Если вы собираетесь изменить лендинг страницу, а трафика пока маловато. Стоит ли запускать A/B тест или просто раскатить изменение на всех, и понаблюдать за изменением метрик недельку-две? Если ваш новый лендинг кардинально меняет позиционирование продукта (pivot), то эксперимент может окупиться. Если же это улучшение UI без глубокой цели, то скорее всего, на данном этапе это пустая трата ресурсов. Уравнение может измениться в вашу пользу, если у вас есть опыт и навыки, и запуск эксперимента “стОит” вам относительно дешево.
Собственно, развитие современного продакт менеджмента целиком построено на принципах продиктованных EVI.
→ проверять только те гипотезы, которые смертельно критичны для бизнеса на данном этапе (riskiest assumption first)
→ проверять гиптезы не самым точным, а самым экономным способом
Напоследок посоветую книгу на эту тему: How to Measure Anything. Когда в очередной статье я увидел цитату из нее, то решил наконец нормально ее дочитать до конца. Как только дочитаю, то поделюсь еще чем-нибудь интересным!
Если у вас в голове есть пример того, как гипотезу очень изящно проверили очень экономным способом – делитесь в комментариях.
- затраты на получение информации
- с ее потенциальной ценностью для решений, которые мы собираемся принять.
Допустим, мы хотим улучшить экран X в нашем продукте. Хммм, а сколько человек вообще посещают экран X? А что это за сегмент пользователей? А какая у них конверсия в сравнении с остальными? Упс, мы только что потратили 8 часов на анализ задачи, которая (в лучшем случае) даст нам прирост 0.1% целевой метрики.
Если мы хотим проверять свою гипотезу A/B экспериментом, то уравнение становится еще сложнее. Далеко не все гипотезы и далеко не всегда разумно проверять тестами.
Если помнить про ожидаемую ценность информации (EVI), то нужно каждый раз задавать себе вопрос “А какие решения я ожидаю принять на основании того исследования, которое я собираюсь провести?”
→ Иногда придется признать, что лучше принять решение без дополнительной информации, потому что потенциальная выгода не окупит затрат на исследование.
→ В остальных случаях придется сильно экономить, и выбирать самый дешевый способ проверки гипотезы. Часто это будет означать, что мы будем использовать не настолько точные методы исследования, как нам (data driven людям) бы хотелось.
Конечно, провести A/B эксперимент гораздо приятнее, чем простое коридорное исследования… но если коридорка стоит вам 30 минут, а запуск теста – несколько дней, то даже если коридорный тест дает 60% точности (против 90-95% в A/B), это часто будет рациональным решением.
Ну или другой пример. Если вы собираетесь изменить лендинг страницу, а трафика пока маловато. Стоит ли запускать A/B тест или просто раскатить изменение на всех, и понаблюдать за изменением метрик недельку-две? Если ваш новый лендинг кардинально меняет позиционирование продукта (pivot), то эксперимент может окупиться. Если же это улучшение UI без глубокой цели, то скорее всего, на данном этапе это пустая трата ресурсов. Уравнение может измениться в вашу пользу, если у вас есть опыт и навыки, и запуск эксперимента “стОит” вам относительно дешево.
Собственно, развитие современного продакт менеджмента целиком построено на принципах продиктованных EVI.
→ проверять только те гипотезы, которые смертельно критичны для бизнеса на данном этапе (riskiest assumption first)
→ проверять гиптезы не самым точным, а самым экономным способом
Напоследок посоветую книгу на эту тему: How to Measure Anything. Когда в очередной статье я увидел цитату из нее, то решил наконец нормально ее дочитать до конца. Как только дочитаю, то поделюсь еще чем-нибудь интересным!
Если у вас в голове есть пример того, как гипотезу очень изящно проверили очень экономным способом – делитесь в комментариях.
❤49👍9🔥5👏4🤔1
А так можно было!? Список задач в виде набора вкладок в Chrome? Или в инбоксе в Gmail?
Продакты работают с тысячами задач, маленькими и большими. Роль предполагает коннекты с десятками коллег и стейкхолдерами. А еще управление процессами в своей собственной команде, что подразумевает сотни мелких и не очень дел, за которыми нужно следить.
Сейчас я пытаюсь повысить свои организационные навыки. Готовлюсь к следующему шагу в своей карьере, где давление будет ещё больше. Ищу способы сделать управление задачами и их приоритизацию более устойчивым к нагрузкам. Для этого, в том числе, общаюсь с коллегами, чтобы понять, как они строят свой рабочий процесс. Особенно с теми, кто известен в сообществе продактов своим отличным перформансом.
Я думаю, для вас не будет сюрпризом, что люди используют очень разные методики для управления своими задачами и информацией, связанной с работой. Я много лет "в теме" и давно знаю основные подходы. Но два моих коллеги действительно меня поразили. И я не могу не поделиться с вами тем, как они работают.
→ Вкладки бразузера как список задач
Коллега X использует вкладки браузера Chrome как свой основной и единственный список задач. Да, вы правильно прочитали. Открытая вкладка = невыполненная задача. Несмотря на очевидные ограничения в возможностях управлении списком, X считает, что это идеальный способ уменьшить сопротивление: вам не нужно ничего дополнительно делать, чтобы приступить к задаче, и весь необходимый контекст уже под рукой.
Когда X получает новый проект, он открывает новое окно Chrome. Когда ему нужно создать задачу в Jira, он создает новую вкладку, открывает диалог создания задачи, пишет короткий заголовок и оставляет вкладку открытой. Вуаля, он может вернуться, к ней когда у него будет время, и доделать ее.
→ Инбокс Gmail как список задач
Другой коллега Y использует свой почтовый ящик Gmail в качестве списка задач. Задача выполнена = в архив. Для управления списком он часто использует функцию "Отложить/Snooze", которая переносит электронное письмо на выбранную дату в будущем. Если ему нужно создать задачу для себя, он отправляет себе электронное письмо (иногда с отправкой в определенный момент в будущем).
В мире, где большинство задач поступают к вам в виде электронных писем, и ваше действие в большинстве случаев – это ответить, это имеет смысл, и также устраняет большую часть "трения".
Оба коллеги управляют довольно сложными областями продукта и отлично справляются с тем, что они делают.
Лично я все еще пытаюсь работать в более традиционной схеме (GTD) и продолжаю вести отдельный списки задач.
Расскажите как у вас? Мне очень интересно узнать, как продакты управляют своими задачами и дедлайнами.
Продакты работают с тысячами задач, маленькими и большими. Роль предполагает коннекты с десятками коллег и стейкхолдерами. А еще управление процессами в своей собственной команде, что подразумевает сотни мелких и не очень дел, за которыми нужно следить.
Сейчас я пытаюсь повысить свои организационные навыки. Готовлюсь к следующему шагу в своей карьере, где давление будет ещё больше. Ищу способы сделать управление задачами и их приоритизацию более устойчивым к нагрузкам. Для этого, в том числе, общаюсь с коллегами, чтобы понять, как они строят свой рабочий процесс. Особенно с теми, кто известен в сообществе продактов своим отличным перформансом.
Я думаю, для вас не будет сюрпризом, что люди используют очень разные методики для управления своими задачами и информацией, связанной с работой. Я много лет "в теме" и давно знаю основные подходы. Но два моих коллеги действительно меня поразили. И я не могу не поделиться с вами тем, как они работают.
→ Вкладки бразузера как список задач
Коллега X использует вкладки браузера Chrome как свой основной и единственный список задач. Да, вы правильно прочитали. Открытая вкладка = невыполненная задача. Несмотря на очевидные ограничения в возможностях управлении списком, X считает, что это идеальный способ уменьшить сопротивление: вам не нужно ничего дополнительно делать, чтобы приступить к задаче, и весь необходимый контекст уже под рукой.
Когда X получает новый проект, он открывает новое окно Chrome. Когда ему нужно создать задачу в Jira, он создает новую вкладку, открывает диалог создания задачи, пишет короткий заголовок и оставляет вкладку открытой. Вуаля, он может вернуться, к ней когда у него будет время, и доделать ее.
→ Инбокс Gmail как список задач
Другой коллега Y использует свой почтовый ящик Gmail в качестве списка задач. Задача выполнена = в архив. Для управления списком он часто использует функцию "Отложить/Snooze", которая переносит электронное письмо на выбранную дату в будущем. Если ему нужно создать задачу для себя, он отправляет себе электронное письмо (иногда с отправкой в определенный момент в будущем).
В мире, где большинство задач поступают к вам в виде электронных писем, и ваше действие в большинстве случаев – это ответить, это имеет смысл, и также устраняет большую часть "трения".
Оба коллеги управляют довольно сложными областями продукта и отлично справляются с тем, что они делают.
Лично я все еще пытаюсь работать в более традиционной схеме (GTD) и продолжаю вести отдельный списки задач.
Расскажите как у вас? Мне очень интересно узнать, как продакты управляют своими задачами и дедлайнами.
🤯15❤11🔥6👏3🤔2😎1
Бесят очереди и неэффективный процесс на tax-return – сделай апу. Раздражает непрозрачность пенсионных накоплений – сделай бизнес!
С вами Владимир с еще одной книгой для продактов: “Fall in Love with the Problem, Not the Solution: A Handbook for Entrepreneurs” от Uri Levine.
Автор – серийный стартапер, самый его известный проект – Waze. Это приложение для навигации, которое строит само комьюнити, просто ездя по маршрутам. То есть там, где 3 раза проехала машина – там дорога. А если кто-то отметил дом номер 6, то с большой вероятностью рядом дома 5 и 7. Бизнес модель – “нежная” реклама магазинов/заправок и тд на карте.
Ему долго отказывали говоря, что он никогда не победит “настоящие” картографические данные, но потом пришел Google и купил их за 1.3 миллиарда. Теперь Waze существует и как отдельное приложение, и, вероятно, как-то “питает” гугловые карты.
Автор запустил еще с десяток стартапов, так что, вроде доверять ему можно. Он еще раз акцентирует внимание на поиске проблемы пользователя. Например, его бесили очереди и неэффективный процесс на tax-return – он сделал апу. Его раздражала непрозрачность пенсионных накоплений – он сделал бизнес и тд. Проблема, которую ты решаешь, достаточно больная для достаточного числа людей?
Потом он много рассказывает про типы пользователей (от early adopters до late majority), о том, почему победа с одними не приносит победы с другими, о том, что стартап – это journey of 100 failures и что надо приготовится падать и вставать.
Много про то, как питчить, как 100 раз слушать отказы инвесторов (венчуры инвестируют примерно в 1%, так что математика суровая), как обговаривать term sheet (договор) и какие подводные камни там ждут. А то построите великий стартап, а выяснится, что у инвесторов и право вето, и почти полное владение компанией, так еще и вестинг период (после которого можно продать свою долю) - 5 лет, так что даже нельзя уйти.
Полезное чтение, как для продактов (ведь они - “стартаперы в тепличных условиях компании”), так и для бесстрашных фаудеров. Точно стоит двух недель вечернего чтения!
С вами Владимир с еще одной книгой для продактов: “Fall in Love with the Problem, Not the Solution: A Handbook for Entrepreneurs” от Uri Levine.
Автор – серийный стартапер, самый его известный проект – Waze. Это приложение для навигации, которое строит само комьюнити, просто ездя по маршрутам. То есть там, где 3 раза проехала машина – там дорога. А если кто-то отметил дом номер 6, то с большой вероятностью рядом дома 5 и 7. Бизнес модель – “нежная” реклама магазинов/заправок и тд на карте.
Ему долго отказывали говоря, что он никогда не победит “настоящие” картографические данные, но потом пришел Google и купил их за 1.3 миллиарда. Теперь Waze существует и как отдельное приложение, и, вероятно, как-то “питает” гугловые карты.
Автор запустил еще с десяток стартапов, так что, вроде доверять ему можно. Он еще раз акцентирует внимание на поиске проблемы пользователя. Например, его бесили очереди и неэффективный процесс на tax-return – он сделал апу. Его раздражала непрозрачность пенсионных накоплений – он сделал бизнес и тд. Проблема, которую ты решаешь, достаточно больная для достаточного числа людей?
Потом он много рассказывает про типы пользователей (от early adopters до late majority), о том, почему победа с одними не приносит победы с другими, о том, что стартап – это journey of 100 failures и что надо приготовится падать и вставать.
Много про то, как питчить, как 100 раз слушать отказы инвесторов (венчуры инвестируют примерно в 1%, так что математика суровая), как обговаривать term sheet (договор) и какие подводные камни там ждут. А то построите великий стартап, а выяснится, что у инвесторов и право вето, и почти полное владение компанией, так еще и вестинг период (после которого можно продать свою долю) - 5 лет, так что даже нельзя уйти.
Полезное чтение, как для продактов (ведь они - “стартаперы в тепличных условиях компании”), так и для бесстрашных фаудеров. Точно стоит двух недель вечернего чтения!
👍18👏17❤9🦄2🔥1🤯1