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

Пятница подкралась незаметно,
Оставив в прошлом всю неделю,
Ее чудесные деньки,
Что были ясны и легки…
Но вот конец уж на пороге,
Его встречаю я в тревоге,
А в памяти лишь понедельник,
То ли склероз, толь я бездельник.

Пишите в коменты, как прошла неделя у вас. В виде дебильных стишков.

#жизашиза

246. Занимательная арифметика зарплат айтишников

Разберу на примере программиста, но работает для многих – дизайнеров интерфейсов, аналитиков, тестировщиков, менеджеров, маркетологов.

Джун получает 75К, мидл – 150К, синьор – 300К. Очевидно, для простых работ надо использовать джунов, а для чего-то сложного сеньоров. Допустим, надо сделать оплату через новую платежную систему. Не особо сложно, но и не очень легко. Отдаем это мидлу, он работает месяц и стоимость фичи получилась 150К.

Если отдать это синьору, он сделает то же самое за две недели. Потому что половину времени мидл разбирается со сложностями, а сеньор с ними уже разобрался в прошлой жизни. Стоимость фичи в исполнении сеньора также получилась 150К.

Если отдать фичу джуну, он будет долго страдать и сделает за два месяца. Бюджет опять же останется 150К.

Невероятно, но факт: по деньгам все три работника оказались одинаковы. Зато сеньор сэкономил кучу времени всей компании. А еще то, что он сделал, будет проще поддерживать и развивать.

Получается надо брать только сеньоров?

Все не так просто. Суровая реальность не такая занимательная, как арифметика. Есть много других факторов, кроме времени и зарплаты, о которых, возможно, мы поговорим в другой раз.

Попросил ребят из Garage Eight рассказать о том, как они проводят продуктовое интервью.
————————————

Продуктовое интервью: что говорить после слова «привет»

Наш продуктовый дизайнер Слава провел более 50 интервью и нащупал свои приемы. Сегодня поговорим о том, как начать разговор.

1. Объясняем суть происходящего. Иногда люди видят слово «интервью» и представляют разговор в духе тех, что печатают в журналах. Важно немного рассказать о себе и о цели происходящего. Я объясняю, что мы хотим понимать проблемы клиентов и их действия в продукте. Тогда человек видит, что не нужно показывать, насколько он супер крут, и расслабляется.

2. Устанавливаем эмоциональный контакт. Чем быстрее человек заговорит, тем быстрее убедится, что его понимают, слушают, что он важен. Плюс так он обозначит комфортный темп беседы. Иногда люди приходят с заготовочкой рассказа о себе. Этот момент нужно «подковырнуть», тогда мы получим возможность задать дополнительные вопросы, зацепиться за тему.

3. Проявляем искреннюю заинтересованность. Спроси, как человек начал пользоваться продуктом. Там всегда есть какая-то история. Копая в личный опыт, задавая вопросы и показывая, что тебе интересно, ты мотивируешь людей вовлекаться и больше рассказывать.

4. Держим в рукаве фреймворк TEDW. Разговорить собеседника помогают «5 почему», переупакованные в 4 фразы:

Tell me more,
Explain me, how/why
Describe me, how/why
Walk me through

Больше подобных тем — на нашем канале @garage_eight

#партнерскийпост

105. Юзабилити-тестирование для самых маленьких

На прошлой неделе два разных продакта из разных компаний пригласили меня на UX-тестирование в качестве подопытного. Я порадовался, что такие исследования стали популярны. Но оба раза меня ждало разочарование. Оба тестирования начались с показа мне прототипа и вопроса: «Ну как тебе, что скажешь?» Это было настолько неправильно, что я даже растерялся.

Мне неловко писать такие азбучные истины, но видимо нужно. Итак, азы юзабилити-тестирования или UX-тестирования, как его теперь называют:

1. Цель тестирования – найти проблемы в пользовательском интерфейсе, о которых вы знали, но сомневались или о которых даже не подозревали.

2. Сбор фидбэка от пользователей – это вспомогательная активность. Проходит после тестирования.

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

4. Важно, чтобы вопросы не давали подсказки. Плохой пример: «Нажмите на пункт меню “Бытовая техника” и добавьте любой чайник в корзину».

