Jim Gochee, New Relic Inc.
11 сентября 2012г.
перевод статьи A Developer Becomes a Product Manager
В старое доброе время я зарабатывал на жизнь программированием. Это был один из самых лучших и беззаботных этапов в моей трудовой жизни. Помимо написания кода у меня было мало других обязанностей. Я понятия не имел откуда у компании берутся деньги на мою зарплату и не представлял откуда клиенты узнают про наш продукт. Я не задумывался о том почему мой босс просит меня запрограммировать фичи X/Y/Z — я просто писал код. Моё время было занято решением интересных технических задач и в общем-то моя жизнь крутилась вокруг программирования.
Реальный мир
Шло время и я стал замечать что за пределами моей инженерной команды есть целый другой мир — мир «бизнеса», или как я сейчас его называю — “реальный” мир. В этом мире привлекаются инвестиции, рекламируются и продаются продукты, обслуживаются клиенты, и сокращаются зарплаты. Всё то время, которое менеджеры по продукту
проводят не с инженерными командами, они проводят в этом реальном мире. В технологических стартапах роль менеджера по продукту зачастую играет CEO. В больших компаниях менеджеры по продукту это мини-CEO. (Если хотите узнать больше о том какое влияние имеют менеджеры по продукту, прочитайте статью о Мариссе Майер, где обсуждается роль менеджеров по продукту в Гугле.)
Задача менеджера по продукту состоит в том, чтобы работа инженерной команды шла в направлении совпадающем с бизнес-целями компании. Одна из очевидных целей — создание продукта, который отдел продаж сможет продать, в котором отдел маркетинга сможет заинтересовать потенциальных клиентов и который отдел техподдержки сможет поддерживать. Менее очевидные цели включают в себя нивелирование конкурентных угроз, стратегическое позиционирование продукта, удовлетворение пожеланий инвесторов, и создание долгосрочной выгоды для акционеров. И хотя это достаточно размытые понятия, они помогают определить контекст для ежедневного принятия решений менеджером по продукту.
Если бы я хотел описать каждодневную жизнь менеджера по продукту одним словом, то это было бы слово «НЕТ». Как только продукт запущен, количество идей как его улучшить (aka “новые фичи”) будет значительно превышать возможности вашей команды по их реализации. В NewRelic мы отслеживали запросы на улучшения в течение двух лет. Когда их количество достигло 1000, мы остановились, почесали в затылке и удалили их все. Мы перестали отслеживать новые запросы по отдельности и стали просто их считать. В такой ситуации менеджер по продукту может сосредоточиться на небольшом количестве дел, которые принесут наибольшую отдачу в бизнесе, и говорить нет всем остальным запросам. (Один простой способ этого достичь — вести приоритезированный список грядущей работы.) И когда придут те неизбежные два-три запроса в день, их можно сравнить со списком top-10 и они либо попадут в этот список (и вытеснят что-то другое), либо не попадут.
Определяя цели
Бизнес-цели могут отличаться в разных компаниях, но обычно общим для всех проектов является то, что приходится создавать продукт для «кого-то», кто делает «что-то». Этот кто-то называется модным термином «Персона». Иногда в продукте только одна Персона, иногда пара. И очень важно понимать кто эти люди. Как можно построить что-то для кого-то если ты их даже не понимаешь? Программисты часто наступают на эти грабли и полагают что они создают продукт для кого-то вроде самих себя. (Ну ведь наши пользователи тоже используют компьютеры, так?). Возьмите к примеру Salesforce — эти ребята точно понимают кто такие Персоны для их продукта: торговые представители, менеджеры по продажам и высшее руководство.
«Что-то» важно потому что ваш продукт скорее всего предназначен для решения определённого ряда «проблем» или «болевых точек». Например, если ваш продукт является Решением для Мониторинга Производительности, важно чтобы ваши клиенты могли с помощью вашего продукта решить проблемы производительности своих приложений. Второе наиболее часто употребляемое мной выражение (после «НЕТ») — «какие проблемы это решает?». Вот пример реальной ситуации с которой вам возможно придётся столкнуться. Дизайнерам не нравится макет веб-страницы и они настаивают на том, чтобы его изменить. Это изменение сделает продукт лучше, так что проблем быть не должно, верно? Но опасность может подстерегать в двух местах: a) пользователи не испытывают проблем с существующим макетом б) пользователи испытывают другие проблемы с дизайном — и в итоге решение этих проблем будет отложено.
Если спросить самого себя — какие из проблем в моём продукте стоят наиболее остро и направить команду на решение именно этих проблем, то это и будет правильная приоритезация бэклога. И последнее замечание о «проблемах» — иногда они маскируются под другие вещи, такие как «возможности». Например, пользователи не скажут вам, что установка приложения занимает слишком много времени. Здесь нет очевидной проблемы. Тем не менее, будучи умным человеком, ты сможешь распознать что ускорение процесса установки повысит количество продаж. Длительное время установки приложения является проблемой, поскольку у пользователей короткий период удержания внимания. Другой пример — Apple iPod. iPod не принес на рынок новую функциональность, но он был простым и стильным — модным продуктом. Фактор модности на первый взгляд не решает никакой проблемы, люди просто хотят быть модными. Но предложив на рынке модный продукт, можно удовлетворить желание (решить проблему) большой группы людей.
И хотя я иногда скучаю по программированию, я не готов променять на него управление продуктом. Мне нравится играть ключевую роль в успехе NewRelic, и мне нравится насколько успешен NewRelic!
Автор: ivanku
