Read the book: «Вдохновленные. Все, что нужно знать продакт-менеджеру»

Глава 6. Фундаментальные причины неудач в работе над продуктом

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

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

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

Рис. 6.1. Основные этапы создания продукта

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

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

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

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

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

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

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

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

Хорошо, пусть большинство команд работают так, но почему это обязательно становится причиной стольких проблем? Давайте-ка расставим все точки над «и» прямо сейчас, чтобы ясно понять, почему этот распространенный повсеместно метод приводит к неудачам при создании софта.

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

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

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

Мы не можем знать, сколько денег заработаем, потому что это всецело зависит от того, насколько правильным и удачным будет наше решение. Если команда проделает отличную работу, она может оказаться невероятно успешной и изменит весь дальнейший ход деятельности компании. Но, к сожалению, многие замыслы продуктов в конечном счете не приносят компании ровным счетом ничего. И это вовсе не преувеличение! Буквально ничего (это определяется в результате A/B-тестирования).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Глава 7. Lean и Agile и не только

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

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

Но, как я уже сказал, их тоже нельзя считать волшебными средствами, и, как и в случае с любым инструментом, нужно подходить к их использованию с умом. Множество команд утверждают, что придерживаются принципов Lean, а сами месяцами работают над тем, что называют «минимально жизнеспособным продуктом» (minimum viable product, MVP). На самом деле они не знают, что у них получилось и будет ли это продаваться, до тех пор, пока не потратят массу времени и денег. Вряд ли такая стратегия в духе Lean. Или же они бросаются в другую крайность: считают, что должны тестировать и перепроверять каждую мелочь, и, соответственно, не слишком быстро продвигаются вперед.

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

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

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

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

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

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

Глава 8. Ключевые идеи

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

ПРОДУКТ В ЦЕЛОМ

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

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

Если вы разрабатываете сайты для e-commerce, то ваш продукт включает в себя опыт выполнения и возврата заказа. В общем продукт такой компании представляет собой все, кроме реального, фактического товара, который продается. Аналогично продуктом медиакомпании будет все, кроме предлагаемого потребителям контента.

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

НЕПРЕРЫВНОЕ ИССЛЕДОВАНИЕ И ВЫВЕДЕНИЕ ПРОДУКТА НА РЫНОК

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

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

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

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

Рис. 8.1. Непрерывный процесс исследования продукта и его поставки на рынок

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

ИССЛЕДОВАНИЕ ПРОДУКТА

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

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

1. Будет ли пользователь это покупать (или использовать)?

2. Сможет ли он понять, как это использовать?

3. Смогут ли инженеры это построить?

4. Станут ли заинтересованные стороны это поддерживать?

ПРОТОТИПИРОВАНИЕ

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

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

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

ПОСТАВКА ПРОДУКТА НА РЫНОК

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

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

СООТВЕТСТВИЕ ПРОДУКТА ОЖИДАНИЯМ РЫНКА

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

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

ВИДЕНИЕ ПРОДУКТА

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

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

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

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

Минимально жизнеспособный продукт

Минимально жизнеспособный продукт (minimum viable product, MVP)⁴ – одна из самых важных концепций в нашей отрасли, предложенная много лет назад. Термин придумал Фрэнк Робинсон (в 2001 году), а я писал об этой концепции в первом издании книги (в 2008 году). Но заслуга ее популяризации принадлежит Эрику Рису, в частности его работе The Lean Startup⁵ (2011 года).

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

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

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

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

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

Часть II. Правильные люди

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

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

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

Продуктовые команды

ОБЗОР

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

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

Глава 9. Принципы сильных продуктовых команд

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

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

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

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

КОМАНДА «МИССИОНЕРОВ»

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

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

СОСТАВ КОМАНДЫ

Типичная продуктовая команда состоит из продакт-менеджера, продуктового дизайнера и от двух до 10–12 инженеров-программистов.

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

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

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

ПОЛНОМОЧИЯ И ОТВЕТСТВЕННОСТЬ В КОМАНДЕ

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

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

РАЗМЕР КОМАНДЫ

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

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

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

ПОДОТЧЕТНОСТЬ В ПРОДУКТОВОЙ КОМАНДЕ

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

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

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

СОТРУДНИЧЕСТВО В КОМАНДЕ

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

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

РАСПОЛОЖЕНИЕ КОМАНДЫ

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

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

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

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

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

ЗАДАЧИ И КОМПЕТЕНЦИИ КОМАНДЫ

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

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

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

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

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

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

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

ВРЕМЯ РАБОТЫ КОМАНДЫ

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

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

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

САМОСТОЯТЕЛЬНОСТЬ КОМАНДЫ

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

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

ПОЧЕМУ ЭТО РАБОТАЕТ

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

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

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

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

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

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

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

Принципы и методики

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

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

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

Глава 10. Менеджер продукта

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

Менеджер продукта может выбрать один из трех подходов к работе, но, по моему глубокому убеждению, только один из них ведет к успеху:

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

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

