Притчи продуктолога
1.33K members
8 links
Концентрированная мудрость о менеджменте продуктов и построении команды. Заметки выходят по вторникам и четвергам.

Алексей Рытов @aleksritov сайт: http://ritov.ru
Продакт в SEMrush, ex CEO «Аренда без посредников», ex Chief UX в Digital Design.
Download Telegram
to view and join the conversation
23. Продакт – это и есть главный юиксер

На нашу конференцию Global Marketing Day регистрировались так: пользователь заполнял форму и получал письмо со ссылкой на завершение регистрации. Посыпались жалобы, что ссылка выдает ошибку. Проблему долго не могли воспроизвести ни QA, ни разработчики. Наконец я внимательно сопоставил письма пользователей о проблеме и логи их сессий и разгадал ребус. Оказалось, пользователи начинали регистрацию с десктопа, а заканчивали на айфоне. В этом случае Айфон открывал подтверждающую ссылку с ошибкой. 

Мы тестировали по отдельности и на десктопе, и на мобильном, а в реальной жизни люди используют их совместно. Для меня такие истории – пример настоящего UX. Его сложно спроектировать заранее. Такие ситуации можно отловить, только внимательно наблюдая изо дня в день за боевым проектом. Обычно этим занимается менеджер продукта, он глубже всех погружен в UX. По этой причине 7 лет назад я перестал рисовать интерфейсы и сосредоточился на продуктовом менеджменте.
24. Умение нанимать людей на работу – базовый навык

Моя команда недавно переключилась на другой продукт. За три месяца нам пришлось найти, нанять и обучить команду себе на замену: менеджер, 2 бэкенд разработчика, 2 фронта и QA. Умение проводить собеседования и нанимать коллег – это базовый навык каждого в продуктовой команде. Нам помогают такие советы:

1. Пишите текст вакансии сами. Простым человеческим языком про ваш продукт. Не надо доверять это HR-ам, они пишут стандартные корпоративные тексты, от которых всех тошнит.

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

3. Наладьте обратную связь с рекрутерами. Чтобы не было ситуации, когда рекрутер присылает миллион неподходящих кандидатов, а разработчики неделями не отсматривают присланные резюме.

4. Не ходите на собеседование всей командой одновременно. Но каждый в команде должен уметь проводить собеседование и оценивать не только технические, но и софт-скиллы. Если кто-то из команды не умеет – обучайте.

5. Умейте «продать» свой продукт кандидатам. Хорошие специалисты нужны везде, у них часто по несколько офферов на руках. Продавая свой продукт, не врите и не приукрашивайте. Вам нужен коллега на годы, а не на пару месяцев.

Сохраняйте терпение и оптимизм.
Пятничная рубрика #БайкаОтПродакта. Забавные истории из жизни профессионалов продуктовых компаний. Написать может любой желающий.
————————————

Как-то раз я решил почистить наш аккаунт в Mailchimp (инструмент для email рассылок) от устаревших аудиторий, подписчиков и писем. Остановил автоматические рассылки, удалил лишнее, объединил несколько аудиторий и включил заново автоматическую воронку писем, которую мы шлем всем новым пользователям.

На следующее утро смотрю аналитику – рекорд по продажам. Начинаю искать причины. В продукте ничего не меняли. Захожу в Mailchimp и понимаю, что по ошибке отправил первое письмо рассылки всем старым пользователям. Тем, кто такое письмо уже недавно получал, и для кого оно должно быть неактуально. Оказалось наоборот. По ошибке провел удачный эксперимент. Как говорил Макиавелли: фортуна – подруга отважных.

——
Иван Палий, продакт менеджер в Sitechecker, канал @sitecheckerpro
25. Учитесь увольнять людей

У нас в SEMrush команды разработки сами нанимают и увольняют людей. За последние годы я работал с двумя командами. Одна умела увольнять и жила замечательно. Другая не умела и столкнулась с кучей проблем, как технических, так и личных. Плохие сотрудники парализуют работу. Они пишут ужасный код, который годами будет пить кровь даже после их ухода. Они делают работу всей команды невыносимой. Иногда нужно уволить одного человека, чтобы сохранить команду и обезопасить продукт.

Люди боятся увольнять коллег: «Ну как же, мы на тимбилдинге тусили и в кикер на обеде играли». В этом вопросе нам сложнее, чем компаниям,  где увольняет злой менеджер. Я вдохновляю свою команду словами, что увольнение – от слова «воля». Уволенный программист не будет просить милостыню у метро, а быстро найдет работу и все у него будет хорошо. Не бойтесь увольнять людей, промедление дорого вам обойдется.
26. Теория не должна сильно опережать практику

