Введение в продуктовый менеджмент

Что такое продукт?

Вступление

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

Короче, как корабль назовешь, так он и поплывет.

Математика терминов

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

Есть несколько способов давать определения:

  • Определение (вывод) посредством уже определенных терминов.
  • Определение через перечень значений.
  • Определение через свойства.
  • Определение как аксиома.

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

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

Игра в угадайку. Часть 1.

Попытаемся дать определение «продукт», смотря на примеры уже существующих продуктов и пытаясь выделить в них какие-то свойства, присущие им всем.

Система управления задачами Jira

Давайте посмотрим на Jira. Мало у кого возникнут сомнения, что она является продуктом. Практически все it-шники сидят в ней. Поставляется как SaaS, а может и развертыванием на вашей инфраструктуре. Монетизируется за счет периодической подписки или разовой покупке лицензии. Решает проблемы компаний и их сотрудников. ИМЕЕТ ИНТЕРФЕЙС (раз есть, значит точно про продукт, да, ребята?). Посмотрим на другой пример.

Карандаш

Многие могут сказать, что это не продукт, а товар. Окей, давайте откроем Википедию и посмотрим определение товара:

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

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

Продукты [питания]
Ну, тут у них даже слово «продукты» подходит. Да и вообще фраза «продуктовая корзина» звучит так же круто, как и «продуктовый портфель». Вот я, когда произношу её, сразу чувствую себя не ниже CPO или Product VP. Так или иначе, ими тоже пользуются для того, чтобы закрывать свои потребности (еда, белок, деликатесы). Они тоже стоят денег (и постоянно дорожают). А еще они заканчиваются (впрочем, как и карандаш и лицензия на Jira).

Прямоугольник

Ну, это вряд ли может быть продуктом. Это же прямоугольник. Хотя, в принципе, я могу продавать прямоугольники. Но решает ли он какую-то проблему клиентов? Я смог выдумать только банальное «нарисовать стену домика». Типа такого:

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

Тезис 1. Продукт должен решать проблему.

Игра в угадайку. Часть 2.

Стрижка в барбершопе

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

Услуги — предпринимательская деятельность, направленная на удовлетворение потребностей других лиц.

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

Партия еды

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

Тезис 2. Продукт может быть товаром, услугой или их целостной совокупностью (комплексом).

Игра в угадайку. Часть 3.

Все детские примеры отбросим. Возьмемся за настоящий хардкор.

Водопой

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

Википедия

Сложно отрицать, что Википедия это продукт. Но вы за неё не платите. Даже косвенно через просмотр рекламы. Деньги она получает от меценатов на безвозмездной основе. Она решает проблему знаний. Почти все — её пользователи. У неё есть команда, которая этот «социальный» продукт создаёт и поставляет пользователям.

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

Тезис 3. Продукт существует только в контексте передачи от одного участника отношений другому участнику.

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

Здесь та же фигня. Вспомните Amazon и их инфраструктуру. Когда-то их серверы были только ресурсами для ecommerce, а потом они превратили это в продукт и стали продавать другим. Именно в понимании третьего тезиса кроется путь в голубые океаны.

Примеры продуктов по свойствам

Комбинации примеров продуктов по наличию свойств

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

Также, занятно, что сразу видно, где лежат стартапы и почему, все-таки, у них не получается. Подавляющее большинство из них (14 строка) так и не находят проблему клиентов (или сегмент под выдуманную ими проблему), хотя даже делают MVP. Меньшая часть (6 строка), хоть и не решают проблему, но каким-то образом успевают продаться перед закрытием (ах, эти ICO!!!). Хотя более вероятен, что стартап даже до первых пользователей не дорастает (15 строка). Правда, бывают и такие, как водопой (11 строка): и уже MVP сделано, и проблема протестирована, а до продажи и передачи дело почему-то не дошло.

Многие могут возразить, в чём же все-таки отличие продукта от товаров и услуг, которые также продаются и/или передаются. Так вот, самое главное отличие продукта от товаров или услуг — в первом тезисе. Именно решение проблемы наделяет обычный товар магией продукта. Хотя подавляющее большинство товаров и услуг решают проблемы, но в продукте фокус делается именно на решении, а не товарно-денежных отношениях. У меня есть пример.

Во время работы в компании LiveTex у нас был период, когда каждый из продактов управлял «продуктами», которые на самом деле ими не являлись. Мы называли продуктами личный кабинет клиента, приложение для работы оператора, само окошко чатика на сайте клиента, мобильные приложения, часть функционала (например, виртуальный ассистент). Но ни одно из них не решало проблему клиента по отдельности. По отдельности чатик не решал проблему коммуникации без приложения оператора. В личном кабинете вообще были только настройки и статистика с историей по коммуникациям, что тоже не способствовало решению проблем, т.к. без самих обращений, которые генерятся и обрабатываются в других местах, он был бесполезен. Всё перечисленное было лишь тачпоинтами при взаимодействии пользователей с продуктами компании, а мы были touchpoint manager’ами. Хоть и не сразу, но мы осознали свою ошибку и изменили структуру компании согласно именно продуктовым направлениям. В итоге, у нас получились три продукта: omnichannel communication platform, engagement и lead hub. Каждый из них был интегрирован друг с другом, но вполне мог существовать независимо и решать свой определенный кластер проблем.

