150. Сначала практика
 
Больше двадцати лет назад в питерском троллейбусе ехал молодой человек и читал толстенную книгу Photoshop 5.0. Прочитанное поражало его, иногда он восклицал: «Невероятно! Не может быть!» Этим молодым человеком был я. К этому моменту я уже год работал в Фотошопе и даже заработал свои первые деньги как дизайнер.
 
Тогда я только закончил институт и работал инженером-электриком. На моем рабочем компьютере был установлен пиратский Фотошоп. Я вспомнил детскую мечту стать дизайнером и начал ретушировать фотографии. Интернета у меня не было, Ютуб еще не изобрели. Поэтому я просто пробовал разные инструменты, жал кнопки и пытался разобраться, как это работает.
 
Для ретуши старых испорченных фотографий основной инструмент в Фотошопе – это Штамп. Я не понял, как он работает и поэтому ретушировал фотографии без него. Ретушировал успешно, потому что научился эмулировать работу этого инструмента через инструмент Лассо и горячие клавиши. Поэтому когда я прочитал в книге, как работает инструмент Штамп, я был поражен, обрадован и жутко смущен. Я понял, как глупо я работал последний год.
 
С одной стороны это история, что надо сначала освоить хотя бы основы теории и только потом приступать к практике. С другой стороны, вспомните, как многому вы учились в институте, на конференциях, прочли в книгах, но давно уже позабыли, потому что не применяли на практике.
 
Принцип «сначала практика, потом теория» – отлично работает. Хотя применим не во всех профессиях – надеюсь, что хирурги ему не следуют.

149. Метрика под микроскопом
 
Недавно я писал, что неправильно смотреть на все-все метрики при проведении эксперимента, а лучше выбрать одну-две важных и ориентироваться только на них. Хочу дополнить, когда вы выбрали ключевую метрику, копните ее глубже. Посмотрите на нее под микроскопом.
Проводили мы эксперимент, ключевой метрикой выбрали MRR. Эксперимент и контрольная группа не показали стат. значимых различий. Т.к. эксперимент был про новый дизайн с установкой «не сделать хуже», то результат «MRR остался таким же» означал победу эксперимента.
 
Мы решили посмотреть на MRR внимательнее. Посмотрели распределение по странам, по периоду подписки, по источникам трафика. Все было одинаково, кроме распределения по тарифам. Есть три тарифа: дешевый, средний и дорогой.  Экспериментальная группа опередила контрольную по дешевому тарифу, но проиграла по дорогому. По среднему – были равны.
 
Что делать? По дешевому тарифу эксперимент выиграл, по дорогому проиграл, суммарно вышло одинаково. Мы решили, что дорогой тариф нам важен и признали эксперимент проигравшим. Хотя изначально оно казался победителем. Рассматривать метрику под микроскопом оказалось полезным занятием.

148. Ошибаться профессионально
 
В сериале Devs был супер-пупур компьютер, способный просчитать квантовую неопределенность каждой молекулы во вселенной. В общем, он мог увидеть прошлое и предсказать будущее. Пока таких компьютеров не существует, просчитать всё – невозможно. Из-за этого возникают проблемы в куче профессий.
 
К счастью, лечение зубов или строительство дома – вещи, которые можно просчитать достаточно точно, поэтому мы спокойно спим по ночам. Но в профессии продуктового менеджера или UX-дизайнера – все просчитать невозможно. Да, мы активно используем статистику и опираемся на данные, но они лишь служат для проверки наших выдуманных из головы гипотез. Стальной каркас наших знаний опирается на зыбкую почву субъективных суждений и везения.
 
Раньше я думал, что любитель не знает, как нужно делать хороший продукт и мыкается впотьмах. А профессионал знает и делает. Больше я так не думаю. Ни профессионал, ни любитель не знают, как сделать хороший продукт, удобный интерфейс или прибыльный бизнес. Они могут лишь попробовать, ошибиться и попытаться исправить всё при следующей попытке.
 
Разница между любителем и профессионалом в том, что профи сможет добиться хорошего результата за меньшее количество попыток, потратит на это меньше времени и ресурсов.
 
Мы – профессиональные ошибальщики.

147. Сходи на собеседование
 
Кажется, что ходить на собеседование нужно только, чтобы получить работу. Но даже если вас не взяли, это все равно полезно. 
 
Можно подглядеть в другую компанию, как они нанимают на работу, какие вопросы задают. Узнать, как у них построена статистика и разработка. Ничего тайного не подглядишь, но сможешь познакомиться с интересными людьми и узнать о полезных практиках из первых рук. Иногда после собеседования можно с удивлением понять, что «моя текущая компания самая классная».
 
А еще это ускромняет. Работаешь годами в одной компании, тебя все знают, уважают. Постепенно у тебя складывается чувство, что ты незаменим, гениален и невероятно крут. А когда приходишь на разговор в другую компанию, то там ты – никто. Тебе задают вопросы с пристрастием, приходится доказывать свою компетентность. Это отрезвляет.
 
Не призываю ходить на собеседования постоянно, но раз в год – неплохая разминка. Естественно, не нужно никого обманывать. Если вас приглашают на собеседование, но при этом вы не ищите работу, то можете так и сказать: «Работу не ищу, но если хотите познакомиться и пообщаться, то я готов».

Не все зависит от тебя
 
В 2013 году мои друзья предложили мне возглавить стартап по аренде квартир без посредников. К тому времени у меня уже был опыт в запуске качественных и при этом дешевых в производстве продуктов. 
 
Суть стартапа: в Москве и Санкт-Петербург сдается множество квартир, при этом 85% объявлений – от агентов, которые просят месячную цену аренды за свое посредничество. Мы решили собирать объявления собственников квартир из открытых источников (Вконтакте, форумы и т.п.) и публиковать их у себя. Нашей фишкой стала практически идеальная чистота базы – больше 95% объявлений от собственников (например, на Авито их всего 15%). 
 
Большую часть работы в компании делал лично я: брендинг, айдентику, касдев, UX/UI, менджмент продукта, найм и обучение персонала, маркетинг, рекламу, финансы. Программистов (сервер, iOS, Android) брали временно, на сдельную оплату. Также постоянно работало 4 модератора объявлений. Все работали удаленно из разных городов и стран. 
 
Мы запустились сразу на двух платформах: iOS и Android. Через полгода приложения были в ТОП-3 в App Store / Play Market по всем «квартирным» запросам. Через год стартап вышел на операционную безубыточность. И тут случился кризис, рубль обвалился и это отразилось на продаже мобильного приложения. 
 
После этого приложение просуществовало еще два года. Я оптимизировал все процессы, несколько раз менял цены, но серьезного роста выручки достичь не смог. Рынок мобильных пользователей в те годы был намного меньше, чем сейчас, и мы выпили его досуха. А для расширения на другие платформы нужны были инвестиции, которые я не смог найти. 
 
В результате через три года успешной работы, я закрыл приложение. Убытков оно не приносило, но и прибыли добиться не удалось. Эта история научила меня, что не все зависит от тебя. Ты можешь работать за семерых, добиться хороших показателей даже при минимальных ресурсах, но все равно не получить коммерчески успешный продукт.

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

145. Первый вопрос на собеседовании
 
Есть большая ошибка, которую совершают почти все HR-ы. Первым делом они спрашивают: «Расскажите о себе?»
 
Тот, кто пришел на собеседование – гость. Как правило чувствует себя волнительно и неловко. Тот, кто интервьюирует – «хозяин», это его компания, обычно он уверен в себе и чувствует себя немного вершителем судеб. Получается, что соискатель эмоционально в более сложной ситуации. 
 
Первым вопросом просить гостя рассказать о себе – это невежливо. Когда я провожу собеседование, то всегда рассказываю первым: что у нас за продукт, почему нам нужен новый человек, чего мы от него ждем. Только после этого прошу соискателя рассказать о себе.
 
