Вы не авторизовались

Главная
Привлечение клиентов
Мелисса Перри
Product Management без ошибок. Гид по созданию, управлению и успешному запуску продукта
Читать онлайн бесплатно

Product Management без ошибок. Гид по созданию, управлению и успешному запуску продукта бесплатное чтение

Мелисса Перри
Product Management без ошибок
Гид по созданию, управлению и успешному запуску продукта

* * *

Отзывы о книге

«Эта книга не только помогает дать определение продакт-менеджменту, но и рассматривает его в организационной перспективе. Мелисса Перри мастерски сочетает накопленный опыт, наглядные примеры и знания, создавая четкую картину понятия управления продуктом (чего так не хватает во многих других книгах). Она говорит о ценности команды и организации, о приверженности, которая требуется, чтобы стать хорошим специалистом. Эта работа написана не только для продакт-менеджеров, но и для руководителей. В ней изложены обвинения „проектного“ мышления и четкое, практическое руководство для компании, ориентированной на продукт. Книга обязательна к прочтению».

– Джефф Готелф, автор Lean UX и Sense & Respond

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

– Дэйв Прайк, Институт юридической практики

«В книге, изобилующей полезными инструментами, методами и реальными примерами из практики, руководителям, предпринимателям и бизнес-лидерам предлагается мощное понимание того, как создать организацию, ориентированную на продукт, и преуспеть в мире инноваций».

– Барри О’Рейли, основатель ExecCamp и автор Unlearn и Lean Enterprise

«Книга Мелиссы является частью нового стандарта в области управления продуктом. Слишком часто продакт-менеджмент рассматривается как удача в сочетании с большим самомнением. Мелисса демонстрирует его действенность и дисциплину».

– Джефф Паттон, консультант по управлению продуктом и автор User Story mapping

«„Фабрики по производству функций“ или те группы, которые просто заняты тем, что создают все подряд: остановитесь! Прочитайте книгу и переориентируйтесь на решение самых важных проблем с пользой для клиента. Перед вами понятная и проницательная книга для специалистов в области продакт-менеджмента всех уровней, и она, безусловно, станет основным руководством на книжных полках менеджеров».

– Дэйв Мастерс, директор по продукту в Realtor.com

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

– Джез Хамбл, автор и лектор по продакт-менеджменту в Калифорнийском университете в Беркли

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

– Адриан Ховард, консультант по продакт-менеджменту в Quietstars

«Существует много замечательных книг об управлении продуктом, стратегии и разработке. Я обычно рекомендую их со сноской, например: „Эта книга ориентирована на стартапы“; „Вам понадобится другая книга“; „Эта книга охватывает UX“; „А эта в основном для владельцев продукта в контексте Scrum“. Книга Мелиссы Перри уникальна тем, что представляет собой полный пакет – никаких сносок. Она краткая и милая, имеет прочную основу в теории и практические инструменты. Книга переходит к сути вопроса – от управления „фабрикой функций“ или проектов к развитию ориентированной на продукт и воздействие организации. А в качестве бонуса – книга интересная! Вымышленная история компании Marquetly очень понятна. Она соединяет в голове все кусочки головоломки. Снимаю шляпу, Мелисса! Это круто».

– Джон Катлер, евангелист продукта в Amplitude

Введение

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

– Майкл Делл^[1]

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

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

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

Я хотела стать лучше. Я хотела создавать более качественный продукт.

В те времена как раз формировалась концепция «бережливого стартапа». Будучи инженером по образованию, я, конечно же, заинтересовалась, потому что концепция предлагала научный подход к менеджменту. «Вы хотите сказать, что я могу по-научному тестировать свою продукцию? Я смогу использовать данные для принятия обоснованных решений? Я в деле! Запишите меня!» – подумала я.

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

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

Несколько лет спустя меня начали приглашать на конференции. Мне нравилось рассказывать о том, чему я научилась; нравилось делиться опытом. Я любила вдаваться в подробности и объяснять, как и почему мне помогли новые знания. Вскоре я поняла, что мои советы оказывали положительное влияние на аудиторию, в результате чего все больше и больше менеджеров, руководителей и дизайнеров начали обращаться ко мне за помощью. В конце концов, в 2014 году я решила стать консультантом.

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

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

Однако моя маленькая цель переросла в большое стремление.

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

«Почему вы перестали взаимодействовать с пользователями? Почему вы больше не экспериментируете?» – поинтересовалась я.

Все они сослались на кучу системных проблем.

«Моя премия зависит от количества разработанных функций. Конец года уже не за горами», – услышала я в одной из компаний.

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

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

Именно по этой причине я начала переписывать книгу: я хотела сосредоточиться на необходимости создания организации, нацеленной на рост за счет продукта (модель product-led). Затем меня пригласили руководить масштабными процессами модернизации в компаниях с многомиллиардным оборотом. Я консультировала руководителей высшего звена по вопросам перехода на новую бизнес-модель, стремясь применить полученные знания. И я даже не предполагала, как многому я научусь благодаря этому опыту.

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

Эта книга представляет собой руководство, которое поможет вам выбраться из капкана роста при помощи эффективного управления. Мы рассмотрим, что значит быть организацией, нацеленной на продукт (рис. 1).

Весь процесс включает в себя четыре ключевых компонента:

• Создание должности продакт-менеджера с надлежащими обязанностями и структурой

• Создание стратегии, способствующей принятию правильных решений

• Поиск и развитие эффективного продукта путем экспериментов и оптимизации

• Поддержка сотрудников при помощи правильно организационной политики, культуры и вознаграждений, способствующих росту продакт-менеджмента

Рисунок 1. Организация, нацеленная на продукт

На протяжении всех страниц настоящей книги вы будете читать о компании под названием Marquetly. Хотя Marquetly – вымышленная организация, ее истории основаны на реальных событиях: либо на моем собственном опыте в роли продакт-менеджера, либо на опыте компаний, с которыми я работала. Вы будете следовать за Marquetly на пути к тому, чтобы избежать ловушки и стать предприятием, ориентированным на продукт. Если вы хотите узнать, насколько ваша компания соответствует этим критериям, ознакомьтесь с небольшим тестом в последнем разделе книги.

За последние десять лет я побывала на многих должностях: продакт-менеджер, UX-дизайнер, разработчик, генеральный директор, предприниматель, консультант, советник, учитель и студент. Самой важной для меня оказалась роль студента. Меня восхищает то, чему я научилась, как и то, чему я до сих пор учусь. Я рада поделиться с вами опытом, но при этом я знаю, что мне самой еще многому предстоит научиться.

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

Если вы хотите узнать больше о продакт-менеджменте, загляните в нашу онлайн-школу Product Institute. Мы постоянно разрабатываем курсы, способные помочь каждому, от члена команды до руководителя. Я также безумно рада новому сотрудничеству с Insight Venture Partners и Шелли Перри. Мы начнем готовить следующее поколение главных специалистов в Produx Labs. Данную сферу ожидает весьма увлекательное будущее.

Спасибо за внимание,

Мелисса Перри,

Генеральный директор Produx Labs

Благодарности

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

Особую благодарность я выражаю команде в Produx Labs и моим студентам в Product Institute. Именно благодаря вам я встаю по утрам, зная, что мы вместе строим будущее продакт-менеджмента.

Спасибо Шелли Перри из Insight Venture Partners за сотрудничество, наставничество и поддержку, а Кейси Кансельери – за рецензирование четырех версий книги на протяжении двух лет, что помогло сформировать ее нынешний вид.

Спасибо моему издателю, О’Райли, и редактору, Анжеле Руфино. Ваше терпение и руководство в этом процессе было незаменимым.

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

Огромную помощь мне оказали очень щедрые рецензенты, как первые, так и те, кто читал мой труд много позже. Спасибо Гиффу Констеблу, Адриану Ховарду, Лейну Голдстоуну, Джону Катлеру, Саймону Беннету, Дейву Мастерсу, Кейт Грей, Блэр Ривз, Дэвиду Звенячу, Эллен Чайз, Джереми Хорну, Райану Харперу, Дейву Пинке и Фрэнсису Клоузу.

Спасибо тем, кто работает в области продакт-менеджмента, UX-дизайна, Agile, Lean Startup, Lean fields. Я многому научилась за последние годы. Спасибо вам всем за информативные беседы. Спасибо, что бросаете вызов моим предвзятым мнениям. Спасибо, что открыли мне другие способы работы. Спасибо за вашу поддержку.

Выражаю благодарность моим друзьям из книжного клуба, которые встречались со мной каждую неделю в течение двух лет, чтобы обменяться идеями, выразить мнение, а иногда и оказать столь необходимую поддержку. Спасибо Дэвиду Блэнду и Барри О’Райли. Без вас я бы никогда не закончила книгу. Спасибо, что не дали мне сойти с ума.

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

Спасибо моим родителям, Джоанне и Сальватору, и моей сестре Дженни. Вы – мое все.

Часть I
Ловушка разработки

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

«Крис, ваша проблема заключается не только в менеджерах, – заметила я. – Да, они определенно „зеленые“, и вам придется нанять несколько более профессиональных сотрудников. Но дело не в этом. В компании есть сложности с процессом, стратегией и организацией, и они мешают достигать поставленных целей».

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

Шестью месяцами ранее Крис нанял меня с целью обучения продакт-менеджеров. Компания развивалась довольно быстро. Рост выручки из года в год стабильно составлял около 30 %. За очень короткий промежуток времени организация наняла сотни людей, поручив им всевозможные проекты. Многие из этих людей были разработчиками, но вскоре после принятия гибкой системы управления проектами (Agile) под названием Scrum они поняли, что им не обойтись без продакт-менеджеров.

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

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

«Я вынуждена работать под сумасшедшим давлением, – призналась она. – Отдел продаж пообещал корпоративным клиентам функции, которые мы никогда не разрабатывали. Теперь нам придется создавать все с нуля. А учитывая, что у меня двадцать прямых подчиненных и сроки, в которые нужно уложиться, у меня физически нет времени на стратегии».

Сотрудники отдела продаж тоже были расстроены и чувствовали себя загнанными в угол.

«Нам нужна стратегия. Что делать, если у нас нет продукта? Как и что нам продавать? Я только кормлю всех обещаниями, потому что продакт-менеджеры ничего не могут нам дать», – жаловался руководитель отдела продаж.

Организация оказалась в тупике, и все показывали друг на друга пальцем. Каждый из них ссылался на отсутствие навыков, как на проблему.