Еще пару примеров

Компания Яндекс

Является ли продуктом компания Яндекс? Или любая другая компания. Всё зависит от контекста. Если как сферический Яндекс в вакууме, то нет. Хотя Яндекс.Такси — да. Но если в контексте инвестиций, то это товар, который можно продать другому. Ну, или который приносит дивиденды.

Тихомиров (справа, стрелочки еще показывают на него, не перепутайте)

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

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

Что такое ценность?

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

Одно из определений, которое встречается в экономике, звучит так:

Потребительская ценность — это способность блага/товара/услуги удовлетворять какую-либо человеческую потребность.

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

Ценность — степень, в которой продукт закрывает потребности пользователей.

Слово «степень» очень важное и отличается от слова «способность», т.к. степень подразумевает наличие некоторого числового ряда, чьё количество значений больше, чем у «способности» (способность либо есть, либо её нет).

Из чего состоит продукт?

Продукт состоит из фич!

Очевидное невероятное

Т.е. фич в продукте какбэ много. Все ли они закрывают потребности клиента? Они закрывают разные потребности или одни и те же? А может быть одна фича закрывает сразу несколько потребностей? А может быть какие-то фичи вообще не закрывают ни одну из потребностей (выпилить её к чертям).

Получается, что есть два слоя: слой потребностей пользователя и слой фич продукта.

Трассировка слоёв друг на друга

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

С одной стороны проблему выявления потребностей клиентов решает customer development, когда как раз и нужно найти верное соотношение сегмента, его проблем и вариантов их решения. С другой стороны создание таких форматов описания требований, как user story и jobs-to-be-done, как раз и произошло по причине переноса фокуса от реализации задачи к цели её реализации (пользовательскому кейсу, и, как следствие, проблеме), выдвигая на первый план именно ценность.

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

Один мой товарищ в своё время вёл в университете к дипломному проекту студентов. Дело было то ли в Военмехе, то ли в Политехе, контингент был сугубо инженерным. И вот для одного нерадивого неофита он практически полностью подготовил проект — студенту оставалось только его защитить перед комиссией. Получилась у него это не очень, профессура откровенно скучала, уже понимая, кто в действительности делал проект. И вот она решила дать ему последний шанс: «Скажите, молодой человек, вот вы всё время говорите о хрупкости. Мол, хрупкость то, да хрупкость это. А… в чём измеряется хрупкость?». На что балбес, не раздумывая ни секунды, гордо произнёс: «В хрупах!». После этого задавший вопрос профессор пошел пить конъяк, а студент получил свой трояк (ведь план по кафедре выполнять же надо, несмотря на количество идиотов).

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

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

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

AARRR

AARRR позволяет оценить, насколько успешно компания или продукт привлекает клиентов и конвертирует их в доход.

HEART

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

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

Пример метрик для каждого этапа жизненного цикла продукта

Подробнее об этом можно почитать во второй части моей статьи про product marketing «Метрики и критерии успешности».

Зачем нужен продакт?

Продакт менеджер, как бы романтично ни звучала эта профессия, какой бы ни был у неё ореол великого Стива Джобса, как бы гордо ни выглядила фраза «product manager is a mini-CEO», как и все остальные работяги всего лишь функция.

Продакт = функция

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

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

Функция продакта — максимизировать ценность продукта

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

Давайте посмотрим на вход этой функции. Для этого вспомним фразу «product manager is a mini-CEO», прозвучавшую в начале. Какие ресурсы должны быть доступны продакту (не с точки зрения владения или управления, а именно доступности)? Да практически любые. Ведь чтобы максимизировать ценность, нужно представлять, как формируются потребности у клиентов (анализ рынка и проектирование профиля пользователя и его опыта), каким образом должны быть реализованы фичи (дизайн, архитектура, системный анализ, UX), нужна команда для реализации (разработчики, тестировщики), необходимо правильно донести до клиентов информацию о созданной ценности (маркетинг, реклама, PR, продажи), после внедрения нужно померить результаты (BI аналитики, маркетинг, продажи). Продакт не владеет с точки зрения организационной структуры никем из них, но все они необходимы, чтобы в продукте появилась ценность.

Ресурсы продакта

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

Пару месяцев назад Анна Булдакова (@proproduct) в facebook запустила флешмоб с хештегом #япопал_nfng, в котором продакты рассказывали свои истории о том, как они попали в профессию. Есть весьма интересные истории и все абсолютно разные (хотя многие и начинаются со слов «ой, я попал в Яндекс, и тут понеслось»).

Чем конкретно занимается продакт?

Профессиональный стандарт

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

Стандарт определяет деятельность продуктовых менеджеров так:

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

В нём выделены четыре основных трудовых функции:

  • Сопровождение развития существующего продукта
  • Управление продуктом
  • Управление серией продуктов и группой их менеджеров
  • Управление портфелем продуктов и подразделением управления продуктами

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

