Есть такое понятие: 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. Когда в очередной статье я увидел цитату из нее, то решил наконец нормально ее дочитать до конца. Как только дочитаю, то поделюсь еще чем-нибудь интересным!

Если у вас в голове есть пример того, как гипотезу очень изящно проверили очень экономным способом – делитесь в комментариях.

Погнали! https://www.youtube.com/live/YLCuP8_E7kU?si=h8_kMOBbiNLikfL_

А так можно было!? Список задач в виде набора вкладок в Chrome? Или в инбоксе в Gmail?

Продакты работают с тысячами задач, маленькими и большими. Роль предполагает коннекты с десятками коллег и стейкхолдерами. А еще управление процессами в своей собственной команде, что подразумевает сотни мелких и не очень дел, за которыми нужно следить.

Сейчас я пытаюсь повысить свои организационные навыки. Готовлюсь к следующему шагу в своей карьере, где давление будет ещё больше. Ищу способы сделать управление задачами и их приоритизацию более устойчивым к нагрузкам. Для этого, в том числе, общаюсь с коллегами, чтобы понять, как они строят свой рабочий процесс. Особенно с теми, кто известен в сообществе продактов своим отличным перформансом.

Я думаю, для вас не будет сюрпризом, что люди используют очень разные методики для управления своими задачами и информацией, связанной с работой. Я много лет "в теме" и давно знаю основные подходы. Но два моих коллеги действительно меня поразили. И я не могу не поделиться с вами тем, как они работают.

→ Вкладки бразузера как список задач

Коллега X использует вкладки браузера Chrome как свой основной и единственный список задач. Да, вы правильно прочитали. Открытая вкладка = невыполненная задача. Несмотря на очевидные ограничения в возможностях управлении списком, X считает, что это идеальный способ уменьшить сопротивление: вам не нужно ничего дополнительно делать, чтобы приступить к задаче, и весь необходимый контекст уже под рукой.

Когда X получает новый проект, он открывает новое окно Chrome. Когда ему нужно создать задачу в Jira, он создает новую вкладку, открывает диалог создания задачи, пишет короткий заголовок и оставляет вкладку открытой. Вуаля, он может вернуться, к ней когда у него будет время, и доделать ее.

→ Инбокс Gmail как список задач

Другой коллега Y использует свой почтовый ящик Gmail в качестве списка задач. Задача выполнена = в архив. Для управления списком он часто использует функцию "Отложить/Snooze", которая переносит электронное письмо на выбранную дату в будущем. Если ему нужно создать задачу для себя, он отправляет себе электронное письмо (иногда с отправкой в определенный момент в будущем).

В мире, где большинство задач поступают к вам в виде электронных писем, и ваше действие в большинстве случаев – это ответить, это имеет смысл, и также устраняет большую часть "трения".

Оба коллеги управляют довольно сложными областями продукта и отлично справляются с тем, что они делают.

Лично я все еще пытаюсь работать в более традиционной схеме (GTD) и продолжаю вести отдельный списки задач.
Расскажите как у вас? Мне очень интересно узнать, как продакты управляют своими задачами и дедлайнами.

Бесят очереди и неэффективный процесс на 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 лет, так что даже нельзя уйти.

Полезное чтение, как для продактов (ведь они - “стартаперы в тепличных условиях компании”), так и для бесстрашных фаудеров. Точно стоит двух недель вечернего чтения!

Одно из самых полезных занятий для развития продуктового мышления – это внимательно наблюдать за тем, что делают большие компании и задавать себе вопросы: почему они выбрали такое решение? Какую метрику они сейчас оптимизируют?

Поэтому я люблю читать информационные каналы, такие как фичизм. Это не мудрые мысли еще одного коллеги о судьбах индустрии, а интересные факты, которые невооруженным взглядом не заметишь, которые дают отличный повод потренировать ум.

Например, вот недавний пост в фичизме: Нетфликс изменил тарифную сетку: они убрали тариф Basic, и теперь подписка без рекламы стала сильно дороже $12 → $15,5. А тариф с рекламой за $7 в месяц оставили нетронутым.

Я начинаю пытаться представить себе о чем думает продакт, который отвечает за монетизацию. Давайте выпишем метрики, которыми он оперирует:

→ ARPPU (в данном случае совпадает с ARPU)
→ Ad reveue per user per month (для пользователей на тарифе с рекламой)
→ Retention rate
→ Распределение пользователей по тарифам (здесь скорее всего релевантны только новые подписки, так как из новости мы видим, то существующие пользователи сохранили свой текущий тариф).