5. Такие исследования – качественные. 5-10 респондентов часто бывает достаточно. Они не отменяют и не заменяют количественные исследования и сбор статистики.

Проводить юзабилити-тестирование достаточно легко. Этому можно быстро научиться. Самый простой способ – напроситься в помощники к опытному специалисту.

#старыйпост

104. Защитная реакция от приступов ярости

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

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

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

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

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

Сын говорит: «Пап, чего ты как дебил говорил, ответил бы достойно». Я промычал что-то типа: «да ладно, не важно это». И не стал объяснять ребенку, что пока я мямлил, я боролся с желанием выйти из машины и разбить наглецам голову огнетушителем.

Лучше прослыть тормозом, чем разбираться с последствиями насилия.

#старыйпост

0. Чего такой сонный?!

Эй! Да, да, вот ты, подписчик моего канала. Именно ты. Чего такой сонный сегодня?

Погода может быть? Или не выспался? Ну, бывает. Пошли по кофейку бахнем. Или можно китайского чая заварить, у меня есть хороший улун.

А потом за работу. Сейчас день четверга, а не вечер пятницы. Соберись уже!

245. Чеклист технического здоровья продукта

В идеальном бирюзовом мире работает так.

Product owner отвечает за продукт, его успешность, фичи, направление развития. Если продукт не нравится пользователям и не приносит денег, овнера бьют по голове канделябром и закапывают в саду.

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

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

В помощь продуктовым менеджерам небольшой чеклист по технике. Дополняйте в комментариях.

1. Есть мониторинг основных технических характеристика: загрузка серверов, очереди уведомлений, платежей. В идеале – это несколько дашбордов с графиками в реальном времени, например в Grafana.

2. Настроены алерты в телеграм / слак / sms / телефон о серьезных инцидентах. Недоступность продукта с внешнего сервера, не проходит авторизация пользователя, не проходит платеж, не отправляются уведомления пользователям, проблемы с серверами, например закончилось место.

3. Есть тот, кто реагирует на алерты и регулярно смотрит мониторинги. Если у вас тысяча сообщений, которые никто не читает – смысла в них нет.

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

5. Продукт можно развернуть в полном окружении и работоспособности за сутки. Лучше, за час.

6. У вас есть больше одного человека, кто может поддерживать продукт и восстановить его с нуля. Если у вас всего один разработчик, найдите разработчика на парт-тайм, обучите и пусть он будет за минимальную плату в горячем резерве.

7. Технический долг / проблемы описаны в бэклоге, и существует реалистичный план что и когда с ними делать.

8. У вас не используются языки программирования, фреймворки и библиотеки, на которые сложно найти работников в будущем, когда незаменимый Вася уйдет.

9. Ваши пароли, ключи и доступы хранятся в зашифрованном хранилище. К ним есть доступ не только у разработчиков, но и у менеджера.

10. Есть минимальная документация, с помощью которой посторонний инженер может за день-два разобраться, как работает продукт и начать его поддерживать (или развернуть с нуля).

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

Детей по смартфонам считают

#ПоговоркиПродуктолога

Из загадочного

1. Некоторые люди ставят в скобках лишние пробелы ( например так ).

2. Некоторые ставят пробел перед запятыми , например , так. Еще видел такой вариант ,например ,так ( ваще жесть ) !

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

244. Читайте noreply

Многие сервисы отправляют письма с адреса noreply@. Адрес своим именем говорит: «Я робот, не надо отвечать на это письмо, не пойму». Обычно с этого адреса отправляют пароли и различные уведомления.

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

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

У нас noreply заведен в helpdesk систему и превращается в тикеты. Надо только отфильтровывать автоответы типа «Коллеги, я в отпуске».

Читайте все, что пишут пользователи. Даже если это отправлено на адрес непишимнебольше.

Семь бед – один ресет

#ПоговоркиПродуктолога

Иллюстрация к посту

243. Фигма – лучшая документация

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

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

Бывает продакт описывает логику в техническом задании, но это случается редко. Обычно задачи ставятся в виде бедно оформленных карточек и обсуждаются устно и в чатах. Что делать менеджеру, кто придет через пару лет и будет пытаться разобраться «как это работает»? Я нашел выход – это Фигма.