Плюсы такого подхода:
 
1. У соискателя есть время прийти в себя и почувствовать, что принимающая сторона уважает его.
 
2. Когда он будет рассказывать о своем опыте, он расскажет то, что релевантно вашим задачам и опустит лишнее. Да, есть риск, что он использует полученную от вас информацию и наврет с три короба. Но я принимаю этот риск.
 
3. Когда у вас закончится встреча, обе стороны переговоров гарантированно выскажутся. Ведь бывает, что кандидата час мучают каверзными вопросами, а потом встреча заканчивается и на вопросы соискателя времени не остается. 
 
Сегодня ты нанимаешь человека на работу, завтра он тебя. Скромность и вежливость не повредят.

144. Исправление очевидных ошибок
 
Когда я работал UX-дизайнером, я постоянно замечал плохие интерфейсные решения в чужих продуктах. Пишешь письмо в Gmail и видишь явный косяк. Я даже думал в Гугл устроиться на работу, чтобы исправить их проблемы.
 
Раньше я думал, что большие компании не правят очевидные проблемы из-за приоритетов. Невозможно исправить все, надо сохранять фокус на важном. Это так, но не всегда.
 
Недавно оптимизировали одну продуктовую страницу, через которую проходит много пользователей. Сделана она была очень давно, содержала много очевидных проблем. Мы исправили интерфейсные ошибки и частично автоматизировали взаимодействие с интерфейсом. При этом постарались не менять страницу слишком радикально, целью был легкий тюнинг и исправление очевидных недоработок.
 
Изменения относительно небольшие и очевидно полезные, иногда мы подобное запускаем без всяких экспериментов. Но страница очень посещаемая, поэтому решили запустить А/Б-эксперимент, чтобы убедиться, что «как минимум стало не хуже». 
 
Новый удобный и красивый вариант проиграл старому неудобному. Да, он лучше вовлекал пользователей в продукт и получил хорошие метрики по активности пользователей. Проблема в том, что он так хорошо вовлекал в одну часть продукта, что другая осталась без пользователей. В итоге новый вариант проиграл по выручке.
 
Исправление очевидных UX-ошибок не всегда приводит к хорошим результатам.

143. Невозможно все успевать
 
В девяностые я пытался стать великим рок-гитаристом. Пытался подбирать на слух соло Led Zeppelin и прочих великих. Получалось плохо, потому что слушал я на кассетном магнитофоне, нельзя было замедлить, неудобно перематывать. Сейчас на Ютубе можно найти детальный разбор любого соло. Иногда даже сам автор объясняет и показывает с 10 ракурсов. В молодости я так мечтал о подобном, но не получил.
 
Теперь я столкнулся с обратной проблемой – полезной информации слишком много. По любой профессии есть множество материалов – статьи, курсы, подкасты, туториалы, митапы, вебинары, каналы. И они качественные! Я был подписан на двадцать хороших каналов про менеджмент продуктов, дайджест продуктового дизайна Юрия Ветрова, подборки на VС и Хабре, записывался на вебинары и просил дать доступ «по-знакомству» на онлайн конференции. С особой любовью у меня лежала стопка непрочитанных бумажных книг (электронные давно перестал считать).
 
Успевал ли я это все читать, смотреть, изучать? Конечно нет! От этого я чувствовал вину и профнепригодность. Материалы действительно качественные и полезные. 
 
Однажды я признался, что все успеть невозможно. Я отписался от большинства источников профессиональных знаний. И решил, что не буду себя винить, если не успеваю что-то изучить. С отдельной болью я отписался от прекрасного Дайджеста продуктового дизайна. Прости Юра. 
 
На собеседованиях я иногда спрашиваю: «Как профессионально развиваешься, что читаешь?» Как бы я сам ответил на этот вопрос? Пожалуй: «Больше всего я учусь в текущих проектах, над которыми работаю».

142. Определись с метриками заранее
 
Когда я провожу эксперимент в продукте, то ориентируюсь на данные. Проблема в том, что данных много и глаза разбегаются. Например, вы сравниваете два варианта страницы:
 
– По конверсии в платежи — победил вариант 1.
– Зато возврат денег запросили меньше в варианте 2, он победил.
– По последующим покупкам также лидирует вариант 2.
– А вот активность в продукте выше в варианте 1.
– Но удержание в течение трех месяцев лучше в варианте 2.
 
Метрик несколько десятков, может случиться, что в половине из них выиграет первый вариант, а в другой половине – второй. Глаза разбегаются, не понятно как сделать выбор. Данные не только вносят ясность и помогают принять решение, но также запутывают и заставляют застыть в нерешительности.
 
Чтобы не смущаться и не тормозить, лучше до начала эксперимента решить, какая метрика для вас главная. Также выбрать 2-3 вспомогательных метрики, которые помогут глубже взглянуть на главную метрику. Остальные 20 метрик нужно волевым решением игнорировать, чтобы они ни показывали.

141. Дэйта шейминг
 
В продуктовой разработке модно быть data driven. Ну, типа, мы не просто решили сделать вот такую кнопку и сделали. Мы скрупулезно собирали и анализировали данные, провели эксперимент, сравнили несколько вариантов и выбрали тот, у которого лучшие метрики (не забыв про стат. значимость). 
 
Принимать решения на основе данных – отличная идея. Однозначно лучше, чем «мы поставили кнопку сюда, потому что директору понравилось». Но популярность подхода порождает троллинг и шейминг на этой почве.
 
Задать каверзный вопрос про данные – легко. Задавать их к месту и не к месту научились все, особенно полюбили это дело дизайнеры: «Вот вы здесь решили передвинуть кнопку на 200 пикселей вверх, а вы просчитали риски этого изменения?» 
 
Вопрос нормальный. Проблема, что задают его люди, которые большинство своих действий делают без оглядки на данные. Потому что «ждать аналитиков долго, а сами мы не умеем».
 
Стараюсь следить за собой, чтобы мои вопросы про статистику не выглядели как троллинг или шейминг.

140. Ответственность сама собой не появится
 
Сыну 11 лет. У нас остро стоит вопрос, как быть со смартфоном. Мы стараемся не жестить как некоторые родители, которые вообще запрещают смартфоны или дают пользоваться полчаса в день. Сейчас и домашние задания в Вотсапе выдают, так что смартфон нужен. Но совсем не ограничивать ребенка нельзя – он целый день просидит в телефоне, даже поесть забудет.
 
Долгое время у нас было правило: пришел из школы – поиграл час и отдал телефон родителям, сделал уроки – можешь поиграть еще час, после опять отдай телефон. За пару лет мы здорово задолбались за этим следить. Попытки ограничить использование телефона с помощью софта – провалились.
 
Главная проблема, что не только мы задолбались, но и сын не развивался. Не учился контролировать себя, не вырабатывал навык «отложить смартфон и заняться делом». Поэтому мы решили изменить подход. Теперь мы отдаем ему телефон на целый день. Но пользоваться он им должен не больше 4 часов экранного времени в день. Он сам заходит в настройки «Цифрового благополучия» и следит за расходом.
 
Он стал более ответственным. Через несколько дней пришел ко мне и попросил настроить ограничение на игры «не больше часа в день», чтобы случайно не «сжечь» весь дневной лимит на одну игрушку.
 
Если вы как менеджер заметили, что вашим работникам ничего нельзя доверить и они ведут себя как дети, то, возможно, стоит дать им больше ответственности. Возможно вы слишком их опекаете и не даете им шанса стать взрослыми.

139. Продакт – венец творения или шарлатан?
 
Моя профессия последние годы стала популярной: куча вакансий, множество курсов. Недавно узнал, что это венец творения и предел мечтаний.
 