«Жаль, что наши менеджеры не обладают более глубокими знаниями, – сетовал технический директор. – Было бы проще. Нам важно, чтобы они думали и находили больше решений».

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

«Вы создали условия, в которых Карен – единственный руководитель и наставник. Так нельзя, – объяснила я. – У нее нет времени обучать десятки людей. Если вы хотите развивать младших сотрудников, вам придется перевести некоторых из них обратно и нанять опытных продакт-менеджеров».

«Нет, нет, так не пойдет, – возразил он. – Мы не можем нанять столько новых людей. Продолжайте их обучать. Если понадобится, наймите еще одного наставника».

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

Когда к третьему месяцу команда не справилась, руководство пришло в ярость. «Они не справляются с работой! – гневался генеральный директор. – Нам нужно разрабатывать больше функций! Почему они не умеют ставить приоритеты?»

Все пальцы указывали на неэффективную работу продакт-менеджеров. Но на самом деле проблема заключалась не в этом.

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

Они старались сделать все возможное, чтобы уложиться в сроки, применяя при этом отличные стратегии. Вот только никто из них не был настроен на результат и его ценность. Сроки были установлены еще до моего прихода и закреплены в контрактах. Всякий раз, когда я предлагала оценить необходимость создания новой функции, менеджеры давали мне значительный отпор. Вот что они говорили: «Это требование руководства. Я должен выполнить работу, иначе я не получу премию». Они попали в ловушку плохой организации и ужасной стратегии. В то же время рост доходов Marquetly снижался, и совет директоров начал оказывать давление на руководство. Карен всеми силами пыталась противостоять, но руководители продолжали настаивать. «Вы не понимаете. Если мы не создадим новые функции и не покажем совету директоров, что мы способны на большее, мы не сможем привлечь финансирование», – признал генеральный директор.

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

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

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

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

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

– Я не понимаю. Как другие компании добиваются успеха? – спросил он. – Как они приходят в себя после такого краха? Что мы делаем не так?

– Дело не только в навыках продакт-менеджеров, – объяснила я. – Некоторые из них работали хорошо и принимали верные решения. Они действительно пытались понять, как обеспечить ценность новых функций. Если бы им дали возможность продолжать идти этим путем, они бы справились. Но в вашей компании существует масса организационных проблем, которые мешают сотрудникам создать что-то стоящее.

– Например? – полюбопытствовал он. – Что мы можем улучшить?

– Скажите мне, что сейчас для вас самое главное?

– Рост выручки, – отчеканил он без лишних колебаний. – Нам нужно вернуть показатели хотя бы на прежний уровень.

– Когда я спрашивала сотрудников, они дали другой ответ, – призналась я.

Крис выглядел слегка изумленным.

– Технический директор сказал, что самое важное – это мобильная стратегия. Когда я попросила пояснить ответ, он сослался на члена совета директоров. Когда я спросила Карен, она ответила, что самое главное – это привлечение большего количества учителей. Когда я спросила руководителя отдела продаж, он сказал, что нужно привлекать больше корпоративных клиентов. Никто не ставит доход на первое место. У вас разногласия, ребята.

Я продолжила:

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

– А на что тогда менеджеры? – вдруг спросил он. – Ведь это их работа. Как и работа других руководителей. Если видят проблему или не справляются, пусть скажут мне напрямую.

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

Крис выглядел подавленным, но был готов к диалогу.

– Так что мне делать? Компания должна развиваться, Мелисса. Что я могу сделать, чтобы все исправить?

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

Крис выглядел ошарашенным.

– Вы готовы к таким переменам? Это нелегко, но на 100 % возможно, – обещала я.

– Что ж, в том же духе нам нельзя продолжать, иначе мы выйдем из бизнеса, – признал он. – Да, я готов.

И вот тогда мы начали.

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

Ловушка разработки – это страшное место, потому что она отвлекает от истинной задачи. Все настолько сосредоточены на выпуске большего количества программного обеспечения, что теряют из виду главное: создание ценности для клиентов, достижение бизнес-целей и поиск инноваций для борьбы с конкурентами.

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

Компания Kodak даже не заметила, как цифровая фотография подорвала их успех. Вместо того чтобы отреагировать на изменения, они удвоили усилия и продолжили делать то, что делали всегда. Когда они попытались внедрить инновации (о которых я рассказываю в конце книги), ничего не получилось. Было уже слишком поздно.

Хотя компании Microsoft не грозил немедленный крах, она находилась на пути к разрушению. Она снова и снова использовала один и тот же стратегический рецепт, рассчитывая на то, что Windows станет основой бизнеса. И так было до тех пор, пока не пришел генеральный директор Сатья Наделла. Он переориентировал компанию на стратегию, способную помочь компании продолжать внедрять инновации, а затем соответствующим образом настроил людей, занимающихся этой деятельностью.

Ловушка разработки касается не только программного обеспечения. Она связана с осознанием, что вам придется изменить привычный порядок действий. Это значит, что вы путаете показатели прогресса, ориентированные на результат, с реальными показателями ценности. Чтобы выбраться из капкана, вам нужно взглянуть на всю компанию, а не только на команду разработчиков. Оптимизируете ли вы организацию для постоянного производства ценного продукта? Нацелены ли вы на его рост и развитие? Именно этим занимается нацеленная на продукт организация.

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

Но сначала давайте рассмотрим, как возникает ловушка, и на какие признаки вам следует обратить внимание. Первое – это неправильное представление о ценности.

Глава 1
Система обмена ценностями

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

Давайте вернемся к основам и определим, что такое истинная ценность. По сути, компании работают на основе обмена ценностями, как это показано на схеме 1.1.

Схема 1.1. Обмен ценностями

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

Схема 1.2. Реализованный обмен ценностями

Ценность с точки зрения бизнеса довольно проста. Это то, что может подпитывать ваш бизнес: деньги, данные, капитал знаний или продвижение. Каждая функция, которую вы создаете, и любая инициатива, которую вы предпринимаете как компания, должна приводить к какому-то результату, связанному с ценностью для бизнеса.

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

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

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

Однажды я работала в компании, которая создавала платформу данных для корпоративных компаний. Когда я пришла, в ней было задействовано 30 функций и еще около 40 находились в разработке. Изучив показатели существующих функций, мы обнаружили, что люди используют из них всего лишь 2 %. И тем не менее разработка велась с целью добавления новых программ, вместо того чтобы попытаться переоценить уже имеющиеся.

Как они дошли до такого состояния? Существует несколько причин, и все они применимы ко многим застрявшим в ловушке компаниям. Организация играла в догонялки – пыталась быстро обогнать конкурентов по каждой выпущенной функции. Она даже не знала, хорошо ли эти функции работают у конкурентов, но руководство настаивало на паритете. Именно в эту ловушку угодила Google+. Вместо того чтобы создавать что-то новое, они просто копировали Facebook.

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

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

Вы должны узнать своих клиентов и пользователей, глубоко понять их желания, определить, какие продукты и услуги удовлетворят их потребности (как со стороны потребителя, так и со стороны бизнеса). Именно так вы разрабатываете систему обмена ценностями, как показано на схеме 1.3. Чтобы добиться понимания, компаниям необходимо приблизить своих сотрудников к клиентам и пользователям. Они должны у них учиться. А это, в свою очередь, означает, что в организации должна быть разработана правильная политика.

Схема 1.3. Система обмена ценностями

Политика – это один из примеров ограничений, влияющих на обмен ценностями. Как мы видим на рис. 1.3, вся система с обеих сторон ограничена влиянием.

Глава 2
Ограничения системы обмена ценностями

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

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

Например, многие компании придерживаются настолько жесткого процесса разработки, что у них не остается возможности экспериментировать. Каждый раз, когда я начинаю новый тренинг или семинар, я говорю продакт-менеджерам: «Поднимите руку, если вы вернулись и выполнили итерацию, выпустив последнюю вашу программу». Обычно руку поднимают 15–20 % людей. Мой следующий вопрос: «Откуда вы знаете, что программа успешна?» Ответы обычно сводятся к соблюдению сроков и завершению работы с кодом без ошибок.

Это и есть яркий пример компании, нацеленной на показатель, а не на продукт. Показатель – это то, что легко измерить: количество продуктов или функций, количество релизов или скорость работы команд разработчиков. Результат – это то, что получается, когда мы наконец предоставляем эти функции клиенту и решаем его проблемы. Истинная ценность реализуется в результатах как в бизнесе, так и среди потребителей.

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

Большинство компаний не осознают пагубного влияния этих факторов на ценность, и все потому, что они не измеряют результат своих действий. Они теряют связь со стратегией и попадают в ловушку.

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

Глава 3
Проекты и продукция, продукция и услуги

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

В настоящее время существует множество методов, которые способствуют развитию мышления, необходимого для работы с проектами: PRojects in Controlled Environments (PRINCE2), Project Management Institute и Project Management Body of Knowledge (PMBOK). Компании, застрявшие в ловушке, обычно путают их с методологией продакт-менеджеров.

Чтобы разобраться в продакт-менеджменте и понять, чем он отличается от проджект-менеджмента, сначала нужно определить, что такое продукт и почему он важен.

Продукт, как я уже говорила, является носителем ценности. Он доставляет эту ценность клиентам и пользователям, не требуя от компании каждый раз создавать что-то новое. Это может быть оборудование, программное обеспечение, потребительские товары или любые другие артефакты, где не требуется вмешательство человека для доставки ценности. Microsoft Excel, детское питание, Tinder, iPhone – все это продукты.

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

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

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

Продукт – это то, что нужно взращивать и доводить до зрелости. Это занимает много времени.

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

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

Глава 4
Организация, нацеленная на продукт

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

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

Компании, ориентированные на отдел продаж

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

Многие небольшие компании начинают с продаж, и это нормально. Для продолжения работы стартапу необходимо привлечь первого крупного клиента и получить доход. Поэтому компания будет делать все возможное: тесно сотрудничать с клиентом, учитывать все его пожелания, а иногда и создавать что-то непосредственно для него. Однако такой подход к работе не бывает долговечным. Когда у вас 50–100 и более клиентов, вы не сможете на постоянной основе создавать уникальный продукт, дабы соответствовать потребностям каждого (если только вы не хотите стать агентством, работающим на заказ). Если это вам не по карману, вам необходимо изменить стратегию и перейти к созданию функций, применимых ко всем, без персонализации.

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

