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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

– Вы готовы к таким переменам? Это нелегко, но на 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.