Был на презентации ребят, которые делают для школьников квесты из разряда «Создай свой стартап». Проект хороший, рассказывают детям про целеполагание, Agile/Scrum и т.п. Так вот, они объясняли родителям, что дети будут развиваться и в будущем смогут дорасти до Product owner-a. Меня позабавила сама идея, что прогрессивные молодые ребята мечтают стать продактами. 
 
Открою тайну, профессия сама по себе ничего не значит. Я много раз видел, как продактами в ведущих компаниях становились не очень квалифицированные люди. Некоторые из них потом выступали на конференциях и выглядели довольно круто. Они настоящие менеджеры продукта, просто плохие.
 
Невозможно быть музыкантом, не умея играть. Нельзя работать разработчиком, не умея программировать. А продактом может работать любой. Выполнять действия профессии – вести бэклог, приоритезировать задачи, проводить касдев, выдвигать гипотезы (полный список смотри в любой вакансии на Хедхантере) – способен любой студент. Наверняка он сделает это плохо, но кто проверит?!
 
Хайп вокруг профессии продакта в сочетании с трудностью проверки реальной квалификации кандидата – открывают большой простор для спекуляции и шарлатанства.

138. Промолчать и забыть
 
Все в этом мире учит нас отстаивать свои права и достоинство. Фильмы воспевают людей, которые борются с преступность, когда полиция не справляется. Не обязательно драться: с тобой плохо обошлись на работе – засуди ублюдков. Да, не все готовы бороться с несправедливостью словом или кулаком. Но подразумевается, что они слабаки.
 
К счастью, мы не так часто сталкиваемся с серьезными ситуациями. А вот рабочие конфликты встречаются постоянно. В них не нужно бороться за справедливость, в них нужно выслушать оппонента, попросить прощения, если требуется и найти компромисс. Если конфликты на работе не решать, то будет всем плохо – стресс, обиды, сплетни и козни. 
 
Я стараюсь решать конфликты и выяснять отношения. Но бывают ситуации, когда нужно промолчать и забыть. Я опознаю такую ситуацию по двум проверочным вопросам:
 
1. Поможет ли выяснение отношений стать лучше кому-то из сторон?
2. Если я промолчу, будет ли меня грызть эта ситуация и мешать в будущем?
 
Если на оба вопрос я отвечаю «нет», то можно и промолчать. Таких ситуаций, в которых выяснять отношения излишне, достаточно много. Опознать их легко. Если вам хочется сказать «я же говорил», скорее всего лучше промолчать. Еще один маркер таких ситуаций, когда хочется сказать: «Ах ты, гад, щас я тебе». Возможно это значит, что не нужно быть мстителем и борцом за справедливость, а лучше промолчать и забыть.

137. Пропагандистские документы
 
Мое детство прошло в Советском Союзе. В садике висел красный лозунг и большой портрет Генерального секретаря. В целом, советская пропаганда не сильно влияла на мое детство, разве что огорчало, что три года подряд умирали правители страны. Это было ужасно, каждый раз в течение недели по телевизору не показывали мультики и приключенческие фильмы.
 
Пропаганды было много. Везде висели непонятные лозунги. В почтовый ящик приходила газета «Правда» в которой было что-то про злостных империалистов с атомными ракетами. По телевизору показывали как ужасно жить в Нью-Йорке и как много там бедности и преступности. 
 
И знаете что? Всем было наплевать на пропаганду. Детям, родителям, учителям и даже тем, кто по долгу службы эту пропаганду нёс в массы. Все понимали, что все эти слова и лозунги формальные и ничего не значат. Все знали, что за границей круто, и оттуда нужно привезти джинсы. 
 
В больших компаниях любят писать документы «за все хорошее». Миссии всякие или кодексы поведения сотрудников (Code of conduct). Важно не то, что в них написано, а реальное положение дел. Если в компании принято устраивать публичные порки сотрудников и орать на них, все слова про уважение и равные возможности – туфта. 
 
Если вас волнует компания – улучшайте реальные вещи, а не садитесь писать пропагандистские документы. Сами по себе они не работают.

136. Старые джинсы
 
Я очень люблю носить старые джинсы. Гораздо больше, чем новые. Нравится, когда они потертые, привычные и удобные. У меня нет комплексов, что я хожу в старье. Я не боюсь, что кто-то подумает, что я нищеброд и не могу позволить себе нормальную одежду. Я ношу старые джинсы, потому что это мне нравится, а не потому что нет возможности купить новые.
 
Этот принцип я применяю и в других вещах. Например, у меня старая дешевая машина. Это удобно. Если кто-то поцарапал мой бампер, я говорю: «Мужик, не парься, никаких проблем», а не бегаю по страховым компаниям. Меня полностью устраивает моя машина, она идеальная по техническому состоянию, в нее помещается вся моя семья и три велосипеда. Мне наплевать, что она не выглядит крутой и элитной.
 
Я веду переговоры так, как 15 лет назад меня научил мой коллега. Да, я читал разные книги про это, но его метод все еще работает. Я планирую спринт команды, как меня научили 12 лет назад. Есть и другие методики работы с командой, но старый подход все еще работает.

135. Ежедневная статистика
 
У всех владельцев бизнеса, которых я встречал за 20 лет работы, есть общая привычка. Они начинают свой день с просмотра статистики. Смотрят на метрики и радуются, если те растут. Или бегут к подчиненным, начинают размахивать руками и паниковать, если метрики падают.
 
Когда у меня была своя компания, я тоже так делал. Это не было решением, о котором я узнал в бизнес-школе. Скорее это был нервный тик, я просто не мог не смотреть на статистику и не переживать за нее. И я тоже бежал к подчиненным, если не мог сам разобраться в причине падения платежей.
 
У любых платежей есть волатильность. Паника начальника по поводу плохой статистики часто бывает ложной, например, в этом году Пасха позже обычного, и это повлияло на активность покупателей. Часто волноваться не стоит и статистика нормализуется сама. Но иногда параноидальное беспокойство позволяет выявить серьезные проблемы на ранней стадии. Я был свидетелем, когда ежедневное «ручное» наблюдение выявляло фрод или серьезные проблемы в продукте. 
 
Смотреть в статистику каждый день и переживать о ней – это обременительная, но полезная привычка владельцев бизнеса, которую стоит перенять менеджерам продукта.

134. Умеренность в тирании
 
Если смотреть на историю народов ретроспективно, например, сотни лет в 10-минутном ролике, то можно заметить закономерность. Тираны бывают очень эффективными менеджерами, но длится это не бесконечно. Можно собрать множество рабов и построить великие пирамиды, или множество заключенных и выкопать лопатами длинный канал, завершить пятилетку в три года и т.д. Но рано или поздно тирана свергает восставший народ или убивают завистливые приближенные. 
 
Хочется подсказать этому историческому тирану: «Чувак, ты добился отличных результатов, пора остановиться, дать послабления народу, раздать дары соратникам и заняться благотворительностью». Но тиран не слышит и строит очередную пирамиду до тех пор, пока его не поднимут на вилы.
 
Недавно мы запускали новый продукт. Планировали сделать за 3 месяца, но я очень хотел успеть за два. Это позволило бы развязать руки другим командам. Поэтому я всячески подгонял нашу команду, урезал функциональность, жертвовал качеством и вел себя как тиран.
 
Мы успели. К концу у разработчиков дергался глаз, а дизайнеры пару раз вызывали меня на разговор «так жить нельзя». Но бунта против бесчеловечной тирании не произошло. Я дал всем отдохнуть, перестал подгонять дизайнеров и выполнил все их требования. Разработчиков отпустил заниматься рефакторингом и другими тайными удовольствиями. Через пару недель вернулись в обычный темп.
 
Лучше не быть тираном. Но если уж стал, то умей вовремя остановиться.

133. Как проводить опросы
 
