19. Мечты недостаточно, нужны навыки и скромность, чтобы учиться

Когда мне было 10, мы с другом мечтали собрать собственную машину. Бродили вокруг гаражей, искали на помойке выброшенные детали. Подолгу разглядывали чертежи ВАЗ 2106 в старой книжке. «Папа, я хочу собрать машину», – страстно заявлял я, проходящему мимо родителю. «Ага, ага», – отвечал он. В те времена сборка собственной машины была фантастикой даже для взрослого.

В наше время мотивационных коучей и историй про то «как Стив Джобс смог», много людей хотят сделать собственное приложение, сервис, продукт. Некоторые приходят ко мне за советом – юристы, риелторы, торговцы. Я пытаюсь объяснять азы продуктового менеджмента, но все чаще думаю, что мой папа был прав. Переубеждать «детей» бесполезно. А «взрослые» сами разберутся, что кроме веры в свою мечту, надо общаться с пользователями, тестировать гипотезы, разбираться в статистике. Ну, или признают, что знаний у них недостаточно и пойдут учиться.

20. Перевод на иностранный язык как способ улучшения текста 

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

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

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

————————————

История как мы облажались за 5 тысяч долларов, а потом исправились и повысили ретеншн. Три года назад нам в SEMrush написал SEO-эксперт Дэвид Амерланд: “Привет! Я только что закончил книгу по SEO и хочу продать вам права на распространение”. Мы согласились, договорились на 5000$. Стали думать, что с этой книгой делать, и появилась гениальная идея, дарить ее при переходе с дешевого тарифа за 100$ на дорогой за 200$. Запустили рекламную кампанию – тишина. 

И тут пользователи дорого тарифа стали задавать резонный вопрос: “Как я могу получить книгу, я уже на дорогом тарифе, мне некуда переходить?” Пришлось мне в рекордные сроки придумывать выход. У нас как раз появилось много новых инструментов для SEO, опытные пользователи их еще не распробовали. Мы сделали геймификацию: настрой 5 новых инструментов и получи книгу. Оформили в виде закрытого сейфа, который открывался, когда выполнил задание. А в сейфе книжка. Разослали предложение 4000 пользователей, 48% open rate, больше 900 настроенных инструментов. А с экспертом мы подружились.

——
Ольга Андриенко, ведущая канала @marketersdiaries
Head of global marketing SEMrush

21. Два принципа для улучшения любого процесса

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

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

1. Непосредственные исполнители должны быть лично заинтересованы в оптимизации процесса;

2. У них должна быть возможность этот процесс трансформировать.

Проверьте свою команду на соблюдение этих принципов.

22. Обучение через практику – самое быстрое

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

В 2011 году у меня было 15 вакансий для UX дизайнеров. Такого количества кандидатов не было на рынке труда. Пришлось открыть «Школу UX» и применить «американский» подход. Студентам ничего не объясняли, а давали практические задания. Они, естественно, косячили. Кураторы жестко, но конструктивно разбирали ошибки и указывали на области, которые нужно подтянуть. «Подтягивать» недостающие знания студенты должны были самостоятельно, мы им помогали крайне скупо. Кто-то обижался, кто-то просто не выдерживал темпа. Те, кто выдержал, теперь работают в ведущих компаниях мира.

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

В одной очень, очень большой компании новенькая сотрудница решила налить себе кофейку. Рабочий день уже начался, но обед еще не наступил. Подходит барышня к кофейному аппарату, а там её начальник. И что-то у него с аппаратом не клеится, не дает подлая техника начальству кофею испить. Ну, барышня, добрая душа, и говорит: “А давайте я вам помогу кофе налить?” А он ей в ответ: “Знаете, сейчас еще не обеденный перерыв. И я ожидаю, что вы не кофе пьете, а работаете. Кофе пейте либо до начала рабочего дня, либо в обед, либо после окончания работы”. 

Барышне после этого уже не то что кофе не хочется – вообще ничего не хочется. И вы, конечно, скажете, что руководитель должен мотивировать своих сотрудников, а не вести себя как идиот. И нафиг такой руководитель вообще нужен. А я скажу, что нафиг нужен руководитель, который кофейный аппарат победить не может.

——
Сергей Колганов, автор канала об управлении проектами и продуктами @psilonsk

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. За статистикой не видно пользователей

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

Я внимательно отношусь к статистике продукта. Когда ко мне прибегает молодой коллега с фидбэком от пользователя, я снисходительно говорю: «Ну, батенька, это просто мысли одного человека, они не так важны, давай лучше смотреть на статистику». Глядя на неудачную спортивную площадку, я подумал, что статистика у нее прекрасная. Ее посещает много народа, она популярна. Хорошая статистика соседствует с отсутствием здравого смысла. Я испугался, а вижу ли я за статистикой простых пользователей? Вдруг они вынуждены кастомизировать наш продукт с помощью автомобильных покрышек!