Компании, ориентированные на концепцию

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

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

Ориентация на концепцию не всегда создает устойчивую платформу. Для развития нужны инновации. Когда над проблемой работают 5000 мозгов (а не один), вы сможете лучше использовать эту силу для достижения успеха.

Компания, ориентированная на технологии

Еще один распространенный способ работы – это ориентация на технологии. Эти компании руководствуются новейшими и самыми навороченными разработками. Проблема заключается в том, что они часто страдают от отсутствия ориентированной на рынок стратегии, направленной на создание ценности.

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

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

Компания, ориентированная на продукт

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

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

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

Глава 5
Известное и неизвестное

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

Схема 5.1. Известное и неизвестное

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

Вам необходимо выделить эти пункты и обозначить те, в которых вы не точно уверены (известное-неизвестное). В данном случае предположения достаточно ясны, и вы знаете, какой вопрос нужно задать. Сюда относятся предположения, которые вы хотите проверить; данные, которые вы хотите изучить; проблемы, которые необходимо выявить. Вы используете методы открытия и эксперименты, чтобы прояснить их, превратить в факты, проработать и удовлетворить.

Неизвестное-известное – это те моменты, когда вы говорите: «Я чувствую, что так будет правильно». Это интуиция, сформировавшаяся в результате многолетнего опыта. Хотя мы все должны прислушиваться к интуиции, вы также должны быть осторожны, потому что именно здесь чаще всего возникает предвзятость. Чтобы понять, права ли ваша интуиция, необходимо проверять и экспериментировать.

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

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

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

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

Продакт-менеджеры – это ключ к компании, ориентированной на продукт.

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

Часть II
Роль продакт-менеджера

Продакт-менеджмент – это карьера, а не просто роль, которую вы играете в команде. Менеджер по продукту глубоко понимает как бизнес, так и клиента, и может определить правильные возможности для создания ценности. Они отвечают за синтез множества данных, включая пользовательскую аналитику, отзывы клиентов, маркетинговые исследования и мнения заинтересованных сторон, а затем определяют, в каком направлении должна двигаться команда. Они удерживают внимание команды на том, зачем мы создаем продукт, и к каким результатам он приведет. Директор по продукту является краеугольным камнем команды, помогая связать бизнес-цели со стратегией и представить результат совету директоров. Чтобы оставаться конкурентоспособными на современном рынке, компаниям необходимо создать стандартизированную карьерную лестницу в области управления продуктом, чтобы привлечь нужных специалистов и предоставить им возможности для роста.

Это был мой первый месяц работы в должности продакт-менеджера, и я только что закончила свою первую в жизни спецификацию. Я распечатала документ, чтобы начальник мог с ним ознакомиться, и пять минут сидела и смотрела на него со слезящимися глазами, как смотрят на любимого ребенка. На его подготовку у меня ушла целая неделя. Спецификация состояла из двадцати страниц, четырнадцати красиво оформленных макетов и разбора всех известных человеку ошибок. Что я думала в тот момент? Я думала, что разработчики будут несказанно рады. Им даже не придется задавать вопросы. У них в руках будет все, что только нужно, для создания страницы смены пароля на нашем сайте.

За несколько месяцев до этого я даже не знала, что такое управление продуктом. На той первой работе я выяснила, что роль менеджера – это роль создателя и арбитра. Мы связывали команды разработчиков с бизнесом, собирали требования и воплощали их в функции, которые люди могли реально использовать. Я часто встречалась с отделом продаж, желая узнать о том, чего хотят наши клиенты. Несколько раз мы опрашивали реальных клиентов, чтобы узнать об их привычках и потребностях. Получив список требований, при помощи Photoshop я прикидывала, как будет выглядеть продукт. Прошли годы, прежде чем я узнала, что управление продуктом и UX-дизайн – это не одна и та же дисциплина.

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

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

Я так гордилась, когда страница «сменить пароль», мой первый продукт, родившийся из 21-страничной спецификации, был передан клиентам. Моя первая настоящая функция! Тогда я еще не знала, что весь этот релиз, вероятно, можно было бы сделать всего за несколько бесед с хорошими разработчиками и примерно за десятую часть документации или даже меньше. Но меня не так учили управлению продуктом. И большинство людей тоже учат не так.

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

Глава 6
Архетипы плохого менеджера

На сегодняшний день существует немного путей изучения продакт-менеджмента. Этому не учат в колледже. Программы обучения на рабочем месте обычно отсутствуют. Microsoft и Google – две единственные крупные компании, которые действительно имеют карьерный путь для менеджеров по продукту. Стажировки тоже немногочисленны, поэтому большинство менеджеров либо переместились с должности на должность внутри компании, либо были «повышены» из отдела разработки программного обеспечения.

Если вам посчастливилось получить образование в области управления продуктом, то, как правило, полученные знания все равно достаточно тактильные: вы умеете писать спецификации (или пользовательские истории в Agile-проектах), планировать встречи с разработчиками и проводить контрольные собрания, собирать запросы бизнес-команды, проводить тестирования. Многие из этих этапов вытекают из работы продакт-менеджеров, которые работают в традиционной каскадной среде. Именно в такой среде училась и я.

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

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

Если вы слушаете и разводите руками, говоря: «Так не должно быть!», я с вами соглашусь. С ростом популярности методологии Agile все больше и больше людей видят недостатки этой системы, которая может годами определять ценность этих требований.

Многие компании, например, наши друзья из Marquetly, охотно приняли Agile, полагая, что это волшебное средство создаст ценность программному обеспечению. И все же они были разочарованы. Так почему же? Agile действительно продвигает эффективный способ сотрудничества и более быстрый метод создания программного обеспечения, но он в значительной степени игнорирует вопрос осуществления успешного управления.

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

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

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

Когда я прошу людей дать определение продакт-менеджеру, я получаю множество разных ответов – даже от самих менеджеров. «Менеджер по продукту – это тот, кто придумывает идеи!» Или: «Они – голос клиента!» И всегда: «Менеджер по продукту – это генеральный директор продукта!»

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

Мини-CEO

Продакт-менеджеры не являются генеральными директорами, однако 90 % объявлений о вакансиях, которые я просматривала, описывают их как мини-директоров. Генеральные директора обладают единоличной властью над многими вещами. Они имеют право увольнять людей. Они имеют право менять команды. Они могут менять направления. С другой стороны, менеджеры по продукту не могут изменить многое из того, что может сделать генеральный директор в организации. Особенно у них нет власти над людьми, поскольку они не являются менеджерами на уровне команды. Но вместо этого их начинают подталкивать в определенном направлении.

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

Честно говоря, Ник ужасно себя вел с дизайнерами и разработчиками. Он изначально хотел стать менеджером по продукту, потому что воображал себя следующим Стивом Джобсом, провидцем, который будет сидеть наверху и диктовать своей команде все, что они должны создать. Излишне говорить, что остальным членам команды это очень не нравилось. Он был расстроен: «Команда меня не слушает и ничего не делает». Бедный Ник. Он просто не понимал своей роли.

Тогда я отвела его в сторону и сказала:

– Слушай, я когда-то была в твоей роли, и позволь заметить, что такой образ мышления работает не в твою пользу. Я пришла в OpenSky, ухватилась за эту должность и не хотела ее отпускать. Я никогда не хотела слышать критику в адрес своих идей. В конце концов, я же визионер! Это была моя работа. Если кто-то приходил ко мне с идеей, я сразу же ее отвергала. Пойми, так друзей не завоюешь. И, честно говоря, я была несчастна, потому что моя команда не хотела со мной работать.

Я заметила, что привлекла его внимание. Тогда я продолжила:

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

Ник сидел и вникал в происходящее.

– Я хочу добиться успеха. Скажите, что нужно сделать, чтобы стать лучше и создавать крутые продукты.

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

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

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

Официант

«Официант» – это менеджер по продукту, который в душе является исполнителем. Такие люди приходят к заинтересованным сторонам, клиентам или менеджерам, спрашивают, чего те хотят, и превращают желания в список вещей, которые необходимо разработать. Здесь нет цели. Нет концепции. Нет принятия решений. Такой архетип встречался у 90 % владельцев продукта в Marquetly.

Самый распространенный вопрос, который я получаю от продакт-менеджеров, находящихся в таком положении, звучит так: «Как мне расставить приоритеты?» Поскольку у них нет цели, способной обеспечить контекст для компромиссов, это превращается в некий конкурс. Чаще всего приоритет получает самый главный человек. Такое часто случается в очень крупных компаниях. Менеджеры по продукту с самыми благими намерениями отправляются поговорить с клиентами и узнать, чего они хотят. Но вместо того чтобы обнаружить проблемы, менеджеры спрашивают: «Чего вы хотите?» Клиент просит конкретное решение, а менеджеры его реализуют. Именно здесь вы попадаете в то, что мой друг Дэвид Блэнд, советник и консультант по продукту, называет циклом смерти продукта. См. схему 6.1.

Схема 6.1. Цикл смерти продукта, автор Дэвид Дж. Блэнд

Цикл смерти продукта – это специфическая форма ловушки. Вы реализуете идеи, не подтвердив их. Придумывать собственные решения не входит в обязанности клиента. Это ваша работа. Вы должны глубоко понять их проблемы, а затем определить лучшие стратегии.

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

Очень часто архетип «официанта» идет в паре с другим архетипом – управлением проектами. Поскольку они не сосредоточены на причинах и результатах, они склонны уделять много внимания срокам. Менеджеры проектов, которых назначают на должности менеджеров продуктов, часто становятся «официантами», размахивающими календарем.

Бывший продакт-менеджер

Менеджеры по продукту не являются менеджерами проектов, хотя для правильного выполнения своей роли необходимо разбираться в обеих областях. Менеджеры проектов отвечают за сроки. Когда закончится проект? Все ли идут по плану? Уложимся ли мы?

Менеджеры по продукту отвечают за причины. Почему мы это создаем? Как это принесет пользу нашим клиентам? Как это поможет достичь целей? На последние вопросы ответить сложнее, чем на первые, и слишком часто менеджеры по продукту, которые плохо понимают свою роль, прибегают к выполнению такого рода работы. Многие компании до сих пор считают, что менеджер проектов и менеджер по продукту – это одно и то же.

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