Продуктовые команды постоянно создают что-то новое, экспериментируют. Конечно, лучше делать выводы на основании численных метрик: MRR, ARPPU и т.д. Но бывают случаи, когда метрики не показательны и приходится опираться на отзывы пользователей. Например, мы решили изменить внешний вид главной страницы: для новых пользователей хорошей метрикой будет количество первых платежей, а для старых – Churn Rate + отзывы. Можно выкатить новую версию на 10% старых пользователей и понять, как сильно они будут ругать или хвалить новый дизайн. Расскажу, как я провожу такие опросы.
 
Сначала дать попробовать. Бессмысленно спрашивать пользователей до того, как они распробовали новинку. Конечно, они могут написать в любой момент. Но баннер с вопросом мы проактивно показываем только через несколько дней. 
 
Оценка + текст. Можно спрашивать мнение пальцем вверх/вниз или пятью звездочками, но я люблю градацию из трех вариантов: нравится / не нравится / нейтрально. Погрешность таких голосований очень высокая, поэтому мы просим написать комментарий. Комментарии более показательны и точны.
 
Критерии успеха заранее. Важно определиться с критерием успеха до начала эксперимента. Задайте себе вопрос: «Если 50% пользователей будут ненавидеть новую версию, мы оставим ее?» Если ответ отрицательный, то попробуйте уменьшать цифру до тех пор пока вы и ваши стейкхолдеры не согласятся, что, к примеру, 30% негативных отзывов вполне приемлемы. После этого определите минимальный порог количества участников. К примеру, я решил, что если в опросе участвовали менее 1% пользователей, то я вообще не смотрю на долю негативных отзывов. 
 
Подключайте разные источники. Чтобы собрать больше отзывов, мы использовали разные источники: баннер на странице, чат-бот, группу в Фейсбуке, обращения в саппорт. 
 
Отрабатывайте негатив в личном порядке. Всегда будут недовольные пользователи. Я люблю общаться с ними в личной переписке и специальной закрытой группе в Фейсбуке «для своих». Это гораздо лучше для PR, чем публичные набросы в Твиттере.
 
КОММЕНТАРИЙ:
 
Свежий пример.
Недавно я проводил опрос, стоит ли разыгрывать книги на этом канале. Я решил заранее, что буду учитывать результаты опроса, если в нем проголосуют хотя бы 200 человек (проголосовало больше). И решил, что если доля негативных ответов будет больше 25%, то я не буду разыгрывать книги. Против высказались 6% пользователей, так что я открываю регулярную рубрику розыгрыш книги + конспект на нее от победителя.

132. День рождения в офисе
 
Пришло время высказаться о запретной теме, о которой принято молчать в современном корпоративном мире. Поговорим о подарках на день рождения коллегам. 
 
У меня в команде 10 человек. Еще есть коллеги-продакты и коллеги из других департаментов, с кем постоянно пересекаемся по работе, где-то 25 человек. Отдельная каста – начальники, их не много, человек 5. Это все близкие люди, а не просто едва знакомые коллеги.
 
Итого, в офисе у меня 40 дней рождений в году, почти каждую неделю. На каждый день рождения создается чат, где обсуждают «что подарить и как поздравить». На каждого нужно скинуться деньгами «кому сколько не жалко». В какой-то момент меня это достало, и я просто отключил такие чаты. Осталось решить вопрос с собственной командой.
 
На ретроспективе я встал и поделился, что меня достало придумывать подарки и вся эта ерунда с конвертиками. Предложил волевым решением прекратить поборы. Коллеги предложение поддержали, но попросили «закончить круг, чтобы не было обидно».
 
Мы больше не собираем деньги и не страдаем выбором подарков. Если кто-то хочет подарить подарок от себя лично – никто не запрещает. Если именинник приносит тортик, мы радостно его съедаем и не мучаемся совестью. 
 
Насколько я знаю, в Студии Лебедева официально запрещен сбор денег на любые праздники. Мне кажется это правильная HR-политика.

131. О туалетах и управлении продуктами
 
У нас в офисе в туалетах стояли дозаторы с мылом. Подошел, нажал, в ладонь вылилось достаточное количество жидкого мыла, помыл руки. Рядом висели бумажные полотенца. Потянул, оторвал сколько нужно, вытер руки.
 
Однажды все оборудование заменили на автоматическое. Надо поднести ладонь к дозатору, чтобы сработал сенсор. Сенсор срабатывает не сразу и не всегда. Ты долго машешь рукой, в результате тебе на ладонь плюхается издевательски малая капля пены. Помыть руки ей нельзя, нужны 2 или 3 капли, так что ты как нищий стоишь с протянутой рукой и умоляешь сенсор отсыпать тебе мыла.
 
Бумажные полотенца тоже с сенсором. Если долго махать, тебе выделят малюсенький кусочек бумажки, руки им нормально не вытереть. Честно говоря, я теперь вытираю о джинсы.
 
Если посмотреть на офис как на продукт, то эти изменения никак не отразились на продуктовых метриках. Арендодатели не стали съезжать из офиса, работники не стали увольняться. Все хорошо, новые фичи внедрены, метрики стабильны. Есть пара негативных отзывов, но это не страшно.
 
Мне подумалось, что продуктовым командам, когда они внедряют новые фичи и переходят на новые фреймворки, стоит задаваться вопросами: «А не ходят ли мои пользователи с грязными и мокрыми руками?»

130. Горизонтальный рост для продакта
 
Менеджер продукта может расти вертикально: отвечать за группу продуктовых команд или стать директором по продукту, CPO или даже CEO. А может расти горизонтально – открывать новое, не меняя должность.
 
Хороший способ расти горизонтально – сменить продукт. У меня два раза получилось сделать это, не покидая компанию. 
 
Первый раз я ушел один. Запустил продукт и два года развивал его. В какой-то момент решил сосредоточиться на другом проекте. Нашел себе замену, два месяца вводил нового менеджера в курс дел, объяснял, помогал. Когда он был готов, оставил его вместе с командой развивать продукт дальше. 
 
Второй раз я ушел со своей командой. Три года мы занимались новым направлением. Дела шли неплохо, но за годы концепция продукта изменилась, и для развития потребовались другие специалисты. Тогда мы наняли новую команду себе на замену, передали им дела, обучили. Когда они были готовы, мы перешли в другой продукт.
 
В обоих случаях и я и команда получили возможность заниматься новыми интересными вещами. При этом «старые» продукты никак не пострадали и не замедлили своего развития. К сожалению, я встречал и плохие примеры перехода, когда команда доводила свой продукт до такого печального состояния, что сама не была готова им заниматься и просто бросала его. В таких случаях «новой» команде приходилось в одиночку бороться за живучесть корабля.

129. Уйти ответственно
 
Когда-то давно я работал дизайнером в московско-швейцарской компании. Делал весь дизайн – айдентику, графический дизайн, сайты. Общался с типографиями и разработчиками. За два года в моих руках сосредоточилось огромное количество материалов, исходников, контактов. 
 
Когда я решил уйти из компании, я аккуратно разложил все по папочкам и написал подробную инструкцию, где что найти. Мне сказали: «Ой, спасибо, ты такой ответственный». 
 
Через полгода позвонили:
 
– Привет, не подскажешь, где исходник взять?
– В такой-то папке.
– А где она?
– Я же вам отдал! По такому-то адресу в корпоративной сети.
– Ой, да… Хорошо, что есть такое.
 
После этого еще пару раз звонили, и этот разговор повторялся.
 
Спустя время я работал Chief UX в холдинге из 6 компаний. Выстраивал процессы, создавал регламентирующие документы, системы грейдов, обучение. Через два года, когда я завершил это большое дело, я разложил все материалы по папочкам и написал подробную документацию, как этим пользоваться. 
 
В течение года пару раз звонили:
 
