Назад

# Проблема приемного папы. Процессная должостная инструкция для продуковнера зрелого крупного продукта. Tags: менеджмент, управление Есть у нас такая должность: "Руководитель продукта". Можно его назвать продуктологом или продуктовнером. Он - самый заинтересованный в продукте чувак, продвигает его, развивает, защищает, выбивает под продукт бюджет и делает другие полезные вещи. Мы называем его "папой продукта", т.к. это ментально очень схожие понятия. Если не понимаешь что ты должен сделать в конкретной ситуации - представь, что продукт - это твой ребенок: защити, покачай, если критикуешь, то аккуратно, чтобы не было лишней демотивации у команды. Это все лирика, но отсюда выходит главная проблема нашего подхода - такого продуктолога невозможно нанять, восспитать, это изначально должен прийти человек с горящими глазами и создать с нуля продукт. Поэтому у нас часто "папа приемный". Так как продуктолог - должность очень загруженная, часто приходится идти на компромиссы, выбирать приоритеты, на какие-то вещи просто не остается сил. В этом самая большая проблема, т.к. продуктолог - должен быть тем человеком, который видит границы в продукте, которые нарушать нельзя, он должен чувствовать компромиссы, на которые идти нельзя принципиально - продуктолог должен стукнуть кулаком по столу и сказать: "Мне плевать, что мы потеряем этого крупного клиента, но иначе мы потеряем весь продект!". Получилось немного пафосно, но именно такого поведения от продуктолога и ждешь. Проблема в том, что "приемный папа" такими способностями не обладает и может легко повестись на ложное направление или долго не замечать критичных болячек продукта, пока продукт от них не умрет. Далее идет набросок решения этой проблемы. Что если мы пропишем в должостной продуктолога простой цикл: возьми первую подсистему продукта, изучи ее, опроси клиентов, составь список улучшений, получи результат, возьми следующую подсистему... И так по кругу. Это должно держать продуктолога в тонусе, заставит его погрузиться во все тонкости продукта. Со временем он изучит в нем каждый винтик, осознает каждое принятое решение, собственоручно изучит все боли и радости клиентов. И полюбит продукт <3 :) #### Вводные Для начала, нужно сделать 2 уточнения. Во-первых, мой набросок подходит для зрелого и достаточно крупного продукта (у которого минимум 3 разных подсистем, что их нельзя в одно время удержать в голове). Во-вторых, набросок заточен под наш цикл разработки, который мы используем в зрелых продуктах: - выпускаем новую версию 1 раз в месяц - чередуем месяц разработки новых фич и месяц без фич, для починки проблем на которые вечно нет времени. Для исполнения должостной, продуктолог должен завести перечень всех подсистем своего продукта. Для примера возьмем наш продукт биллинг, список подсистем мог бы быть такой: интеграция с оборудованием, crm, helpdesk, управление абонентами, платформа, установка, масштабирование, интерфейс кассира, платежные системы, миграции, интеграции... #### Набросок должостной **Двух месячный цикл:** - в начале 1 месяца выбираем одну подсистему продукта, по порядку - погружаемся в вопрос, подтягиваем знания, читаем информаци по конкурентам, рынку, тренды и.т.д. - проводим проблемные и продуктовые интервью по подсистеме с 3-5 клиентами: - понимаем как клиент работает с подсистемой - получаем проблемные места, понимаем как их улучшить - составляем статью "1 день из жизни клиента", описывам по шагам что он делает и как взаимодействует с подсистемой. И прочий кастдев. Слово в слово потом это можно использовать как основу для хорошей новостной статьи о новой версии - разгребаем беклог, формируем на следующий (2й) месяц задачи для разработки по подсистеме - в 1й месяц у разработчиков - месяц багфиксов, 2й месяц у них - месяц фичей - в конце 2го месяца принимаем работу от разработчиков, делаем релиз - 3й месяц - начинаем сначала, по новой подсистеме #### Вывод Можно это назвать CustDev-цикл для продуктолога. Такой продолжителный цикл удобен, когда подсистемы могут сильно отличаться по технологиям, когда с ними работает разный персонал (например, процесс установки или управление оборудованием и работа в crm) - продуктологу нужно время, чтобы хорошо вникнуть в тему, вспомнить все нюансы. Плюс, у него полно других задач, так что времени на изучение останется не так много и срок в месяц - вполне оправдан. Часть по работе с клиентами и изучение трендов отрасли позволит оставаться актуальным решением на рынке, активно развивать продукт. Бонусом может идти статья в блог, о том как мы провели кастдев с 5 клиентами: рассказ как у их сотрудников проходит рабочий день, как они взаимодействуют с нашим продуктом, какие проблемы испытывают и как мы эти проблемы устранили. Если кастдев будет правильным, то список болей из статьи может сильно срезанировать у читателя, часть с решением покажет какие мы молодцы, а описание кейсов и рабочего для - будет просто интересно почитать другим клиентам. Из проблем я вижу: - долгий цикл по подсистемам, если их больше 12 - то это уже больше двух лет без значимых фичей в подсистеме. В принципе, ни кто не мешает решать "горячие" проблемы, которые приходят от клиентов во время "чужого" цикла другой подсистемы - разработчики часто погружены в 2-3 подсистемы и будет сложно вовлечь всю команду разработки в проработку 1й подсистемы. Это может касаться опыта, предпочтений и технологий подсистемы. Плюс, они будут мешаться друг другу -> повышается нагрузка на менеджмент (настройка всех на 1 общую цель, координация работы). Но с другой стороны, это снижает бас-фактор, прекрасно шарит знания и технологии внутри команды.