Я прошу UX-дизайнера прорабатывать вместе со мной все состояния системы и фиксировать их в фигма макетах. Мы записываем комментарии по логике работы рядом с макетами на ярких плашках. Фигмовские нативные комментарии используем только для обсуждений, логику в них не пишем. Логика должна быть в виде простого текста рядышком с макетом.

Правильно сделанные макеты в Фигме – хорошее описание системы. Оно наглядно и понятно всем участникам – бэку, фронту, QA, менеджерам.

Конечно, макеты быстро устаревают. Но их в любом случае нужно делать, так что это как бы «бесплатная» документация. Нужно лишь проработать все состояния и дополнить их текстовыми комментариями.

Так вот какие они – «после праздников»

#ПоговоркиПродуктолога

Заставь айтишника праздники отмечать, он себе аптайм расшибёт

#ПоговоркиПродуктолога

242. О сложных процессах

Коллега рассказывал как работал в жутко секретном отделении немецкого автопроизводителя:

— У нас компьютеры блокировались с помощью usb-токена. Вставляешь такую флешку в комп и он работает. Вынимаешь – блокируется. Уйти из комнаты, не заблокировав компьютер, не выйдет, потому что этот же токен открывает дверь. Хочешь сходить в туалет – вынимаешь из компьютера флешку, с ее помощью открываешь дверь помещения. Выйти вместе с коллегой из комнаты не выйдет – за этим следят камеры.

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

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

— Да ну, брось ты. Все эти стандарты безопасности сделаны для успокоения головного офиса. С ними работать невозможно. Поэтому все файлы по работе мы пересылали друг другу через личные сообщения Вконтакте.

Две важные вещи о процессах: они должны быть простыми и уметь адаптироваться. В противном случае их быстро хакнут и начнут тайно саботировать.

Кто на удалёнке, тот не пьет шампанское

#ПоговоркиПродуктолога

С Владимиром, автором Product Management мы давно «дружим каналами» и являемся почитателями творчества друг друга. У него просто кладезь полезной информации, проблема, что много всего разного. Поэтому вот подборка самого лучшего за год. В этом году немало было про собеседования и устройства на работу. Итак.

Подборка самых полезных постов 2022 года с канала @ruspm:

– 50 вопросов на собеседовании продакта и 50 ответов на них
– Резюме продакт-менеджера, с которым берут в Microsoft

🔥 12 постов с советами от продактов из США/Европы: один, два, три, четыре, пять, шесть, семь, восемь, девять, десять, одиннадцать, двенадцать.

– Как лучше понимать своих коллег и сотрудников
– 25 ситуаций в которые попадает каждый продакт

– 4 совета как продемонстрировать компетентность на собесе
– 15 красных флагов в вакансиях продакт-менеджера

– Как продавать дорогие продукты/услуги
– 45 способов продуктового маркетинга без бюджета

– Как конкурировать с МЕГАКОРПОРАЦИЕЙ
– Приоритизация идей и гипотез без сложных методологий

– 5 ошибок при проведении исследований
– Как завоевать и удержать доверие своей команды

– Лучшие бизнес-эссе Пола Грэма
– 10 заблуждений продакт-менеджера и его команды

– Список ошибок-искажений в работе продакта
– 4 совета по работе с метриками и целями
– Прокси-метрики и как их использовать

– 11 полезных привычек для продакт-менеджера любого уровня
– 15 вопросами, которые нужно задать в конце года

#партнерскийпост

242. Сделать себя (не)заменимым

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

Мне такое поведение не понять, потому что я наоборот стараюсь стать самым заменяемым сотрудником. Делать любое дело так, чтобы в нем могли разобраться коллеги.

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

Я завожу ящик для инвойсов (если его нет) и подписываю на него бухгалтерию. Я копирую все переписки с дизайнером и делаю из них документацию в wiki. В следующий раз, когда появляется новый контрактор, я просто шлю ему ссылку на готовую инструкцию.

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

Главный принцип: Неполная быстрая документация – намного лучше полной, но ненаписанной.

Я стараюсь быть заменяемым и прозрачным. Почему-то за 20 с лишним лет меня за это ни разу не уволили.

Бадди познается на корпоративе

#ПоговоркиПродуктолога