– Ой, а помнишь мы вот это делали, где материалы?
– В такой-то папке.
– А где она?
– Я же вам отдал! По такому-то адресу в Гугл документах.
– Ой, да… Хорошо, что есть такое.

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

128. Когда надо остановить или закрыть продукт
 
Когда мне было 13 лет, я смотрел боевик про крутого полицейского. Здоровый бородатый мужик спокойно раскидывал злодеев, включая модных тогда каратистов. По сюжету он – бывший гребец. Мой друг, с которым мы вместе смотрели фильм, сказал: «Понятно почему он такой здоровый, у нас на озере секция гребли, там все амбалы».
 
Я очень хотел быть большим и сильным, поэтому записался в секцию гребли. Я занимался 2 раза в день. Не отлынивал от заданий тренера. Тренировался самостоятельно. У меня начало неплохо получаться, и через несколько месяцев занятий меня взяли на соревнования в другой город. Я мечтал о спортивной карьере.
 
А потом наступил 1991 год, рухнул Советский Союз, а вместе с ним система детско-юношеских спортивных школ. Тренировки прекратились. Другой секции в моем городе не было. 
 
Иногда в продуктовой разработке бывает также. Вся команда пашет изо всех сил и создает отличный продукт. Этот продукт нравится пользователям, он удобный, красивый, уникальный, лучше конкурентов. Он приносит деньги, но небольшие. И чтобы ты не делал, бизнес не растет. Например, рынок небольшой, и хотя вы «выбрали его до дна», едва балансируете на грани рентабельности. Или случился локдаун, и ваша ниша схлопнулась. 
 
В этом случае не нужно бесконечно вкладывать средства в попытки вырастить продукт. Если продукт рентабельный, надо прекратить его развивать и оставить только поддержку работоспособности. Если продукт убыточный, и на горизонте нет шанса к изменениям, надо его закрыть. Даже если он классный и всем нравится.
 
А прекрасная продуктовая команда пусть начнет заниматься новым продуктом.

127. Когда нужно разделить команду
 
С точки зрения пользователя у компании может быть один продукт, например, агрегатор объявлений об аренде квартир. Но внутри – это много разных продуктов: сборщик объявлений с разных площадок, система для модераторов, приложение под iOS, приложение под Android, веб-портал, биллинг, система для работы с корпоративными клиентами. У каждого такого «внутреннего» продукта может быть своя команда разработки, свой менеджер продукта и собственные бизнес-метрики.
 
Обычно компании растут постепенно и начинаются с одной команды и одного продукта. Постепенно происходит рост, но количество продуктов растет быстрее, чем количество команд. В какой-то момент одна команда отвечает за 8 разных продуктов. Приходится делить команду на две. А потом еще на две. 
 
Делить команду нужно, когда этого попросит один из трех участников: 
 
Команда. Разработчикам может быть морально тяжело отвечать за множество различных систем и постоянно переключаться. Или команда разрослась до 15 человек, и работать по Скраму стало затруднительно.
 
Менеджер продукта. Он может захотеть отбросить все лишнее и сфокусироваться на одном направлении. Обычно дело не в загрузке менеджера, а в производительности команды. Я видел много примеров, когда продакты разделяли команду, набирали людей в обе части, при этом оставались менеджерами и там, и там.
 
Бизнес. Иногда какое-то направление приносит много денег, а другое убыточно. И даже если команда и менеджер готовые отвечать за оба, бизнес овнер может вмешаться и разделить активы.
 
Технически команду делить не сложно. Скорее всего она уже давно внутри себя разделила зоны ответственности. Осталось оформить это официально и нанять недостающих людей в обе части.

126. Советоваться нужно, но сложно
 
Мне всегда нравился этот отрывок из Притчей Соломона:
 
Предприятия получают твердость чрез совещание, и по совещании веди войну. (Притчи 20:18)  
 
Типа никто не совершенен и даже самым умным людям нужны партнеры и советники. Советуйся и будет тебе счастье, обязательно победишь в своей войне. Однако на практике мне сложно советоваться.
 
Прежде всего я довольно гордый и самоуверенный человек. Мне кажется, что я сам отлично знаю, как построить команду, как провести эксперимент, сделать продукт успешным. Так зачем советоваться? Жизнь не раз учила меня, что так поступать глупо, но я все равно наступаю на эти грабли.
 
Другая проблема: я боюсь, что мне посоветуют что-нибудь хорошее и придется менять планы. Недавно я проектировал большой и сложный эксперимент. Я работал над ним полтора месяца и, наконец, завершил подготовку. Меньше всего мне хотелось что-то переделывать.
 
Но я все же пересилил себя. Показал описание эксперимента коллеге и попросил покритиковать. Он сделал два существенных замечания. Из-за них много пришлось переделать, но результат мне понравился. Мне очень хотелось остановиться. Но я попросил совета еще одного коллеги. Он тоже предложил улучшения, и мне снова пришлось дорабатывать.
 
В конце концов я сделал работу гораздо эффективнее и элегантнее, чем планировал изначально. Но далось мне это нелегко.

125. Допустимая ржавчина
 
Когда-то давно я ездил на ржавой четверке жигулей. Ржавым в ней было все: двери, крылья, пороги, днище. Больше всего на свете я мечтал, чтобы ржавчина исчезла. Кажется, у меня даже случался  нервный тик при виде ржавчины.
 
У моего коллеги была крутая тачка – девятка. Она была достаточно новая и совсем не ржавая. Я завидовал ему всеми оттенками зависти. Однажды я увидел, что на его прекрасно-нержавой машине дворники покрыты ржавчиной. Я очень удивился и спросил: «Почему ты не заменишь дворники, это же недорого?» 
 
Его ответ я запомнил на годы: «В любой машине должно быть хоть немного ржавчины, пусть лучше она будет на дворниках, чем на дверях».
 
В нашей компании нет бюрократии, а командам предоставлена большая свобода действий. Это очень круто. Но все же есть требования регулирующих органов, разные законы. Иногда все же приходится делать что-то ради бюрократии. Например, пройти какой-то тест на соответствие законам. 
 
Коллеги ворчат, мол, зачем это все, формализм ведь, толку никакого. А я улыбаюсь и говорю: «Лучше пусть бюрократия будет здесь, чем в нашем продукте».

124. Закон Мёрфи в разработке продуктов
 
Неоднократно сталкивался с такой ситуацией. Программисты делают новую фичу и внимательно проверяют, что все работает хорошо. Потом проверяет инженер по качеству – он находит много ошибок. Программисты исправляют ошибки, продукт готов. 
 
Менеджер продукта пробует новую фичу, чтобы сделать красивые скриншоты и похвастаться достижениями. Случайно он обнаруживает критическую проблему. Инженер по качеству и программисты в шоке от того, что пропустили такой косяк. Каются. Все исправляют.
 
Новую фичу презентуют заинтересованным лицам. Во время демонстрации перед всем честным народом вылазит новая ошибка, еще более страшная, чем все предыдущие. Вся команда в шоке. Все каются. Исправляют.
 
Однажды фичу решает посмотреть САМЫЙ-БОЛЬШОЙ-НАЧАЛЬНИК, это может быть главный инвестор или какой-нибудь председатель совета директоров. Он не пользовался продуктом уже полгода, но тут решил зайти на пару минут. Именно в эти пару минут он находит самую ужасную ошибку из всех виденных ранее.
 
Мы столкнулись с частным случаем закона Мёрфи:
Чем выше начальник, тем критичнее проблема, которую он обнаружит.

123. А/Б-эксперименты без стратегии – путь в никуда
 
Раньше я считал А/Б-эксперименты вредной ересью. Сначала дизайнер с любовью и вкусом создает продукт, например, сервис по бронированию отелей. Потом устраивают 200 тестов «какая кнопка принесет больше покупок, красная или синяя» и в результате получают неудобного и некрасивого монстра. Множество маленьких полезных улучшений не приводят к хорошему результату.
 
