19470
🚀 Про продакт-менеджмент в международных компаниях @vladimir_kalmykov Lead PM Booking.сom, @andrewmende Sr PM ML Booking.сom, @povarov Sr PM Wolt, @santaux Sr PM Coupang. Симуляторы: productdo.it Написать нам: @productdo_team_bot https://bit.ly/4jOoXLX
Небольшая рефлексия о том что такое хороший и плохой пользовательский опыт и о том, что мотивирует наших коллег делать качественные интерфейсы. Обратите внимание, что в обоих случаях речь не идет про то, как продукт решает проблему пользователя, а исключительно о техническом исполнении сценария.
(1) Пример #1. Интерфейс для регистрации ребенка в программу дополнительных занятий по определенному предмету (дополнительные занятия языком). В программу направляет школа, поэтому я зарегистрировался бы в ней даже если бы пришлось заполнять бумажную форму, никакую метрику эта воронка не растит.
И тем не менее, кто-то продумал:
1. Механизм сохранения сессии. Первым делом форма спрашивает email и тут же отправляет на него ссылку по которой можно будет вернуться к заполнению в будущем или с другого устройства.
2. Этот же механизм сессий позволяет принимающей организации внести какие-то исправления в форму и вернуть родителям “на подпись” новую версию.
3. Мелочь, но какая приятная: в формах про детей никогда не понятно про кого заполнять конкретное поле, про ребенка или про родителя. Чтобы путаницы не было, как только ты вписываешь имя ребенка, оно автоматически подставляется в лейблы всех последующих полей, где речь про него.
Хотя у продакта явно не было прямой коммерческой мотивации, он очень круто сделал свою работу, продумав кучу мелочей. Честно говоря, я не уверен, что я исполнил бы этот интерфейс также качественно (в том числе потому, что не считал бы это важным).
Привет, если вы не копаате картошку на даче, то это Владимир со статьей про SLI (SLO/SLA - потом).
В пост не влезло, поэтому вот ссылка на vc: https://vc.ru/hr/1136732-prodakt-menedzher-i-sli-slo-sla
Приятного чтения!
Отметьте 👍, если интересно еще понять про SLO/SLA (не SLI!) и такие более тонкие темы продакт менеджмента, и поставьте 😎, если и так все знаете/не интересно.
Через час встречаемся на бесплатном вебинаре:
https://www.youtube.com/live/HrfckvDGuxI?si=0JJLxU4jYx37HgcN
Вчера в Амстердаме на митапе ProductTank выступал Marthy Cagan. Автор книг "Inspired" и "Empowered", которые точно входят в число канонических текстов о продукте.
Он презентовал свою новую книжку "TRANSFORMED: Moving to the Product Operating Model" про то как компаниям переходить к правильной продуктовой культуре.
Я написал небольшой конспект его выступления и завтра поделюсь с вами, а пока хочу предложить вам угадать (или догадаться).
Что Марти Каган считает основной причиной того, что европейские продуктовые компании отстают от американских?
Друзья, приходите делиться опытом и рассказать о себе. Есть еще пара вакантных микрофонов для тех, кто пришел из разработки в упраление продуктом. Пишите Вике @victoriamende в личку.
Читать полностью…
Один специалист по B2B позиционированию опубликовал в LinkedIn вот такой пост, сопроводив его ссылкой на данные (все как мы любим).
Как вы думаете, что написали в комментариях специалисты по A/B тестированию, когда заметили этот пост?
Proof that positioning works!!!Читать полностью…
Here're the A/B test results from a client who went live with a new webpage based on the positioning and messaging we worked on.
The test was conducted by their product and marketing team,
They served the old and the new page with a 50-50 ratio for a week.
And measured a bunch of engagement and conversion metrics.
As you can see for yourself,
Better positioning --> Better messaging --> Better conversions.
Привет, это Владимир. Сегодня - мини-гайд по API для продакта с примерами того, как читать документацию и задавать требования к API самому. В пост полезность не влезла - держите ссылку на VC:
https://vc.ru/hr/1126538-chto-prodakt-menedzher-dolzhen-znat-ob-api
Надеюсь, будет полезно. Пишите, если вам интересны мини-гайды (теория + примеры) по разным темам продакт менеджмента.
Классика или тренды?
Улетела на выходные в Амстердам и встретилась здесь со своим хорошим другом, Андреем Менде, ML продактом из Букинга. Вы можете его знать по курсу ProductDo, ну или по какому-нибудь из выступлений на конфах.
Разгоняли про ML и LLM, и тут Андрей говорит:
— Жаль, что мы заранее не договорились встретиться. Могли бы какой-нибудь вебинар вдвоем устроить, раз оба здесь.
— А в чем проблема, давай сделаем, - как обычно подхватываю я))
— Хм, ну вообще, у меня дома все настроено, го.
Итог: завтра в 18 по Мск сделаем эфирчик, ссылку сюда скину)
Конкретной повестки нет, но мы поняли, что это будет битва консерватора Андрея и новатора меня, ахах. Приходите послушать, позадавать вопросы. Что-то из этого интересное получится (:
Накидывайте в комментарии вопросы, ответы на которые хотели бы от нас услышать.
Привет! Завершаем цикл посвященный разбору кейса про A/B эксперимент.
Мы разобрались с тем, что запускать тест на два часа – это не самая лучшая идея даже если согласно расчету мощности вам бы хватило и двух часов для того, чтобы набрать требуемую статистическую мощность. В первую очередь из-за недельных и суточных циклов, которые приводят к тому что случайно выбранные два часа не репрезентативны всей аудитории вашего продукта.
У нас осталось две возможные стратегии запуска и тут мнения наших экспертов расходятся, поэтому приведем вам обе версии с аргументами:
(1) Запустить тест на небольшую долю аудитории (5% + 5%)
Эту стратегию поддерживают Костя и автор кейса, Владимир Меркушев.
+ меньше ресурсов будет потрачено на обработку и обсчет теста, Костя отмечает что на большом объеме данных это могут быть довольно значительные деньги
+ можно оставить 90% трафика на другие тесты и исключить вероятность пересечения и конфликта экспериментов
+ если в тесте есть ошибки, которые вы заметите не сразу, или это просто неудачное продуктовое изменение, то, возможно, потери будут меньше, меньше пользователей столкнутся с проблемами
(2) Запустить тест на весь трафик (50% + 50%)
За эту стратегию выступает Андрей Менде.
+ иметь избыток мощности – это всегда лучше чем иметь просто достаточный минимум: ваши выводы будут сильно точнее как качественно (хорошее это изменение или нет), так и количественно (насколько именно изменилась конверсия)
+ если у вас хорошо работают системы мониторинга, то от проблем пострадает ровно такое же количество пользователей, но узнаете вы у них немного раньше (потому что нужное количество наблюдений наберется быстрее)
+ опыт больших компаний говорит о том, что волноваться о пересечении тестов не стоит, проблемы от этого возникают гораздо реже, чем кажется (см. статью).
Еще со времен поиска первого съемного студенческого жилья я слышу, что риэлторы не добавляют никакой ценности, и вот этот новый технологичный продукт (с использованием blockchain или AI, в зависимости от того, что модно в этом сезоне) обязательно окончательно убьет эту профессию-рудимент. Студенчество закончилось лет 20 назад, большие цифровые продукты на рынке недвижимости медленно, но верно растут, но агенты всё еще среди нас, живут и процветают.
Наверно, второй по частоте рынок, который новые продукты грозятся задизраптить – это рынок найма. То, что рынок функционирует не очень эффективно, довольно очевидно: каждая компания пытается самостоятельно придумать процесс тестирования и оценки, хотя часто у них нет для этого ни ресурсов, ни компетенций.
Опыт соискателей тоже далек от идеала: им приходится много раз отвечать на одни и те же (часто нерелевантные) вопросы, не имея никаких гарантий по сроку и качеству обратной связи.
У вас тоже чешутся руки сделать мир найма лучше? Наш знакомый ищет себе продакта в команду стартапа, full remote. Стартап, кстати, как и учит нас продуктовая наука, сконцентрировался на одной конкретной роли, но на какой – это пока NDA. Подробности о том, как подаваться ниже.
Вакансия: менеджер продукта с бэкграундом в рекрутинге
1. Early-stage US-based HR tech startup Talentway
2. Фулл-тайм, 100% удаленно
3. 1500-3000 долларов в месяц
4. Наш идеальный кандидат имеет бэкграунд в рекрутинге и опыт продакта/проджекта от 2-х лет
5. Свободный английский не ниже С1
Подробное описание и контакты по ссылке.
Аналитик: бьется несколько часов, чтобы выявить закономерность стоящую за аномальной загрузкой некоторых объектов размещения. Он анализирует все параметры пытаясь понять, почему пользователи выкупают все номера в одних гостиницах, при том что другие стоят пустыми.
На картинке видно, что делают пользователи на самом деле. Угадаете, что их мотивирует?
Я по-прежнему считаю, что огромная трагедия телеграма как продукта в том, что он пытается совмещать в себе функции персонального мессенджера и медиа платформы.
Точнее трагедия в том, что главный продакт телеграма продолжает игнорировать эту дихотомию, и не дает пользователям нормальных инструментов, которые позволят отделять школьно-родительский чатик (нужно читать максимум пару раз в день) от переписки с потенциальным партнером (нужно ответить в течение часа). И их оба от заметок остроумного продакта в канале с психоделическим названием (лучше бы не попадался на глаза, если я сознательно не буду искать развлекательный контент).
Да, можно наложением рук делать черную магию с фильтрами и папками, но это явно не решение для массового пользователя.
Можно страдать сколько угодно, но благодаря другим свойствам телеграма, здесь появляется очень много фантастически интересного контента, который больше нигде не встретишь (как в ЖЖ в 2000х). Мне очень нравится, что тут большинство каналов – персональные, в них люди делятся личным опытом и своими индивидуальными взглядами.
Мне повезло быть лично знакомым с большим количеством авторов продуктовых каналов. С ними мы собрали небольшой синдикат (или картель?). Подписывайтесь в два клика на все большие продуктовые каналы и они автоматически лягут в отдельную папку.
👉 Ежедневная порция мыслей про продукты в нашей папке Products
Разбор кейса 👆 от Андрея Менде
(1) Первое что бросается в глаза при чтении кейса – то что там не упоминается напрямую один из самых главных параметров. Минимальный детектируемый эффект (он жe MDE или MRE). Длительность теста напрямую (но не линейно) зависит от того, какой эффект мы ожидаем от изменения. Поэтому я ожидаю от аналитика не ответ "два часа", а что-то вроде:
- за два часа мы задетектим изменение метрики на 5%
- за день на 1%
- за неделю на 0.5%
Можно построить график этой зависимости и вместе выбрать на этом графике точку, которая соответствует целям эксперимента.
Предположим, что продакт с аналитиком заранее договорились о том какой эффект они ожидают. Хотя на практике такое редко встречается, потому что никто не умеет предсказывать насколько ответит метрика).
(2) Если у вас такой бешеный избыток мощности, то с той ли метрикой вы работаете? Как правило, чем метрика ближе к истинной бизнес ценности, тем у нее меньше чувствительность и опытный продакт-экспериментатор будет выбирать максимально точную метрику, на которую у него хватает трафика.
Круто работать с конверсией, но если трафика пока мало, можно работать с добавлением в корзину или вообще с кликом на предложение. Поэтому большинство продактов работают на грани мощности. Если мощности в избытке – можно посмотреть нет ли более точной и глубокой метрики.
(3) Длительность теста зависит не только от мощности. У большинства бизнесов есть существенные суточные и недельные циклы, что означает что рандомные два часа в какой-то день недели не репрезентативны, выводы сделанные на такой выбоке нельзя экстраполировать на всю аудиторию сервиса. Поэтому в большинстве компаний длительность теста округляют до целой недели в большую сторону.
(4) Изменять соотношение между базой и вариантом и запускать тест на 90/10 имеет смысл только в одном случае: если у вас в тесте могут быть негативные последтсвия, которые видны только с большой задержкой. Представим себе, что наш эксперимент уменьшает конверсию на 5%. Если вы помните, как устроен расчет мощности, то чтобы задетектить это изменение вам нужно N наблюдей. Если вы запустите тест на небольшую долю аудитории, то единственное что вы сделаете – это увеличите время через которое вы этот результат получите. Пострадает ровно такое же количество пользователей! Мощность не зависит от времени, только от количества наблюдений. Поэтому тесты почти всегда стоит запускать 50/50.
Что бы я сделал (если более удачной метрики нет): запустил бы тест на неделю и порадовался. Работать на пределе мощности теста – на самом деле опасно и плохо, этого надо избегать. При избытке мощности сильно снижаются вероятности ошибок всех родов, так что надо радоваться.
Let the statistical power be with you.
Привет, друзья! На связи Владимир.
Немного внутренней статистики: 40% наших студентов приходят по рекомендациям тех, кто уже закончил один или несколько наших курсов.
Почти все остальные – после таких вот постов в этом канале ;).
15 апреля стартует живой курс Технические знания для продакта. Я провожу его не так часто. Делаю объявление заранее, т.к. early bird цена действует только до вечера ближайшей пятницы (до 29 марта).
Больше отзывов и программа курса вот тут.
До встречи на курсе!
Сегодня стартует новый поток курса "ML для продакта"!
Привет, это Андрей.
Что нового в этом потоке:
- если вы еще не сталкивались с ML на практике, вы можете пройти симулятор по основам ML и разобраться с основными понятиями – этого будет достаточно, чтобы дальше полноценно участвовать в курсе
- у нас появились практические задания по ML: часть в виде симуляторов, часть в форме командных заданий
- живые воркшопы, где мы вместе разбираем различные кейсы по применению ML в продуктах
Уникальная ценность этого курса в том, что мы будем разбирать именно те аспекты, за которые отвечает продакт менеджер. Не архитектуры моделей, не оптимизацию гиперпараметров, а выбор бизнес кейса, управление сложным циклом разработки и внедрение в продукт.
Воркшопы проходят по средам в 17:00 CET (19:00 GMT+3).
Записи сохраняем, но личное участие бесценно.
Запрыгивайте в последний вагон, пока поезд катится еще медленно.
Empowered: Ordinary People, Extraordinary Products
Недавно мы обсуждали выступление Марти Кагана на продуктовой конференции, а я сейчас как раз дочитываю его книгу "Empowered: Ordinary People, Extraordinary Products". Книга представляет собой готовый набор best practices из больших продуктовых компаний по организации процессов и выстраиванию работы с продуктовыми командами.
Возможно, для матерых продактов из биг теха там не будет много откровений, но для всех остальных она будет полезна. По моим наблюдениям, именно в больших устоявшихся компаниях действительно хорошо выстроены и формализованы процессы, которые в компаниях поменьше попросту отсутствуют. И если вы планируете расти карьерно и проходить собеседования уже как people manager или директор, то эту книгу можно использовать как готовый набор приемов, применимых к действию. Ниже некоторые моменты, которые мне понравились.
Важность проведения регулярных "One-to-one" со своими сотрудниками
Регулярный диалог со своей командой и ведение квартальных и годовых ревью является ключевой вещью для формирования сильной команды. В фидбеке очень важный момент – это "nothing should be a surprise". Его нужно давать вовремя! Для продакта не должно быть сюрпризом в конце года, что он делал что-то не так. Если тебе не удалось донести до человека вовремя его косяки и успехи, то это прежде всего твоя ошибка как руководителя, а не его.
Работа продакта не для всех
Она предполагает, что человек сможет самостоятельно принимать решение и вести разработку. А не делать каждый день только то, что ему говорят. При этом продактом все же не рождаются, а становятся. Если человек хочет стать продактом, то в этом ему надо активно помогать. В Google есть отдельная программа "APM: Associate Product Manager". По ней находят потенциально крутых продактов среди разных специальностей и учат их 2 года, чтобы они стали крутыми продуктовыми лидерами.
Часто бывает, что продакту в руководители попадается не профильный человек (например, уровня VP). Если такое случается, то такой менеджер должен найти себе коуча и сам расти как продакт, чтобы разговаривать со своими коллегами на одном языке. Учиться никогда не поздно, даже если ты уже забрался высоко! Я думаю, что тоже самое вполне релевантно и для фаундеров стартапов.
Ну и последнее...
Для продуктового лидера его команда и есть его продукт
Директор так же не обязан быть самым скилованным в команде, но при этом должен стараться нанимать максимально скилованных людей. А затем помогать им раскрываться.
Вроде простые вещи, но на мой взгляд про них достаточно мало пишут. И часто грамотному проведению 1-1, прозрачным квартальным ревью и понятной карьерной лестнице уделяется крайне мало внимания. Возможно это удел исключительно больших компаний, но в компаниях поменьше по моему опыту этого часто не хватает. При этом при собеседованиях в компании побольше от вас будут ожидания понимания всех этих процессов.
А как у вас обстоят дела с этими процессами на работе? Обязательно делитесь в комментах!
Беззастенчиво краду рубрику "Что посмотреть на выходных" у Продуктория Владимира Меркушева.
Сегодняшнее видео появилось в моем списке по рекомендации Марти Кагана. У этого видео очень интересная история: Стив Джобс очень редко давал длинные интервью, особенно для телевидения. В 1995 году передача "Triumph of the Nerds" (зацените название!) взяла у Стива большое интервью. В этот момент Стив был изгнан из Apple, и руководил малоизвестной компанией "Next Computers". Возможно поэтому охотнее общался с прессой. До его триумфального возвращения в Apple оставалось еще два года...
Из часового интервью в передачу вошло всего несколько минут "хайлайтов", а весь остальной разговор долго считался утраченным. Пока в 2017 году продюсер не обнаружил у себя в гараже (ha-ha, classics) VHS кассету с записью целиком.
Я согласен с Марти, что это очень интересный материал. Мало где Стив высказывает свои мысли настолько откровенно и прямолинейно. Почти нигде его характер не проявляется так фактурно. И поразительно, конечно, как он видел развитие отрасли из 1995 года...
https://www.youtube.com/watch?v=rDqQcmVqAm4&list=PPSV
Правильный ответ на вопрос в предыдущем посте: Marthy Cagan считает, что европейские компании ‘are addicted to process’, и поэтому не могут выстроить нормальную продуктовую работу.
Вот некоторые тезисы, которы лично мне показались важными из выступления Марти:
(1) Марти считает, настоящая продуктовая работа – это решать проблемы клиентов. Главный отрицательный герой в мире Марти – это feature teams. Команды, которые просто имплементируют фичи следуя родмапу, который кто-то написал, а не занимаются discovery.
– Вы же не хотите быть feature team? – c угрозой спрашивает Марти.
По его мнению команды должны очень активно искать ответы на вопросы:
- Какую проблему мы должны пытаться решить
- Как мы можем решить эту проблему
А если вы просто что-то разрабатываете, то вы не продакт, а в лучшем случае проджект, и вам не место в профессии. В delivery Марти ценит только скорость (в духе CI/CD), все остальное ценным или интересным не считает. Think about time to money, not time to market.
(2) Марти очень сильно топит за автономные кросс-функциональные команды, которые способны быстро эксперементировать с решением проблем. Он считает, что вся команда, в том числе инженеры, должны быть вовлечены в продуктовую работу. We don’t hire great engineers to tell them what to do, we hire great engineers so they would show us what is possible.
(3) Марти считает процессы и фреймворки главными врагами продуктового мышления, потому что они подменяют собой анализ и критическое мышление. За это в частности он очень жестко проходится по Agile: исходные принципы хороши, но то, как их пытаются внедрить на практике, чаще похоже на бездумное следование предписанному процессу.
(4) Вместо фреймворков Марти предлагает набор first principles продуктовой разработки, которые можно трактовать и практиковать в меру вашего понимания и таланта. Эти принципы на картинке.
(5) Lead with context, not control. Чтобы раскрыть этот тезис Марти рассказывает историю продуктового руководителя в Netflix. Когда его подчиненные начинали творить какую-то дичь, сначала он хотел всех уволить. Но потом вспоминал что Netflix и так каждый год увольняет всех у кого перформанс хоть каплю ниже “exceptional”. Тогда он осознавал, что если умный продакт делает что-то странное – значит он как руководитель продолбался, и не дал подчиненному какую-то важную часть контекста. И шел разбираться, какого же знания не хватало команде.
Кирилл (который создает очень крутые программы обучения для разработчиков у себя в Хекслете) провел опрос об отношении к скраму.
Стоит иметь ввиду, что для 27% потенциальных кандидатов акцент на теме скрама в вакансии будет негативным сигналом.
У скрама не отнять былых заслуг: практические все сейчас работают спринтами, и используют скрамовские термины для ритуалов и артефактов: бэклог, ретроспектива, груминг и планнинг. Но пытаться придерживаться строгих канонов методологии – это уже, видимо, удел староверов, с которыми мало кто хочет работать.
Слушайте свою команду, и не уделяйте слишком много внимания процессам. Это не то, что позволит вам оторваться от конкурентов.
По мотивам предыдущего поста я решил набросать эскиз картинки "Продакт гадает на статистическом шуме" для нашего стикерпака. А то кофе в этих ваших старбаксах без гущи наливают, как еще принимать важные продуктовые решения – непонятно.
Какая картинка лучше передает идею?
🦄 = фотореалистичная
🔥 = комикс
Умеете промтить DALL-E лучше, чем я? Кидайте свой вариант в комменты. У меня итоговый промпт занимал уже три строчки.
Привет, друзья!
Какое-то время назад мы анонсировали серию практических вебинаров по карьерному росту и переходу из разных ролей в продакта. Ссылки на записи уже состоявшихся вебинаров ищите ближе к концу этого поста.
Мы продложаем в этом. Это бесплатно и очень полезно.
На следующей встрече поговорим о переходе из разработчиков в продакты.
Для кого будет полезно и что обсудим:
- Программистам, которые только собираются – какие скиллы подтянуть и что выпячивать на собеседовании
- Молодым продактам, кто только-только перешел из программистов – как ощущения (не захотелось обратно?), чего опасаться и как закрепиться
- Матерым продактам, которые когда-то начинали девелоперами – приходите хвалиться и помогать новичкам советом
Кто ведет?
Владимир Калмыков, Lead Product Manager
Tech platform solutions Booking. com (ex developer, но бывших разработчиков не бывает)
Мы ищем спикеров!
Если вы уже (давно или только что) совершили переход "разработчик -> продакт" и хотите поделиться опытом с комьюнити – напишите мне в личку @victoriamende.
Готовьте вопросы!
Ну и поскольку мы любим все практическое и полезное: вот вам табличка перехода из разных ролей (маркетолог, аналитик, дизайнер, программист, проджект) в разные типы продактов (обычный PM, Tech PM, Data PM, Payments PM, ML PM, Growth PM, UX PM). Во время лайва мы на нее тоже посмотрим.
Когда и где:
25 апреля 18:00 Амстердам / 19:00 Мск
ProductDo/streams">Наш канал на YouTube. Вкладка Live / Трансляции
Уже сосотоявшиеся вебинары по теме:
Из проджекта в продакты: https://youtube.com/live/YLCuP8_E7kU
Карьерный путь продакта https://youtube.com/live/9RfhXY9yhGo
Релокация https://youtube.com/live/2hlGZCiwfGk
Спасибо всем, кто присоединился!
Запись эфира: https://youtube.com/live/BkHR7QTs1qQ
Завтра вечером Андрей Менде проведет спонтанный эфир с Аней Подображных. Аня была проездом в Амстердаме и мы не могли упустить такую возможность.
Тема: различные подходы к ML. Модные LLM и старые добрые рекоммендательные системы.
17:00 по европейскому времени, 18:00 по мск. Подключайтесь!
Мы постоянно улучшаем наши симуляторы и недавно добавили полноценный урок по построению Service Blueprint продукта в курс "Технологии для продакта". Данный инструмент позволяет связать действия пользователя, фронтенд, бэкенд сервисы и саппорт в единую картину, образуя мост между техническими и нетехническими стейкхолдерами. Построение хорошей архитектуры (а значит, понимания как запустить продукт от идеи до первых продаж), начинается именно с Service Blueprint.
Урок уже доступен как часть симулятора, а углубить практику можно на живом интенсиве, стартующем на следующей неделе (еще есть несколько мест, следующий поток только осенью).
(для тех, кто уже покупал курс "Технологии для продакта" ранее, ничего доплачивать не нужно, заходите попрактиковаться)
40% наших студентов приходят по рекомендациям тех, кто уже закончил один или несколько наших курсов. Ниже немного свежих отзывов.
Привет! Курс классный, понравилось полное отсутствие воды - весь текст это выжимка знаний. Также хорош формат "порционной" подачи информации вместо длинных статей - менее утомительно читать после долгого рабочего дня) Курс хорош тем, что умело структурирует разрозненные кусочки знаний и понятий в голове - кажется, что абсолютно все термины были знакомы, но они наконец-то выстроились в единую картину и обросли взаимосвязями. Спасибо!
Все круто и понравилось! 1. Очень много полезного материала 2. Вместе с интенсивом напомнило очень хороший университетский курс, но только лучше, т.к. с ценным погружением в практическую проблематику (что университетский курс редко дает) 3. Удалось практически сразу использовать в работе - уже рисовал архитектуру нового продукта и разбирался с sequence диаграммами и API.
Большое спасибо за курс! С минимальным опытом в продуктах мне было непросто. Знания уже начала применять на практике.
На самом деле курс действительно интересный и полезный. Конечно, часть материала мне была известна, например в уроках по безопасности или тестированию было мало белых пятен, так как я все таки из банковской сферы)) Там с этим жестко )). Очень актуальны были уроки с API, поиграться с ними на практике, потому что теория теорией, но я никогда руками их не трогала. Очень понравились уроки с метриками. До этого у меня более плоское впечатление о них было. Сейчас картина мира сильно расширилась.
Понравилось. Пока проходил сменил компанию. В прошлой (стартапе), часть знаний казалась бесполезной и слишком теоретизированной. Но сейчас пришел работать в большую компанию и курс стал сильно понятнее. Да он точно практикоориентирован, особенно для работы в больших ИТ компаниях.Читать полностью…
Друзья, Константин на связи!
Я не смог удержаться, чтобы не прокомментировать один из предыдущих постов на тему разбора кейса Владимира Меркушева. Есть ряд ключевых моментов, которые точно стоит пояснить.
Почему нельзя запускать тест на 2 часа?
Одно из самых главных правил при запуске а/б теста – это соблюдение принципа репрезентативности выборки. Ваш а/б тест должен отражать потенциальный результат запуска тестируемой фичи на полную аудиторию продукта и желательно учитывать долгосрочные эффекты. Добиться такого результата без учета сезонности поведения пользователей в течении разного времени суток, временных зон и дней недели невозможно. Даже на крупных сервисов (вроде всем известных поисковиков или маркетплейсов) никто не будет запускать тест на 2 часа несмотря на то, что нужный объем данных ты сможешь набрать за короткий промежуток времени. И отсутствие репрезентативности, которая покажет действительно надежный доверительный результат, является главной причиной.
Но почему нельзя использовать такие результаты для “быстрых выводов”?
Глядя на “значимый” результат эксперимента после первых N часов, есть соблазн использовать результаты “быстрой оценки”, однако делать этого категорически не стоит. Статистика не прощает допущений и ошибок. Либо ты доверяешь своим результатам с заданной вероятностью (например, уровень стат. значимости в 90% или 95%), либо не доверяешь. Например, вечером пришли пользователи, которые склонны совершать импульсивные покупки, а уже утром придут другие пользователи, которые вашу конверсию опустят и дадут противоположный результат. Или наоборот.
А разве есть смысл набирать максимальное количество пользователей при разбивке 50/50?
Чем больше данных – тем лучше. Большее количество данных не только даст возможность задетектить меньшее по размеру изменение, но и повысит уверенность в результатах даже для больших изменений. Если абстрагироваться от проблемы подглядывания, то просто представьте, что у вас будет выбор – протестировать изменение на 1 тыс. человек или на 10 тыс. Какому из результатов вы будете доверять больше? Я думаю, что уровень доверия к результату даже на интуитивном уровне тут для всех очевиден. Поэтому, конечно же, большее количество пользователей даст вам большую уверенность в результате.
(продолжение следует)
4 апреля Андрей Менде проведет бесплатный вебинар на английском языке. Присоединяйтесь! Ссылка для записи в LinkedIn.
Details
Let’s discuss the decisions that a PM is responsible for in a team that is running an A/B experiment. As a PM, you need to know which levers and controls to use to ensure that the team operates at maximum efficiency.
The majority of the materials about experimentation focus on statistical aspects, such as choosing the Bayesian or frequentist approach. However, for Product Managers, it is not so relevant if there is a diesel or gasoline engine under the hood. PM needs to know how to accelerate, break, and steer. Understanding internal combustion doesn’t add much value to this skill set.
Key Takeaways:
- Find out why the concept of statistical power is relevant for backlog prioritization.
- Identify the decisions related to an experiment that are the responsibility of the Product Manager.
- Learn the most significant relation in testing math that a PM should intuitively comprehend.
Как готовить кейсы к интевью?
Всем привет, это снова Константин. Я продолжаю (начало тут) рассказывать про найм в международные компании, и как облегчить себе этот нелегкий процесс. Одна из самых главных вещей для прохождения интервью заключается в том, чтобы подготовить успешные кейсы заранее. Давайте про это поговорим.
Что это могут быть за кейсы? Это могут быть самые разные ситуации, которые в целом сводятся либо к вашим успехам, либо к сложным конфликтным ситуациям. Первая группа это вопросы вроде: “Расскажи про свое самое удачное достижение в последнем продукте?”, “Какой был твой самый сложный продукт?” или “Чтобы ты сейчас сделал по другому, если бы была возможность?”. Вторая группа вопросов на подобии: “Расскажи про ситуацию, когда ты был несогласен со своим руководителем?”, “Расскажи про свою самую большую ошибку в разработке продукта?” и т.д.
Такой цикл вопросов часто объединяют в термин behavioral interviews. Несмотря на название, мне кажется, что это даже не отдельный этап интервью, а некий общий контекст вопросов, которые будут размазаны по всем этапам. Чтобы облегчить себе жизнь, кейсы эти нужно подготовить заранее и отрепетировать подачу. В идеале иметь не менее 10 заготовленных случаев, чтобы точно чувствовать себя уверенно. Тогда вы сможете (как фокусник из шляпы) быстро приводить примеры из своей рабочей практики (и не тратить время и нервы на поиск в голове подходящей ситуации).
Еще полезней будет, если вы подготовите все свои ситуации в формате STAR или другом ему подобном варианте. Техника STAR расшифровывается как: Situation, Task, Action, Result. Ничего сложного в этом нет, достаточно открыть любую статью или ютуб видео, чтобы увидеть множество примеров на этот счет. Главное, чтобы для каждой ситуации вы моги спокойной описать:
- В чем была ситуация/проблема?
- Какая перед тобой стояла задача?
- Какие ты принял действия, чтобы свою задачу выполнить?
- Каков был итоговый результат?
Ничего сложно, но, как я уже говорил, если вы будете вспоминать такие моменты на ходу, переводить в голове всё на английский язык и подгонять под этот формат, то может быть крайне стрессово. А стресса всегда нужно избегать.
И последнее: не забывайте про метрики! Все серьезные компании в любом случае работают по OKR’ам. Совсем не обязательно под каждый из кейсов четко помнить все метрики успеха и квартальные задачи (часто это просто сложно вспомнить для работы 5-ти летней давности, например). Но как минимум вы должны четко ответить на две вещи: Какие были потребности пользователей на ваших продуктах? Как вы измеряли успех/неудачу? Это достаточно банальная вещь, но спрашивать ее будут, и если вы не сможете четко ответить, то собеседование может окончиться провалом.
На этом на сегодня все. Дальше будут еще посты на эту тему. А пока в комментариях пишите на каком на ваш взгляд этапе в цепочке рекрутинга отсеивается большая часть людей? В следующем своем посте обязательно напишу свои инсайты по этому поводу (вопрос с подвохом!)
Владимир Меркушев у себя в канале выложил продуктовый кейс по A/B тестированию.
Я не могу пройти мимо, хочу написать на него разбор. Сразу предупрежу, мы с Владимиром не сверялись насчет правильного ответа, так что вполне возможно, что его решение с моим не совпадет. По крайней мере, мне не нравится ни один из вариантов, который он предлагает на голосование. :)
=== Кейс ===
Вы продакт в компании, которая развивает один из самых популярных онлайн сервисов в стране. Много трафика, постоянных клиентов и денег. Вы планируете эксперимент в виде A/B теста UI изменений формы, через которую проходит большинство пользователей сервиса.
Аналитик показывает вам расчёт необходимого количество трафика для того, чтобы результаты теста были статистически значимыми. По его расчётам тест займёт всего 2 часа. Что будете делать?
👇🏻Выбирайте вариант, который считаете правильным в опросе. Завтра напишу разбор вопроса и всех вариантов ответа.
#productquestion
Я вижу много советов, как хакнуть интервью: игры с LinkedIn профайлом, заучивание стандартных ответов, “корректировка” опыта в лучшую сторону и вот это все. Давайте посмотрим, что может пойти не так.
Если вы, как 95% продактов честно работаете и растите скилл, то написанное ниже к вам не относится. Но для данного примера предположим, что вы решили прыгнуть выше своей головы (например, будучи джуном запрыгнуть сразу в Core или Sr), и по каким-то причинам вам это удалось. Бывает всякое – ведь интервьюеры тоже люди и они могли не выспаться или давать вам “общие” вопросы, к которым легко подготовиться.
Итак, оффер в руке, а с ним и ощущение, что вы хакнули систему. Что же может пойти не так?
1. Во-первых, в большинстве компаний HR делает какие-то скрининги вашего резюме и всякие факт-чеки. И если, например, вы написали, что работали в Google 5 лет, а потом выяснилось, что нет, то на этом сказочке конец.
2. Далее следует испытательный срок. В разных компаниях процедура немного разная, но, если по-простому, то после 2-3-4 месяцев наступает день, в который вы либо продолжаете работать, либо… заканчиваете. За этот срок вполне можно отличить тех, кто попал на позицию случайно (например, по фидбеку команды, отсуствию базовых навыков типа написания PRD, А/Б тестирования и тд) и принять сложное решение начинать найм на роль с нуля.
3. Далее следует годовая оценка сотрудников. В больших компаниях существует система оценки перформанса, обычно складывающаяся из соотвествия планки роли (например, синьор должен делать сильно более сложные штуки, чем джун), бизнес достижений, фидбека команды и коллег. Например, если синьор в итоге и командой не смог толком управлять, и цели завалил, и клиенты жалуются, то год для него закончится так себе. В некоторых странах увольнением (почитайте книгу No Rules Rules про то, как в Netflx чистят нижние 10% перформеров), а в странах с более сильной соц. защитой - просто пониженными зарплатами.
Ну и помимо перечисленных выше фактических препятствий, есть еще более тонкие психологические: синдром самозванца будет реветь на всю, впечатление коллег надо будет долго растить обратно, и в целом работа из приятного планомерного роста превратится в непонятно кому нужную гонку. Что-то типа забега на 20 км, когда вы еле-еле бегаете 3 – в принципе можно, но вместо кайфа от дофамина и рассматривания птичек вы будете с красным лицом и пыхтением бороться за жизнь.
Мораль простая: доводите выданные вам проекты, качайте хард скиллы, зарабатвайте авторитет. Так вы получите более интересный проект, потом еще один, потом уже начнете выбирать проекты сами. Потом компании. А потом, если захотите, откроете свою.
Сегодня посмотрим на ML задачку для продакта вместе с Владимиром.
Кейс: относится ли пользователь к выбранной нами категории.
Например, в финансовом продукте это может быть "fraud" / "non fraud". В случае аренды самокатов - "Risky" / "Non risky" катающийся. В случае Google - являетесь ли вы роботом (которого шлют на капчу) или нет. Привет чат-жпт ботам!
Это может звучать странно, но с точки зрения ML эти кейсы решаются абсолютно одинаково. Так что выберем обобщенный: в большом онлайн магазине понять, является ли пользователь мошенником и направить его по "другому" пути (например, попросить доп. документы перед покупкой).
Как бы вы подходили к решению? Начали бы думать над какими-то условиями:
- Пользователь только что зарегистрировался и сразу бежит покупать. Разумная гипотеза, но в то же время это может быть и нормальным поведением.
- Пользователь уже N раз заказывал и отменял товар. Тоже логично, но иногда и это нормально.
- Пользователь скопировал номер кредитки, а не ввел его
А что насчет типа браузера? Устройства? А какая страна IP-адреса? Стоимость покупки? Категории товара?
А имейл "выглядит" адекватно (jeka.ivinin99@gmail.com) или странно (dfs863199939339@gmail.com). Или это не странно? Ну и так далее.
Какое из этих правил важнее? Первые два? Или второе, четвертое и седьмое? А может все вместе? А они равнозначные?
Горе тому продакту, который решить решать эту задачу мышцей продуктового решения. Зато слава тому, кто увидит в задаче стандартную ML-задачу классификации (classification problem).
Фичами модели станут перечисленные выше критерии, целевой функцией - классы "Fraud" / "Non fraud".
Магия ML в том, что если запихнуть в алгоритм циферки для, скажем, 100 пользователей, помеченных "хорошими" и еще 100, помеченных "мошенниками", то ML-ка сумеет сама найти оптимальную связь между всеми критериями и для нового случая (приготовившегося платить нового пользователя) сумеет дать свой предикшн.
Если хотите, научиться видеть ML-задачки там, где сегодня видна стена и приоткрыть себе дверь в инновационные продукты, приходите на курс ML для продакта от Sr.ML PM @ Booking .com Андрея Менде. Он один из тех продактов, которые очень глубоко разбирается в теме - я сам с ним постоянно советуюсь. А еще можно пройти симулятор "Основы ML для продакта" и получить базу ML-подготовки и потом решить, хочется ли добавить к ним живую часть и более продвинутый симулятор.
Старт живого потока 20 марта. Продолжительность 5 недель. Ранняя цена действует еще два дня. Начиная с выходных будет дороже.
В следующем посте я расскажу, что может пойти не так с подходом выше в реальной жизни, и что по этому поводу делать.
P.S. Про идеи для стикеров мы помним – дайте плз еще немного времени на анализ🙏