- Кто такой Product manager?
Откуда это все пошло? С западной части США. Почему оттуда? Потому что именно там, в Юте, был утвержден Agile Manifesto с его «product owner» в 2001-м. Потому что именно благодаря Сан-Франциско и его «Силиконовой долине» в начале 21 века стало широко распространено понятие «стартап», и именно в стартапах возникла глобальная потребность в «product managers». И именно там находится штаб-квартира «Яблока», продемонстрировавшего миру, что может случиться, если продуктом займется хороший product manager.
Ладно, так кто же такой менеджер продукта?
Согласно Википедии – «…человек, отвечающий за создание новых продуктов, анализ рынка, ассортиментную политику и бла-бла-бла…». Или вот еще: «…задача продукт-менеджера — определить концепцию продукта и стратегию его развития. Продукт-менеджер задает критерии успеха и принимает решения…». Уже лучше, но все еще водянисто. Нужно проще.
Смотрим в историю. Когда появились продукт менеджеры? Тогда, когда очевидные потребности людей уже были удовлетворены и необходимо было найти или создать новые. Когда тысячи стартапов пробовали делать десятки тысяч разных продуктов и никто не мог сказать, какой из них будет нужен потребителю. Они даже не знали, кто их потребитель. Короче, всем нужен был ответ на вопрос «ЧТО делать?». И менеджеры продуктов его дали.
Итак, менеджер продуктов — это про «ЧТО». Если смотреть через призму проектного управления, то это про содержание. Например, в PMBoK разделяют project scope и product scope , потому что первое, это все-таки про «как», а вот второе, это как раз «что». Кстати, про проектное управление…
- ProductM vs ProjectM
Чтобы никто не путался, сразу определим разницу между менеджером продукта и менеджером проекта:
- Первый – постановщик задачи, второй – контроллер исполнения.
- Первый говорит, что делать, второй – кто, когда и как это будет делать.
- Это не может быть один человек, если только он не страдает раздвоением личности.
Часто говорят, что менеджер продукта отвечает за то, чтобы «делать правильные вещи», т.е. за результат, а менеджер проекта за то, чтобы «делать эти вещи правильно», т.е. за эффективность. Ну че тут сказать, правильно говорят, чертяги.
Как правило, эти двое, если они работают вместе, балансируют на грани того, чтобы навалять друг-другу, потому что один всегда хочет сделать лучше, а другой – быстрее и дешевле. Но это, в целом, не мешает им делать хорошие продукты.
Для закрепления образа менеджера продукта вспомним еще одного крутого типа:
- Что должен уметь product manager?
А вот реально, что? И как этому научиться? Вот тут появляются проблемы. Менеджер продукта – это созидатель, человек творческий. Как можно научиться творчеству? Очень долго время люди считали, что способность творить – это дар, ему невозможно научиться. Сейчас процесс творчества стал лучше детализирован, появились определенные технологии сбора информации с потребителей, людям помогают развивать эмпатию, благодаря которой они могут лучше понять потребителя. Т.е., в-принципе, тут есть чему поучиться.
И все же это далеко не Body of Knowledge, как PMBok. Есть ощущение, что такого свода знаний для менеджеров продуктов не появится, и искать идеальный набор скиллов для менеджера продукта придется каждому самостоятельно, ну или в небольших кучках. А это уже сам по себе творческий процесс. Поэтому если Вы не можете по достоинству оценить Бетховна, Курта Кобейна,и Эминема (именно всех троих) - не мучайтесь, в Вас нет чувства прекрасного, и менеджером продукта, Вам, скорее всего, быть не удастся.
Строго говоря, не существует вуза, специальности или дисциплины, после изучения которой человек был бы (пусть даже теоретически) готов к тому, чтобы стать менеджером продукта. И наоборот, человек, который ни черта не разбирается в программировании, в управлении проектами, не имеет образования маркетолога, реально может стать успешным продукт менеджером. Забавно, да?
И все-таки попробуем определить, что должен делать менеджер продукта, чтобы успешно отвечать на вопрос «Что?».
- Так что же должен делать менеджер продукта?
Это если коротко. Заметьте, тут достаточно много скиллов, которые могут быть оценены только субъективно. Как, например, понять, слышит этот чел потребителя или нет? Как вообще отличить хорошего менеджера продукта от плохого, например, на собеседовании? Тут сильно поможет обращение к прошлому опыту:
- Какие продукты у него были ранее?
- Были ли они успешны?
- Если нет, то почему?
- Что он про это говорит?
- Ищет он проблему в себе, или списывает на обстоятельства?
Но давайте, все-таки, разберем эти 5 пунктов. По буковкам.
- Знать рынок и конкурентов.
Тут все просто. Чтобы ответить на вопрос ЧТО, нужно знать, для КОГО, а также понимать, чего им пока не предложили остальные. Найти, у кого проблема, понять, кто его проблемы пытается решать, и почему у них не получается.
- Слышать потребителя.
Не нужно быть богом, нужно быть чиновником. Нет, не в том плане, что бюрократом, хотя об этом еще будет дальше, а в том, что чиновник, по замыслу – слуга народа. По-английски, кстати, так и звучит: «civil servant». Нужно быть гипервнимательным к тому, что говорят потенциальные клиенты, и реально хотеть им помочь. Нужно слышать, что говорят продажники, и помогать им тоже. Нужно учитывать, что говорят разработчики. Помогать не обязательно. Шутка.
В общем, нужно уметь заметить проблему по вершкам, едва вырастающим из земли среди сорняков, и уметь докапываться до корней. Вспоминаем Форда.
- Точно определять, что именно должно быть сделано.
Насколько гибким нужно быть при сборе информации (с потребителей, с разработчиков, с продажников), настолько четким нужно быть при формулировании требований к продукту. Все должно быть максимально однозначно. Об устной постановке задач разработчику и речи быть не может, поэтому нужно уметь хорошо писать. Хорошо – значит коротко, но полно и понятно.
Если в требованиях есть какие-то неопределенности, которые нужно снять – нужно снять их. Не можете сами – попросите кого-нибудь поработать аналитиком.
- Описывать требования к продукту и всегда держать их в актуальном состоянии.
Это не про план, это скорее про большую волосатую цель. Про то, куда мы хотим прийти. Такой документ, в котором описывается, для кого это продукт, какие проблемы он должен решать, каких принципов стоит придерживаться в разработке, кто его ключевые потребители, их истории и так далее, вплоть до бэклога, который, кстати, тоже нужно содержать в порядке.
Да, это такая своеобразная бюрократия. Да, это много букв. Но для продуктовой команды это и компас, по которому они будут сверяться в пути, и показатель серьезности ваших намерений (если у Вас в бэклоге хаос, значит Вам класть на этот продукт, а тогда и команде тоже есть смысл класть).
- Разрабатывать презентации и инструкции для тех, кто продает продукт
Если Вы не можете продать этот продукт, то, наверно, никто не сможет. Но, даже если Вы его продаете, нужно еще научить этому продажников. Часто это напоминает обучение обезьянок тому, как носить очки. Представляю, как обучал продажников Форд:
- Автомобиль.
- Лошадь.
- Ав-то-мо-биль!
- Ло-шадь!
Это, конечно, шутка. Про обезьянок, не про Форда. С продажниками нужно дружить. Ведь если они не захотят или не смогут продавать Ваш гениальный продукт, он уйдет в небытие. Это легко представить, поскольку практически у любой компании на рынке 1С продукт не один: кто-то торгует коробками, кто-то продает разного рода услуги. Если Ваш продукт продажнику не понятен, или продавать его не получается, он будет продавать другие коробки или услуги.
Так что дружимся, учим, помогаем. Да и если приглядеться, продажники – классные ребята, хоть и другие.
- Каким командам нужен менеджер продукта?
От красивых сказок идем ближе к реальности. Где будет востребован такой герой? Смотрим исключительно на рынок 1С.
a) 1С и партнеры-разработчики.
Точно не будет лишним в продуктовой разработке. Думаю, если бы у каждого продукта, выпускаемого 1С и партнерами, был хороший продукт-менеджер, они бы не выглядели так:
Ведь можно делать так:
Да и сами продукты были бы более сфокусированы на проблемах клиента. Ведь проблема существующих продуктов 1С и Ко именно в этом – не всегда понятно, для кого они сделаны. Достаточно часто на партнерском форуме приходится слышать от разработчиков 1С ответ «Мы учтем ваши пожелания, но непонятно, когда мы это сможем сделать». И такой ответ встречается на вполне разумные пожелания, поддерживаемые множеством участников форума.
Одна из основных сложностей 1С в этом плане – необходимость разрабатывать максимально широко применимые продукты. Очень сложно угодить толпе, и уж тем более утопично пытаться прислушиваться к ней. В итоге, если попробовать нарезать разработку продукта слоями, в случае с 1С получится модель «Анархия разработчиков»:
Многие партнеры 1С, кстати, наоборот, неплохо понимают потребности их клиентов. Их продукты более узкоспециализированы, а значит, понять, что именно должен давать продукт пользователю, существенно проще. Но у них, к слову, есть другая проблема, приводящая к модели «Красиво, но опасно»:
Ну, вы поняли. В общем, рекомендую 1С искать менеждеров продуктов (а в случае с 1С, можно даже менеджеров подсистем) в рядах партнеров-разработчиков. Наверняка есть спецы, которые неплохо разбираются в предметной области, имели опыт участия в продуктовой разработке, или участвовали во множестве проектов и могут сформулировать, что именно хочет клиент.
Для компаний, разрабатывающих продукты на платформе 1С, это вобще «must have», потому что не имея таких ресурсов, как у 1С, невозможно сделать продукт «для всех и ни для кого», который бы при этом хорошо продавался.
b) Проектные команды.
Казалось бы, а зачем оно им? Они же не разрабатывают продукты.
Во-первых, это пока. Хорошо понимая определенную отрасль, грех не сделать для нее специализированное решение. И если вы - проектная команда, но не видите, какой продукт можно сделать для отрасли, с которой вы много работаете, или считаете, что существующие продукты 1С, партнеров, или сторонних вендоров полноценно закрывают потребности рынка – вы, наверно, плохая проектная команда. Даже к 1С: Бухгалтерии постоянно выходят какие-то примочки типа электронной сдачи отчетности, проверки контрагентов, автоматического распознавания и ввода накладных и т.п.
Во-вторых, в проектах, независимо от того, по какой технологии они выполняются, должен быть кто-то, ответственный за систему, за то, чтобы она удовлетворяла требованиям, снятым с заказчика. И это точно не РП. Этот кто-то – не совсем менеджер продукта. Он еще не говорит самостоятельно, ЧТО должно быть сделано, он, как правило, узнает это у клиента, у одного конкретного клиента. Но может повлиять на это решение, подсадив клиенту пару идей, или высказав свое авторитетное мнение. Этакий эксперт-методолог. Это и есть будущий менеджер продукта.
c) Продавцы и разносчики пиццы ИТС и коробок 1С.
Им не нужно. Точка.
Вместо красивого конца:
Мое мнение, большинство решений на рынке 1С имеют сложные интерфейсы, они не всгда удобны для пользователя, и, самое главное, часто они не решают проблем клиентов, для которых предназначены. Продающие сайты и служба поддержки многих продуктов также оставляют желать лучшего. Но появляются и очень приятные решения. Приятные в том плане, что они четко закрывают некоторые насущные проблемы клиентов, они технически интересные, визуально приятные, хорошо обернутые маркетинговыми материалами. А это значит, что где-то за ними стоят менеджеры продуктов, пусть даже они сами так себя и не называют.
Мне бы очень хотелось, чтобы все, кто имеет какое-то отношение к продуктовой разработке, принимали во внимание эту роль и осознавали ее важность. Тогда, возможно, мы через какое-то время увидим линейку принципиально иных программных продуктов на платформе 1С. Таких продуктов, которые клиентам не придется сравнивать с импортными аналогами, и которыми мы сможем гордиться.