Поэтому я предпочитал развивать продукты, основываясь на юзабилити-исследованиях и собственном хорошем вкусе. Это приносило плоды. Но лишь до поры, пока я не стал заниматься сложными продуктами с большой аудиторией. В них количество факторов, влияющих на результат, оказалось таким большим, что создавать продукт на основании дизайнерской чуйки стало невозможно.
 
В результате я примерил два подхода:
 
1. Если не понятно, куда развивать продукт стратегически, мы генерируем из головы хоть какие-то идеи и на их основе проводим количественные А/Б-эксперименты и качественные UX-исследования. Цель – провалидировать идеи и понять «в какую сторону бежать».
 
2. Когда понятно, в какую сторону развивать продукт, надо писать стратегию и дальше двигаться под ее руководством. Анализировать все новшества качественно (UX-техники) и количественно (аналитика).
 
3. А/Б-эксперименты использовать для контроля, как способ проверить, что не делаешь хуже.
 
Если совсем коротко: А/Б-эксперименты без стратегии – вредны. Но они помогают с идеями на ранних этапах и помогают не заблудиться на поздних.

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

121. Переписывайте продукты по частям
 
Случилось так, что вам достался старый продукт. Он работает, приносит деньги. Но внутри полон ужасного легаси кода, поддерживать и развивать его невозможно. Команда разработки вынесла вердикт: «Это надо полностью переписать, нам надо полгода». Вам кажется, что за полгода вы напишете новый продукт, закроете старый и заживете счастливо. На практике все будет иначе.
 
Команда будет увлеченно переписывать продукт. Но бизнес идет, старый продукт приносит деньги и его нужно поддерживать. Это будет отвлекать и раздражать команду. Т.к. новый продукт нельзя запустить в минимальном виде (вы же переписываете большой продукт, создававшийся годами), разработка затянется, в полгода вы не уложитесь. Начальство начнет нервничать. За ним начнете нервничать вы и станете подгонять команду. Команда пойдет на компромиссы в вопросах качества, самые идеалистичные разработчики уволятся. 
 
В результате вы перепишете продукт. Но потратите на это в 3 раза больше времени, чем планировали. Новый продукт не будет идеальным, в нем будет ненамного меньше технических проблем, чем было в старом. Выгоревшие и разочарованные вы уйдете из компании. Продукт достанется новому менеджеру и новой команде. Они посовещаются и вынесут вердикт: «Это надо полностью переписать, нам надо полгода».
 
Продукты надо переписывать по частям. Ваша команда может сказать, что это монолит, тут нет модулей, по частям переписать не получится. Не ведитесь! Всегда можно что-то придумать, для этого есть специальные техники, как на уровне технической архитектуры, так и на уровне организационных процессов. Время разработки одного модуля не должно быть больше 2-3 месяцев.

120. Не всё золото, что блестит
 
Мой папа был выдающимся советским инженером-электриком. Всю жизнь он запускал и развивал ГРЭС (большие электростанции). Попутно разрабатывал уникальные методики ремонта высоковольтного оборудования, помогавшие сэкономить миллионы. О том, что он крутой инженер, знали только те, кто с ним непосредственно работал. Широко он не был известен, потому что не пиарился и не пытался добиться административных успехов. Знакомый увидел его инновационную методику ремонта высоковольтных выключателей и сказал: «Это готовая диссертация, давай оформим тебя задним числом в аспирантуру, ты напишешь несколько научных статей, а потом защитишь кандидатскую». Мой отец не стал заморачиваться. Реальная работа была для него гораздо интереснее официальных регалий.
 
В любых профессиях есть хорошие специалисты, а есть известные. Среди известных есть хорошие, но основная масса крутых спецов не пиарятся. Они занимаются интересными проектами, им просто некогда, да и неинтересно ездить по конференциям и выступать на вебинарах.
 
На профессиональных конференциях я иногда вижу бывших коллег в качестве спикеров. Они хорошо выступают, у них много регалий. Меня это веселит. Я знаю, что их по сути выгнали с работы, потому что они были самыми профнепригодными. Конечно, я не утверждаю, что все, кто выступает на конференциях, плохие специалисты. Но если вы охотник за головами, вам точно не стоит искать кандидатов среди спикеров конференций.

119. Страх как ушиб
 
Некоторым из нас свойственно бояться ерунды. Особенно этому подвержены дети и старики. Когда мне было девять лет, по телевизору показывали советский фильм «Человек-невидимка». Там был момент, где он разматывает бинты на голове, а под ними – ничего (он стал невидимым). Момент вообще не страшный, а по сегодняшним временам даже прикольный. Но я очень испугался, ночью не мог уснуть и не стал смотреть вторую серию на следующий день.
 
Моя мама часто боится, что со мной что-то случится. Если я еду на машине в другой город, то обязательно должен позвонить, что доехал. При этом она абсолютно не переживает, что я езжу каждый день по городу на мотоцикле.
 
Наверное, все боятся какой-нибудь ерунды. У каждого есть слабое место. Даже Супермен боялся минерала Криптонит. Я, например, боюсь разговоров с некоторыми коллегами. Понимаю, что ничего страшного не случится, но ничего поделать с собой не могу. 
 
Недавно я понял, что с небольшими страхами можно не бороться. Достаточно просто подождать. Работает как со слабым ушибом. Упал, ударился ногой – надо приложить лед и несколько дней подождать. Пройдет само. Да, эти несколько дней будет немного болеть, но жить с этим можно и проще не обращать внимания. 
 
Так и с несерьезными страхами. Можно сколько угодно уговаривать себя, что «ничего страшного нет» – не поможет. А можно не обращать внимание и через несколько дней само рассосется.

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

117. Знать ≠ уметь
 
У нас в семье принято после использования душа переключать воду «обратно в кран». Один из детей постоянно оставлял переключатель в положении «в лейку». Когда я открывал кран, чтобы набрать воды, мне на голову включался дождь. 
 
Это жутко раздражало. Мы несколько раз говорили с ребенком. Он говорил, что, мол, всё понятно, больше не будут, простите. Но в следующий раз все повторялось. Тогда я позвал ребенка в ванную и попросил при мне «правильно выключить воду» 20 раз подряд. С тех пор проблема решена. Это было не наказание, а отработка навыков.
 
Как-то наша команда забрала себе старый глючный продукт. Конечно, мы со временем все исправили и переписали, но первые месяцы пришлось поддерживать старую систему. Разработчики получили все доступы, ознакомились с кодом и сказали: «Мы поняли, как тут все устроено, если что-то сломается, мы готовы починить».
 
Я в этом сомневался, потому что знать и уметь – не одно и то же. На практике окажется, что или прав не хватает, или что-то не деплоится. Поэтому я нашел небольшую, но важную задачу для старой системы и попросил ее сделать. Естественно, все прошло не гладко. Но в результате справились, и я смог спать спокойно: случись чего – исправят.

Как быстро запустить продукт
 
Чем быстрее вы запустите продукт, тем лучше. Конечно, минимализм – не самоцель. Даже минимальный продукт должен приносить какую-то пользу и быть способным доказать или опровергнуть гипотезу. Но большинство людей склонны затягивать запуск, потому что хотят сделать все идеально. Расскажу, как с этим бороться.
 
1. Рисуем идеальный прототип. В начале мы создаем прототип, в котором реализованы все наши идеи. На этом этапе мы себя не ограничиваем.
 
2. Оставляем «одну комнату». Потом мы начинаем убирать из прототипа куски, спрашивая себя: «Без этого можно запуститься? Если да, то выкидываем». Урезанную версию прототипа несем коллегам и просим их продолжить. Коллеги не работали над прототипом, им не жалко труда, поэтому они выкидывают еще больше. В результате остается минимум как в анекдоте про строителя, который строил однокомнатный дом, потому что «меньше одной комнаты не имеет смысла».
 