Именно по этой причине многие из менеджеров проектов, которые когда-то существовали в этих компаниях, теперь стали менеджерами по продукту или владельцами продукта. Однако им зачастую не хватает опыта, необходимого для того, чтобы стать хорошим менеджером. Как вы поняли, ответ на вопрос «почему» сильно отличается от ответа на вопрос «когда». Это требует стратегического мышления, понимания клиента, бизнеса, рынка и организации. Только такой набор навыков поможет стать успешным продакт-менеджером.

Глава 7
Успешный продакт-менеджер

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

Название должности само по себе вводит в заблуждение. Эффективный менеджер по продукту – это не директор. Должность не предполагает больших прямых полномочий. Чтобы стать успешным лидером, менеджеры по продукту должны признавать сильные стороны членов команды и работать с ними для достижения общей цели. Им нужно убедить команду, как и всю компанию, в том, что их действия являются правильным решением. Эти навыки влияния очень важны.

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

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

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

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

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

Технический эксперт и рыночный эксперт

Успешный менеджер по продукту должен уметь взаимодействовать с бизнес-подразделениями, технологическими и дизайнерскими отделами и использовать их коллективные знания. Одной из худших черт продакт-менеджера может быть менталитет одинокого волка – идея о том, что только он несет ответственность за успех своего продукта. Это приводит к тому, что они становятся высокомерными и пренебрежительно относятся к идеям своих команд.

Успешные менеджеры понимают, что они добьются успеха только тогда, когда будут использовать навыки и опыт коллег. Они не придумывают решения в вакууме. Они работают с UX-дизайнером, чтобы понять ключевые рабочие процессы; с разработчиками, чтобы определить, как быстро вывести продукт или функции на рынок.

Мне часто задают вопрос: «В чем разница между UX-дизайном и управлением продуктом?» Эти две дисциплины во многом пересекаются, но пользовательский опыт – это только одна часть создания хорошего продукта. Дизайн – его важнейший компонент. Но опять же это тоже только одна его часть. Управление продуктом – это изучение всей системы: требований, компонентов функций, ценности, пользовательского опыта, базовой бизнес-модели, ценообразования и интеграции. Это выяснение, как конкретный продукт может принести доход компании. Речь идет о понимании всей картины организации и выяснении того, как продукт – а не только опыт – в нее вписывается.

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

Менеджер по продукту должен быть технически грамотным, а не свободно владеть техникой. Это означает, что они могут обсуждать и понимать технологию, разговаривать с разработчиками и принимать решения о компромиссах. Они знают, какие вопросы нужно задать инженерам, чтобы понять сложность определенных функций или улучшений. Менеджеру по продукту не обязательно уметь кодировать (если только продукт не является высокотехничным и для принятия решений необходимо глубокое понимание технологии).

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

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

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

Грамотный продакт-менеджер

«Так что же представляет собой грамотный менеджер по продукту?» – спросила команда Marquetly. Я решила, что им надоело слушать мои рассуждения, поэтому пригласила Меган, знакомого мне продакт-менеджера. Она работала над программным обеспечением для потребительских ипотечных кредитов в крупном розничном банке. Меган пришла поговорить с командой о том, что она думает о своей роли, и какую работу она ежедневно выполняет.

«Я всегда начинаю с концепции нашего ипотечного подразделения, – объяснила Меган. – Это наш бизнес. Наша цель – сделать так, чтобы заявителям было проще и удобнее подавать заявки (как и владельцам ипотечных кредитов получать доступ к информации)».

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

«Я очень сопереживаю клиентам и выясняю, что им не нравится. Я называю их Мэри и Фред, – рассказала она команде Marquetly. – Они живут в Нью-Йорке и ищут свой первый дом в Коннектикуте, потому что Мэри беременна, и им нужно больше места. Вы не поверите, через что им пришлось пройти, чтобы подать заявку на ипотечный кредит. За последний месяц они несколько раз ходили в местное отделение банка на встречу с кредитным инспектором. Они заполняли огромное количество бумаг в офисе. Иногда они забывали нужные документы, и им приходилось за ними возвращаться на следующий день и делать все заново. Затем им приходилось ждать, чтобы узнать, одобрена ли сумма». Меган продолжала объяснять очень подробный процесс, через который пришлось пройти паре. Было ясно, что она хорошо знает клиентов и знает их болевые точки.

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

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

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

Меган периодически приглашала членов своей команды – разработчиков и UX-дизайнера – на сеансы исследования пользователей, чтобы все могли четко понять проблемы. Вскоре они обнаружили закономерность: многих потенциальных клиентов просили прийти в офис для проверки документов (поскольку это нельзя было сделать онлайн). Большинство людей предпочитали обратиться в другой банк, потому что в этом банке не было свободных мест на ближайшее время. Проведя опрос среди более широкого круга людей, Меган выяснила, что это была самая распространенная проблема. Только 25 % людей заполнили заявки в ее банке.

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

Меган рассказала нашей команде о первом тестировании. Чтобы понять, как создать онлайн-систему для загрузки и проверки необходимых документов для ипотеки, они сразу перешли к практике и попросили заявителей прислать документы по электронной почте. На время тестирования банк назначил человека для проверки документов и их одобрения. За это время новые заявители заполняли свои заявки на 90 % чаще, чем те, кто приходил в офис.

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

Отсюда команда Меган работала в обратном направлении: они определяли, что должно войти в первую версию нового продукта, и расставляли приоритеты по ценности и усилиям. Кроме того, они расширили эксперимент и создали более надежные способы для отправки документации и заявок. Одобрение по-прежнему выполняли люди. Хотя им не удалось проверить информацию каждого клиента в режиме онлайн, они смогли сократить количество необходимых визитов на 50 %. Это было отличное начало.

Команда планировала и дальше совершенствовать решения, включая компоненты искусственного интеллекта (ИИ) и онлайн-нотариусов, пока не достигнет своей цели – нулевого количества визитов для проверки. «Самое важное, чему я научилась в продакт-менеджменте, – это всегда фокусироваться на проблеме. Если вы будете ориентироваться на продукт, вы с большей вероятностью создадите правильную вещь», – сказала Меган.

Начните с «почему»

Теперь давайте поговорим о том, что помогло Меган и ее команде добиться успеха. Она начала с вопроса «почему?».

• Почему мы переходим на цифровое обслуживание в сфере ипотеки?

• Зачем вообще делать этот проект?

• Каков желаемый результат?

• Как выглядит успех?

• Что произойдет, если мы перейдем на цифровое обслуживание, но никто не будет брать кредит?

• Как мы можем снизить этот риск?

Слишком часто менеджеры по продукту погружаются в создание решений, не продумав сопутствующие риски. Каждый из вышеупомянутых вопросов представляет для Меган риск, который потенциально может погубить ее проект. Здесь назревает вопрос: почему мы так поступаем? Во многих розничных банках и других организациях менеджерам по продукту не дают возможности задать вопрос «почему». Они получают функции и решения от заинтересованных сторон или менеджеров. Иногда эти функции определяются и утверждаются во время ежегодного периода бюджетирования. В других случаях их рассматривают как работу менеджера – диктовать решения, которые необходимо создать. Поступая таким образом, вы создаете риск неудачи, связанный с предвзятостью этих решений, организационной или личной. Единственный способ борьбы с этой предвзятостью – учиться у пользователей и экспериментировать.

Во многих случаях, когда организации предлагают решения, они не устанавливают метрики успеха и цели. Проект Меган мог бы пойти совсем по-другому, если бы это было так, и если бы ей просто сказали: «Сделайте процесс подачи заявки цифровым, чтобы никому не пришлось лично обращаться в банк». А что, если бы она обнаружила, что ее клиенты не хотят подавать заявки онлайн и им удобнее делать это в офисе? Что, если бы цифровизация процесса привела к резкому снижению процента оформления заявок? Как она могла принять решение и исправить ситуацию, если у нее не было для этого никакого пространства?

Самая большая проблема, которую я слышу от руководителей, приходя в их организации, заключается в том, что продакт-менеджеры не хотят делать шаг вперед и «владеть продуктом». Однако это обоюдоострый меч. Во многих случаях менеджер может сделать больше. Например, он может поставить под сомнение определенные решения. Работа, необходимая для сбора данных и доказательства эффективности решения, требует времени. И вот именно здесь люди обычно путаются между тем, что в Agile называется владельцем продукта и менеджером по продукту.

Если посмотреть на роль владельца продукта в большинстве литературы по Scrum (методология управления проектами), то в обязанности этой должности входит следующее:

• Определение бэклогов и создание действенных пользовательских историй для команд разработчиков.

• Выявление и расставление приоритетов работы в бэклоге.

• Приемка завершенных пользовательских историй и проверка работы на соответствие критериям.

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

• Как мы определяем ценность?

• Как мы измеряем успех продуктов на рынке?

• Как убедиться, что мы создаем нужный продукт?

• Как устанавливать цену и упаковывать продукт?

• Как вывести продукт на рынок?

• Что имеет смысл создавать, а не покупать?

• Как выйти на новые рынки, используя стороннее программное обеспечение?

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

Без такого опыта человек может эффективно выполнять роль владельца продукта, но он никогда не сможет быть уверенным в том, что он создает правильную вещь. Другими словами, владелец продукта – это роль, которую вы играете в команде Scrum. Менеджер продукта – это карьера.

Если вы уберете Scrum-команду и Scrum как процесс, вы все равно останетесь менеджером продукта. Управление продуктом и Scrum могут хорошо работать вместе, однако управление продуктом не зависит от Scrum. Эта роль должна существовать с любой структурой или процессом, и компании должны понимать это, чтобы настроить своих сотрудников на успех.

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

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

Поговорив с людьми, которые не закончили подачу заявки на ипотеку, она узнала о проблеме проверки документов. Именно тогда она смогла сказать: «Ага! Если я найду эффективный способ проверки документов, тогда люди будут завершать оформление ипотеки». Она нашла проблему, которую нужно решить, вместо того чтобы гадать, что должно произойти, а затем бросать все свои силы на решение проблемы, которые могут существовать, а могут и не существовать.

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

Менеджеры по продукту играют несколько ключевых ролей, но одна из самых важных – это способность объединить бизнес-цели с целями клиентов для достижения ценности. Хорошие менеджеры способны понять, как достичь целей бизнеса, создавая или оптимизируя продукты, и все это с учетом решения реальных проблем клиентов. Это очень важный набор навыков.

