Good PM, bad PM
Вообще я планировал рассказать о наших trials and tribulations в построении автономной команды продукта на Джинне, но эта тема требует подготовки. Maybe next week.
Сегодня хочу поговорить о роли ПМ и чем отличается плохой продакт менеджер от хорошего. В роли ментора у нас Бен Хоровиц, со-основатель венчурного фонда a16z, крипто(?) миллиардер и автор книги Hard Things About Hard Things.
Для контекста: эссе Good product manager, Bad product manager Хоровиц написал где-то в начале 2000-х, когда Nescape, где Бен работал в роли продакт менеджера, был продан AOL. Есть также обновленный и сильно сокращенный вариант в блоге a16z, написанный спустя 15 лет.
Ниже цитаты из Хоровица + примеры из моего опыта
A Good Product Manager plays critical role in a successful product. [the best recommendation] is the candidate's track record (or lack thereof) of successful products that become profitable businesses for their company.
Успех и эффективность продакт менеджера оценивается по успеху продукта на рынке, никакие оговорки и оправдания не принимаются.
Если ваш продукт “не взлетел”, виноват ПМ. Надо было увидеть раньше и найти другой путь или требовать свернуть проект и начать заново. Обратное кстати не всегда верно – иногда ПМ оказывается “в нужном месте в нужное время” и продукт становится успешным несмотря на плохие решения ПМ.
Bad product manager leads to (…) the wrong product being built
Это наверное худшее, что может сделать ПМ.
Мы потеряли минимум год, когда я само-устранился от управления продуктом на Джинне и позволил команде драйвить “направление” продукта.
Два вывода:
1) ПМ отвечает за ключевые метрики продукта
2) Если вы не готовы полностью доверить кому-то ответственность за продукт, то ПМ это де-факто вы, даже если у вас тайтл CEO.
Good product managers are viewed by the entire product team as the leader of the product.
Если ты не знаешь куда ты идешь, то тебе сложно туда придти, не так ли? У ПМ должно быть четкое понимание, какой продукт мы строим и для кого. Когда беклог определяется голосованием, это значит у продукта нет ПМ.
A good product manager understands the difference between opinions, hunches, and objective facts. Bad product managers go on their instinct and "confirm" it with two unusual customers.
Женя Шпика хорошо рассказал о том как делать custdev и да, неумение эффективно валидировать гипотезы ведет к принятию плохих решений и созданию “неправильного” продукта.
Мы потратили на Джинне три месяца на создание нового интерфейса инбокса для рекрутеров, который решал несуществующую проблему, потому что я не задал вовремя вопрос “какую задачу пользователя мы решаем”.
Good product managers clearly define product requirements -- in writing
Идея создания детального PRD (product requirements doc) в эпоху software-as-service и daily releases потеряла свою актуальность, но коммуникация с разработкой в виде письменных артефактов или видео – все так же важно.
Команде нужен референс, что мы делаем и зачем, к которому можно возвращаться снова и снова. Объяснения “на пальцах” работают только для тривиальных задач и там не всегда. Каждый раз, когда я ленился потратить полдня, чтобы сформулировать, что я хочу и зачем, я об этом жалел.
Bad product managers worry about specifying every feature in detail thinking they know more about how to solve a problem or how the product should behave or be architected.
“Описывайте проблему, а не решение” – хорошо звучит в теории, не всегда легко на практике. Часто требуется хорошее понимание продукта и возможностей (ограничений) команды, чтобы найти решение, которое сработает для нас.
Плохой ПМ описывает проблему так, что никак не помогает команде найти решение. “Я хочу больше наймов на Джинне” – wtf we supposed to do with that? Это как в анекдоте про успешного инвестора – “заработать на акциях очень просто, достаточно покупать дешево и продавать дорого”.
Good product managers have clear goals and can always explain how their product is better / different than the competition. Bad product managers have mushy goals and mushy product advantages.
Реальность рекрутинг рынка такова, что никому не интересен ваш продукт как продукт. Джинн стал успешным, потому что решал конкретные проблемы пользователей, а не из-за своих рюшечек или интересных дизайнерских решений.
Важно в процессе роста этот инсайт не потерять. E.g. чем Джинн отличается от LinkedIn сегодня, что мы можем сделать для пользователя, что LinkedIn не сделает никогда?
Good product managers know a handful of current and potential customers personally. Bad product managers don't care about individual customers.
Без эмпатии сложно построить хороший продукт. Когда у тебя есть “нетворк” доверенных пользователей, с которыми ты можешь быстро провалидировать какую-то гипотезу или быстро задать вопрос, это суперсила. На Джинне у нас есть dev chat в Телеграме, плюс я пушу разработчиков, чтобы у каждого был свой “мини-нетворк” контактов с лояльными пользователями.
Good product managers focus the team on revenue and customers. Bad product managers focus team on how many features Microsoft is building.
1) понять в чем проблема пользователя 2) придумать как ее решить 3) проверить, что решение работает 4) рассказать о нем пользователям – универсальный рецепт успеха.
Стратегия “сделать фичу Х потому что она есть у нашего конкурента” это тупик. Во-первых, вы всегда опаздываете и у вас нет дифференциации, во-вторых, вы никогда не знаете наверняка, успешную ли фичу вы копируете или она исчезнет в следующей версии.
Good product managers define good products that can be executed with a strong effort. Bad product managers define good products that can’t be executed or let engineering build whatever they want.
Здесь мне кажется супер важен технический бекграунд для ПМ, вдвойне если у нас продукт для ИТ-рынка. Без технической базы сложно понять, когда программисты тебя “булшитят” (не хотят делать и придумывают отмазки), а когда ты действительно хочешь невозможного и нужно искать другой путь.
Good product managers decompose problems. Bad product managers combine all problems into one.
Это очень интересный и очень ценный навык – умение раскладывать проблему на несколько более простых задач, которые можно делать по очереди.
Несмотря на все разговоры про SCRUM/Agile, большинство разработчиков и ПМ по прежнему живут в парадигме длинных циклов разработки. Вот идея, на ее реализацию нам нужно шесть спринтов по две недели, т.е. через три месяца мы узнаем сработает наша идея или нет. Скорее даже через пять, так как что-то всегда идет не так и эстимейты оказываются ошибочными.
Хороший ПМ придумает какие могут быть деливери каждую неделю или две. Это дает visibility проекта для компании, дает шанс заметить проблемы сразу, а не спустя три (пять) месяцев и возможность эффективного управления в т.ч. отмены проекта и переключения фокуса на другую задачу.
Good product managers err on the side of clarity vs. explaining the obvious. Bad product managers never explain the obvious.
Один раз объяснил и забыл – не работает. Важные вещи нужно повторять снова и снова, даже если все их “знают”. У всех у нас есть recency bias, когда самая “свежая” информация автоматически считается самой “важно”.
Если ты хочешь улучшить какую-то метрику в продукте, мало об этом рассказать один раз команде. Дашборд, ежедневный репорт в Slack, скриншот перед созвоном каждую неделю. А потом еще и подумать, как рассказать об этом по другому, потому что люди уже не замечают.
Good product managers focus their time in two areas: 1) tasks that are critical to their product success and 2) tasks that have a high impact on their business. Bad product managers put out fires all day.
Лучше и не скажешь. Весь мой блог об этом и это мой challenge каждый день. Startups are hard.
Fin.
Ссылки на эссе: