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

Product Management без ошибок

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

* * *

© О. Захватова, перевод

© ООО «Издательство АСТ»

© Melissa Perri 2019

* * *

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

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

– Джефф Готелф, автор 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 была убедительная и четко сформулированная концепция: «Мы растим профессионалов цифрового маркетинга, предоставляя им доступ к качественному обучению по широкому спектру тем в увлекательной форме, направленной на максимальное усвоение материала за короткий промежуток времени».

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

Стратегические намерения

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

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

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

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

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

Таблица 13.1. Метод мышления о ценности. Джошуа Арнольд

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

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

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

Таблица 13.1. Стратегические намерения компании Marquetly

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

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

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

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

Таблица 13.2. Стратегические намерения и продуктовая инициатива Marquetly

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

Глава 14

Концепция продукта и продуктовый портфель

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

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

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

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

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

Концепция продукта

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

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

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

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

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

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

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

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

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

Продуктовый портфель

Компании, имеющие более одного продукта, часто объединяют свои продукты в так называемый продуктовый портфель. Очень крупные компании имеют несколько портфелей, объединенных по типу ценности, которую они предоставляют клиентам. Например, у Adobe в качестве продуктового портфеля есть Adobe Creative Cloud, который состоит из приложений Photoshop, Illustrator, InDesign и других. У компании также есть другой продуктовый портфель для приложений нового поколения, состоящий из новых творческих инструментов, например, для быстрого создания прототипов.

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

• Все ли наши продукты работают как единая система и обеспечивают ценность для клиентов?

• Какую уникальную ценность предлагает каждая из продуктовых линеек? Что делает эту систему привлекательной?

• Какие общие ценности и принципы мы должны учитывать при принятии решений по новым продуктам?

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

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

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

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

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

Часть IV

Процесс управления продуктом

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

– Может быть, нам стоит предложить бесплатную версию аккаунта? Люди смогут попробовать его, прежде чем купить.

– Нет, я думаю, нам нужно предложить скидки. Так люди подпишутся на несколько месяцев.

– Дело в учителях. Если мы привлечем высококлассных педагогов, студенты сами подтянутся.

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

– Подождите! – вмешалась я. – Давайте сделаем шаг назад и разложим по полочкам то, что мы знаем. Наша цель – увеличить доход от индивидуальных пользователей. Я могу предложить три способа, основываясь на том, что мы знаем из метрик продукта. Что вы думаете?

Моника, менеджер по продукту, ответила:

– Найти новых пользователей. Это увеличит доход.

– Именно, – подтвердила я. – Что еще? Есть еще два варианта.

Криста, еще один менеджер, нерешительно произнесла:

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

– Бинго. Удержание людей увеличит ПЦК. Остался один.

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

Итак, это были три наших варианта:

• Привлечь больше индивидуальных пользователей.

• Лучше удерживать существующих пользователей.

• Создать новые потоки доходов для существующих пользователей.

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

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

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

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

– Это потрясающе! – обрадовалась Моника. – Давайте попробуем и посмотрим, что получится.

Команда разместила на своем сайте Qualaroo. В течение недели они собрали более сотни ответов.

– Удивительно, сколько всего мы узнали, – сказала Моника. – И никто не сказал, что они уходит из-за бесплатного периода!

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

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

Остальные 20 % ответов включали множество других вариантов, но ничего существенного.

– Я думаю, мы нашли две большие проблемы.

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

– Мы узнали, что через шесть месяцев с нами остаются только 40 % клиентов, – объясняла Криста. – Мы связались с сотней людей, которые недавно ушли, и спросили их о причинах. 90 % ответили, что закончился интересный для них контент. Они прослушали около десяти наших курсов, но не нашли новых методик. Это был старый стандартный материал, который они могли изучить где угодно – иногда бесплатно на YouTube.

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

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

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

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

Продуктовые инициативы Marquetly

ИНИЦИАТИВА 1

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

Варианты:

• более простые и быстрые способы создания курсов для преподавателей;

• обратная связь для преподавателей по интересующим студентов областям;

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

ИНИЦИАТИВА 2

Мы считаем, что, создав возможность для студентов подтвердить навыки перед потенциальными или нынешними работодателями, мы сможем увеличить число пользователей и повысить доходы на $1 500 000 в месяц.

Варианты:

• непрерывная оценка, позволяющая студентам постоянно проходить тесты для подтверждения своих навыков;

• сертификаты о прохождении обучения.

Команда представила эти идеи Джен на утверждение. Когда она дала добро, они разделились и начали исследования.

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

Глава 15

Product-Kata

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

The Product Kata

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

Таблица 15.1 Product Kata. Мелисса Перри

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

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

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

Контекст имеет значение

С тех пор как появилась концепция «Бережливого стартапа», исследования превратились в жаркую тему для многих компаний-разработчиков программного обеспечения. Я вижу, как команды с готовностью бросаются в эксперименты, стремясь запустить A/B-тест или создать прототип. Но прежде чем приступать к работе, важно сделать шаг назад и понять, что необходимо на данном этапе. Именно здесь помогает Product-Kata.

После того как мы поставили цель, мы обращаемся к Product Kata и задаем себе следующие вопросы:

1. Какова цель?

2. На каком этапе мы находимся по отношению к этой цели?

3. Какая самая большая проблема или препятствие стоит на пути?

4. Как я буду решать эту проблему?

5. Что произойдет (гипотеза)?

6. Что произошло на самом деле, и что мы узнали?

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

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

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

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

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

При таком подходе к управлению продуктом вся работа по проектированию и разработке направлена на достижение цели. Это не значит, что все, что вы попробуете, будет отправлено в продажу. И это правильно. Лучшее, что вы можете сделать на этом этапе, – это уничтожить плохие идеи! Чем меньше функций, тем лучше. Именно так можно уменьшить проблемы. В противном случае вы можете быстро столкнуться с усталостью клиентов от функций. Помните, речь идет о качестве, а не о количестве. Самое главное – сосредоточиться на Product Kata и определить, на какой фазе вы находитесь и какие инструменты у вас есть. В следующих нескольких главах мы поговорим о том, как пройти через каждую из этих фаз:

1. Понимание направления;

2. Исследование проблемы;

3. Поиск решения;

4. Оптимизация решения.

Глава 16

Понимание направления и определение показателей успеха

В компании Marquetly я работала с вице-президентами по продукту Карен и Джо. Мы выясняли, как количественно оценить инициативу по продукту, чтобы донести ее до Джен.

– Давайте обратимся к данным, которые уже имеются, – предложила я. – Каковы текущие показатели удержания и привлечения клиентов?

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

– В настоящее время мы удерживаем 40 % пользователей. Через шесть месяцев они уходят. Не самые лучше показатели.

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

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

– Ну, – начала Карен, – у нас есть две точки данных, из которых мы можем получить приблизительные данные. Мы оставили Qualaroo на сайте примерно на месяц и выяснили, что из всех ответивших людей около 55 % нуждались в разнообразии курсов. Также мы получили статистическую значимость этого числа, и вот что мы узнали: ежемесячно мы потенциально теряем 82 500 человек. Выгода от решения этой проблемы достаточно высока.

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

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

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

– Если мы увеличим коэффициент удержания с 40 до 70 %, мы будем получать доход в размере 90 000 долларов в месяц. Если мы удвоим коэффициент привлечения, то сможем получить еще чуть более 7 миллионов долларов в год. Таким образом, общая сумма составит чуть более 8 миллионов долларов, что позволит вплотную приблизиться к 30 %-ной цели роста доходов в соответствии с нашим стратегическим намерением.

Карен записала инициативу, чтобы представить ее Джен:

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

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

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

– Отлично! Дайте мне знать, когда появятся данные, – велела Джен. – Пока что все выглядит хорошо.

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

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

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

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

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

– Я могу создать открытый опрос с текстовым полем и спросить преподавателей, что мешает им взять второй курс, – предложил UX-дизайнер Мэтт.

– А я могу вытащить из системы время сессии. Так мы узнаем, когда люди начинают курс, а когда они его заканчивают. У нас есть хронометраж событий, – добавил Рич, ведущий разработчик.

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

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

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

– Да, я нашел похожую информацию в базах данных и записях событий, – сказал Рич. – В среднем учителю требуется 61 день с момента начала курса до его публикации. Более 75 % учителей, которые начинают курс, никогда его не публикуют. Я думаю, что некоторые из проблем, обнаруженные Крисом, как раз послужили причиной.

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

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

– Отлично.

У них действительно все получалось.

– Теперь нужно взять эти цифры за основу и собрать их вместе в отчете.

Команда собрала цифры, полученные из данных, и определила свой первоначальный вариант матировки:

«Мы полагаем, что, ускорив и упростив процесс создания курсов, мы сможем увеличить количество публикуемых курсов до 50 % и увеличить количество создаваемых вторых курсов до 30 %».

Карен ответила:

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

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

Метрика продукта

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

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

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

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

Существует множество методов, которые помогут вам продумать соответствующие цели продукта. Две мои любимые – Pirate Metrics и HEART.

Pirate Metrics

(пиратские метрики)

Пиратские метрики созданы Дейвом МакКлюром, основателем венчурного фонда 500 Startups, чтобы рассказать о жизненном цикле пользователей через ваш продукт. Представьте это в виде воронки (сх. 16.1): пользователи находят ваш продукт – это приобретение (acquisition); пользователи получают отличный первый опыт – это активация (activation); пользователи возвращаются к вашему продукту – это удержание (retention); пользователи рекомендуют другим, потому что им нравится ваш продукт, – это привлечение (referral); и, наконец, пользователи платят за ваш продукт, потому что видят в нем ценность, – это доход (revenue). Сложите все вместе, и у вас получится пиратская метрика AARRR.

Схема 16.1. Пиратская метрика. Дэйв МакКлюр

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

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

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

Хотя пиратские метрики и обрели популярность, некоторые люди увидели недостаток: там не говорилось об удовлетворенности пользователей. Учитывая этот промах, Керри Родден, сотрудник компании Googler, создал метрику HEART.

Метрики HEART

Метрики HEART измеряют счастье, вовлеченность, принятие, удержание и успешность выполнения задач. Обычно они используются, когда речь идет о конкретном продукте или функции. Здесь принятие аналогично активации в Pirate Metrics, потому что вы говорите о том, что кто-то использует продукт впервые. Удержание – то же самое, что и в Pirate Metrics. В HEART вы добавляете другие метрики, чтобы рассказать, как пользователь взаимодействует с продуктом. Счастье – это показатель, насколько пользователь удовлетворен продуктом. Вовлеченность – показатель того, как часто пользователи взаимодействуют с продуктом. Успешность задачи измеряет, насколько легко пользователю выполнить задуманное с помощью продукта.

Чтобы узнать больше о метриках HEART, вы можете обратиться к статье Роддена «Как выбрать правильные UX-метрики для вашего продукта».

Определение направления с помощью данных

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

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

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

Обычно показатели успеха, которые мы устанавливаем вокруг вариантов, являются опережающими показателями результатов, которые мы ожидаем от наших инициатив, потому что варианты – это стратегии, рассчитанные на более короткий период времени, о чем мы говорили в предыдущей главе. Метрики успеха должны быть соизмеримы с продолжительностью ставки. Измерение показателей на уровне вариантов помогает избежать неожиданностей, когда на уровне инициатив появляются холодные, жесткие факты. Чтобы убедиться, что у вас достаточно данных для действий, важно внедрить инструменты, облегчающие измерение этих показателей. Это одна из первых вещей, которую должна сделать каждая компания, – внедрить платформу для измерения показателей. Amplitude, Pendo.io, Mixpanel, Intercom и Google Analytics – все это платформы данных. Некоторые из них, такие как Intercom и Pendo.io, также обеспечивают хорошую обратную связь с клиентами, поскольку предоставляют инструменты, позволяющие связаться с пользователями и задать им вопросы. Внедрение платформы метрик, будь то собственная или сторонняя, очень важно для компании, управляющей продуктом, поскольку позволяет менеджерам принимать обоснованные решения.

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

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

Глава 17

Исследование проблемы

Криста вела свою команду через Product Kata, чтобы начать работу над изучением варианта.

– Какова цель нашего варианта? – спросила она Мэтта и Рича.

– Увеличить количество опубликованных курсов до 50 % и увеличить количество вторых курсов, созданных преподавателями, до 30 %, – ответили они.

– На каком этапе мы сейчас находимся?

– Мы все еще в самом начале: процент публикаций курсов, которые были начаты, составляет всего 25 %. Довольно плачевно. Количество вторых курсов составляет всего 10 %.

Все были немного шокированы, получив данные, и это чувство осталось с нами надолго.

– В чем заключается проблема?

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

– Какой шаг мы можем предпринять, чтобы лучше понять?

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

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

– Конечно, я смогу прийти на половину из них. Я освобожу расписание.

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

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

Мэтт был новичком в компании и пришел всего за месяц до этого.

– Так и было, потому что мне пришлось его разрабатывать, – вздохнул Рич. – А я и есть разработчик. Шесть месяцев назад у нас не было UX-дизайнеров!

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

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

– Я знаю. Но способа у них нет. Что ж, – сказал Мэтт, – давайте запишем проблемы и наметим карту наших действий.

– Да. У меня есть несколько интересных замечаний. Вот формулировки, которые я получила во время опроса, – вызвалась Криста и показала команде свой список:

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

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

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

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

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

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

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

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

Они записали гипотезу:

«Мы считаем, что если учителя получат возможность быстрее загружать необходимый контент в систему, мы увеличим количество публикуемых курсов до 50 %, а количество вторых курсов поднимется до 30 %».

Понимание проблемы

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

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

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

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

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

Я: «Какую проблему вы решаете?»

Компания: «У пользователей нет дашборда».

Я: «И… каково ваше решение?»

Компания: «Дашборд».

Когда я спрашиваю, зачем пользователям дашборд, я получаю следующие ответы:

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

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

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

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

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

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

Пользователям не нужно приложение

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

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

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

Тогда мы провели эксперимент. Мы опросили женщин и предложили им идею такого приложения. Реакция была не самой хорошей.

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

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

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

Разрушение барьеров и творческий подход

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

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

Даже если у вас есть доступ к нужным вам людям, исследование клиентов не лишено подводных камней. Это может быть непросто, потому что, как вы уже могли убедиться, люди часто начинают рассказывать вам готовое решение. «О, мне нужна кнопка, которая позволит сделать Х», – говорят они. Как менеджер по продукту, вы должны отступить назад и спросить: «Хорошо, но зачем? Зачем вам кнопка? Почему вы считаете, что кнопка – это то, что нужно? Чего вы пытаетесь достичь?» Именно понимание потребности пользователя, а не кнопки поможет вам приблизиться к пониманию корня проблемы.

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

Валидация проблемы

В Marquetly Криста и ее команда получили урок.

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

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

Криста задумалась на мгновение.

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

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

– Давайте вернемся к Kata, – предложила я. – Что вы узнали на последнем этапе?

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

– Отлично. Каково ваше текущее состояние?

– По отношению к цели мы все еще топчемся на одном месте.

– Ладно, тогда какое самое большое препятствие стоит на пути к ее достижению? Чему вам нужно научиться дальше?

Помолчав минуту, Криста ответила:

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

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

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

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

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

– Недели через две. Давайте тогда приступать.

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

Команда попросила учителей прислать им все, что у них имелось по курсу, в любом удобном для них формате. Материал приходил во всех формах: ссылки на Dropbox, Google Docs, электронные таблицы с учебными планами и ссылки на YouTube. Самым удивительным было то, в каком формате приходили видео. Учителя присылали их без редактирования, но с инструкциями. Аудиофайлы приходили отдельно.

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

Рич тоже пребывал в недоумении.

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

Учитывая, что Мэтт проводил много времени с пользователями, он вроде как понимал, что происходило.

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

Члены команды уставились друг на друга.

– Нужно понаблюдать. Давайте поглубже вникнем в проблему.

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

– Вот дела, – обронил Рич. – Мы упустили истинную проблему. Да, над выгрузкой когда-то придется поработать, но сейчас не в ней дело. Сложность заключается в создании видеоматериала.

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

– Похоже, мы наконец-то нашли проблему, – объявил Рич.

Глава 18

Исследование решений

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

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

Я очень гордилась ими.

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

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

Команда приступала к методу Kata.

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

– Отлично. И как вы это сделаете?

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

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

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

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

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

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

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

Команда вернулась к работе и приступила к выявлению решений, необходимых для учителей:

• руководство по успешному созданию видео;

• возможность объединить видео со слайдами, изображениями, аудио и видео с YouTube;

• возможность показывать текст поверх видео;

• вступительный слайд.

Они также подумали о том, какой тип опыта или факторы приведут к успеху:

• контроль над готовым продуктом;

• простота предоставления информации редакторам;

• человеческий язык в отношении того, что необходимо, а не технические слова.

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

Эксперименты и новые знания

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

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

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

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

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

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

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

Существует множество способов экспериментов. Concierge («Консьерж»), Wizard of Oz («Волшебник страны Оз»), тестирование концепции – вот три примера экспериментов, о каждом из которых я расскажу вкратце.

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

Консьерж

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

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

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

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

