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

Делюсь трюком, которым я пользуюсь, чтобы проверять готовность идей к разработке:
Тест "Начинаем завтра!"

Привет, это Владимир. На неделе я встречался с продактом из соседнего департамента и услышал от нее отличную идею, которую она предлагает для нас сделать. Поскольку конкретный пример вам будет не очень понятен без контекста (а NDA никто не отменял), давайте предположим, что мы в компании Spotify и “идея” состоит в том, чтобы показывать ближайшие концерты группы неподалеку от слушателя.

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

Но на этой неделе я опять получил “идею”: она немного обросла деталями MVP, но по-прежнему не прошла “начинаем-завтра-тест”.

Тест очень простой – вы спрашиваете себя или коллегу: “Если у нас завтра появляется 5 свободных программистов/дизайнеров/итд, проработана ли идея продактом так, чтобы ее можно было прямо завтра начать кодить?”

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

- Радиус “ближайших городов” - 200 km
- MVP: только артисты одного лейбла, который дает нам доступ к своей базе данных концертов
- Показываем только дату/название клуба внизу странички артиста - ссылки пока не кликабельные
- Меряем событие viewed этот элемент > 3 seconds

Вот эта идея уже проходит “начинаем завтра-тест". Так что вы удивитесь, что вместо месяцев мучительных двиганий тикета по Jira, это MVP будет запущено за неделю.