Теперь можно попробовать сделать reverse engineering этого решения. Судя по всему, это означает, что (конверсия + ARPPU + ad revenue + retention) на тарифе с рекламой выглядят сейчас для Netflix привлекательнее, чем ARPPU на тарифе без рекламы. Понятно, что продакт пытается оптимизировать LTV, но никаких способов быстро измерить влияние на LTV у него нет (и предсказательные модели тут скорее всего не помогут).

Таким образом, по имеющимся на данный момент у Netflix данным, пользователи охотнее платят за сервис просмотром рекламы, чем живыми деньгами – это уже очень полезный вывод.

Еще можно представить себе, что на продакта давят, требуя повысить краткосрочную маржинальность в ущерб долгосрочным показателям, но в случае Netflix мне эта теория кажется не очень правдоподобной.

А вы что подсмотрели у лидеров рынка в последнее время и какие выводы сделали?

Реальный сценарий открытия страницы товара (!) на мобильном устройстве по ссылке из рекламы.

А кто-то, наверное, ломает голову почему конверсия на телефонах такая низкая…

Фокус с календарем (он же фокус-день):
завести хотя бы 4 часа в неделю, когда тебя нельзя достать никак.

Продакт все время бегает: разблокирует команду, держит за руку клиентов, менеджит менеджера, договаривается с зависимостями, тушит пожары, планирует спринт, квартал, год. Мы такие занятые!

Между тем доказано, что мозг реагирует на сообщения (в соц сетях или slack’е) очень просто – ему нравится короткие картинка +текст или вопрос-ответ-решение, и он выдает порцию дофамина. Потом вторую. Потом пятую. Потом десятую. И потом, когда вы наконец решили сесть за стратегию, то… уже ничего не осталось на выдачу.

Плохо ли это? В режиме пожаротушения или просто “надо-сделать-это” проекта – отличный скилл.

Но действительно классные идеи так не рождаются. Для них нужно несколько часов загружать в мозг контекст (что ты хочешь сделать? что говорят эти 3 ресерча? что показали эти 5 экспериментов?) и тогда кукушка сделает именно то, что пока не может ChatGPT – соединит миллионы нейронов и выдаст “Эврика!” (например, заметит проблемный сегмент пользователей или возможность фичи).

Хорошие новости в том, что этот процесс выделяет больше дофамина, чем чатик. Плохие – что найти 4 часа продакту сложно.


Вот прямой сейчас давайте посмотрим в свои календари: на эту неделю забронировано время для сфокусированной работы? Сколько часов?

Когда я читаю статьи про тайм менеджмент и личную эффективность, написанные больше десяти лет назад, то там основным источником коммуникации чаще всего считается электронная почта.

Для обработки электронной почты придумано много всяких полезных приемов: и автоматические фильтры, и система папочек, и концепция zero inbox.

Однако сейчас уже, мне кажется, 90% важных сигналов поступает через мессенджер. Но, на мой взгляд, настолько же хороших систем фильтрации и обработки информации для мессенджеров все еще нет, и в этом есть некоторая трагедия.

И хорошо еще если это Slack, в котором какие-то инструменты для систематизации общения все же есть. По личным проектам я переписываюсь в основном в телеграме, и это просто ужас. Хитрая система папок и правил может помочь как-то ориентироваться в ленте чатиков, но “из коробки” это все стремиться оставаться в состоянии хаоса.

В slack я 90% времени пользуюсь вкладкой ‘Unread’. Она офигенна тем, что в ней можно сколько угодно смотреть на новые сообщения, они не будут помечены прочитанными, пока ты сознательно не нажмешь на кнопку ‘Mark as read’. Это фантастически удобно, и позволяет работать с мессенджером как со списком задач.

Если же просто открыть чатик, чтобы посмотреть, что именно тебе написали нового, то он автоматически исчезнет из зоны внимания (а новые сообщения исчезнут из вкладки Unread), даже если там тебя просят что-то сделать и ты не можешь сделать это сразу. Приходится постоянно нажимать ‘Mark unread’.

Еще я довольно часто пользуюсь функцией ‘Remnind me about this…’ чтобы отложить сообщение на определенную дату. Да, это в некотором смысле дублирует функционал списка задач, но сильно добавляет скорости.

В телеграме же, если ты открыл чатик и находишься внутри, то нет возможности быстро отметить диалог непрочитанным. Такая опция есть только в конекстном меню в списке чатов, но не внутри чата.