Волшебник страны Оз

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

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

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

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

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

Я позвонила некоторым из них, чтобы выяснить это. У всех была одна общая проблема. Они говорили: «Я хочу контролировать покупки. Я подписан на слишком большое количество товаров. Я бы предпочел делать заказ самостоятельно». Зная это, мы попробовали применить другой подход. В итоге мы каждый месяц отправляли простое электронное письмо тем людям, которые покупали продукты с предложением перезаказа. Продажи резко возросли! А поскольку мы сначала экспериментировали, то в итоге сэкономили более 100 000 долларов на разработке.

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

«Волшебник страны Оз» также можно сочетать с такими техниками, как A/B-тестирование. При A/B-тестировании вы распределяете часть трафика на новую идею решения, чтобы посмотреть, насколько она изменит показатели по сравнению с текущим состоянием сайта. Вы можете использовать этот метод и за пределами «Волшебника», чтобы протестировать новый дизайн или сообщения на вашем сайте.

Но в использовании A/B нужно быть осторожным. Его не стоит применять, если: 1) вы все еще не уверены в направлении решения; 2) у вас недостаточно трафика, чтобы результаты имели статистическую значимость. В последнем случае для получения обратной связи можно использовать такие методы, как концепт-тестирование.

Концепт-тестирование

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

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

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

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

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

Когда не нужно проводить тщательные эксперименты

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

Например, я работала с одной командой, которая экспериментировала над тем, как уменьшить количество звонков в техподдержку. Команда обнаружила проблему – на экране пропала необходимая кнопка. Будучи отличниками в методологии, они хотели провести A/B-тест, отобразив кнопку для половины участников и измерив изменения. Я сказала команде, что это неправильный подход. В данном случае команда знала проблему и решение. Пришло время его реализовать. Здесь не было необходимости в предварительном тестировании, хотя они все равно должны были измерить, уменьшилось ли количество звонков после внедрения.

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

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

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

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

Экспериментирование в сложных отраслях

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

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

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

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

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

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

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

Они установили на телефон (Android) программное обеспечение, которое должно было работать на очках, и использовали камеру в качестве объектива. Для имитации положения и высоты инженеры использовали 3D-принтер. В эти очки вставлялся телефон, а затем все это устройство надевалось на голову. Теперь они могли предоставить «очки» своим пользователям для тестирования в течение дня.

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

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

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

Экспериментирование с внутренними продуктами

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

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

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

И он был прав. Я не решала проблемы пользователей. На самом деле я только усложняла их работу.

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

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

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

Выбор правильного решения в Marquetly

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

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

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

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

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

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

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

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

Через три недели команда начала замечать, что курсы размещаются. К концу месяца уже 30 из 40 преподавателей опубликовали свои курсы. Это был не такой высокий показатель, как в эксперименте с «консьержем», но он был гораздо выше, чем 25-процентный показатель без ПО. Эксперимент был признан успешным, и Карен смогла использовать данные, полученные с помощью Kata (как показано в таблице 18.1), и представить их команде высшего руководства.

Таблица 18.1. Product-Kata для команды Marquetly

Глава 19

Построение и оптимизация решения

– Как вы знаете, одна из наших стратегических целей – удвоить рост доходов от индивидуальных пользователей за два года, – сказала Карен руководству компании Marquetly. – Мы считаем, что, увеличив объем контента на нашем сайте в ключевых областях, представляющих интерес, мы сможем удвоить количество пользователей и повысить уровень удержания существующих пользователей до 70 %. В результате потенциальный рост доходов от индивидуальных пользователей составит 8 миллионов долларов в год. Команда Кристы обнаружила проблему. Только 25 % учителей, начавших курс, на самом деле опубликовали его на сайте и только 10 % учителей публикуют второй курс.

– Что?! Это безумие. Я понятия не имел! Что за цифры! Это ужасно, – воскликнул Крис, генеральный директор.

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

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

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

– Каковы риски? – спросил финансовый директор.

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

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

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

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

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

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

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

– Да, и я подсчитал критерии успеха. Вот что у меня получилось:

• 75 % наших преподавателей приняли программу в течение одного месяца;

• доля опубликованных курсов увеличивается с 25 % до 60 %;

• время на создание нового курса уменьшается с трех месяцев до менее чем одного.

– Рич, мы сможем измерить показатели для первого релиза? – спросила Криста.

– Конечно. Мы выполним настройки, чтобы отслеживать показатели.

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

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

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

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