Слишком часто компании даже не знают, в чем состоит работа продакт-менеджеров. Они не понимают их значимости в компании. Я нередко слышу, что руководители не хотят нанимать продакт-менеджеров, потому что не понимают, зачем они нужны. «Всем занимается генеральный директор, – вот что они говорят. – У нас не такая большая организация – несколько сотен человек. Команда справится». Отговорки только накапливаются, и в итоге организации не удается сохранить долгосрочную ценность для пользователей. Они быстро разваливаются или, в случае с крупными компаниями, медленно угасают. Если вы хотите выбраться из ловушки и начать фокусироваться на правильных решениях и продуктах, которые нужны и востребованы клиентами, вы должны внедрить в свою компанию управление продуктом.

Одна роль, много обязанностей

Крис начал понимать. «Похоже, мне и правда нужны продакт-менеджеры. Но как мне удержать их в процессе работы? У них есть возможность карьерного роста?» Мы обсудили их обязанности и карьерную лестницу.

Ваши роли и обязанности будут меняться в зависимости от контекста, стадии развития продукта или вашей руководящей позиции в организации. Без Scrum-команды или с небольшой командой вы можете заниматься стратегией и проверкой продукта. Со Scrum-командой вы будете более сфокусированы на выполнении решений. Будучи руководителем продакт-менеджеров, вы можете руководить стратегией для большей части продукта и обучать свои команды поиску и выполнению решений.

Scaled Agile Framework (SAFe) (масштабированный гибкий фреймворк) учит этому по-другому, и я думаю, что это одно из самых слабых мест во всей системе. В SAFe менеджеры по продукту являются руководителями владельцев продукта и отвечают за взаимодействие и работу с внешним миром. Они разговаривают с клиентами, определяют требования и объем создаваемых продуктов и передают их владельцам продуктов. Владельцы продуктов работают внутри компании, определяя компоненты решения и работая с разработчиками над его внедрением.

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

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

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

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

Важно иметь гибкость в выборе размера команды в зависимости от стадии развития продукта. Если вы дадите продакт-менеджеру бэклог большой Scrum-команды, который он должен поддерживать, пока вы находитесь в режиме открытий, он будет его поддерживать. Но при этом они будут разрываться между обеспечением потока работы для разработчиков и попытками выполнить работу для подтверждения направления. В результате ни то, ни другое не будет выполнено должным образом.

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

Глава 8
Карьерный путь менеджера по продукту

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

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

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

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

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

График 8.1. Стратегическое, оперативное и тактическое процентное соотношение ролей (для команд численностью более 10 человек)

Давайте рассмотрим типичный карьерный путь менеджера по продукту:

• младший продакт-менеджер;

• менеджер по продукту;

• старший менеджер по продукту;

• директор по продукту;

• вице-президент по продукту;

• главный директор по продукту (CPO).

Младший продакт-менеджер

Роль младшего продакт-менеджера является начальным уровнем. Однако, как я уже упоминала в начале этой части, в компаниях, кроме Microsoft и Google, таких должностей не так много. Именно это нам и требуется изменить в отрасли. Если компании хотят иметь грамотных менеджеров, им нужно начать их выращивать.

Хотя я считаю, что основам управления продуктом можно обучить любого человека, у которого есть склонность к этой области и желание учиться, важно помнить, что это дисциплина, которой нужно овладеть в процессе карьеры. Как я уже объясняла, управление продуктом – это не то, чему можно научиться на двухдневном курсе, как хотели бы вас убедить многие Agile-консультанты. Вам нужно развивать набор навыков посредством опыта и практики, как и в любой другой специальности.

Разработчики учатся своему ремеслу, работая в паре со старшими IT-архитекторами и очень опытными разработчиками. Сотрудники отдела продаж учатся у опытного руководителя в своем подразделении. В продакт-менеджменте должна существовать такая же система, и именно поэтому компании важно иметь опытных людей, которые смогут работать в паре с младшими сотрудниками. Однако, как знает любой человек, кто когда-либо пытался нанять старших специалистов по продуктам, на рынке их не так много. А тех, кто есть, быстро расхватывают. Так почему у нас так мало людей с опытом работы в этой роли?

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

Менеджер по продукту

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

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

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

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

Многие компании добавили должность владельца продукта, включающую в себя обязанности, о которых мы говорили в предыдущей главе. Они рассматривают эту должность как роль начального уровня, предшествующую должности менеджера по продукту. Как я уже объясняла, когда вы думаете, что продакт-менеджер занимается только стратегией, а владелец продукта – только тактикой, вы упускаете связь между концепцией и повседневной работой. Это приводит к тому, что человек, отвечающий за продукт, становится слишком тактичным. Когда вы попытаетесь продвинуться по карьерной лестнице, владелец продукта не будет иметь опыта работы со стратегией, который столь необходим для эффективной работы. Я считаю, что в отрасли лучше отказаться от названия «владелец продукта» и называть всех, кто занимает эту должность, менеджерами по продукту, чтобы обеспечить последовательный и осмысленный карьерный рост.

Старший менеджер по продукту

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

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

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

Директор по продукту

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

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

Вице-президент по продукту

Следующая должность – вице-президент по продукту. Человек в этой роли контролирует стратегию и операции для всей линейки продуктов.

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

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

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

Главный директор по продукту (CPO)

Главный директор по продукту – это довольно новая, но очень важная роль для организаций. CPO курирует весь портфель продуктов компании. Это самая высокая должность менеджера по продукту, и она означает место за исполнительным столом компании.

Компании следует задуматься о введении должности CPO, когда она начинает разрабатывать второй продукт, расширяет географию деятельности или объединяется с другой компанией. Эта роль очень важна для обеспечения совместной работы всего портфеля для достижения целей компании.

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

CPO должен уметь взаимодействовать и на уровне совета директоров. Шелли Перри, венчурный партнер компании Insight Venture Partners и эксперт по роли CPO, объясняет это следующим образом: «Члены совета директоров заботятся о финансовых последствиях решений, касающихся технологий и продуктов. Успешный директор должен уметь переводить свои действия в понятные для совета директоров термины».

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

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

Чтобы вселить уверенность в направление развития продукта, CPO работают со многими функциями. Они должны объединять ключевые отделы и заинтересованные стороны. Чтобы это сделать, они изменяют способ изложения истории и ведут себя правильным образом. Данная черта позволяет им добиваться результатов посредством влияния, а не посредством прямых полномочий.

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

Наконец, CPO должны быть неутомимыми и стойкими сотрудниками. Им крайне необходимо обладать желанием копаться в деталях и выяснять, что работает, а что – нет. Они постоянно оценивают, анализируют, пытаются доказать правильность или неправильность своих гипотез.

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

Наличие сильного лидера в руководстве – это критически важный шаг к тому, чтобы стать компанией, ориентированной на продукт. К сожалению, в настоящее время на рынке не так много CPO, поскольку эта область еще только формируется. Моя компания, Produx Labs, в партнерстве с Insight Venture Partners создала акселератор CPO, в котором вице-президенты по продукту превращаются в CPO своих компаний. Мы рады развивать будущих лидеров, находящихся на стадии роста, которые могут помочь создать успешные, нацеленные на продукт организации.

Глава 9
Организация команды

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

Marquetly была структурирована вокруг технических компонентов. «Наш тренер по Agile предложил создать Scrum-команды для каждой области продукта», – сказал технический директор. Хотя в теории это имеет смысл, на практике это способствовало плохому управлению продуктом.

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

– Все это, конечно, замечательно. Я бы хотела так работать, но не могу, потому что мне нужно поддерживать бэклоги для API-логина. Если я перестану, моим разработчикам нечем будет заниматься.

– Это новый API? – поинтересовалась я. – Есть ли с ним сейчас какие-то серьезные проблемы, которые вы пытаетесь исправить?

Оказалось, никаких серьезных проблем не было. Интерфейс прекрасно работал.

– Какова ваша цель? – продолжила я. – Когда вы поймете, что с API покончено и можно переходить к чему-то другому?

– О, нет-нет-нет, – запротестовала она. – Я владею им. Он принадлежит нашей команде, и мы никогда не возьмем что-то другое. Это наша функция.

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

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

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

Здесь назревает вопрос: разве это плохо, когда команды владеют функциями и присматривают за ними? И да, и нет. Чтобы эффективно организовать команды, вам нужно сбалансировать их равновесие и масштаб с целями, которые вы пытаетесь достичь.

Если компания небольшая, то организовать команду гораздо проще. Рассмотрим, как это делает TransferWise, базирующаяся в Лондоне компания, занимающаяся электронными переводами. Вы можете отправлять деньги в разные страны в других валютах с очень низкой комиссией по сравнению с тем, что взимают банки. У TransferWise относительно небольшое количество продуктовых команд – около 12. То, как они организуют свои команды – в соответствии со стратегическими целями – позволяет им оставаться небольшими и при этом выполнять огромный объем работы.

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

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

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

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

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

Многие компании смущает слово «продукт». Вы говорите «продукт», и люди думают о приложении, функции или интерфейсе. Если вы вспомните нашу диаграмму обмена ценностями на рисунке 1.1, продукты – это носители ценности. Поэтому, если ваше приложение, интерфейс или функция сами по себе не добавляют ценности, то это всего лишь часть всего продукта. Это не значит, что никто не должен им управлять. Это просто означает, что вы должны смотреть шире.

Рассмотрим страховую компанию. Продукты страховой компании – это то, что она продает клиентам: автострахование, страхование жилья, страхование жизни. Я покупаю страховку на автомобиль, потому что она обеспечивает мне душевное спокойствие на случай, если я попаду в аварию. Это и есть ценность. Наличие приложения для iPhone, которое позволяет управлять страхованием автомобиля, является лишь частью потока ценности этого продукта. Приложение может помочь мне получить больше информации о страховом полисе или найти варианты действий, если я попаду в аварию. Функциональность для меня ценна, но само по себе приложение не является достаточной ценностью. Мне по-прежнему нужен продукт автострахования.

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

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

Продуктовая команда компании Marquetly

Команда компании Marquetly не была рассчитана на масштабирование. В компании было задействовано 20 продуктовых команд, организованных вокруг компонентов, а менеджеры по продуктам писали пользовательские истории каждую секунду каждого дня. Большинство из 20 продакт-менеджеров должны были считаться младшими, поскольку они являлись новичками в этой роли. Кроме того, у них был только один старший сотрудник – Кáрен, вице-президент, который мог их обучать.

– Как организовать компанию? – спросил однажды Крис.

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

Но и это еще не все:

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