Если посмотреть в общем на skill map в стандарте, то можно отметить, что продакты разного уровня должны знать и уметь:

  • Проведение количественных и качественных исследований / контроль за метриками продукта
  • Проектирование продукта / проверка гипотез продукта
  • Формирование требований к продукту
  • Взаимодействие с командой с точки зрения передачи требований и приёмки результатов
  • Подготовка активностей для донесения ценности о продукте до клиентов
  • Участие в presale / взаимодействие с партнерами по продукту
  • Стратегический менеджмент
  • Анализ рынка и текущего места продукта на нём
  • Бюджетирование продукта
  • Управление командой продактов

Типажи продактов

Однако, на практике я встречал куда больше типажей / специализаций продактов:

  • Продакт-исследователь (discovery) — фокусируется на исследовании рынка, поиске голубых океанов, трендов и инсайтов. Думает, что чем больше статистических данных, тем лучше получится продукт. Плачет после первого запуска, потому что это не так.
  • Продакт-писатель [требований] — оборачивается пледиком и начинает строчить тикетули в Jira. Размеру его беклога больше, чем расстояние от Земли до Альфа-Центавра. Постоянно потеет, потому что хотелок написал много, а команда может сделать только четыре.
  • Продакт-проектировщик (design) — обожает стикеры и почесать языком с потенциальными пользователями или стейкхолдерами (обратный типаж — великий гений создает своё шедевр в одиночестве). Рисует невнятные каляки-маляки, которые потом с болью превращаются командой в код. Быстро теряет интерес к продукту после MVP.
  • Продакт-проджект — в его речи чаще слышны burndown chart и фокус-фактор, чем cohort analysis и коэффициент доверия. Скрамовский оунер, стремится не столько приносить ценность в продукт, сколько увеличить велосити команды. Плохо понимает, какой реальный профит принесёт то, что делает командой.
  • Продакт-роадмеппер — прохвост, рисующий дороги-карты с датами. Когда выпуск фичи не попадает в дату, находится тысяча причин, почему его сбалансировано-построенный роадмеп правильный, а другие — нет. Любит говорить о том, как текущее корыто превратится в космический корабль. Не очень понимает, когда это все же наступит.
  • Продакт-продажник — любит костюмы и очки с деревянными дужками. Ездит по пресейлам, продавая клиентам ожидания. Для команды использует только два приоритета: СРОЧНО и ВНЕЗАПНО. Уверен, что продукт должен делать деньги, а не ценность. Внедряет всё, что просят крупные и не очень клиенты, лишь бы их удержать.
  • Продакт-маркетинг — умеет пользоваться Яндекс.Метрикой и скакалкой. Меряет конверсию продукта во всё, что угодно. Подготавливает рассылки, рекламу и флаеры. Любит писать фельетоны про «уникальный продукт» и «новое качество жизни». Сидит в твиттере и фейсбуке через телеграм на iwatch. Раз в год отрывается в щи на СПИКе.
  • Продакт-аналитик данных — знает, как считать когорты при помощи куба и сводных таблиц. Различает среднее от медианы. Слышал про моду и статистическую значимость. Любит навешивать цели на всё, что попадется под руку. Когда говорит и показывает графики с сияющими глазами, никто ничего не понимает, но все кивают. Впадает в аналитический паралич чуть менее, чем постоянно.
  • Продакт-руководитель — любит водить руками в стороны, создавая муссоны. Ничего не умеет делать, кроме «синхронизировать» других для разработки продукта. Илита, кормящая своим продуктовым молоком личинок продактов. В резюме пишет, что делает в год по сто продуктов. Не человек — конвейер!
  • Продакт-евангелист — спит в поездах за деньги компании. Когда бодрствует, говорит ртом в толпу на разных вписках. Вместо обоев дома клеит бейджики с конференций. Придумывает фичи, пока вещает. Забывает, что они еще не реализованы. Уверен, что его компания лидер рынка. Знает, куда этот рынок придет через 20 лет. Не знает, что выдаст команда через неделю.
  • Продакт-блоггер — пишет обо всякой херне. Устраивает конкурсы. Каждое второе предложение начинает со фразы «Меня часто спрашивают…». Совершенно не понятно, балабол он или все-таки продукты делал какие-то. Ну, как я, например.

Связь с другими зверьми

Вот тут диаграмма Венна, которая отображает общее между UX, маркетинг и програм менеджерами и, собственно, продакт менеджером. Еще много полезного можно найти тут:

https://blog.pendo.io/2016/01/21/the-dynamic-duo-product-management-and-ux/

https://medium.com/all-things-product-management/differences-between-product-management-ux-productmarketing-ab35548ebe6b

https://www.romanpichler.com/blog/romans-product-management-framework/

https://www.justinmind.com/blog/product-managers-and-ux-designers-ways-to-work-better-together/

Всё, я спать.

P.S. Спасибо Денису Бескову, основателю и директору Product.Vision, одному из создателей профстандарта, за исправления относительно времени разработки. Стандарт был написан не 1,5 года назад, как я указал раньше, а в 2013 (принят годом позднее).

P.P.S. Автор картинки про продакта — Владимир Червоненко, hemule, который делал переводы комиксов про Дилберта.