– Уровень внедрения не совсем тот, который нам нужен, – сказала она команде. – В первый месяц только 60 % учителей начали работу с ПО. Те же, кто принял ее, превзошли предыдущий показатель публикаций: процент поднялся до 75. Нам нужно выяснить, что им мешает. Давайте обратимся к тем, кто не стал пользоваться программой, и выясним причину.

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

– Я довольна, что ты все еще диагностируешь проблемы, применяя Kata.

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

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

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

Развитие концепции продукта

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

После определения направления важно убедиться, что все понимают контекст и работу, которую необходимо выполнить. Story mapping и документы «Северная звезда» – вот два способа помочь командам достичь согласованности.

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

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

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

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

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

Расстановка приоритетов

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

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

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

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

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

Возможно, вы думаете: «Но как мне рассчитать доход от каждого из моих продуктов?» Озлем Юче и Джошуа Дж. Арнольд – эксперты в области «Стоимости задержки», и они создали качественный способ ее оценки, как показано на схеме 19.1.

Схема 19.1. Качественная стоимость задержки. Джошуа Арнольд и Озлем Юче

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

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

«Стоимость задержки» может помочь положить конец спорам о том, что должно и не должно быть приоритетным. Если вы хотите узнать больше, посетите сайт Black Swan Farming и прочитайте о том, как использовать эту концепцию в вашей компании.

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

Реальное определение готовности

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

Мы заканчиваем разработку или итерации над функцией только тогда, когда она достигла своих целей. Часто команды выпускают первую версию функции, а затем переходят к следующей, не оценивая результаты для пользователей. Как однажды сказал Джефф Готелф, автор книги «Sense & Respond»: «Версия 2 – это самая большая ложь в разработке программного обеспечения». Такой менталитет всегда ведет к ловушке разработки.

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

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

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

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

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

Часть V

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

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

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

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

За несколько месяцев до старта проекта, 9 января 2007 года, Стив Джобс анонсировал первый iPhone. Несмотря на то что все сходили с ума от возможности пользоваться Интернетом в телефоне, компания Kodak была нацелена на Интернет и камеры на одном устройстве. Это была опасная комбинация для бизнеса, поскольку признаки уже указывали на срыв. Несколькими годами ранее цифровые фотоаппараты были еще в новинку. Их можно было носить с собой, чтобы запечатлеть любое собрание или махинацию. Однако с выходом iPhone мы начали оставлять громоздкие цифровые камеры дома и использовать телефоны в качестве фотоаппаратов. Это было удобнее, и телефоны могли сразу же загружать изображения на Facebook. Рынок цифровых и пленочных фотоаппаратов – основных направлений деятельности компании Kodak – сокращался.

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

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

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

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

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

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

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

Что ж, теперь наша идея превратилась в реальность. Вы можете быстро и легко редактировать фотографии, прежде чем поделиться ими в Сети. Камеры мобильных телефонов настолько высокотехнологичны, что никто больше не пользуется цифровыми камерами. Вы можете ставить геотеги на снимки, и у вас есть контроль над тем, кто какие посты видит. Однако не компания Kodak создала эти функции. Это были Instagram, Apple, Android и Facebook. Что же произошло после этой встречи?

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

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

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

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

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

Глава 20

Коммуникации, нацеленные на результат

На очередном ежеквартальном бизнес-обзоре Карен рассказала о достижениях команды: – В этом квартале нам удалось запустить программное обеспечение для редактирования видео и добавить на сайт 150 новых курсов в ключевых областях, интересующих наших пользователей. С момента запуска мы наблюдаем увеличение коэффициента приобретения с 15 до 25 %, а число пользователей, остающихся на сайте, выросло до 60 %. Мы находимся на пути к достижению поставленных целей. Благодаря дополнительным усилиям других команд по реализации этого стратегического замысла мы достигнем цели раньше – в течение полутора лет.

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

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

– Это потрясающе! – сказал он мне, когда мы встретились после ежеквартального совещания. – Я не знал, чего ожидать, но я определенно вижу прогресс. Раньше нам было трудно, и я знаю, что у нас еще есть недочеты, которые нужно устранить, но я вижу, почему такой способ работы имеет смысл.

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

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

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

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

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

Каденции и коммуникация

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

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

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

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

• ежеквартальные бизнес-обзоры;

• обзоры продуктовых инициатив;