3. Соблюдаем дедлайн. Перед реализацией минимального прототипа мы ставим дедлайн. Обычно это 1-3 месяца. Часто времени не хватает, и хочется сдвинуть сроки. Важно побороть это желание и запустить продукт вовремя. Для этого придется его еще немного упростить. Например, пожертвовать анимацией интерфейса и прочей необязательной красотой.

116. Человек-оркестр
 
Я считаю, что UX и UI должен делать один человек. Знаю, что меня закидают тухлыми помидорами за такие слова, но мой личный опыт как UX- и UI- дизайнера и опыт руководителя дизайн подразделений говорит о том, что разделять профессии не нужно. В продуктовых компаниях используются дизайн-системы, которые помогают не тратить время на рисование кнопочек. Поэтому специалист, кто проектирует UX, может делать и UI. Это экономит кучу времени на коммуникациях и убирает еще одну очередь задач.
 
Я пытался внедрить этот подход в компании, где сейчас работаю, но не смог. Так что я – одинокий ренегат в UX-среде. Но сегодня я хочу пойти еще дальше и заработать себе репутацию ренегата в области продуктового менеджмента.
 
Есть «продакт», Product manager, а есть «проджект», Project manager. Это профессии с различными наборами навыков и ответственностей. Я считаю, что можно сочетать в одном человеке функции продакта и проджекта. Одновременно. Именно так я и делаю. А чтобы окончательно вас добить, сознаюсь, что я еще исполняю функцию скрам-мастера.
 
Плюсы: единство стратегии и тактики, большая скорость тестирования гипотез, большая скорость во всем, чувство локтя с командой.
 
Минусы: ты можешь вести только одну команду.
 
Требования: большой арсенал хард- и софт-скиллов, взрослая самостоятельная команда разработки, UX-специалист с развитыми аналитическими способностями.
 
Короче, это как быть человеком-оркестром в стартапе. Не все умеют, кто хочет. Не всем нравится, кто умеет. Но лично мне заходит отлично.

115. Длинные стендапы на удаленке
 
Когда наша команда работала в офисе, много мелких вопросов решались между делом. Что-то обсудили за кофе, что-то уточнил, проходя мимо стола коллеги. На удаленке такой возможности нет, а в чате не всегда удобно. Поэтому все рабочие мелочи начали обсуждать на ежедневных стендапах.
 
Стендап – это 15-минутная встреча, где каждый коротко говорит о том, что сделал за прошедший день. С переходом на удаленку стендапы стали длиться по часу. У каждого был какой-то рабочий вопрос, который срочно нужно обсудить. Длинные стендапы всех утомляли.
 
Тогда мы стали «парковать» вопросы. Проводим короткий стендап, каждый говорит «что делал, что планирую делать», если есть проблема – называет ее. Проблему записываем на виртуальной доске-парковке, но на стендапе не обсуждаем. Стендапы вернулись к 15 минутам. Но после стендапа мы сразу обсуждали вопросы с парковки, что занимало еще 45 минут. Поменяли шило на мыло.
 
Тогда мы решили, что парковка будет именной. Записываем вопрос + имя человека, ответственного за решение. Каждый решает свой «парковочный» вопрос в индивидуальном порядке. На следующем стендапе проверяем парковку, все ли вопросы решены. Если нет, ждем еще день. Но все равно решить вопрос надо индивидуально, не тратя время всей команды. 
 
Если вопрос с парковки не решается неделю, тогда это повод обсудить его всей командой на специальной встрече.

114. Скучная рутина тоже нужна
 
Дочке учиться в школе еще полтора года, а она – вполне профессиональный молодой дизайнер. Учится в Skillbox на UI/UX, и это не первое ее образование в этой сфере. В свои 16 она где-то на уровне моих 26. 
 
Она думает о своем профессиональном будущем и решает, какая область дизайна ей наиболее интересна. Но школу никто не отменял – надо сидеть на скучных уроках и делать домашки. А еще есть друзья и увлечение музыкой. В общем, школа это потеря времени, и лучше бы она поскорее закончилась.
 
На самом деле, скучная работа будет сопровождать тебя всю жизнь. Даже в самой крутой компании есть много рутинных дел. Без них не обойтись, они тоже важны. Не стоит ждать, что вся работа будет прекрасной и интересной. 
 
Те, кто живет в краях вечного лета, не ценят солнце и тепло также, как мы после месяцев туманной слякоти. Так же и рутинная работа нужна для того, чтобы больше кайфануть от выполнения интересных задач.

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

Страхи работы на иностранном рынке
 
Последние 6 лет я работаю над международным продуктом. Основные рынки – Северная Америка, Западная Европа и Австралия. До этого у меня был собственный стартап для российского рынка, и мне казалось, что делать продукт для «запада» ужасно сложно. Оказалось, разницы почти нет, если говорить о работе менеджера продукта. Есть надуманные страхи:
 
1. Я не знаю английский.
Знать язык необязательно. Я много общался с клиентами из Испании через переводчика. Регулярно читаю фидбэк от пользователей на итальянском и французском – спасибо Гугл транслейту. Не вижу ничего страшного в общении через переводчика и с англоговорящими клиентами. Провести десяток интервью для касдева – не такая уж большая задача, можно договориться с коллегой-маркетологом, кто может переводить.
 
2. Я стесняюсь своего акцента.
Многие знают английский, но стесняются акцента а-ля русский гангстер в голливудском фильме. Коротко – забейте. Всем пофиг на ваш акцент. Важнее – не тормозить и не мямлить. Для этого нужно готовить вопросы заранее и репетировать. Даже на вашем родном языке.
 
3. У них другая ментальность.
Я не заметил серьезной разницы в общении с американцами и европейцами по сравнению с русскими. В деловом общении стандарты схожие. Однако, помните, что хвалят они сильнее русских. Делите восторг клиентов на два и получите похвалу по «русской» шкале.

112. Ментальное здоровье при работе дома
 
В 2020 году многие менеджеры по всем миру с удивлением узнали, что сотрудники могут работать из дома. При этом они не халявят, а работают даже эффективнее. Я это понял еще в 2012 году, когда все мои работники были на удаленке в разных городах, работали по свободному графику, при этом выполняли задачи в 2-3 раза быстрее, чем «в среднем офисе». 
 
Тогда же я узнал, что через год работы дома, начинаешь сходить с ума. Утром встаешь, садишься за компьютер, работаешь целый день, потом ложишься спать. И такой «день сурка» постоянно. 
 
Чтобы не закиснуть от работы дома, достаточно каждый день куда-то ходить или ездить хотя бы на час. Лично мой метод: в обед я сажусь на мотоцикл, час катаюсь по красивым местам вдоль залива, потом возвращаюсь домой и работаю дальше. На мотоциклетной парковке перекидываюсь парой фраз со знакомыми – это доза small talk, которые тоже важны для психики.
 
Проблемы у меня начались зимой. Мотоцикл стоял на парковке. По утрам я гулял в сквере возле дома, но этого было мало – в течение часа там делать нечего. Я стал закисать и морально уставать.
 
Тогда я начал ездить в офис (у нас он ограниченно открыт) один день в неделю. Приезжаю, работаю один в пустой комнате. В столовой немного общаюсь с людьми. Вечером еду домой. Одного дня в неделю мне хватает для здоровой психики.

111. Продукт и заказная разработка
 
Крупные компании, например банки, раньше заказывали IT-разработку на стороне. А сейчас многие из них запустили собственные продукты и обзавелись штатом сотрудников для продуктовой разработки. 
 
Зачем компании создают свои продукты? Почему не заказать разработку на стороне? Поясню на примере.
 