Какие полезные приемы вы используете, чтобы эффективно работать с рабочими мессенджерами?

Работая в платформенной команде, часто приходится делать различные интеграции с другими сервисами других команд и решать их проблемы с запуском экспериментов. Какое то время назад я обнаружил, что в некоторых командах существует их отдельный слэнг, который часто может мешать общаться с ними на одном языке. В таких случаях я взял себе за правило вначале составлять паритет по терминам внешней системы и нашей и только потом уже двигаться вперед.

И чем более узко-специализированная команда к тебе обращается, тем больше у нее внутреннего слэнга, который мешает разобраться в чем же состоит их проблема. Например, у нас есть свои тремины для обозначения некоторых типов пейволов с подписками, свои названия для иерархических конфигураций на клиенте, для "зависимых" друг от друга а/б тестов и т.д. И в таких разговорах люди из разных команд и департаментов часто даже не понимают друг друга. И в чем заключается проблема тоже не понимают.

Это классическая история про Jobs To Be Done. Потому что когда начинаешь раскручивать этот клубок из требований, довольно часто приходишь к неожиданным результатам. Например:

- Команда запрашивает возможность ссылаться из одного а/б на другие а/б тесты, а на самом деле проблема в том, чтобы разделять аудиторию между несколькими экспериментами, которые не должны пересекаться.
- Или требует ввести функционал быстрого перезапуска а/б теста с тем же именем (что затратно по ресурсам и вызывает проблемы с анализом этих а/б теста в будущем), но на самом деле им нужно научиться быстро выкатывать новые эксперименты без обновления кода клиента.
- и т.д.

Как урок на будущее, я вынес для себя следующее: вначале определиться с терминами, чтобы говорить с клиентами на одном языке. И всегда копать вглубь, пока наружу не выплывет истинная проблема и мотивация.

Как продакты мы постоянно работаем с данными и анализируем их.
А еще среди нас есть продакты, которые работают с данными о продактах.

Чтобы у них было больше данных о продактах, а мы все лучше понимали как сейчас устроена индустрия и куда всё движется, поучаствуйте, пожалуйста в исследовании: https://survey.alchemer.eu/s3/90657221/2024

Среди прошедших опрос разыгрываются билеты на ближайший сезон Podlodka Product Crew.
Опрос анонимный, все данные конфиденциальны и будут использованы в обобщенном виде.
Результаты можно будет увидеть уже в конце февраля. Обязательно обсудим тут ;).

Результаты предыдущего исследования devcrowd.ru/pm22

Хард скиллы помогут тебе на всех этапах карьеры: от джуна до директора

Привет, это Владимир.

Спорил на днях со своим директором об одной метрике и осознал, как же он хорошо шарит в деталях, несмотря на свою должность (под ним 10 команд).

От продактов, которые готовятся стать менеджерами, я часто слышу, что “они готовы к стратегической работе” и “детали им уже не так важны”. Вместе с этим приходит представление, что Product Director – это стратег, сидящий за дубовым столом и владеющий собственным если не самолетом, то по крайней мере Porcshe и суровым взгдядом.

Спешу вас расстроить – директор отвечает за 8-10 команд, и если в одной из них проблема: подчиненный ушел в незапланированный отпуск, что-то сильно сломалось или нужно крайне сложное решение, то директору не на кого положиться – приходится впрыгивать. И часто спасают его хард скиллы.

Например, A/B тест показал смешанные результаты, все смотрят на директора. Если он просто “стратег”, то он нежно отфутболит это команде обратно. Но если он сам запустил не одну сотню тестов, то он предложит такие опции, которые и не дадут прямой ответ, и двинут команду вперед.

Или, скажем, принимается решение по архитектуре и тех лиды уже месяц не могут решить, делать X или Y (не редкость в сложных проектах). Хороший директор подключит бизнес-смекалку, услышит доводы технарей (потому что сам разбирается) и поможет двинуть команду к одному из решений.

Конечно, в идеале команда все должна решать сама, но когда вы в последний раз участвовали в идеальном проекте? А отвечает за него в итоге кто? Вот-вот.

Качайте хард скиллы на наших симуляторах, благо задачек в них хватит не на одного директора!

По теме вчерашнего поста - держите красивую табличку прокачки хард (80%) и софт (20%) скиллов от Джуна до Синьора. Там же есть колонка "чего делать не надо" - если узнаете себя в ней, то будьте осторожны.

https://productdo.it/matrix