3. Он может сам выполнять свою работу.

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

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

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

И такой вопрос – явный признак того, что вы и слыхом не слыхивали о по-настоящему эффективном управлении продуктом.

КРУГ ОБЯЗАННОСТЕЙ

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

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

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

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

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

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

ДОСКОНАЛЬНОЕ ЗНАНИЕ ПОТРЕБИТЕЛЯ

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

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

ГЛУБОКОЕ ПОГРУЖЕНИЕ В ДАННЫЕ

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

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

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

ДОСКОНАЛЬНОЕ ЗНАНИЕ БИЗНЕСА

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

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

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

ДОСКОНАЛЬНОЕ ЗНАНИЕ РЫНКА И ОТРАСЛИ

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

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

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

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

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

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

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

УМНЫЙ, КРЕАТИВНЫЙ И НАСТОЙЧИВЫЙ

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

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

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

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

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

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

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

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

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

• Станьте бесспорным экспертом по своему продукту и отрасли и делитесь этими знаниями открыто и щедро.

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

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

ЗНАКОМЬТЕСЬ С ЛУЧШИМИ ПРОДАКТ-МЕНЕДЖЕРАМИ

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

• Джейн Мэннинг из Google.

• Лиа Хикман из Adobe.

• Алекс Прессланд из BBC.

• Мартина Лаученгко из Microsoft.

• Кейт Арнольд из Netflix.

• Камилла Херст из Apple.

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

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

Вот главные уроки, которые вы, я надеюсь, из этого вынесете:

1. У управления продуктом мало общего с другими направлениями деятельности компании. Эта сфера сильно отличается от дизайнерской работы и явно не то же самое, что менеджмент проектов. Безусловно, некоторые элементы управления проектами просматриваются и тут, как на любой руководящей должности. Но ставить знак равенства между управлением продуктом и управлением проектом значит исказить суть роли менеджера продукта. Я сравнивал бы эту роль скорее с постом СЕО, правда, с одной существенной оговоркой: в отличие от главы компании у менеджера продукта нет подчиненных.

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

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

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

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

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

Во-первых, термин «владелец продукта» пришел к нам из Аgile; так в команде называют человека, ответственного за бэклог. Имейте в виду, что agile-методы используются в любых компаниях, а не только в тех, которые занимаются разработкой программного обеспечения.

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

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

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

Два важнейших учебных курса для продакт-менеджеров

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

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

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

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

2. Введение в бизнес-учет/финансы. Помимо языков программирования, стоит изучить язык бизнеса. Если вы никогда не изучали основ бизнес-финансирования, непременно сделайте это.

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

Глава 11. Дизайнер продукта

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

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

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

ИССЛЕДОВАНИЕ ПРОДУКТА

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

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

КОМПЛЕКСНЫЙ ОПЫТ ВЗАИМОДЕЙСТВИЯ

Понятие пользовательский опыт (user experience, UX) намного шире понятия пользовательский интерфейс (user interface, UI). Некоторые люди, чтобы подчеркнуть эту мысль, даже используют термин клиентский опыт. UX распространяется на все способы, которым пользователи реализуют ценность вашего продукта, в том числе любые взаимодействия потребителя с вашей компанией и продуктом длительное время. В случае с современными продуктами все это обычно включает в себя несколько различных интерфейсов, а также точки контакта с потребителями: электронная почта, маркетинговые кампании, продажи, поддержка клиентов и другие. В некоторых продуктах UX также включает офлайн-сервисы, такие как поездки на автомобиле, вызванном через службу Uber, или место для ночлега, найденное через сервис Airbnb.

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

• Как потребители узнают о продукте?

• Как мы будем знакомить нового пользователя с продуктом и (возможно, постепенно) раскрывать ему его новые функциональные характеристики?

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

• Что еще конкурирует за внимание пользователя?

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

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

• Как мы будем радовать пользователя?

• Как пользователь будет делиться своим опытом с другими людьми?

• Как потребители будут получать офлайн-услуги?

• Как продукт реагирует на действия пользователя?

ПРОТОТИПИРОВАНИЕ

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

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

ТЕСТИРОВАНИЕ КЛИЕНТСКОГО ОПЫТА

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

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

ДИЗАЙН ВЗАИМОДЕЙСТВИЯ И ГРАФИЧЕСКИЙ ДИЗАЙН

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

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

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

КОГДА ДИЗАЙН ПРОДУКТА ОТСУТСТВУЕТ

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

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

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

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

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

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

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

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

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

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

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

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

1. Сделайте все от вас зависящее, чтобы дизайнер сидел рядом с вами.

2. Включайте дизайнера в дело с самого начала разработки идеи.

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

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

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

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

Глава 12. Инженеры-программисты

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

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

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

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

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

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

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

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

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

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

Роль технического руководителя

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

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

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

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

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

Глава 13. Продуктовый маркетолог

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

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

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

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

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

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

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

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

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