В советские времена родственница работала охранницей в ДК. В основном пила чай на вахте. Однажды она удивила меня цитатой из устройства револьвера Нагана: «Спусковой крючок служит для спуска с боевого взвода, для поднимания и опускания ползуна собачки и для отодвигания барабана после выстрела». Оказалось, она каждый год сдает экзамен на знание револьвера. Я был поражен и уточнил, как часто ей выдают оружие. Она посмеялась и сказала, что никогда в жизни его даже в руках не держала.

Много примеров, когда люди учат и успешно сдают предмет, при этом ничего в нем не понимая. В русских школах изучают сложные английские времена, но большинство школьников с хорошими отметками не способны общаться на английском даже на бытовом уровне. Профессия продуктового менеджера сегодня на хайпе. В наличии множество прекрасных статей, вебинаров, митапов и конференций. Обучаться можно и нужно. Главное следить, чтобы твои теоретические навыки не опережали практику на два порядка.
Пятничная рубрика #БайкаОтПродакта. Забавные истории из жизни профессионалов продуктовых компаний. Написать может любой желающий.
————————————

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

Но потом коллективный разум прозрел и мы поняли, что нет смысла бороться за сокращение времени модерации – мы просто убрали все упоминания о ней из интерфейса. Для рекламодателей выглядело так, что их задание на рекламу сразу можно предлагать любому блогеру. Само собой, блогеры видели задания только после модерации. Упали отказы, выросло удержание, а главное, количество сделок между пользователями. Наверное, это самый хитрый гросхак KPI, который был в моей жизни.

——
Владимир Миролюбов, основатель платформы для самообразования «Единорог», канал @ruspm
Рубрика #УголокТщеславия. В порыве мании величия пару месяцев назад я решил публиковать «Притчи продуктолога» на английском языке. Текст это скорее литературный, поэтому я даже не пытался переводить сам и поручил это нелегкое дело прекрасной и умнейшей Марии Вилиной. Английская версия называется Tales of a Product Owner и выходит на Медиуме: https://medium.com/@aleksritov

Читателям оригинальной русской версии будет не очень интересно, потому что английская версия выходит с отставанием на два месяца. Но если вы хотите насладиться прекрасным британским языком, подписывайтесь. А еще посоветуйте, пожалуйста, в личку, в каких пабликах Медиума лучше размещать такой формат.
27. Технический долг – «кто виноват»

Несколько лет назад мы с командой накопили такой технический долг, который полностью парализовал развитие продукта. Любое изменение приходилось делать неделями, и оно порождало множество ошибок. Команда была деморализована, начались ссоры. Выяснение отношений на ретроспективе помогало слабо. Продукт перестал развиваться, представители бизнеса выражали обеспокоенность все чаще. Встал вопрос «кто виноват». Scrum говорит, что я как Product owner отвечаю за продукт, а техническая реализация, включая технический долг – это ответственность команды.

Я смотрю на это иначе. Продакт овнер – на то и «овнер», что отвечает за всё, что влияет на продукт. Я как старый дед постоянно ворчал, что надо заниматься техническим долгом и архитектурой. Но дальше слов и призывов взяться за ум дело не шло. Я был обязан предвидеть коллапс и принять меры. Какие именно, расскажу в следующей притче. Главная мысль этой: продуктовый менеджер отвечает за всё, даже за что он не отвечает.
28. Технический долг – «что делать»

Наверняка вы знаете, как устроены кредитные карты. Вы берете в долг у банка, потому что не хватает своих денег или вам так удобнее. У вас есть месяц-другой грейс периода, когда можно не отдавать долг. Если не успели погасить долг в течение грейс периода, придется выплачивать проценты. Можно отдавать очень медленно, но проценты будут расти как снежный ком.

С техническим долгом работает также. Вы торопитесь выпустить новые фичи и берете в долг у «себя из будущего». Какое-то время долг не мешает жить, но постепенно дает о себе знать. Потом критично накапливается и доводит до банкротства. Понять «что делать» помогут банковские практики:

1. Правильно оценить объем долга. Это самое сложное. Как сделать, расскажу в следующей притче.

2. Утвердить график выплаты долга. Выплаты должны быть регулярными и равномерными.

3. Если «платеж» просрочен, организовать серьезный разговор. Как это делают банки.

4. Если «платеж» просрочен несколько раз подряд – вызывать коллекторов. В нашем случае – вводить внешнее управление командой разработки.

Помните, любой долг берется легко, а отдается сложно.
29. Зачем вам нужен технический бэклог