На схеме 9.1 показан первый вариант конечной организации Marquetly. Начали мы с него, зная, каким был продукт. Но после найма главного директора и по мере формирования более сильной концепции мы захотели увидеть итерации. Нельзя построить организационную структуру без видения продукта, потому что потоки ценности не очевидны. К счастью, у Marquetly было достаточно концепций, чтобы оказать значительное влияние в краткосрочной перспективе.

Схема 9.1. Организационная схема управления продуктом Marquetly в окончательном виде

Здесь мы балансировали между старшими и младшими сотрудниками и убедились, что можем масштабироваться должным образом. Вы можете заметить, что в организации нет 20 человек. Почему? Когда мы начали разбивать продукт на потоки ценности и организовывать работу вокруг наборов функций, которые обеспечивают полную ценность (вместо областей компонентов, таких как API), мы обнаружили, что 20 областей не существует. Такое часто случается, когда команды перестраиваются на основе ценности, а не компонентов. Они обнаруживают, что им не нужно так много людей для достижения своих целей.

Pandora, музыкальный сервис по подписке, является примером компании, которая обнаружила, что ограничение в виде небольшой команды может привести к успеху. Они смогли увеличить число пользователей до 70 миллионов в месяц, имея всего 40 инженеров. Они добились этого благодаря расстановке приоритетов, что в конечном счете заложило основу для сегодняшней оценки Pandora в 7 миллиардов долларов. Оставаясь маленькой, компания смогла сосредоточиться на выполнении самой важной работы для развития бизнеса.

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

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

Часть III
Стратегия

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

В 2005 году Netflix собрала более четырех миллионов подписчиков и 50 000 наименований фильмов и телепередач в каталоге DVD, что за шесть лет существования компании представляло собой значительный рост. Вся компания сплотилась вокруг идеи, которую сформулировал ее основатель после того, как в компании Blockbuster ему выписали штраф на 20 долларов за опоздание: «Необходимо предоставлять фильмы и телепередачи наиболее удобным и простым для клиентов способом». Ориентируясь на клиента, компания Netflix поставила перед собой цель полностью перевернуть потребительский рынок, связанный со сферой развлечений.

В то время компания инвестировала значительные средства в DVD, где она была невероятно успешна. Однако организация не рассматривала DVD как конечную точку. В интервью журналу Inc. в 2005 году основатель и генеральный директор компании Рид Хастингс сказал следующее:

«DVD в ближайшем будущем продолжит приносить крупную прибыль. У Netflix впереди еще как минимум десятилетие господства. Но фильмы, предоставленные в Интернете, тоже не за горами, и в какой-то момент это станет большим бизнесом. Мы начали инвестировать 1–2 % от выручки в скачивание, и я думаю, что это фундаментально снизит наши расходы на рассылку. Мы хотим быть готовыми к появлению видео по запросу. Именно поэтому компания называется Netflix, а не DVD-by-Mail».

Netflix понимала, что если она действительно хочет предоставить самую удобную платформу для просмотра фильмов, ей необходимо найти способ быстрее доставлять развлечения в руки пользователей. Несмотря на то, что в начале 2000-х годов Интернет быстро развивался, скорость скачивания оставляла желать лучшего. В те дни мне требовалась целая ночь, чтобы скачать аудиоальбом с Napster. Фильм весит в 1000 раз больше, чем один из этих файлов. Но к 2005 году Интернет достиг того уровня, когда это стало возможным. Это событие помогло компании разработать общую стратегию на будущее:

1. Добиться успеха в DVD;

2. Лидировать в стриминге;

3. Расширяться по всему миру.

Поскольку компания Netflix уже работала в сфере онлайн-видео, она смогла понять, что людям это интересно. Интернет становился все быстрее, и компания ожидала, что все большее количество людей будут скачивать видео по запросу, а не оформлять подписку на DVD. С точки зрения стратегии это имело смысл – мгновенные развлечения, безусловно, удобны. Однако их предложение приняли не так уж и много людей. Почему?

Отступив назад и взглянув на ситуацию с точки зрения клиента, Netflix поняла, что единственными устройствами с доступом в Интернет в то время были ноутбуки и домашние компьютеры. Это был не самый удобный способ просмотра фильмов. Время от времени – да, но для постоянного пользования такой вариант не подходил. Большинство людей предпочитали смотреть фильмы на большом экране в кругу семьи и друзей. Чтобы занять лидирующие позиции на рынке потокового вещания, компания решила вплотную заняться этим вопросом: создать способ смотреть контент на любом устройстве.

Поэтому Netflix создала собственное устройство, подключаемое к Интернету и к телевизорам. Они назвали его «Проект Гриффин». Компания потратила годы на разработку продукта, тестирование и проверку устройства. Все были воодушевлены. Затем, за несколько дней до запуска в 2007 году, Рид Хастингс разослал по электронной почте письмо с просьбой остановить производство. «Уничтожьте все», – велел он.

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

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

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

История Netflix – это воплощение отличной стратегии, и нам повезло, что они открыто рассказали о ней, чтобы мы могли извлечь из нее уроки. Однако, даже имея такую стратегическую основу, компания все равно попала в ловушку. Почему? Легко отвлечься, как объяснил Гастингс в интервью The New York Times:

«После того как мы в конце концов выиграли битву с Blockbuster, я оглянулся назад и понял, что все эти вещи нас отвлекали. Они не помогли, а лишь навредили. Мы победили потому, что улучшили ежедневный сервис. Мы выросли благодаря этому опыту. Лучшее выполнение основной миссии – это путь к победе».

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

Во-первых, они сосредоточили компанию вокруг четкой концепции. Концепция менялась со временем по мере развития рынка. Сейчас видение Netflix таково: «Стать лучшей глобальной службой распространения развлекательного контента, лицензировать этот контент по всему миру, создавать рынки, доступные для создателей фильмов, и помогать создателям контента находить аудиторию». В концепции говорится не только о том, почему компания существует, но и о плане достижения цели. Это настраивает команду на правильный лад.

Затем Netflix самоорганизовалась вокруг ключевых результатов и стратегий, способных помочь достичь поставленных целей. Гибсон Биддл, который занимал должность вице-президента по продукту в Netflix с 2005 по 2010 год, рассказывает о том, как он выстроил команду вокруг общего руководства для оценки стратегии продукта. Вот их ориентир – «радовать клиентов и повышать прибыль трудновоспроизводимыми способами». Он определил принципы, которые позволят достичь этих целей и помогут Netflix реализовать концепцию с помощью ключевых инициатив (Таблица III–1), включая персонализацию, увеличение маржи, мгновенный доступ к контенту и простоту использования. Затем команды смогли изучить тактику достижения этих целей и обратить все внимание на ценность.

Сочетание концепции, целей и ключевых инициатив помогает создать систему, в которой Netflix может принимать решения относительно своих продуктов. Иногда эти решения непросты, как, например, убийство Roku. Netflix способна менять тактику или уничтожать идеи, потому что она берет на себя обязательства не за решения, а за результаты, которые эти решения приносят. Затем компания внедряет этот менталитет с помощью согласованно продуктовой стратегии, которая как раз и позволяет принимать решения.

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

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

Глава 10
Что такое стратегия

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

– Мы столкнулись с регистрационной воронкой. Мы видим, что люди отваливаются на третьем шаге. Нам нужно протестировать программу и понять, почему это происходит. Это наша цель на неделю. Как мы это сделаем? – спросила я команду, как раз в тот момент, когда технический директор зашел в зал и сел в кресло.

– Нужно как-то связаться с этими людьми, – предложил один из разработчиков. – Может быть, мы сможем обратиться к…

Его резко перебил технический директор:

– Я не понимаю, в чем заключается продуктовая стратегия.

– А я не понимаю, что вы имеете в виду, – ответила я. – Они пытаются диагностировать проблему и найти пути решения. У них есть цель. Они выявляют проблемы, связанные с ней.

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

Я возразила:

– Как они могут сказать вам, что они будут делать, если они не уверены, зачем они это делают? Они не смогут разработать правильный продукт, пока не узнают, какую проблему они решают.

Техническому директору не нужна была стратегия. Ему нужен был план. Хорошая стратегия – это не подробный план. Это основа, которая помогает вам принимать решения. Слишком часто люди думают о стратегии продукта как о документе, состоящем из списка желаемых функций заинтересованных сторон и подробной информации о том, как эти функции будут реализованы. И они переполнены массой «жужжащих» слов, таких как платформа или инновации.

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

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

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

Словарь определяет стратегию как «план действий или политику, направленную на достижение главной или общей цели». Это определение, похоже, является общепринятой трактовкой стратегии в различных компаниях. Многие компании тратят месяцы на «стратегическое планирование» на следующий год, создавая всеобъемлющие и подробные планы задач, стоимость этих действий и доходы, которые они принесут. Часто это связано с процессом составления бюджета, когда команде нужно представить бизнес-кейсы и сроки.

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

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

Хорошая стратегия должна выходить за рамки итераций функций и сосредотачиваться на высокоуровневых целях и концепции. Хорошая стратегия должна поддерживать организацию в течение многих лет. Если вы меняете стратегию раз в год или месяц, не имея на то веских оснований в виде данных или рынка, вы относитесь к своей стратегии как к плану, а не как к основе.

Глава 11
Стратегические пробелы

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

• Пробелы в знаниях;

• Пробелы в согласовании;

• Пробелы в результатах.

Пробелы в знаниях

Пробелы в знаниях (сх. 11.1) – это разница между тем, что руководство хотело бы знать, и тем, что компания знает на самом деле. Организации пытаются преодолеть этот пробел, предоставляя и требуя более подробную информацию.

Схема 11.1. Пробел в знаниях. Стивен Бангей. «Искусство действия»

Если вы как руководитель говорите себе: «О черт, это я», вы не одиноки. Именно эти слова вырвались из уст одного руководителя, когда я представила ему концепцию. Этот пробел, вероятно, является самым легкоузнаваемым из всех существующих.

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

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

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

Представьте, что менеджер по продукту говорит вам следующее: «Я разрабатываю продукт, потому что он поможет увеличить поток клиентов, что, в свою очередь, приведет к увеличению доходов и выполнит приоритетную задачу. Я знаю, что мой продукт может привлечь людей. Мы также знаем, что есть проблема, но пока не уверены, в чем она заключается. Наш следующий шаг – обнаружить эту проблему, решить ее, а затем попытаться оптимизировать решение, чтобы увеличить количество привлеченных клиентов». Отличная речь. Такой менеджер должен внушать доверие. Но, к сожалению, обычно бывает наоборот.

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