Пишите в коментах, если считаете, что мы пропустили какой-то ну очень важный скилл и предложите, как его описать в формате (Jr, Core, Sr, Red flag).

Простите, но я опять про мессенджеры. Мне кажется я провожу в них 20% - 25% рабочего времени, поэтому у меня много мыслей по стилю коммуникации.

И в первую очередь я делю людей на тех, кто имеет тенденцию каждую свою мысль (чаще всего незаконченную) отправлять отдельным сообщеним. Особенно 'Hey!' или "Привет!"

И тех, кто сначала думает, а потом отправляет полное сообщение, ответив себе на вопрос, чего он ожидает от адресата.

Я, честно говоря, даже стесняюсь фидбэк давать на эту тему, ну это же детский сад какой-то. Ты синьер уже по уровню, подумай, блин, перед тем как писать!

В четверг 22/02 у нас будет разбор кейсов на софт-скилы. Присылайте свои кейсы!

Привет, канал. В четверг у нас будет вебинар, на который мы пригласили Александру Клименко. Саша давно занимается обучением IT специалистов коммуникациям, переговорам и прочим софт скиллам.

Ну знаете, когда вам дают на интервью кейс вроде "продакт соседней команды отказывается взять вашу задачу, говорит, что у него нет на нее ресурсов, как вы поступите?". Или когда у вас тлеющий конфликт с тимлидом внутри команды. Я сам, честно говоря, не знаю правильных ответов на эти вопросы, будем разбираться с Сашей.

Кто:
Александра Клименко, СЕО школы коммуникации Soft Skills Lab
Андрей Менде, Senior Product Manager Data Science Booking .com
Когда: 22/02 17:00 (CET) / 19:00 (GMT+3)
Сколько времени займет: час – полтора
Где: наш канал на YouTube, вкладка Трансляции / Live


Чтобы было интереснее и полезнее, мы предлагаем разобрать несколько кейсов от участников нашего сообщества. Наверняка у вас были такие ситуации на работе, про которые вы до сих пор размышляете – как правильно было поступить, чтобы добиться своих целей экологичными методами. Присылайте короткое описание ситуации @victoriamende в телеграм и приходите разобрать его на вебинаре. По желанию кейс можно разобрать анонимно.

Где смотреть вакансии (кроме LinkedIn)

Привет, это Андрей Менде.
У меня было несколько менти, которые переходили в продуктовую должность из “смежной”. В перавую оченедь мы занимались подготовкой к интервью и переупаковкой опыта таким образом, чтобы про него можно было рассказывать продуктовые истории. Но помимо этого, я советовал ребятам максимально использовать “нечестные преимущества" при выборе вакансий.

Например, если вы как продакт или как аналитик занимались товарами FMCG, то компания в той же нише будет расценивать то, что вы хорошо знаете отраслевую специфику как сильный плюс. И более вероятно простит вам небольшое количество опыта и “неправильный” тайтл на последнем месте работы.

Есть целый канал в телеграме, который посвящен поиску работы за рубежом для русскоязычных. Называется Connectable Jobs Abroad.

Там публикуются только вакансии в компании с русскоязычными фаундерами или командами. Они точно смогут оценить то, что вы работали в Яндексе, и у вас будет меньше волнений по поводу культуры общения. И это будет вашим "нечестным преимуществом".

Connectable Jobs – это авторский контент, то есть вакансии редакторы выбирают руками. И, помимо стандартного описания вакансии, вы найдете там
- честный краткий профиль компании,
- информацию об инвестициях,
- ссылки на интервью с основателями (очень полезно, чтобы заранее оценить культуру компании и не попасть в Revolut),
- и даже пометки о том, что несколько подписчиков канала уже смогли устроиться туда на работу!

Например, среди последних опубликованных там есть вакансия продакта по платежам в компанию Trading View. Я этот продукт знаю и люблю, но сам по себе он фантастически сложный для управления. Однако, если у вас есть экспертиза в платежах, вы уверенно можете рассуждать про сертификацию PCI DSS, и знаете, почему лучше сделать refund, чем потом поймать cahrgeback, то у вас есть значимые "нечестные" преимущества.

Мне также кажется, что управление платежами – это отличные позиции для перехода из проджектов в продакты. В платежах совершенно точно не нужно удивлять клиентов революционным видением, но зато нужно очень предсказуемо и надежно выполнить множество технически сложных элементов обязательной программы.

Запись эфира: https://youtube.com/live/XdDMT_OhYX4