В моем районе ремонтировали фасады домов. Оштукатурили и покрасили светло-желтой краской. Компания-подрядчик успешно сдала работу, получила деньги и откланялась. Со временем на домах стали рисовать уродливые граффити. Жилищная контора старательно закрашивает их. Проблема в том, что оттенок краски не совпадает, она или темнее или светлее той, которой выкрашен дом. Теперь дома испорчены уродливыми разноцветными заплатками. 
 
Я тоже делал ремонт в своей квартире. Когда стены покрасили, я сохранил остатки краски и записал код используемого цвета. За годы жизни в квартире периодически приходится исправлять повреждения – то дети поцарапали, то сам велосипедом ободрал. Я брал сохраненную краску и подкрашивал, цвет совпадал идеально. Когда краска кончилась, я поехал в магазин и отколеровал краску по коду. Это занимает 10 минут, услуга бесплатна. 
 
Адекватность, отсутствие формализма и небезразличие – вот что отличает хозяина от наемника.

110. Как задавать вопросы на собеседовании
 
Взять кого-то на работу – ответственное дело. Найми «не того» и потеряешь кучу времени и сил. Чтобы понять человека, у тебя всего час. 
 
С другой стороны, ты не только должен найти хорошего работника, но и сам понравиться. Для этого надо рассказать о своем продукте побольше. На это тоже требуется время. 
 
Я практикую метод, который убивает всех зайцев одним выстрелом. Описываю кандидату ситуацию и спрашиваю, как он будет в ней поступать. Фишка в том, что эта ситуация – реальный контекст предстоящей работы. 
 
Например, могу спросить бэк-енд разработчика: «У нас каждая команда работает независимо, использует тот стек технологий, какой сама захочет и заботится прежде всего о выполнении своих планов. Другие команды ей не указ. Мы собираемся переписать компонент, который использует 10 других команд, при этом от них тоже потребуются доработки. 5 команд согласились помочь, а 5 других не согласились, им некогда. Что будешь делать?». 
 
А мог бы задать тот же вопрос без контекста: «Что будешь делать, если другие команды не хотят делать свою часть работы?»
 
Когда я задал все интересующие меня вопросы, предлагаю кандидату задавать свои. Как правило он говорит, что уже все понял о будущей работе из моих вопросов. Таким образом я могу запланировать больше времени на нужную мне часть интервью.

109. Что мешает быть понятым
  
По нескольку раз в неделю я что-то объясняю людям. Устно и письменно. Выслушивать людей мне тоже приходится регулярно, как и читать их письма. Умение донести мысль – у всех разное. Кто-то за пять минут может объяснить сложную концепцию, а кто-то за час разговора только запутает. С текстами также: мы все читаем блоги и понимаем, что короткий текст бывает информативнее длинного.
 
Хочу рассказать о трёх паразитах, мешающих быть понятным.
 
1. Многословность. Когда речь идет не о дружеской болтовне, а о донесении мысли, важно быть кратким. Длинные тексты, как и длинные лекции тяжело воспринимать. Внимание слушающих рассеивается, а читатели пропускают абзацы. Даже сложную концепцию можно сократить без потери смысла. Обычно этого не делают из-за лени или нехватки времени.
 
2. Неправильный контекст. Людям свойственно считать себя центром вселенной и полагать, что все вокруг понимают вещи также как они. Это не так. Объяснение, как работает твой продукт, будет разным для инвесторов, разработчиков, маркетологов, сейлзов и твоих родителей. Чтобы «объяснить понятно», надо знать контекст аудитории.
 
3. Сленг и англицизмы. В IT люди используют много сленговых словечек или калек с английского. В этом нет ничего плохого. Но в определенной концентрации вызывает рвотный рефлекс у аудитории. Лучше относиться к сленгу как к соли в еде – знать меру.

Чеклист хорошего менеджера продукта
 
Когда я был молодым продуктовым менеджером, я мечтал об идеальном продукте с которым мы проживем вместе всю жизнь и умрем в один день. Оказалось, продукты приходится довольно часто передавать другому менеджеру. Вот мой чеклист для того, чтобы за продукт был не стыдно:
 
1. Есть продуктовая стратегия на ближайший год. Иначе есть риск осуетиться и потратить все время на мелкие улучшения. Моя стратегия – это текстовый документ из 2 страниц. 
 
2. Бэклог проработан на ближайший квартал. Продуктолог должен работать на будущее и опережать свою команду на 1-3 месяца. 
 
3. Настроены дашборды со статистикой. Важная продуктовая статистика должна собираться автоматически и безостановочно. А закладка на дашборд со статистикой быть самой посещаемой. 
 
4. Ведется мониторинг. Вы должны знать, как быстро работает ваш продукт и где есть проблемы. Если среди ночи «все сломалось», разработчикам должен звонить не саппорт, а система автоматического мониторинга.
 
5. Нет драматического технического долга. Технический долг – это нормально. Плохо, если он не описан и не выплачивается. Это путь к банкротству команды и продукта. 
 
6. Есть документация. Нужен минимальный объем, который позволит продолжить работу, если завтра ваш «незаменимый» программист уволится.
 
7. Авто-тесты для проверки регресса. Какие-бы новые фичи не запускались, вы должны быть спокойны, что «старое не поломается».

108. Плох тот дизайнер, что не мечтает стать продактом
 
Дизайнер (UI), проектировщик интерфейсов (UX) и менеджер продукта (продакт) – это три разных профессии. Каждая интересна по-своему. В моем мире хороший UI должен однажды стать UX, а хороший UX в один прекрасный день перейти в продакты. Я сам прошел эти трансформации, и такой путь кажется мне логичным.
 
Я начинал веб-дизайнером. Достаточно быстро понял, что дизайн – это не про красивые картинки, а про элегантное решение задачи. Проектировал навигацию сайтов, тестировал на разных экранах и браузерах, придумывал удобные способы администрирования. В результате стал заниматься UX за несколько лет до появления первых вакансий с такими буквами.
 
Как UX-специалист я заботился о позитивном опыте пользователя при любом контакте с системой. Тогда мобильные телефоны стали массовыми и появились первые смартфоны, поэтому прорабатывал сценарии не только для компьютера, но и для смартфонов и для SMS. Для этого приходилось общаться с кучей людей, собирать требования, разбираться в технических нюансах. Постепенно я стал связующим звеном между директорами, разработчиками и саппортом. Постепенно я стал выполнять 80% задач менеджера продукта, хотя о такой профессии тогда даже не слышал.
 
Моя мысль: преход из UI в UX или из UX в продакты – это естественный процесс. Я говорю не про название должности, а про выполняемую работу. Если за 5 лет переход не намечается, значит специалист делает свою работу по минимуму и не особо растет.

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

106. Сохранять фокус
 
Недавно слушал выступление одного продакта на конференции, он рассказывал, что запускает несколько экспериментов каждую неделю. Подозреваю, что эксперименты очень простые – переместить кнопку из левого угла в правый и тому подобное. 
 
Я последнее время занимаюсь масштабными экспериментами. Их подготовка занимает месяц-два, длятся они по месяцу. Подсчет результатов может занимать до четырех месяцев. В итоге, от планирования до выводов проходит полгода.
 
Продукт большой, активно развивается, над ним работает 30 команд. За полгода окружение и вводные данные изменяются до неузнаваемости. Это здорово усложняет работу над большими экспериментами.
 
Я мог бы написать о необходимости стратегии, прописывании четких критериев успеха, обозначении рисков и разработки альтернативных планов. Но отмечу лишь одну проблему.
 
Сохранять фокус долгое время – тяжело.
 
Много коллег, с кем я работал, могли фокусироваться на чем-то одном около месяца, максимум двух. Я и сам частенько ловлю себя на том, что хочется плюнуть на запущенное три месяца назад «старьё» и начать что-то более перспективное. 
 
Умение работать над одной задачей годами – это самое важное качество продуктового менеджера.