Пробелы в согласовании

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

Схема 11.2. Пробел в согласовании. Стивен Бангей. «Искусство действия»

В одной из компаний, где я работала, я обошла всех менеджеров по продукту из сотни команд и спросила, почему они работали над текущим проектом. Затем я задала тот же вопрос их руководителям. И получила два разных ответа. Они не могли связать деятельность команд с результатами деятельности компаний, потому что руководство передавало запросы на функции, а не ожидаемые результаты и цели. Как только запросы на функции были приняты, изменить их было практически невозможно, потому что компания ожидала, что они будут реализованы.

Хотя я наблюдала подобное во многих компаниях, один пример не выходит у меня из головы. Я проводила обучение продакт-менеджеров в очень крупной и известной компании (назовем ее «B»). Мне сказали, что компания не могла проводить валидацию продукта, потому что решения уже были переданы руководству. Спросите, почему? Потому что компания «B» наняла огромную консалтинговую фирму, чтобы изучить и продиктовать стратегию на следующие пять лет. Консультанты изучили исследования рынка, провели анализ конкуренции и разработали план, который затем был передан командам.

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

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

Вместо того чтобы рассылать мандаты, организациям следует ориентироваться на согласовании вопросов «почему» и «как». Они должны определять ценность, после чего предоставлять следующему уровню возможность выяснить способы ее достижения, а только потом требовать отчеты. При таком подходе управление продуктом становится успешным. Когда руководство не согласовано на самом верху, проблемы просачиваются вниз, к командам. Отсутствие смысла и фокуса постепенно распространяется, и в конце года компания посмотрит на свои целевые показатели и спросит: «А что случилось?» Отсутствие согласованности руководства – это, безусловно, самая большая проблема, которая, по моему мнению, стоит на пути успешного продакт-менеджмента.

Пробелы в результатах

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

Схема 11.3. Разрыв в результатах. Стивен Бангей. «Искусство действия»

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

Чтобы устранить эти пробелы и предоставить клиентам хороший продукт, необходимо по-другому взглянуть на стратегию и, как предлагает Бангей, дать возможность действовать для достижения результатов. Но почему нам так важно, чтобы стратегия становилась чем-то, что дает нам разрешение действовать? Именно так вы масштабируете организацию – создаете условия для действий с помощью автономных команд.

Автономные команды

В компании Marquetly продакт-менеджеры очень переживали из-за отсутствия самостоятельности. Один опытный сотрудник сказал мне: «Мне постоянно говорят, что я должен сам определять концепцию продукта, но мне не разрешают. Мой руководитель продолжает снабжать меня решениями. Каждый раз, когда я пытаюсь предложить что-то другое, мне отказывают. Когда мы переходили на Agile, нам сказали, что Scrum-команды должны быть автономными. Но это – определенно не автономия».

Общаясь с руководителями Marquetly, я услышала другую историю: «Наши менеджеры не хотят брать на себя ответственность за продукт. Мне приходится постоянно что-то им предлагать. И все потому, что они не проявляют инициативы». Это интересная дихотомия, и тем не менее она часто встречается в компаниях, застрявших в ловушке разработки. Все это симптомы отсутствия хорошей стратегической основы, которая позволяет действовать. Когда команды не имеют четкого направления и целей, они не могут принимать эффективные решения. А если они осмеливаются пробовать, то чаще всего руководитель вмешивается и говорит: «Нет, так неправильно».

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

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

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

Глава 12
Создание хорошей стратегии

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

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

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

Бум. Она попала в точку – и всего через неделю Marquetly застряла в реактивном режиме. Она определяла приоритеты крупных проектов на основе запросов клиентов или контрактов. Она не думала стратегически, как развивать продукт.

К счастью, руководство компании Marquetly решило добиться единства взглядов, чтобы стать более мощной организацией. «Мы хотим лидировать на рынке, мы не хотим играть в догонялки», – сказал мне Крис, генеральный директор. Изначально он думал, что проблемы связаны с командами разработчиков. «Они медленно работают. Они халтурят». Крис был большим поклонником целей и ключевых результатов (OKR) и внедрил их во всей компании, но они были слишком ориентированы на показатели, а не на результат. «Разработать первую версию новой платформы для учителей» считалось его целью. А «выпустить к июню 2018 года» рассматривалось как ключевой результат. Они не были привязаны к какому-либо результату – ни в интересах бизнеса, ни в интересах клиента.

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

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

Компания неправильно развертывала и создавала стратегию. Все признаки были налицо. Джен заметила их в первую же неделю работы. Руководящая команда сама определяла приоритеты работы, основываясь на собственных желаниях, а не на отзывах клиентов. Она реагировала на клиентов, которые кричали громче всех, вместо того чтобы оценить, соответствуют ли эти запросы стратегическим целям. Моральный дух компании упал, ввиду чего сотрудники перестали эффективно работать.

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

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

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

Возможно, эта картина вам очень знакома. История повторяется из года в год. В ноябре компания впадает в режим паники, бегая, как курица с отрубленной головой, пытаясь предсказать будущее. Доходы, обязательства перед акционерами, бюджет – все это фиксируется. Список функций, которые необходимо создать, складывается в подробные диаграммы Ганта. А потом наступает 1 января, и все приступают к работе. Они работают в течение года, достигают срока (31 декабря), а затем останавливаются, чтобы принять следующую стратегию.

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

Подумайте об основных видах работ, которые вы выполняете, как о ставках. Хенрик Ниберг, бывший консультант компании Spotify, объясняет, что они мыслили именно так. В своей работе компания использует нечто под названием DIBBs, что расшифровывается как Data, Insights, Beliefs, and Bets (данные, факты, убеждения и ставки). Первые три составляющие – данные, факты и убеждения – обеспечивают работу, называемую ставкой. Концепция, согласно которой инициативы рассматриваются как ставки, является мощной, поскольку она устанавливает совершенно иной тип ожиданий.

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

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

Развертывание стратегии

Стратегии – это взаимосвязанные истории, рассказываемые в рамках организации и объясняющие цель и результаты, адаптированные к определенным временным границам. Акт передачи и согласования этих историй мы называем развертыванием стратегии.

Джейб Блум, основатель консалтинговой компании PraxisFlow, работает с руководителями над созданием и развертыванием стратегий в крупных организациях. Он объясняет, почему мы должны думать о стратегиях разных уровней как об историях в разных временных масштабах:

«На разных уровнях в организациях мы рассказываем истории о нашей работе и о том, почему мы ее выполняем, но делаем это в разных временных масштабах (с разными временными отрезками). Для того чтобы люди могли действовать в соответствии с услышанными версиями, временные масштабы не могут значительно отличаться от тех, к которым они привыкли. Agile-команды хорошо рассказывают истории продолжительностью от двух до четырех недель. Это то, с чем они имеют дело на ежедневной основе. По мере продвижения в организации вы рассказываете истории с более длительными сроками. Руководители умеют рассказывать пятилетние истории, однако команда не может действовать на основе пятилетней версии, если она привыкла думать в рамках двух-четырех недель. Остается слишком много пространства для исследования».

Развертывание стратегии – это установление правильного уровня целей и задач во всей организации. Только сузив игровое поле, команда сможет эффективно действовать. Если руководители могут рассматривать пятилетнюю стратегию, то менеджеры среднего звена мыслят более короткими периодами (год или квартал), тем самым ограничивая команды.

Когда команды недостаточно ограничены, они застревают. Как объясняет Блум:

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

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

В организациях существует множество примеров развертывания стратегии. OKR – метод, используемый компанией Google. Hoshin Kanri – метод, используемый компанией Toyota. Даже военные используют развертывание стратегии с помощью командования миссиями. Все они основаны на одной и той же цели – задать направление для каждого уровня организации, чтобы те могли действовать. Выбор правильного метода важен для организации, но еще важнее понять, что делает стратегическую структуру хорошей.

В большинстве продуктовых организаций должно присутствовать четыре основных уровня (см. таблицу 12.1):

• концепция;

• стратегическое намерение;

• продуктовые инициативы;

• варианты.

Стратегическое развертывание

Таблица 12.1. Уровни стратегического развертывания

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

Создание стратегии

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

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

Стратегия – это способ, с помощью которого вы поднимаете организацию с того уровня, на котором она находится, и достигаете поставленной задачи. Чтобы создать стратегию, необходимо сначала понять концепцию и увидеть четкую цель. Затем мы определяем проблемы или препятствия, стоящие на нашем пути, и экспериментируем с их решением. Мы делаем это до тех пор, пока не достигнем цели.

Именно основа системы непрерывного совершенствования, практикуемая в компании Toyota (Kata), помогла ей определить свои стратегии. Kata учит людей, как стратегически решать проблемы для достижения целей. Майк Ротер описал принцип работы процесса в книге «Toyota Kata», отрывок из которой вы можете увидеть в таблице 12.2.

Таблица 12.2. Четыре шага к Kata. «Toyota Kata: практическое руководство». Майк Ротер.

Во время цикла PDCA (Планируй – делай – проверяй – действуй) команды систематически выявляют препятствия, стоящие на пути к достижению цели, планируют, как с ними справиться, а затем проводят эксперимент, чтобы проверить, сработал ли план. Затем они анализируют достигнутый прогресс (проверка) и на следующем этапе принимают соответствующие меры.

При разработке продукта вы можете использовать тот же подход, но нам нужно адаптировать его к вашей ситуации. Я называю этот метод продакт-Kata, как показано на таблице 12.3.

The Product Kata

Научный систематический путь создания эффективного продукта, разработанный Мелиссой Перри

Таблица 12.3. Продакт-Kata. Мелисса Перри.

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

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

Исследуя и выявляя проблемы, вы обнаруживаете данные, которые необходимы для разработки стратегии и концепции. Концепция не устанавливается исключительно руководством. Вся организация должна обмениваться информацией по мере того, как она узнает об эффективных способах достижения целей. Блум называет это информационной физикой:

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

Именно так мы определяем стратегию. Мы поддерживаем согласованность именно посредством процесса передачи данных по всей организации. Но начаться он должен на уровне компании.

Глава 13
Концепция на уровне компании и стратегические намерения

Концепция компании

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

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

Компания состоит из множества различных продуктов, начиная с сервиса Prime Video и заканчивая сервисом Fulfillment to Amazon. Каждый из них помогает Amazon реализовать общую концепцию, благодаря которой покупатель получает положительный опыт. Следя за общей концепцией, специалисты по продуктам, которые тестируют их, разрабатывают и развивают, могут принимать эффективные решения о том, что им следует делать, а что – нет.