У продукт овнера и команды разработки конфликт. Овнер топит за новые фичи, разработчики требуют время на рефакторинг. Технической частью часто жертвуют и плодят технический долг. Проблема не в жестоком мире бизнеса, а в неумении программистов вести технический бэклог. Обычно он состоит из задач типа «Отрефакторить контроллер». Польза таких задачи не очевидна продукт овнеру. Вот принципы для превращения разрозненных задач в бэклог:

1) ПОЛЬЗА. Задачи должны быть объединены в эпики, у каждого эпика – внятное полезное действие. Плохой эпик: «Отрефакторить сборку проекта». Хороший: «Ускорить сборку с 5 минут до 20 секунд». Плохой: «Переписать JS». Хороший: «Ускорить время разработки нового отчета с 2 недель до 1 дня».

2) ОЦЕНКА. Каждая задача по отдельности и состоящие из них эпики технического бэклога должны быть оценены в тех же единицах, что и ваш продуктовый бэклог. Store points, S/M/L, идеальные часы – не важно, главное оценить.

3) РЕГУЛЯРНОСТЬ. Работа над техническим бэклогом должна быть регулярной активностью в календаре. Наша команда собирается на полуторачасовой технический груминг раз в две недели.

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

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

Мы с командой регулярно показываем результаты нашей работы всей компании. Это называется «демо». Демо стоит на двух столпах: оно регулярное, его даты не переносятся; новый функционал, что мы показываем, должен быть доступен обычным пользователям, никаких тестовых серверов. Никто не оштрафует и не поругает команду, если мы ничего не покажем на демо. Но мы каждый раз изо всех сил стараемся успеть как можно больше. Если не успеваем к сроку, то думаем, как упростить, чтобы успеть. Откладывание релизов – самое страшное, что случается в разработке программного обеспечения.
31. Иногда стоит прикинуться дурачком

Много лет назад я работал руководителем модного тогда SMS-направления в крупной промышленной компании. В процессе работы оказалось, что в компании есть дресс-код, требовалось ходить в костюме и галстуке. И главный ревнитель этого – мой непосредственный начальник. Костюмы и галстуки я люто ненавидел еще с пионерского детства. Поэтому эти требования игнорировал. Ходил на работу в черных джинсах и рубашке. Босс регулярно меня за это ругал. Я был близок к отчаянию. Тогда мой родственник научил меня великолепному приему. Он сказал: «Ты не бычь, не пытайся конфликтовать, а просто затупи и прикинься дурачком».

Когда большой и страшный босс стал в очередной раз спрашивать меня, где мой галстук, я стал «жевать сопли», что-то бормотать, вздыхать и разводить руками. Глядеть на это ему быстро надоело и он сказал: «Ладно, чего там у нас по статусу проекта». Постепенно он отстал от меня, тем более, что с рабочими обязанностями я справлялся хорошо.
32. Работу надо не только сделать, но и продать

Однажды моя жена полдня готовила шикарный ужин. Когда сели есть, сын сказал: «Фу, гадость, я не буду это есть». Естественно жене было обидно, она вложила много сил, а получила в ответ чёрную неблагодарность. Кажется, в этой истории очевидно, кто прав, кто виноват. Однако похожий случай на работе заставил меня иначе взглянуть на ситуацию.

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

Как-то раз я купил сыну журнал, который он любит. Зайдя домой, объявил с порога: «Сынок, у меня для тебя подарок». Получив журнал, он здорово расстроился. Услышав слово «подарок», воображение нарисовало ему новый смартфон. Парадокс: получил что-то хорошее, но почувствовал разочарование. Все дело в несоответствии ожиданий и реальности.

Раньше я регулярно запускал проекты для маркетологов. Пара сотен человек внутри компании были очень заинтересованы в результате. У каждого было мнение и свой взгляд на дизайн, которые я должен был учесть. Чтобы меня не растерзали в коридоре, я начинал формировать ожидания заранее. Рассылал на всю компанию эскизы дизайна и просил прислать любые замечания и предложения. Собирал очные встречи для всех желающих, чтобы обсудить дизайн. В какой-то момент все, кто хотел донести свое мнение, просто выдыхались. К моменту релиза эмоций на обсуждение дизайна ни у кого не оставалось. Не важно, нравилось им изначально или нет, в результате они привыкали. Их ожидания были сформированы заранее.
34. За статистикой не видно пользователей

У меня во дворе сделали баскетбольную площадку. Дорогую, качественную. Несколько месяцев я из окна наблюдал, как ее ровняют, засыпают песком, трамбуют гравий, укладывают резиновое покрытие. После открытия местные пацаны принесли старые автомобильные покрышки, сделали ворота и стали играть в футбол. Баскетбол они видели в гробу.

