В первую очередь следует разъяснить, что именно мы подразумеваем под словом «продукт». В контексте программного обеспечения продуктом может быть сайт, приложение или онлайн-сервис с которым взаимодействует пользователь. В зависимости от размера организации и выпускаемого продукта, продакт-менеджер может отвечать как за целую отрасль (например, мобильные приложения), так и за ее отдельную часть (направление потока заказов на продающий сайт с различных устройств).
И это сбивает с толку, так как в большинстве случаев продукт представляет собой что-то, что вы продаете людям. В частности, в сфере электронной коммерции продакт-менеджеров зачастую путают с отраслевыми менеджерами, в задачу которых входит реализация и мерчендайзинг продукции на продающих сайтах. Так что «продукт» не самый уместный здесь термин. Но что есть, то есть, и потому именно это слово будет использоваться для дальнейшего раскрытия данной профессии.
Дабы определить роль продакт-менеджера, следует обратиться к точке зрения Марка Андрессена (Marc Andreessen) на наиболее важную часть любого стартапа:
«Качество ключевого продукта в стартапе можно определить тем, насколько он интересен для клиента или пользователя: насколько прост в обращении? Как широк функционал? Как быстро продукт работает? Насколько качественно и эргономично он исполнен? Как много (или скорее, как мало) ошибок, багов в нем? Объем рынка для стартапа как раз и будет измеряться числом пользователей. Здесь крайне важно достигнуть тождественности типа «продукт-рынок». Суть в освоении хорошего рынка с продуктом, способным удовлетворить этот рынок».
И хотя Андрессен писал все это для стартапов, важность последнего предложения о тождественности рынка-продукта справедлива для любой организации — неважно, выпускает ли она новый продукт на рынок, проводит редизайн существующего, или что-то среднее. Выше описана некая универсальная дорожная карта к успеху, то самое ядро ответственности, которое ложится на плечи продакт-менеджера.
Можно выделить три составляющие, которые менеджер по продукту никогда не должен упускать из виду:
- Основным показателем успеха является благополучие бизнеса и ценность, которую продукт представляет для пользователей.
- Все начинается с четкого понимания целевого рынка и его потребностей, соответственно, основной целью остается качество продукта.
- Требуется непрерывный цикл планирования и исполнения для удовлетворения потребностей рынка.
Итак, каким образом все вышесказанное соотносится с ежедневными обязанностями продакт-менеджера? Вопрос слишком обширен, чтобы дать простой ответ, но в качестве некоего вступления приведем список общих задач менеджера по продуктам, составленный Марти Кэйгеном (Marty Cagan) для своих сотрудников:
- Выявление и оценка пригодности и целесообразности возможностей продукта
- Обеспечение поставки нужного продукта в нужное время
- Создание стратегии и технологической «дорожной карты» для разработки
- Обеспечение соблюдения командой условий дорожной карты
- Продвижение продукта внутри команды и среди коллег
- Представление клиентов в процессе производства продукта
Но прежде чем продакт-менеджер будет способен выполнить вышеперечисленные пункты, следует задать пару нетривиальных вопросов. Во-первых, действительно ли менеджеры по продукту необходимы компании? И если да, то какими качествами должен обладать профессиональный менеджер? Также, каким образом его роль вписывается в структуру организации? Данные вопросы следует изучить более подробно.
Зачем компании продакт-менеджеры?
Значимость менеджера по продукту не всегда ясна для некоторых компаний. Самые распространенные возражения звучат следующим образом:
- «У нас довольно широкий штат сотрудников, чьи обязанности покрывают каждую из этих задач»
- «Мы не видим, как подобный кадр поможет нам заработать больше денег»
- «Продакт-менеджер лишь замедлит нашу работу»
- «Мы не хотели бы доверять контроль над продуктом кому-то еще» (Да, это обычно вслух не говорят)
Эти вопросы кажутся обоснованными, но только в том случае, если роль менеджера не до конца понята — или в компании сидят неквалифицированные продакт-менеджеры, невольно подпитывающие подобные представления.
Правда в том, что для максимальной эффективности роль менеджера по конкретному продукту не должна выполняться несколькими людьми. Для продакт-менеджера крайне важно видеть всю картину целиком — как с точки зрения стратегии, так и воплощения — дабы принимать верные решения в отношении продукта. Если знание о различных этапах процесса держат в уме разные люди, то ни у кого не сформируется целостного взгляда на задачу, и вся ценность данной роли попросту пропадет.
Рассмотрим два основных преимущества, привносимых менеджером по продукту.
1. Продакт-менеджеры обеспечивают обусловленный рынком подход к делу
Ключевым аргументом в пользу такого сотрудника будет то, что он способствует движению компании, обусловленному потребностями и задачами целевого рынка. Как сказала Барбара Нельсон (Barbara Nelson) в «Who Needs Product Management?»:
«Куда проще идентифицировать проблемы рынка и разработать решение, исходя из них, нежели найти покупателя для вашей существующей технологии».
При правильном исполнении, концентрация на рынке приводит к долгосрочному, устойчивому и выгодному бизнесу, так как компания будет сосредоточена на решении проблем рынка, вместо того, чтобы искать применение новым разработкам — не факт, что полезным для пользователей.
Акцент на рынок важен потому, что такие компании куда прибыльнее тех, что руководствуются прочими факторами (точнее, на 31% эффективнее, согласно Джорджу С. Дэй (George S. Day) и Пракашу Недунгади (Prakash Nedungadi).
Это не значит, что следует сосредотачиваться на постепенных изменениях вплоть до устранения инновационных продуктов. Идентификация рынка заключается не только в обнаружении требующих исправления проблем (например, «60% пользователей уходят со страницы, давайте это исправим»), но и в создании новой продукции для удовлетворения невысказанных потребностей («Ужасный смартфон — давайте сделаем лучше»).
2. Продакт-менеджеры дают вам существенное преимущество во времени.
Второе главное преимущество менеджеров по продукту заключается в существенном сокращении времени достижения поставленных целей. Выверенный и сообразный подход к производственному процессу, возглавляемый профессиональным менеджером, способен сократить как время выхода продукта на рынок, так и время до получения прибыли.
Причина быстрого достижения результата в том, что продакт-менеджер ответственен за определение того, что стоит производить, а что нет. Соответственно, меньше времени уходит на проверку гипотез и больше — на разработку продукции, которая ценится на рынке.
Подобный подход также позволяет организации сосредоточить работу персонала над продуктами, имеющими высокие шансы на успех, нежели раскидывать сотрудников по множеству проектов, в рыночном успехе которых никто не уверен.
Характеристики хорошего продакт-менеджера
Большинство из нас знакомы с понятием Т-паттерна у людей, обладающих глубокими познаниями в одной или двух областях, с разумным уровнем понимания разнообразных дисциплин, относящихся к их основному полю деятельности. В 2009 году, Билл Бакстон (Bill Buxton) написал интересную статью для Businessweek, в которой он описывал к «I-образных» людей:
«Они плотно стоят ногами в почве практического мира, и тем не менее тянуться достаточно высоко, чтобы достать головой облака тогда, когда им нужно. Более того, они одновременно умудряются заполнить все пространство между этими двумя точками»
Это хорошо описывает ту уникальную смесь навыков, которой должен обладать профессиональный продакт-менеджер. Во-первых, он должен держать голову высоко, то есть быть лидером, способным смотреть в будущее и мыслить стратегически. Такие специалисты должны иметь четкое видение того, где следует разместить продукт, и уметь эффективно следовать данному представлению. Более того, они должны уметь показать своей команде пути к этому. То есть, буквально показать: через наброски, прототипы, чертежи — через все, чем можно донести сообщение. Также они должны быть гибкими и способными поменять курс, когда это необходимо; например когда того требует рынок, или ожидания существенно изменились, или подвернулась интересная бизнес возможность.
Но хороший менеджер также плотно стоит ногами на земле. Он уделяет внимание деталям и знает всю подноготную продукта. Он самый активный пользователь своего продукта, его самый преданный фанат и ярый критик. Он знает каждый сложный аспект, который должен быть проработан в ходе каждого решения касательно продукта. И он способен принимать эти решения оперативно, грамотно распоряжаясь всей имеющейся у него информацией.
И что наиболее важно, продакт-менеджер знает, как завершить процесс. Он знает, как с помощью своей команды выпустить продукты и усовершенствования в мир, где целевой рынок сможет их использовать и высказать свое мнение.
Проще говоря, менеджер по продукту настолько же дальновиден, насколько деятелен, он и управляющий и разработчик. И он должен уметь плавно переключаться между этими обязанностями, в любой момент.
Лидер и член команды
Весьма сложно быть одновременно лидером и членом команды. Первая же сложность заключается в том, что коллаборационизм зачастую путают с консенсусом. И это не тот случай. Результатом консенсуальных решений становятся «разбавленные», ничем не примечательные продукты, которые в результате бурных обсуждений, мозговых штурмов и уступок при их разработке, стали лишь тенью первоначальной задумки. Подобный подход также изматывает команду разработчиков, ибо в результате они получают не то, на что рассчитывали, а лишь небольшую часть этого.
При совместном подходе все обстоит иначе. Люди понимают: несмотря на то, что у каждого есть право голоса, не все имеют доступ к принятию решений. Все имеют право на открытое высказывание собственного мнения, на ярые дискуссии касательно должного порядка вещей, на нахождение компромиссов. Но это определенно не означает, что все должны безоговорочно соглашаться с каждым решением.
Первый шаг к выработке подобного подхода заключается в нахождении хорошего лидера. Как вы уже могли предположить, менеджер по продукту является лицом, принимающим окончательные решения. Но это работает только в том случае, когда он является уважаемым и доверенным лицом, способным донести свое видение до команды и принимать решения равным образом выгодные как для клиентов, так и для организации. Он также должен уметь признавать свои ошибки и делать все для их исправления.
Этот пост не о лидерстве — таковых уже создано достаточно. Но хочется привести один совет касаемо лидерских качеств от французского авиатора и писателя Антуана Де Сент-Экзюпери, который помог уже многим:
«Если вы хотите построить корабль, не посылайте людей рубить лес, не назначайте им конкретные участки работы и задания. Лучше привейте им тоску по бескрайней ширине синего моря».
Что в вашем случае означает «бескрайняя ширина синего моря»? Как вместо того, чтобы направлять людей на разработку множества опций, вдохновить их на размышления о том, как продукт способен помочь пользователям добиться их целей? Именно так вы сможете объединить команды одним общим видением.
Итак, как же хороший лидер способствует развитию подобной коллаборационистской культуры? Он добивается этого, создавая окружение и производственные процессы, позволяющие сотрудничеству подпитывать самое себя, а также понимая то, что все люди разные, и каждый из них может непредсказуемым образом отреагировать в какой-то момент.
Чтобы создать правильную среду и процессы для совместной работы, следует в первую очередь сосредоточиться на физическом окружении. Убедитесь, что рабочие места позволяют членам команды проводить импровизированные дискуссии друг с другом и, в то же время, способны полностью оградить их от внешних отвлекающих факторов, позволяя сосредоточится на работе на какой-то период времени.
Офис компании MailChimp являет собой прекрасный пример соблюдения вышеперечисленных условий. Им удалось создать рабочее пространство, идеально подходящее для совместной работы, построенное на соблюдении следующих принципов.
Объединение и взаимовыгодное сотрудничество
Вместо сегрегации команд, объедините людей согласно их персоналиям и проектам, над которыми они работают. Это приведет к ценным дискуссиям, которые не случились бы, сиди каждый в своем «бункере».
Содействие движению
Открытые столы, диваны, стойки: все эти элементы побуждают людей к коммуникации и совместной работе, когда это необходимо.
Идеи, идеи повсюду
Разместите на стенах и рабочих досках наброски, дизайны, списки приоритетов и технические дорожные карты. Это не только облегчит общение, но и позволит любому внести предложение касательно идей, над которыми работают другие.
Обеспечьте конвергенцию
Общее пространство для ланча (и кофе-брейков!) также важно, ибо это позволит сталкиваться людям, которые обычно не работают над одним и тем же проектом. Опять же, это приведет к возникновению интересных идей и перспектив.
Обеспечьте пространство для отдыха
Шум и гам рабочих пространств обладает потрясающей энергетикой, но иногда это здорово отвлекает. Команде и ее членам время от времени нужно тихое место для работы, так что убедитесь, что в их распоряжении имеются переговорные или комнаты релаксации, где никто им не помешает.
Рабочее пространство играет куда большую роль, чем может показаться на первый взгляд. Для многих студий, создавших творческую, приветливую атмосферу, все приложенные усилия быстро окупились. Подобная среда повышает производительность труда, а приятное окружение (и вкусный кофе на вашей кухне) могут побудить клиентов выбрать именно вас.
Стив Джобс очень хорошо понимал всю важность физического рабочего пространства. В биографии Уолтера Айзексона (Walter Isaacson) цитировалось его высказывание касательно дизайна нового кампуса компании Pixar:
«Если здание не поощряет [совместное творчество], вы потеряете множество инновационных идей и той магии, что порождается интуицией. Так что мы спроектировали здание, которое побуждает людей выйти из офиса и тусоваться в центральном атриуме, встречаясь с людьми, с которыми они иначе бы не увиделись» .
Понятно, что физическое пространство лишь одна часть уравнения. Большая часть работы сейчас проводится удаленно, и в нашем распоряжении достаточно инструментов, чтобы сделать ее эффективным и полезным опытом для всех вовлеченных. Коммуникационные инструменты типа Campfire, HipChat и Slack, инструменты для совместной работы над проектами на подобие Trello, Basecamp и Jira, обменники исходным кодом вроде GitHub and Bitbucket — с такими сервисами уже не остается причин заставлять всех физически находиться в одном и том же рабочем пространстве постоянно. Да, на определенных стадиях все еще остается много вопросов, которые следует решать при личной встрече, но даже это может происходить в цифровой среде.
Итак, чем следует заняться после проработки физических и цифровых рабочих пространств? Следующего термина многие пугаются. Многие считают, что слово «процесс» есть синоним к «тому, что мне следует делать вместо работы». Но многие соответствующие, верно направленные процессы вполне имеют право на существование.
Цитируя Майкла Лоппа*: «Инженеры не ненавидят процессы. Они ненавидят бесполезные процессы ». Когда дело доходит до создания культуры совместного творчества, несколько процессов — полезных процессов — могут облегчить жизнь всей команде.
*(Michael Lopp (род. 1970 в Калифорнии), автор веб-комикса, менеджер по разработке программных решений и блогер)
Один из основных процессов, требующих отладки, это регулярная обработка отзывов о дизайне, разработке и бизнес решениях. Загвоздка в том, что данный процесс может легко выйти из под контроля, так как мы просто не очень хороши в предоставлении (или восприятии) мнений. Мы склонны в первую очередь видеть негативные стороны чьей-либо идеи, и зачастую сразу переходим осуждению. Это сразу заставляет человека на другой стороне перейти в глухую защиту, результатом чего обычно становится приведение пустых аргументов и потеря доверия.
Есть лучший способ. В интервью на тему критики и суждения, французский философ Мишель Фуко (Michel Foucault) описал пользу любой позитивной критики. По его мнению, критика должна сосредотачиваться не на том, что не работает, но на выдвижении идей, направленных на исправление этого:
«Не могу удержаться от мечты о такой критике, которая будет не осуждать, но претворять в жизнь сочинение, книгу, предложение или идею; будет бороться с пожарами, наблюдать за ростом травы, слушать шепот ветра, ловить пену морскую и рассеивать ее. Она будет множить не суждения, но следы существования; будет вызывать их, вытаскивать из небытия. Возможно она даже будет изобретать их иногда — это всяко лучше. Критика, выносящая приговор, нагоняет на меня сон; мне хотелось бы слышать критику, стимулирующую скачки воображения. Она не будет независимой и привлекательной, но будет нести знаки предстоящей бури»
Учитывая вышесказанное, обратимся к процессу, применяемому Джаредом Спулом (Jared Spool) и его командой в User Interface Engineering. Ими он применяется конкретно для критики дизайна, но его также можно использовать для работы с любым фидбеком:
- Человек, представляющий свою идею или работу, описывает таким образом проблему, которую пытается решить.
- Если все соглашаются с проблемой, команда двигается дальше. Если согласие в наличии потребности решения проблемы не достигнуто, необходима некая дискуссия для прояснения. Хотя, надеемся, этот шаг не является обязательным.
- Далее, представитель обращается к идее или демонстрирует работу команде. Цель не только показать конечный продукт, но и объяснить стоящий за ним мыслительный процесс. Представитель должен сосредоточиться на том, как идея способна решить проблему, с наличием которой все согласились.
- Первый шаг к предоставлению мнения заключается в озвучивании людьми того, что им нравится в идее. Это не уловка, чтобы получить некую пресловутую ложку дегтя в бочке меда (в начале и в конце все хорошо, но между тем что-то не так). Этот этап скорее подчеркивает, какой подход к решению проблемы является желательным.
- Критика должна быть целостной, не прямыми нападками типа «Мне не нравится…», но вопросами, связанными с самой идеей. Члены команды будут интересоваться, было ли рассмотрено другое решение, на чем был основан конкретный выбор и так далее. Это дает представителю шанс ответить, если вопрос уже был проработан, или сделать себе пометку к следующему разу, когда будет задан подобный вопрос.
- В конце встречи команда просматривает заметки, отдавая предпочтения понравившимся моментам и возникшим вопросам. Представитель затем возвращается к работе над прочими аспектами идеи.
Как менеджер по продукту, вы ответственны за проведение фидбек-сессий, их полезность и значимость.
Суть совместной работы в том, чтобы участники улучшили идеи, основываясь на лучших составляющих различных мнений и точек зрения. Пока люди уверены, что лицо, принимающее решения (а это дорогой наш продакт-менеджер), наиболее заинтересован в продукте и успехе компании, они не будут против того, чтобы их интересы не учитывались время от времени. Будьте уверены, надежны и решительны — и убедитесь, что каждый чувствует себя уверенно, высказывая свое мнение команде.
Разумеется, обо всем этом куда проще говорить, чем сделать. Менеджер по продукту должен провести команду через совместный творческий процесс, и доверия сначала не будет. Это нормально — доверие требует времени. Живите по этим правилам, ведите всех свои примером, и вы сможете построить культуру совместной работы.
Оратор и переговорщик
Более верно было бы озаглавить данный раздел «Архи-оратор и Переговорщик», так как если есть что-то, от чего продакт-менеджер никогда не устает, так это объяснение людям текущего положения дел. Но вместо рассылки тучи писем, лучше работать настолько открыто, насколько это возможно. Убедитесь, что заметки, наброски, планы и стратегии повсеместно доступны для всей компании все время. Это могут быть расставленные по офису доски для креатива, внутренний сайт или дизайн-пространство. Работа в открытую дает дополнительные преимущества в придании контекста общению: все комментарии и решения будут сосредоточены в одном месте, а не разбросаны по множеству писем (или вот вам вариант похуже: собрание, где никто не делает заметок).
Будучи продакт-менеджером, иногда чувствуешь себя разрываемым на части. Для большинства заинтересованных лиц во главе угла стоят интересы их собственных отделов (что логично — им за это платят). С другой стороны, при переговорах продакт-менеджер должен выбрать лучшее решение из тех направлений, которые избрали заинтересованные лица, и затем грамотно продвинуть его, не отпугнув при этом тех, кому подобное решение не совсем понятно. Это не такая уж и простая задача.
Так иногда себя чувствует менеджер по продукту (на рисунке: центральное панно триптиха «Мученичество Святого Ипполита» Дирк Баутс, 1468).
В дизайн-среде есть фраза для обозначения сложности процесса управления ожиданиями (и утверждениями) различных заинтересованных лиц: разработка комитетом. Как и культура консенсуса, культура разработки комитетом встречается довольно часто, особенно в крупных организациях. Тут будет уместным привести в качестве примера подход, предложенный Спейдером Шнайдером (Speider Schneider) в его статье «Why Design-By-Committee Should Die»:
«Разумно будет слушать, впитывать, поглощать, обсуждать, быть в состоянии защитить любое дизайнерское решение аргументированно и доступно, уметь выбирать момент для защиты и знать, когда необходимо все бросить».
Это не так легко, как кажется. Поэтому, со временем были разработаны приемы систематичного подхода к комитетной разработке.
Отвечайте на любое замечание
Ответ на любое требование, критику, любой вопрос и идею требует времени. Но игнорирование данной задачи отнимет куда больше энергии и времени в дальнейшем. Одно дело — выслушать предложение человека и никак его не использовать. И совершенно другое — не слушать человека вовсе. Так что вместо того, чтобы сталкиваться со сложными последствиями игнорирования чужого мнения, выделите время и давайте вдумчивый ответ всякий раз, когда кто-либо высказывает свое замечание или идею (насколько бы неосуществимым это ни было).
Отмечайте факт внедрения предложения
Когда вы внедряете хорошую идею, не стоит делать это втихую. Ведь это прекрасная возможность доказать, что вы человек гибкий и открытый для мнений и отзывов. Давайте людям понять когда и каким образом их идеям находится применение. И также, хотя это и так понятно, не присваивайте себе чужие идеи.
Когда предложение не проходит, объясняйте причину
Большинство получаемых вами предложений не получится задействовать в продукте. Не стоит заметать их по ковер, так сказать. Принуждая себя быть честным и прямолинейным, говоря о предложении, которому не нашлось применения, вы также учитесь мыслить в рамках внедренного решения и грамотно его защищать в случае необходимости. В определенных случаях вы можете обнаружить, что сам факт того, что вы не внедрили плохую идею, уже является улучшением. Люди в целом спокойно относятся к тому, что их предложения не внедряются, но лишь до тех пор, покуда они знают, что их слушают, и что даже отрицательное решение имеет серьезную мотивацию.
Используйте валидационный блок для защиты решений
В своей книге Undercover User Experience Design, Сеннид Боулс (Cennydd Bowles) и Джеймс Бокс (James Box) объяснили суть валидационного блока (validation stack ) пользовательского опыта, еще одного метода, который можно использовать при защите продуктовых решений. Во время защиты, всегда старайтесь приводить пользовательские данные в качестве аргумента — например, юзабилити-тестирования и аналитику сайтов. Если у вас нет прямого доступа к данным пользователей, подберите исследование, сделанное вами или третьей стороной в смежной отрасли. Если все прочее подвело, обращайтесь к теории. Принципы визуального восприятия, убеждения, психологии и им подобные могут быть весьма полезными при объяснении причины принятия вами того или иного решения.
Эти указания должны облегчить переговоры, касающиеся различных запросов и потребностей заинтересованных лиц. Но помните слова Спейдера: есть время сражаться, есть время отступать. В этом заключается искусство быть хорошим переговорщиком и оратором.
Страстный и чуткий
Менеджеры по продукту питают любовь и глубокое уважение к хорошо спроектированному, качественно изготовленному продукту, как физическому, так и цифровому. И они живут ради того, чтобы создавать подобные продукты. Они те люди, которые приходят на вечеринку и без умолку трещат о новых приложениях или сайтах, или скорее, о неимоверной крутости своего актуального проекта.
И их страсть распространяется не только на продукт, но и на пользователя. Они хорошо понимают рынок: ценности своих клиентов, их приоритеты, взгляды и опыт. Страсть по отношению к продукту бесполезна без эмпатии к его пользователям. Создание хорошего продукта невозможно без понимания того, что происходит в голове у использующих его людей. Если мы хотим предвидеть желания клиентов и провести их по этому пути, важность эмпатии даже не должна обсуждаться.
Квалифицированный и любопытный
Продакт-менеджеры обычно приходят из различных областей, таких как UI-дизайн, программирование и бизнес-аналитика. Чтобы применить свои профессиональные навыки на этом поприще — другими словами, влиться в категорию «l-людей» — им необходимо уметь быстро (и под серьезным давлением) изучить новые навыки. И ненасытное любопытство является необходимым условием для способности к быстрому обучению. Почему? Это доступно объясняет Кэп Уоткинс (Cap Watkins):
«Если вы крайне любопытны, я бы меньше всего беспокоился о ваших прочих навыках. Раз за разом я наблюдаю, как великие дизайнеры приобретают новые навыки и раздвигают границы возможного лишь благодаря любопытству и силе воли. Любопытство заставляет нас не спать всю ночь и изучать новые техники работы в фотошопе. Оно будит нас среди ночи из-за тех проблем взаимодействия, которые мы еще не решили. Я искренне считаю, что это величайшее свойство, которым может обладать дизайнер (черт, да любой работник)».
Хороший менеджер по продукту знает все необходимое для того, чтобы сделать продукт успешным. Он постоянно заботится о мельчайших деталях, равно как и о крупнейших стратегических вопросах. Вместо того, чтобы нагружать себя огромным количеством того, что должно быть сделано, любопытство склоняет его оставаться преданными делу и стать как можно более квалифицированным, дабы принять верные решения.
Надежный и этичный
Хороший продакт-менеджер вселяет веру в команду каждым своим решением. Чтобы быть надежным, он должен быть честным (об этом чуть позже расскажем подробнее), последовательным, и всегда должен принимать ответственность за свои решения. Также он должен уметь признавать свою неправоту, что бывает сложно даже в лучшие времена.
С одной стороны, менеджер по продукту должен быть уверен в принимаемых решениях. Он должен постоянно учиться новому, растить и оттачивать свое мастерство. Теория и техника должна укоренится настолько, чтобы стать второй натурой, краеугольным камнем всего что он делает.
С другой стороны, нужно быть готовым к осознанию того, что некоторые направления были избраны неверно. Вернее, это нужно даже приветствовать. Он должен сомневаться каждый раз, когда представляет решение команде или миру. Признание превосходства чьей-либо идеи и внесение изменений на основе здравой критики творит чудеса в улучшении продукта — и повышает степень доверия команды. Джон Лилли (John Lilly) как-то сказал то, что должно быть своеобразной мантрой всех продакт-менеджеров: «Создавай дизайн, будто ты прав; слушай, будто ты ошибаешься»
Лучшие менеджеры по продукту — это те, что руководствуются сильной и этической точкой зрения на мир. Дискуссия на тему этики только осложнит все, но тем не менее было бы неправильно хотя бы не затронуть сей вопрос. Вкратце, мы не просто создаем продукт, мы оставляем в мире свой след, и у нас есть возможность сделать этот мир лучше. Пожалуй, никто не скажет точнее, чем Майк Монтейро (Mike Monteiro) в своем труде «Design Is a Job»:
«Я призываю всех и каждого из вас браться за те проекты, которые сделают мир лучше, чем он был до этого. Раньше мы искали способ попасть на Луну; теперь же пытаемся найти способ никогда не вставать с постели. У вас есть сила изменить это».
Как нам идентифицировать проекты и проблемы, подходящие под эти критерии? Один из вариантов — обратиться к тому, что Пол Грэм (Paul Graham) называет «проблемная слепота»: наша неспособность определить сложную для решения проблему, в основном потому, что мы попросту сознательно ее не ищем. Как Пол советует с этим бороться? Вместо того, чтобы гадать, какую проблему следует решить, задайте вопрос, какую из своих проблем вы бы попросили кого-то решить для вас.
Другим замечательным источником идей для стоящих проектов может стать поприще социально антрепренерства (например, поиск инновационных решений социальных проблем). Меган Феллоун (Meagan Fallone) составила прекрасный обзор характера и важности подобной работы:
«Мы, в свою очередь можем разъяснить Силиконовой Долине природу связи между функцией дизайна и воздействием на качество жизни человека. Мы считаем пользователей не «клиентами», но людьми, чья жизнь должна стать лучше в результате демистификации и открытого доступа к технологии.
В противном случае, мы не видим места для технологии, как основной потребности человека в развивающемся мире. Устойчивый дизайн продукта должен быть направлен на решение серьезных проблем; для нас это не подлежит обсуждению. Социальное представление само по себе ответственно за обеспечение устойчивости и результативности всех возможных аспектов нашей работы».
Книга «Wicked Problems» является отличным источником идей на тему приложения усилий к значимой работе. Разумеется, люди находят другое определение социально значимому труду. Это нормально — что действительно важно, так это как следует все продумать и выделить то, над чем действительно хочется работать.
Ответственный и гибкий
Дабы вызвать симпатию, продакт-менеджеры любят сетовать на то, что самое сложное в их работе — это куча обязанностей и никакого авторитета. Другими словами, даже несмотря на то, что они ответственны за успех и провал своих продуктов, никто перед ними не отчитывается. Вот почему хорошие навыки в общении и совместной работе так критичны.
Основная причина обилия ответственности за продукт заключается в непреклонности: нежелание делегирования нужных задач и упрямое следование плану, даже когда обстоятельства уже сменились. Вот почему менеджер должен быть гибок. Составление плана критично, и основной частью этого является допущение вероятности изменения этого самого плана при наличии определенной информации.
Эта потребность в гибкости может нервировать некоторых продакт-менеджеров, но это необходимая часть процесса создания отличного продукта. Так что свыкнитесь с неопределенностью, в этой работе ее будет много.
Честно говоря...
Это одна из наиболее важных характеристик продакт-менеджера — та, что превыше всего. Имела место дискуссия с одним из членов команды разработчиков на тему производственного процесса новой продукции, начатого за несколько месяцев до этого. Одним из терминов, которые он использовал для описания нового процесса, было слово «честный».
Казалось бы, ничего особенного, но если вдуматься, то начинаешь размышлять о важности честности в продакт-менеджменте. Все характеристики, изложенные выше, безусловно важны, но без честности менеджеру по продукту попросту не справиться.
Взглянем же на определения данного термина и попробуем понять его значение в продакт-менеджменте:
«Честный (прил.) — свободный от предвзятости, предубеждений или личных интересов, не допускающий обмана, мошенничества».
Свободный от предвзятости
Один из наиболее быстрых путей для продакт-менеджера стать неэффективным — начать отдавать предпочтения команде, линии продукции или пользователям. Как только люди поймут, что не ко всем идеям вы относитесь с равной долей интереса, их доверие к вам неизбежно пропадет. А без доверия придется куда усерднее (и дольше) добиваться того, чтобы люди последовали вашей дорожной карте.
Свободный от личных интересов
Если вы начнете принимать решения лишь потому, что «я так хочу» и «так судят о моей эффективности», доверие также неизбежно пропадет. Нельзя быть эффективным, лелея свои любимые проекты и игнорируя прочие окружающие вас потребности.
Свободный от предубеждений
Это зачастую происходит, когда менеджер получает те новости, которые ему совсем не хотелось бы слышать, особенно от команды аналитики или пользовательских исследований. Если какой-либо тест не проходит нормально, не ищите причин того, что вы правы, а пользователи — нет. Сделайте все правильно и перестройте дизайн.
Одно из наиболее сложновырабатываемых качеств, это способность исключить все свои эмоции и чувства из уравнения в момент принятия решения. Да, интуиция играет большую роль в видении продукта, но оно не должно строиться исключительно на персональных предпочтениях и предвзятых идеях. Об этом проще говорить, чем сделать, но это одна из тех вещей, которых следует остерегаться постоянно.
Свободный от обмана
Это кажется очевидным, но очень уж часто встречается, особенно в метриках и оценках. Не игнорируйте и не рассеивайте негативные показатели, и не вините в них кого-то еще. Вы в ответе за продукт, и это значит принимать и его успех, и его провал. Вы завоюете доверие только в том случае, если неудачи будете принимать наравне с успехом, заставляя себя в следующий раз справляться лучше.
Продакт-менеджера часто называют «великим дипломатом», и тому есть веская причина. Наша задача состоит в соблюдении баланса между разнообразием внутренних и внешних потребностей компании и превращением этого в технологическую дорожную карту, способную генерировать бизнес-ценность и удовлетворять потребности пользователя. Сосредоточенность на честности поможет вам в достижении этой цели.
Честность по отношению к пользователям
Относитесь к пользователям уважительно, будьте открыты и прозрачны. Понимайте их потребности, и объясните им, почему вы возможно сделаете что-то, что усложнит удовлетворение этих потребностей.
Честность по отношению к компании
Делайте все необходимое для понимания потребностей маркетинга, мерчендайзинга, клиентской поддержки и прочих отделов. Втяните их в процесс планирования; четко разъясните приоритетность проектов; и помогите им приспособиться к этому процессу, дабы они могли определить цели их проекта таким образом, который приведет их к дорожной карте.
Честность по отношению к технологии
Не пытайтесь принудить команду разработчиков использовать технологию продукта для того, для чего она не предназначена. Поймите технические обязательства организации и активно работайте для укоренения этих улучшений в качестве части постоянного производственного цикла.
Многими из вышеперечисленных качеств хороший продакт-менеджер обладает по умолчанию, но это нужно держать в уме каждый день. Честность есть предпосылка к созданию качественного продукта. Если вы нечестны, вы потонете, работая с командой у которой нет ни малейшей причины верить в правильность ваших решений.
Директор по продукту Zuora Нэйтан Крэсвелл в личном блоге на Medium опубликовал свое мнение по поводу должности продакт-менеджера, основываясь на собственном опыте работы в более чем пяти компаниях. ЦП публикует перевод материала, выполненный командой Interweb Pro .
Менеджер по продукту — странная должность в Кремниевой долине.
Вы почти генеральный директор. Но на самом деле — нет. Вы — «и швец, и жнец, и на дуде игрец», но не умеете ни того, ни другого, ни третьего.
В ваших руках вся власть, и в то же самое время у вас её абсолютно нет. На вас лежит вся ответственность, и в то же самое время вы не отвечаете ни за что.
И, если честно, все сказанное — правда. И одновременно всё — неправда.
Если серьезно, когда ты работаешь продакт-менеджером, иногда ощущаешь себя в каком-то жутком решете парадоксальных формулировок в духе «дзен», и думаешь, что нашел ответ — но нет. И так постоянно.
Я работал продакт-менеджером в SaaS-компаниях пять лет. И мне казалось, это было хорошее время, которое отражало то, чему я научился (разным вещам), чему не научился (куче разных вещей), и где наделал ошибок (много ошибок). Интересно, что когда я только начинал, я часто видел объявления о наборе менеджеров по продукту, в которых говорилось, что у меня «должен быть опыт работы не меньше пяти лет», «не меньше десяти лет».
И, наконец, через пять лет, мне кажется, я понял, почему.
Не переживайте, что вас ненавидят разработчики. Вас все ненавидят. Постарайтесь привыкнуть к этому.
Я не могу себе представить какие-либо еще взаимоотношения, которые были бы настолько же враждебными с самого начала. Вы должны говорить разработчикам, что они должны делать, но у вас нет на это полномочий.
Очевидно, вам приходится убеждать их с помощью некоего поля искажения реальности (что еще сказать, у Стива Джобса оно было, но разве он не был самым лучшим менеджером по продукту всех времен и народов? Ну и разве он не был при этом просто отличным парнем?).
Разработчики автоматически видят в вас врага. Почему? Потому что вы заставляете их работать. И это не всегда та работа, которой они предпочли бы заняться.
Если же у вас есть опыт работы разработчиком, они будут смотреть на вас как на того, кто сует свой нос не в свои дела и вообще зануда. Если у вас этого опыта нет — вы бесполезны и некомпетентны.
Если вы даете им слишком много работы, они открыто отказываются ее выполнять: «Тут еще один пользовательский момент, не вписывающийся в нашу разработку, извините, но вам придется что-то сократить». Что?!
Если же вы недостаточно нагружаете их, то это именно у вас не хватает проницательности, чтобы заставить команду работать.
Вот в этот-то самый момент другие менеджеры продуктов и начинают красть ваши ресурсы. Забавно.
И это касается не только разработки. Каждый готов обвинить вас в чем угодно, при этом большую часть вопросов вы вообще не контролируете. «Где мой запрос функции, который я отправлял еще три года назад?» «Почему выход версии отложен? ВЫ назначили эту дату, не так ли?» «Почему я нахожу эту ошибку после релиза? Вы даже не тестировали?» «Клиент хочет пообщаться с менеджером, они не в восторге от этого продукта».
Кто-нибудь всегда будет вас ненавидеть. Клиенты, разработчики, специалисты по услугам. Другие менеджеры продуктов. Все.
Но это нормально, потому что если вы хорошо делаете свою работу, иногда, только иногда, вы выпускаете хороший продукт. А это заставляет всех этих людей, которые ненавидят вас, ну или кого-то из них, любить вас чуточку больше.
Никогда не наследуйте продукт другого продакт-менеджера
Потому что вместе с ним вы получаете все ошибки его разработки, все то, что было отложено на потом, потому что вовремя это решить было слишком сложно — все вопросы, которые они не удосужились найти время решить, начиная с предыдущего менеджера продукта до них.
Мои поздравления! Теперь это ваши проблемы!
Мне иногда кажется, что среди продакт-менеджеров должны быть одни из высоких показателей текучести кадров в отрасли. Как вы можете не чувствовать себя лишенным всякой мотивации, когда вам вручают глыбу угля и говорят, что нужно превратить ее в бриллиант?
У вас очень редко возникает шанс построить что-то с нуля — то, что будет вашим. Мне самому только дважды выпадала такая возможность за последние пять лет, и только один раз клиенты действительно свыклись с этим.
Если вам выпадет шанс сделать что-то свое, воспользуйтесь им. Потому что вы никогда не почувствуете такого прорыва, когда вам нужно сделать что-то самому и увидеть, как это это становится успешным.
Посещайте совещания и общайтесь с разработчиками
Не знаю, почему некоторые менеджеры считают, что не посещать совещания — совершенно нормальное явление.
Как еще вы сможете узнать, над чем работают ваши люди? Как еще вы узнаете, что мешает им работать и откладывает выход продукта? Как еще ваша команда начнет доверять вам и, возможно, даже не будет вас ненавидеть, если они увидят, что вы делаете все возможное, как и они сами.
Тесное общение с разработчиками — это ключ. Пятиминутный разговор порой стоит дороже, чем сообщение по электронной почте на 20 страниц. Я не понимаю, почему некоторые компании считают, что презентации в виде слайдов — адекватная замена общению.
Вы — всё
В самом начале вы сейлз, менеджер по работе с клиентами, специалист по поддержке и по-всему-что-нужно-делать. На самом деле, я, возможно, не занимался только двумя вещами: не был исключительно разработчиком и исключительно продажником.
И, если честно, в те дни вы всего лишь пытаетесь зацепить следующего клиента, а не сидите в башне из слоновой кости, размышляя над стратегией развития продукта.
А сейчас вы находитесь совсем в другом положении. Крупная компания, множество людей, которые делают все что угодно, когда ВЫ можете наслаждаться бездельем и обдумывать стратегию развития продукта.
Но проблема в том, что вы больше не на передовой. Вы больше не участвуете в каждом посещении клиента, продвигая продукт. И вы можете утратить былую хватку.
Никогда не отрывайтесь от жизни. Хороший менеджер по продукту приветствует любое общение с клиентом, в котором он участвует (да, и даже оскорбительное). Поскольку это единственный способ узнать, что происходит. Кому вы уступаете сделки? Что думают клиенты о вашем продукте? В чем он помогает людям? И вообще, они им пользуются?
Одна из наиболее удивительных вещей, обнаруженных мною — это клиенты, которые оплачивали продукт, но потом никогда им не пользовались. Конечно, они мысленно возвращались к нему, но, безусловно, теряли деньги, ведя себя подобным образом.
Поэтому я не знаю, стал ли я лучшим продакт-менеджером за последние пять лет, но я теперь совершенно точно знаю массу вещей, которые помогли мне стать лучшим менеджером по продукту, чем я был в самом начале.
И если бы сейчас мне нужно было назвать свое краткое парадоксальное высказывание в стиле «дзен», я бы сказал: “поставляйте продукцию и делайте своих клиентов счастливыми”. Это все, что вам нужно сделать. После этого все встанет на свои места.
Нэйтан Крэсвелл, продакт-менеджер Zuora, писал о своей работе так: «Менеджер по продукту - странная должность в Кремниевой долине. Вы почти генеральный директор. Но на самом деле - нет. Вы - и швец, и жнец, и на дуде игрец, но не умеете ни того, ни другого, ни третьего. В ваших руках вся власть, и в то же самое время у вас её абсолютно нет. На вас лежит вся ответственность, и в то же самое время вы не отвечаете ни за что».
Ольга Сорокина специально для GeekBrains разобралась в том, кто такие продакты, что они делают и как ими стать. Передаю микрофон.
Чем занимается
Наиболее точное определение того, что должен делать продакт-менеджер, отражает следующая фраза: «discover a product that valuable, usable and feasible». То есть, дословно: «обнаружить продукт ценный, годный к употреблению и выполнимый». Эта должность находится на стыке трех составляющих: бизнеса, технологий и пользовательского интерфейса. Продакт не кодит, не рисует интерфейсы, не продает, но должен руководить этими процессами и объединять команду общей идеей для получения результата.
Бизнес
Продакт-менеджер максимально заинтересован в получении выгодного продукта с точки зрения бизнеса. Поэтому он знает все о продажах, не продает сам, но руководит этим процессом. Его задача - создать такой продукт, который принесет наибольшую прибыль владельцу бизнеса с минимальными вложениями. С позиции бизнеса продакт-менеджер представляет интересы владельца.
Технологии
Для того чтобы воплотить идею по созданию продукта, нужно понимать технологию его производства. Продакт-менеджер должен понимать язык разработчика, потому что большая часть его работы заключается именно во взаимодействии с командой разработчиков, дизайнеров, проектировщиков. Именно поэтому чаще всего продактами становятся разработчики, обладающие способностью охватить весь процесс от проектирования до продаж.
Продакт может не уметь создавать код и рисовать интерфейсы, но он должен понимать, как это делается. Эти знания позволяют ему, как руководителю оценивать не только возможности команды, но их ограничения. Именно Agile-методика разработки программирования является сутью работы продакт-менеджера, которая в своей основе заключается в постоянном взаимодействии с командой.
UX
Чтобы создать продукт, который принесет максимальную прибыль, нужно сделать то, что хочет получить потребитель, то, что решит его проблемы. Поэтому продакт-менеджер должен прекрасно понимать позицию пользователя, настолько, будто он сам является таковым. Конечно, продакт не обзванивает клиентов с вопросами, вместо этого он анализирует отзывы, жалобы, интересы и требования целевой аудитории, пользуется продуктом сам.
Управление командой
Помимо всего прочего, продакт-менеджер - прежде всего управленец. И управлять приходится практически по всем фронтам, именно поэтому его можно назвать мини-CEO проекта. Переводя на нашу ментальность, мини-гендиректор. Он должен управлять всем, представлять интересы владельца компании, но, все же, не имея тех полномочий, которые подразумевает должность Chief Executive Officer.
Анализ пользовательского спроса, создание идеи, разработка, продажи - это еще не все. После реализации идеи, работа продакт-менеджера не заканчивается, в этом его отличие от проджекта, например. Он продолжает работу над продуктом, снова анализирует мнение пользователя, его реакцию, появившиеся проблемы, оценивает конкурентов. На основе новых данных модернизируется имеющийся, либо создается новый продукт. Его работа в постоянном анализе и коррекции идеи для соответствия ожиданиям клиента, и успешного бизнеса. Это непрерывный, но в то же время динамичный процесс, который требует постоянного анализа и творческих идей.
Откуда берется
Как мы уже обсуждали, хороший источник продуктовых менеджеров - разработчики. Они лучше всех понимают технологию создания и искренне болеют за свое творение. Осталось расширить свои взгляды до понимания бизнес-идеи и восприятия пользовательского опыта.
Реже в продакты приходят дизайнеры. Например, Марисса Майер была инженером, а потом дизайнером в Гугл. Следующей ступенью стала должность продакт-менеджера, с которой она прекрасно справлялась. Сейчас она - CEO Yahoo.
Сандра Лю Хуанг была экономистом в Фейсбуке, а стала продактом в Quora. Специалист по продажам Сачин Рехи стал сначала продакт-менеджером LinkedIn, а теперь он - CEO в компании Connected.
Как им стать
Чаще всего им становится толковый человек из команды, который обладает нужными навыками, об этом говорят биографии большинства известных менеджеров по продукту. В таком случае человеку приходится восполнять необходимые знания.
Учиться
Толковых школ и курсов мало, но они есть. Посмотрите на эти:
- НИУ Высшая школа экономики предлагает курс по переподготовке «Продакт менеджмент технологического продукта ». Длительность - один год. Стоимость обучения 189 000 рублей.
- Курс #tceh «Профессия продакт-менеджер в IT ». 2 раза в неделю в течение 2,5 месяцев. Преподаватели Тимур Гаврилов и Дмитрий Школьников. Стоимость 99 000 рублей.
- Семинар Русской школы управления «Бренд-менеджер. Менеджер по продукту ». Длительность 4 дня по 7 часов. Стоимость 40 715 рублей.
- Product Vision , школа для обучения и развития продакт-менеджеров. Курсы, тренинги семинары на различные темы. Подходит для действующих и начинающих продактов.
Читать
Понимать нужды пользователя можно разобравшись в психологии, причем, не как абстрактного понятия, но в психологии конкретного вашего пользователя. Полезную информацию о поведении клиента и о человеко-компьютерном взаимодействии можно найти здесь.
Откуда это все пошло? С западной части США. Почему оттуда? Потому что именно там, в Юте, был утвержден Agile Manifesto с его «product owner» в 2001-м. Потому что именно благодаря Сан-Франциско и его «Силиконовой долине» в начале 21 века стало широко распространено понятие «стартап», и именно в стартапах возникла глобальная потребность в «product managers». И именно там находится штаб-квартира «Яблока», продемонстрировавшего миру, что может случиться, если продуктом займется хороший product manager.
Ладно, так кто же такой менеджер продукта?
Согласно Википедии – «…человек, отвечающий за создание новых продуктов, анализ рынка, ассортиментную политику и бла-бла-бла…». Или вот еще: «…задача продукт-менеджера - определить концепцию продукта и стратегию его развития. Продукт-менеджер задает критерии успеха и принимает решения…». Уже лучше, но все еще водянисто. Нужно проще.
Смотрим в историю. Когда появились продукт менеджеры? Тогда, когда очевидные потребности людей уже были удовлетворены и необходимо было найти или создать новые. Когда тысячи стартапов пробовали делать десятки тысяч разных продуктов и никто не мог сказать, какой из них будет нужен потребителю. Они даже не знали, кто их потребитель. Короче, всем нужен был ответ на вопрос «ЧТО делать?». И менеджеры продуктов его дали.
Итак, менеджер продуктов - это про «ЧТО». Если смотреть через призму проектного управления, то это про содержание. Например, в PMBoK разделяют project scope и product scope , потому что первое, это все-таки про «как», а вот второе, это как раз «что». Кстати, про проектное управление…
- ProductM vs ProjectM
Чтобы никто не путался, сразу определим разницу между менеджером продукта и менеджером проекта:
- Первый – постановщик задачи, второй – контроллер исполнения.
- Первый говорит, что делать, второй – кто, когда и как это будет делать.
- Это не может быть один человек, если только он не страдает раздвоением личности.
Часто говорят, что менеджер продукта отвечает за то, чтобы «делать правильные вещи», т.е. за результат, а менеджер проекта за то, чтобы «делать эти вещи правильно», т.е. за эффективность. Ну че тут сказать, правильно говорят, чертяги.
Как правило, эти двое, если они работают вместе, балансируют на грани того, чтобы навалять друг-другу, потому что один всегда хочет сделать лучше, а другой – быстрее и дешевле. Но это, в целом, не мешает им делать хорошие продукты.
Для закрепления образа менеджера продукта вспомним еще одного крутого типа:
- Что должен уметь product manager?
А вот реально, что? И как этому научиться? Вот тут появляются проблемы. Менеджер продукта – это созидатель, человек творческий. Как можно научиться творчеству? Очень долго время люди считали, что способность творить – это дар, ему невозможно научиться. Сейчас процесс творчества стал лучше детализирован, появились определенные технологии сбора информации с потребителей, людям помогают развивать эмпатию, благодаря которой они могут лучше понять потребителя. Т.е., в-принципе, тут есть чему поучиться.
И все же это далеко не Body of Knowledge, как PMBok. Есть ощущение, что такого свода знаний для менеджеров продуктов не появится, и искать идеальный набор скиллов для менеджера продукта придется каждому самостоятельно, ну или в небольших кучках. А это уже сам по себе творческий процесс. Поэтому если Вы не можете по достоинству оценить Бетховна, Курта Кобейна,и Эминема (именно всех троих) - не мучайтесь, в Вас нет чувства прекрасного, и менеджером продукта, Вам, скорее всего, быть не удастся.
Строго говоря, не существует вуза, специальности или дисциплины, после изучения которой человек был бы (пусть даже теоретически) готов к тому, чтобы стать менеджером продукта. И наоборот, человек, который ни черта не разбирается в программировании, в управлении проектами, не имеет образования маркетолога, реально может стать успешным продукт менеджером. Забавно, да?
И все-таки попробуем определить, что должен делать менеджер продукта, чтобы успешно отвечать на вопрос «Что?».
- Так что же должен делать менеджер продукта?
a. Знать рынок и конкурентов;
b. Слышать потребителя;
c. Точно определять, что именно должно быть сделано (еще раз, для быстрых, «ЧТО», а не «КАК»), причем выражать свою мысль письменно;
d. Описывать требования к продукту и всегда держать это описание в актуальном состоянии;
e. Разрабатывать презентации и инструкции для тех, кто продает продукт, помогать им продавать.
Это если коротко. Заметьте, тут достаточно много скиллов, которые могут быть оценены только субъективно. Как, например, понять, слышит этот чел потребителя или нет? Как вообще отличить хорошего менеджера продукта от плохого, например, на собеседовании? Тут сильно поможет обращение к прошлому опыту:
- Какие продукты у него были ранее?
- Были ли они успешны?
- Если нет, то почему?
- Что он про это говорит?
- Ищет он проблему в себе, или списывает на обстоятельства?
Но давайте, все-таки, разберем эти 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С. Таких продуктов, которые клиентам не придется сравнивать с импортными аналогами, и которыми мы сможем гордиться.