Притчи продуктолога

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

Видео на 16 минут: https://youtu.be/luojAZvHqIc

44. Самый большой баг в твоем продукте

В продуктовый менеджмент я пришел из дизайна и UX. Я всегда очень гордился своей дотошностью и вниманием к мелочам. Старался, чтобы мои продукты были удобными и красивыми, все баги исправлены, а пользователи счастливы. Когда находил ошибку или просто не элегантное решение в продуктах Гугла или Яндекса, сочинял мысленные послания их HR-ам: «Вы катитесь в пропасть, не видите очевидные косяки, но я могу вас спасти, я – гениальный дизайнер, возьмите меня на работу и все у вас наладится».

При запуске своего первого по-настоящему взрослого продукта я бескомпромиссно боролся за качество. Задерживал релизы, чтобы исправить все баги. И тогда мой босс сказал фразу, которую я помню спустя 15 лет: «Самый большой баг – это если о нашем продукте никто не узнает». Эта простая фраза очень зацепила меня и помогла измениться. Спустя годы я узнал про Agile, MVP и принцип «ошибиться скорее». Но фраза про самый большой баг в продукте до сих пор кажется мне самой точной.

43. Не надо смиряться с убожеством

Летом я люблю прокатиться на мотоцикле по извилистым дорогам Карельского перешейка. По пути встречаю множество дач. Самый популярный тип забора – из профнастила. Выглядит чудовищно. Человек уехал из города на природу, построил дом, насадил газон и цветник. Сидит наслаждается природой, уткнувшись носом в железную стену, окрашенную в далекий от природы цвет. Абсурд. Однако мини-опрос, проведенный среди знакомых дачников, показал, что хозяева считают это нормой.

В цифровом мире тоже встречаются некрасивые решения, кажущиеся нормой. Для подтверждения операции ВТБ присылает одноразовый пароль из шести цифр. Запоминать и вводить его гораздо сложнее, чем 4 цифры у Тинькофф банка. Четырех цифр достаточно для безопасности. Другой пример. В 2008 году я выступал на UX Russia, рассказывал о нашей платежной системе, где можно совершать переводы с мобильного без регистрации. Был только одноразовый подтверждающий пароль. Из зала посмеялись и сказали «ваш прототип не одобрят безопасники». Я ответил: «Это не прототип, это в продакшене». Неэстетичный забор из профнастила можно заменить красивым функциональным аналогом за те же деньги. Не надо смиряться с убожеством.

#партнерскийпост написанный мною лично с большой любовью.

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

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

Epic Growth Premium – это подписка на кейсы роста от самых быстрорастущих компаний России и Кремниевой долины: Miro, Amplitude, GrowthX, Salesforce, Revolut, Яндекс.Такси и других лидеров Apple и Google Store. В докладах – конкретика с цифрами о том, как растить метрики продуктов.

Подписка дает возможность развивать свои профессиональные связи через участие в закрытом продуктовом чате, Random Coffee, участие в Q&A с экспертами по продукту.

Стоит недорого, 990 руб. Первая неделя бесплатно: https://bit.ly/3hmNhnR

42. Глава продукта должен иметь хороший вкус

В двухтысячных я работал дизайнером в платежной системе для мобильных. Поэтому начал проектировал UX для смартфонов, когда это еще не стало мейнстримом. Тестировал на ныне покойных Windows Mobile, Symbian и только что появившейся iOS. Интерфейс айфона резко выделялся на фоне конкурентов удобством, эстетикой и целостностью. Я был убежденным линуксоидом и презирал эппловскую продукцию (довольно странно для дизайнера). Но iOS так сильно выделялась на фоне конкурентов, что не признать качество ее интерфейса было сложно.

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

41. Умение говорить с людьми на их языке

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

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

#спецвыпуск – My First Product
Профессия продуктового менеджера сейчас популярна. Многие интересуются, как стать продактом, где получить первый опыт. Мы с коллегами, авторами телеграмм-каналов о продуктовой разработке, решили сделать серию постов, чтобы ответить на эти вопросы. Принял эстафету от Владимира Меркушева, менеджера продукта в OLX Europe, автора канала @vladimir_merkushev. А вот моя история:
————————————

40. Как я стал менеджером продукта два раза, но не знал, что это так называется

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

В 2007 году стал работать в платежной системе МОБИ.Деньги. Устроился дизайнером, но довольно быстро стал проводить юзабилити-тестирование и делать то, что сейчас называется UX. И чтобы мои интерфейсы делали хорошо, стал тимлидом команды разработки веб-интерфейса. Общался с пользователями, придумывал новые фичи, решал проблемы, помогал саппорту, отслеживал статистику. Делал почти все, что делает современный продакт. Разве что про юнит-экономику тогда никто не слышал.

Я стал работать продуктовым менеджером задолго до того, как официально получил такую должность. Да и профессии такой в России тогда не было. Но разве это важно?

————————————
Эстафету передаю Ярополку Рашу экс-продакт директору в Wargaming, автору канала @YRPLK и Алине Вербенчук Product GTM Lead в Youtube и основательнице проекта про карьеру в tech индустрии, канал @verbetcetera

39. Люби свою паранойю (только на работе)

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

Больше месяца делали сложный эксперимент в нашем продукте. Наконец все было готово и одобрено QA. Я доверяю своей команде, но паранойя подсказала мне, что нужно протестировать самому. Естественно я нашел много багов, их быстро поправили. После релиза все испытывали душевный подъем, праздновали и расслаблялись. Паранойя подсказала мне, что нужно все перепроверить еще раз. Я быстро нашел серьезную проблему и собрал экстренное совещание, чтобы решить, как ее исправить. Тревога оказалась ложной, коллеги смотрели осуждающе. Мы с паранойей решили не обращать внимания и пошли копать дальше. Естественно нашли еще.

38. Количество потраченного времени никак не влияет на результат

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

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

37. Менеджер может заставить делать чушь, но недолго

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

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

36. Не давайте советы, когда не спрашивают

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

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

35. Личный пример заразителен – и плохой, и хороший

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

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

Рубрика #УголокТщеславия. На канале, который я регулярно читаю, «Продукторий Владимира Меркушева» вышла подборка продуктовых каналов, в которую попал и мой скромный канал. Оказалось Владимир регулярно помогает молодым каналам и делает это абсолютно бесплатно. Что, конечно, очень приятно. Вот канал Владимира, сам читаю и вам советую: @vladimir_merkushev

34. За статистикой не видно пользователей

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

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

33. Формируй ожидания внутренних заказчиков заранее

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

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

32. Работу надо не только сделать, но и продать

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

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

31. Иногда стоит прикинуться дурачком

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

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

30. Релиз не должен откладываться

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

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

29. Зачем вам нужен технический бэклог

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

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

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

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

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

28. Технический долг – «что делать»

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

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

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

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

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

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

Помните, любой долг берется легко, а отдается сложно.