Сегодня интересный опыт про продуктовую стратегию

Привет, это Владимир. Мне временно досталась еще одна команда с продактом, и там был небольшой бардак. Поэтому я решил вместе с этим продактом написать статегию. Не в стиле Джобса, а просто чтобы было примерное направление движения.

Во-первых, часто, когда ты что-то подобное просишь, ты видишь глаза человека, который вроде слово “стратегия” понял, но что именно делать пока не уверен. Тут лучше просто помочь со структурой, которую ожидаешь. Просто, чтобы не получить что-то уж совсем раслывчатое.

Далее, ты часто можешь услышать что-то типа “Нам это не нужно, мы знаем, что делать”. Это отлично, значит записать не составит труда, верно?

Потом ты видишь уважительное кивание, когда показываешь в пример какую-то другую команду и их стратегию.
(А продакт их – сын маминой подруги!)
Ты практически в реальном времени видишь расширение сознания и выражение лица “Ахренеть, это и вправду план на год вперед в понятном виде!”.

Потом ты видишь ухмылку “Сделаю такую же завтра, проще-простого”.

Через неделю продакт возвращается без половины волос и говорит, что всё оказалось сложнее, чем он думал. И вообще – вот его первая версия. Виной этому эффект “Да там все ясно”, который заставляет нас игнонировать сложные продуктовые вопросы и плавать в операционке. А когда ты это “ясно” вытаскикаешь на сцену и применяешь к нему логику (“Проблема пользователя, импакт для бизнеса, технические ограничения и тд”), то многие “ясно” просто разваливаются. Когда один за другим разваливаются все “ясно”, то начинаешь седеть: “А что дальше-то!? У меня что, нет планов!?”

Через три-четыре итерации “фидбек менеджера/коллег/переделка” стратегия обретает форму и достигает того самого волшебного эффекта, который можно описать так: “Вроде и планы аж на год вперед, а вся история связная, понятная и реалистичная с точки зрения исполнения”.

Данный артефакт (обычно слайды) важно сделать до начала следующего года (в крайнем случае - в начеле текущего). Огромный плюс: этот док вы будете использовать десятки раз, то объясняя директору план, то напоминая команде компас, то онбордя новичка, и т.д. Свою стратегию я открываю раз по 5 в месяц и, конечно, постоянно немного полирую новыми мыслями.

Есть ли у вас такой док? Если нет, сможете ли вы записать путь от “сейчас” до “31 декабря 2024 года” в понятной любому читателю (программист, нетехнарь-дизайнер, CEO) форме? Если да, снимаю продуктовую шляпу.

Если интересно, то в следующем посте поделюсь шаблоном стратегии.

Делюсь чек-листом по продуктовой стратегии.
По реакциям и комментам 👆видно, что тема горячая.

Сразу обратите внимание на две вещи. Во-первых, не нужно ожидать от шаблона магии - вам всё равно придется ответить на “сложные” продуктовые вопросы (например, какую проблему пользователя вы решаете).
Во-вторых, чтобы ответить на эти главные вопросы, вам нужно будет задать 20 других более мелких вопросов, например:

- Какая конверсия была на странице регистрации?
- Насколько сервис отзывов готов принимать данные о моем продукте?
- Что заставляет меня верить, что вот тут поможет ML?
- Какую метрику выбрать для главной линии экспериментов?
- Уверен ли я, что эту API интеграция реалистично сделать за 2 квартала?

И так далее. А для этого нужны (барабанная дробь) - хард скиллы. Так что пишите стратегию, а когда почуствуете, что не хватает мат. части, то посмотрите на наши симуляторы. Вот тут можно пройти обзорный тест по всем скиллам продакта, из которого есть ссылки на бесплатные уроки по каждой теме:
- Технологии для продакта
- A/B тестирование
- Аналитика, SQL для продакта
- Основы ML
- Планирование и Исследование рынка


Ну и вот сам шаблон по продуктовой стратегии.


Качайте скилл и да достигнет ваша стратегия обещанных в презетации высот.
Если нет, то CEO вам это обязательно в конце года напомнит 😉

У Ahoy вышел новый подкаст. 70 минут пользы и инсайтов.

В гостях Андрей Менде, Senior PM ML в Booking и автор в образовательном проекте ProductDo, рассказал о плюсах переезда в Амстердам, как изменилась продуктовая культура в Booking с ростом компании, почему не всегда нужно стремиться стать менеджером, почему практическое образование лучше теоретического и для кого оно подходит больше всего.