Если вы являетесь компанией, производящей один продукт, как Roku, это несложно, поскольку концепция вашей компании схожа или совпадает с концепцией продукта. Если вы являетесь крупной корпорацией, как Bank of America, это становится сложной задачей. Стратегия должна начинаться на корпоративном уровне, проходить через бизнес-направления и в конечном итоге доходить до продуктов. В таких компаниях продукты – это всего лишь детали того, как проявляется концепция компании. Это носители ценности – то, что вы продаете клиентам, получая взамен определенную ценность. Здесь концепция компании – это обертка, придающая смысл предложенным вами продуктам и услугам.

Сейчас вы, возможно, думаете: «В чем же разница между миссией и концепцией?» Хорошая миссия объясняет, зачем компания существует. Концепция, с другой стороны, объясняет, куда она направляется, исходя из этой цели. Я считаю, что лучшее, что может сделать организация, – это объединить миссию и концепцию в одной матировке. Таким образом компания представляет ценностное предложение – что она делает, почему и что от этого выигрывает. Вот несколько примеров:

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

– WARBY PARKER

«В Bank of America мы руководствуемся общей целью – помочь сделать финансовую жизнь лучше, объединяя клиентов и сообщества с ресурсами, необходимыми для достижения успеха».

– BANK OF AMERICA

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

– NETFLIX

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

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

Возьмем, к примеру, Netflix. Хотя компания и заявила, что хочет стать лучшей международной службой дистрибуции развлекательного контента, она сосредоточилась на том, как она планирует этого добиться – путем лицензирования, создания доступных рынков и помощи создателям контента. Это нормально – хотеть быть лучшим, но вам нужно указать, как именно.

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

У Marquetly была убедительная и четко сформулированная концепция: «Мы растим профессионалов цифрового маркетинга, предоставляя им доступ к качественному обучению по широкому спектру тем в увлекательной форме, направленной на максимальное усвоение материала за короткий промежуток времени».

Здесь объясняется, почему компания существует и ч�

Скачать книгу

* * *

Отзывы о книге

– Джефф Готелф, автор Lean UX и Sense & Respond

– Дэйв Прайк, Институт юридической практики

– Барри О’Рейли, основатель ExecCamp и автор Unlearn и Lean Enterprise

– Джефф Паттон, консультант по управлению продуктом и автор User Story mapping

– Дэйв Мастерс, директор по продукту в Realtor.com

– Джез Хамбл, автор и лектор по продакт-менеджменту в Калифорнийском университете в Беркли

– Адриан Ховард, консультант по продакт-менеджменту в Quietstars

– Джон Катлер, евангелист продукта в Amplitude

Введение

Суть заключается в том, что нельзя на постоянной основе придерживаться неизменных действий и при этом ожидать невероятного результата. Нам требовался новый подход, и здесь неминуемо возникал вопрос: где его найти? Хотя в поисках ответа мы и совершили множество ошибок, но зато мы определили главное: нам нужно больше знать о клиентах, о том, какие проблемы они пытаются решить в своем бизнесе, даже если они не вписываются в существующую категорию наших проблем.
– Майкл Делл[1]

Я хотела стать лучше. Я хотела создавать более качественный продукт.

Однако моя маленькая цель переросла в большое стремление.

Все они сослались на кучу системных проблем.

Весь процесс включает в себя четыре ключевых компонента:

• Создание должности продакт-менеджера с надлежащими обязанностями и структурой

• Создание стратегии, способствующей принятию правильных решений

• Поиск и развитие эффективного продукта путем экспериментов и оптимизации

Рисунок 1. Организация, нацеленная на продукт

Спасибо за внимание,

Мелисса Перри,

Генеральный директор Produx Labs

Благодарности

Спасибо моим родителям, Джоанне и Сальватору, и моей сестре Дженни. Вы – мое все.

Часть I
Ловушка разработки

Сотрудники отдела продаж тоже были расстроены и чувствовали себя загнанными в угол.

– Например? – полюбопытствовал он. – Что мы можем улучшить?

– Скажите мне, что сейчас для вас самое главное?

– Когда я спрашивала сотрудников, они дали другой ответ, – призналась я.

Крис выглядел слегка изумленным.

Я продолжила:

Крис выглядел подавленным, но был готов к диалогу.

– Так что мне делать? Компания должна развиваться, Мелисса. Что я могу сделать, чтобы все исправить?

Крис выглядел ошарашенным.

– Вы готовы к таким переменам? Это нелегко, но на 100 % возможно, – обещала я.

– Что ж, в том же духе нам нельзя продолжать, иначе мы выйдем из бизнеса, – признал он. – Да, я готов.

И вот тогда мы начали.

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

Глава 1
Система обмена ценностями

Схема 1.1. Обмен ценностями

Схема 1.2. Реализованный обмен ценностями

Схема 1.3. Система обмена ценностями

Глава 2
Ограничения системы обмена ценностями

Большинство компаний не осознают пагубного влияния этих факторов на ценность, и все потому, что они не измеряют результат своих действий. Они теряют связь со стратегией и попадают в ловушку.

Глава 3
Проекты и продукция, продукция и услуги

Продукт – это то, что нужно взращивать и доводить до зрелости. Это занимает много времени.

Глава 4
Организация, нацеленная на продукт

Компании, ориентированные на отдел продаж

Компании, ориентированные на концепцию

Компания, ориентированная на технологии

Компания, ориентированная на продукт

Глава 5
Известное и неизвестное

Схема 5.1. Известное и неизвестное

Продакт-менеджеры – это ключ к компании, ориентированной на продукт.

Часть II
Роль продакт-менеджера

Глава 6
Архетипы плохого менеджера

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

Мини-CEO

Тогда я отвела его в сторону и сказала:

Я заметила, что привлекла его внимание. Тогда я продолжила:

Ник сидел и вникал в происходящее.

– Я хочу добиться успеха. Скажите, что нужно сделать, чтобы стать лучше и создавать крутые продукты.

Официант

Схема 6.1. Цикл смерти продукта, автор Дэвид Дж. Блэнд

Бывший продакт-менеджер

Глава 7
Успешный продакт-менеджер

Технический эксперт и рыночный эксперт

Грамотный продакт-менеджер

Начните с «почему»

• Почему мы переходим на цифровое обслуживание в сфере ипотеки?

• Зачем вообще делать этот проект?

• Каков желаемый результат?

• Как выглядит успех?

• Что произойдет, если мы перейдем на цифровое обслуживание, но никто не будет брать кредит?

• Как мы можем снизить этот риск?

• Определение бэклогов и создание действенных пользовательских историй для команд разработчиков.

• Выявление и расставление приоритетов работы в бэклоге.

• Приемка завершенных пользовательских историй и проверка работы на соответствие критериям.

1 Майкл Сол Делл – американский предприниматель, основатель и руководитель компании Dell. – Прим. ред.

Скачать книгу

Product Management без ошибок. Гид по созданию, управлению и успешному запуску продукта бесплатное чтение

Мелисса Перри Product Management без ошибок Гид по созданию, управлению и успешному запуску продукта

* * *

* * *

Отзывы о книге

Введение

Благодарности

Часть I Ловушка разработки

Глава 1 Система обмена ценностями

Глава 2 Ограничения системы обмена ценностями

Глава 3 Проекты и продукция, продукция и услуги

Глава 4 Организация, нацеленная на продукт

Компании, ориентированные на отдел продаж

Компании, ориентированные на концепцию

Компания, ориентированная на технологии

Компания, ориентированная на продукт

Глава 5 Известное и неизвестное

Часть II Роль продакт-менеджера

Глава 6 Архетипы плохого менеджера

Мини-CEO

Официант

Бывший продакт-менеджер

Глава 7 Успешный продакт-менеджер

Технический эксперт и рыночный эксперт

Грамотный продакт-менеджер

Начните с «почему»

Одна роль, много обязанностей

Глава 8 Карьерный путь менеджера по продукту

Младший продакт-менеджер

Менеджер по продукту

Старший менеджер по продукту

Директор по продукту

Вице-президент по продукту

Главный директор по продукту (CPO)

Глава 9 Организация команды

Продуктовая команда компании Marquetly

Часть III Стратегия

Глава 10 Что такое стратегия

Глава 11 Стратегические пробелы

Пробелы в знаниях

Пробелы в согласовании

Пробелы в результатах

Автономные команды

Глава 12 Создание хорошей стратегии

Развертывание стратегии

Стратегическое развертывание

Создание стратегии

The Product Kata

Научный систематический путь создания эффективного продукта, разработанный Мелиссой Перри

Глава 13 Концепция на уровне компании и стратегические намерения

Концепция компании

Введение

Благодарности

Часть IЛовушка разработки

Глава 1Система обмена ценностями

Глава 2Ограничения системы обмена ценностями

Глава 3Проекты и продукция, продукция и услуги

Глава 4Организация, нацеленная на продукт

Глава 5Известное и неизвестное

Часть IIРоль продакт-менеджера

Глава 6Архетипы плохого менеджера

Глава 7Успешный продакт-менеджер

Мелисса Перри
Product Management без ошибок
Гид по созданию, управлению и успешному запуску продукта

Часть I
Ловушка разработки

Глава 1
Система обмена ценностями

Глава 2
Ограничения системы обмена ценностями

Глава 3
Проекты и продукция, продукция и услуги

Глава 4
Организация, нацеленная на продукт

Глава 5
Известное и неизвестное

Часть II
Роль продакт-менеджера

Глава 6
Архетипы плохого менеджера

Глава 7
Успешный продакт-менеджер

Глава 8
Карьерный путь менеджера по продукту

Глава 9
Организация команды

Часть III
Стратегия

Глава 10
Что такое стратегия

Глава 11
Стратегические пробелы

Глава 12
Создание хорошей стратегии

Глава 13
Концепция на уровне компании и стратегические намерения

Часть I
Ловушка разработки

Глава 1
Система обмена ценностями

Глава 2
Ограничения системы обмена ценностями

Глава 3
Проекты и продукция, продукция и услуги

Глава 4
Организация, нацеленная на продукт

Глава 5
Известное и неизвестное

Часть II
Роль продакт-менеджера

Глава 6
Архетипы плохого менеджера

Глава 7
Успешный продакт-менеджер