• обзоры релизов.

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

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

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

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

План и отдел продаж

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

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

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

Одним из замечательных ресурсов для определения того, как составить план, является книга К. Тодда Ломбардо и Брюса МакКарти «Карта продукта: перезапуск». Это глубокое практическое руководство по созданию отличных планов для вашей компании. Обычно они состоят из нескольких ключевых частей:

• тема;

• гипотеза;

• цели и метрики успеха;

• этап разработки;

• любые важные вехи.

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

Эксперимент

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

Альфа

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

Бета

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

Фаза общедоступности (Generally Available (GA))

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

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

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

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

Операционный отдел

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

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

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

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

• создание автоматизированных и упорядоченных способов сбора данных о прогрессе и командных результатах;

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

• создание и поддержка платформы аналитики продукта для отчетности по показателям вовлеченности продукта в рамках всей организации;

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

• организация и проведение важных совещаний с целью создания стратегии, развертывания стратегии и релизов;

• проведение тренингов для продуктовых команд.

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

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

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

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

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

Глава 21

Вознаграждения и стимулирование

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

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

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

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

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

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

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

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

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

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

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

Глава 22

Безопасность и обучение

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

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

Это не значит, что мы должны терпеть неудачи. Хотя с появлением Lean Startup мы начали фокусироваться на результатах, мы также стали радоваться неудачам. Я хочу внести ясность: неудача – это не успех, если вы ничему не научились. Обучение должно лежать в основе каждой организации, ориентированной на продукт. Оно должно быть тем, что движет нами как организацией.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Глава 23

Бюджет

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

Он объяснил мне:

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

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

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

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

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

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

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

Глава 24

Клиентоориентированность

Правильные коммуникации, вознаграждения, стимулирование, бюджетирование, политика и безопасность – все это важно в организации. Но для того, чтобы вы действительно были ориентированы на продукт, необходимо еще кое-что. В дополнение к культуре, которая поощряет и стимулирует обучение, вам нужна культура, ориентированная на клиента. Сегодня многие ведущие компании, такие как Amazon, Netflix, Zappos, Dollar Shave Club и Disney, достигли своего положения благодаря ориентации на клиента. Это отношение проявляется в том, как руководители говорят о клиентах и обращаются с ними.

Одна из самых известных цитат Джеффа Безоса о том, как Amazon добивается успеха, звучит так: «Самое главное – это навязчивая ориентация на клиента. Наша цель – стать самой клиентоориентированной компанией на Земле». Такой подход действительно определяет все, что делает Amazon, и это приносит свои плоды. Компания увеличила число участников программы Prime с 25 миллионов в 2012 году до более чем 100 миллионов в 2018 году за счет того, что людям стало проще делать покупки и находить все, что им нужно, с бесплатной двухдневной доставкой и доступом к множеству развлечений.

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

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

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

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

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

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

Глава 25

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

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

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

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

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

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

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

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

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

Заключение

Как избежать ловушки и стать компанией, ориентированной на продукт

Меня недавно спросили: «Чему самому важному вы научились за время своей карьеры?»

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

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

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

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

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

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

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

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

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

Приложение

Шесть вопросов, которые помогут понять, ориентирована ли ваша компания на продукт

Кто придумал последнюю функцию или идею продукта, который вы создали?

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

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

Какой последний продукт вы уничтожили?

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

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

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

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

Когда вы в последний раз разговаривали со своими клиентами?

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

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

Какова ваша цель?

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

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

Над чем вы работаете в настоящее время?

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

Какие ваши менеджеры?

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

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

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

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

Об авторе

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

Примечания

1

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

Content

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Глава 14 Концепция продукта и продуктовый портфель

Часть IV Процесс управления продуктом

Глава 15 Product-Kata

Глава 16 Понимание направления и определение показателей успеха

Глава 17 Исследование проблемы

Глава 18 Исследование решений

Глава 19 Построение и оптимизация решения

Часть V Организация, ориентированная на продукт

Глава 20 Коммуникации, нацеленные на результат

Глава 21 Вознаграждения и стимулирование

Глава 22 Безопасность и обучение

Глава 23 Бюджет

Глава 24 Клиентоориентированность

Глава 25 Marquetly: компания, ориентированная на продукт

Заключение Как избежать ловушки и стать компанией, ориентированной на продукт

Приложение Шесть вопросов, которые помогут понять, ориентирована ли ваша компания на продукт

Об авторе

Примечания