Я внимательно отношусь к статистике продукта. Когда ко мне прибегает молодой коллега с фидбэком от пользователя, я снисходительно говорю: «Ну, батенька, это просто мысли одного человека, они не так важны, давай лучше смотреть на статистику». Глядя на неудачную спортивную площадку, я подумал, что статистика у нее прекрасная. Ее посещает много народа, она популярна. Хорошая статистика соседствует с отсутствием здравого смысла. Я испугался, а вижу ли я за статистикой простых пользователей? Вдруг они вынуждены кастомизировать наш продукт с помощью автомобильных покрышек!
Рубрика #УголокТщеславия. На канале, который я регулярно читаю, «Продукторий Владимира Меркушева» вышла подборка продуктовых каналов, в которую попал и мой скромный канал. Оказалось Владимир регулярно помогает молодым каналам и делает это абсолютно бесплатно. Что, конечно, очень приятно. Вот канал Владимира, сам читаю и вам советую: @vladimir_merkushev
35. Личный пример заразителен – и плохой, и хороший

До 14 лет я жил в СССР. Одно из самых ярких и неприятных воспоминаний – хамящие продавщицы, работники почты, сотрудники поликлиники. Хамство, синдром вахтера, самодурство – все это казалось дурным советским наследием, которое развеется как ночной кошмар, как только эти наглые тётки уйдут на пенсию. Прошло почти 30 лет, но типаж никуда не делся. Юмористы до сих пор часто обыгрывают ситуации на почте и сбербанке, а они шутят только о злободневном. Конечно, отношение к людям в кафе и магазинах сильно изменилось. Но советский хамоватый стиль общения жив и развивается в гос. организациях. Самое забавное, что теперь так общаются молодые девушки, родившиеся после распада СССР.

Стиль общения в вашей компании никак не зависит от документов и писаных норм. Никакие «кодексы поведения сотрудников» или увещевания HR ничего не изменят. Единственное, что влияет на стиль поведения работников – пример старших товарищей. Если начальство и ключевые сотрудники компании общаются уважительно, выдают объективный фидбэк, честно рассказывают о проблемах, улыбаются при встрече – этот стиль подхватят все молодые сотрудники. Личный пример – единственный способ построить хорошую атмосферу. И плохую тоже.
36. Не давайте советы, когда не спрашивают

Лет десять назад я потолстел. Прошел все стадии от отрицания до принятия проблемы. Разобрался с диетологией, сбросил лишние килограммы и живу счастливо. Побочным эффектом стало то, что я возомнил себя специалистом по питанию. Стал раздавать советы при любом удобном случае. Однажды на конференции во время кофе-брейка увидел знакомую, которая собиралась съесть печеньку, и прочел ей лекцию о том, что происходит, когда ешь сладкое на голодный желудок. Девушка молча выслушала, поблагодарила и ушла. О, каким идиотом я себя почувствовал. Зачем я впаривал ненужные знания человеку, который меня ни о чем не спрашивал! Мне хотелось провалиться от стыда.

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

В начале всеобщего карантина по короновирусу я лежал в больнице. С вирусом моя болезнь, да и вся больница никак не связаны. О речи президента, что все должны сидеть по домам, я узнал от охранника больницы, когда пошел забирать у курьера еду. «Завтра доставку к тебе уже не пущу», — сказал охранник. Утром двери больницы были закрыты на импровизированный засов, сделанный то ли из старой швабры, то ли из древка советского знамени. Я понял, что вкусняшек мне не видать и придется есть невкусную столовскую еду. Однако через несколько часов двери больницы открыли – оказалось, что людям надо где-то курить. Курьеры же успешно передавали заказы, не заходя на территорию – забор был невысоким.

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

Когда я был маленький, мой папа много работал. Рано утром он уходил на гигантскую электростанцию, где был замом главного инженера и возвращался домой поздно вечером. Мама была недовольна и считала, что сын не видит отца. Спустя 30 лет, глядя, как я играю с моим сыном, она сетует: «А вот твой отец не играл с тобой, вечно на работе пропадал». Я с этим категорически не согласен. У меня прекрасные воспоминания о наших играх в детстве. Возможно, этого времени было немного, но оно было качественное. 

Самое глупое, что может сделать менеджер – оценивать сотрудников по количеству отработанных часов. Я работал с программистами, которые проводили на работе по 10-12 часов каждый день, были преданы проекту и работали в полную силу. А потом оказывалось, что их код работает плохо, развивать его невозможно и надо все выкинуть. Но также я работал с программистами, кто постоянно тусил в чатах, играл в кикер и вечно пил кофе. Приходил после 12 и уходил в районе 18. При этом результаты их работы были великолепны. Если вам вдруг хочется поругать коллегу за то, что он мало работает – остановитесь. Говорите о результатах, а не о времени.