Управление продуктом — это искусство рассказывать истории
Управление продуктом — это, по сути, умение рассказывать истории. Поэтому я хочу поделиться тем, как я вижу роль продакт-менеджера и как ИИ изменил эту профессию, через одну историю.
Тот вопрос на собеседовании, который я никогда не забуду
Я начал карьеру инженером в RealNetworks, и через несколько лет отвечал за продукт и инженерную команду RealPlayer. В то время это был очень значимый потребительский продукт: сотни миллионов пользователей, он помог привнести аудио и видео в ранний интернет. Я сидел на встречах с коллегами из бизнес-подразделений, которые предлагали идеи вроде: «Давайте показывать рекламу каждый раз при запуске плеера». Я понимал, что это плохая идея, но мне было нечем крыть их Excel-таблицы с прогнозами доходов. Я хотел стать настоящим продакт-менеджером и решил, что мне стоит пойти в бизнес-школу.
Я поступил в Berkeley Haas School of Business, и вскоре после начала учебы увидел в рассылке своего бывшего университета вакансию в LinkedIn. Я отправил резюме и оказался на собеседовании с Reid Hoffman. Он сел напротив меня и задал вопрос, который запомнился мне навсегда:
«Итак, ты хочешь быть продакт-менеджером. Что является артефактом работы продакт-менеджера?»
Он стал развивать мысль. У инженеров есть артефакт — код. У специалистов по развитию бизнеса — подписанные контракты. Дизайнеры создают визуальный стиль и графику. У CEO есть оргструктура, план финансирования и видение, которое объединяет всех. А что у продакт-менеджера?
Я ответил, что не уверен, есть ли у нас такие же четкие «артефакты», но фундаментальная часть нашей работы — собрать всю информацию и записать её в спецификацию. Спецификация — это чертеж. Здесь мы определяем требования и весь объем работ, и она становится одним из важнейших документов компании, потому что именно она дает командам зеленый свет на разработку.
Я явно нервничал. Думаю, он заметил это, потому что успокоил меня, сказав, что ответ вполне приемлемый. В итоге я получил работу, бросил бизнес-школу ради LinkedIn и с тех пор постоянно возвращаюсь мыслями к тому вопросу.
Эволюция от спецификации к истории
Потому что я дал неправильный ответ.
Это была эпоха Waterfall (каскадной модели) разработки ПО. В LinkedIn мы пытались переосмыслить платформу поиска работы внутри социальной сети: чтобы рекрутеры видели заявки кандидатов в контексте общих знакомых, а соискатели могли находить вакансии и использовать свои связи для выхода на нужных людей. В процессе этого исследования я написал 120-страничную спецификацию, описывающую весь пользовательский опыт и требования.
За прошедшие годы я много об этом думал. Потому что эта спецификация, очевидно, не является самым важным артефактом. Самый важный артефакт — это история.
Спецификация описывает систему, то, что она должна делать, и чек-лист пунктов, которые нужно закрыть, чтобы считать работу выполненной. Это не суть управления продуктом. Суть управления продуктом — рассказать историю о людях, которые будут пользоваться продуктом, и о том, почему это важно для их жизни. Эта история должна быть понятна мгновенно, кому бы вы ни рассказывали. И она должна быть воспроизводимой — люди должны передавать её друг другу без искажений, даже когда вас нет в комнате.
Это совершенно другой документ и совершенно другая работа.
Десять лет назад я выступил с докладом об управлении продуктом, и мне до сих пор присылают его ссылку; это либо комплимент, либо признак того, что индустрия стоит на месте. Я допускаю оба варианта. В любом случае, весь мой доклад сводился к одному предложению: «Продакт-менеджер помогает своей команде (и компании) выпустить правильный продукт для своих пользователей». Я потратил большую часть выступления на разбор этого предложения по словам.
- Помогает своей команде. Вы не лидер. Многие считают, что продакт-менеджер — это руководитель. Но вы тот человек, который помогает сделать так, чтобы всё случилось. А значит, вам нужно…
- Понимать свою команду и свою компанию. Ваша команда — ваша территория: вы обязаны её знать! И вы должны понимать, как она вписывается в общую картину, чтобы служить целям компании, а не только своим собственным.
- Выпускать продукт. Мы можем сколько угодно говорить, но в конечном счете имеет значение только то, что продукт попадает к клиентам.
- Правильный продукт для ваших пользователей. Мы наконец добрались до сути: уточнение того, что на самом деле означает слово «правильный».
Насколько сильно это меняется в мире ИИ?
Что меняется
Очевидно, что что-то изменилось, причем многое. С одной стороны, меняется то, как мы пишем код, и скорость превращения идеи в рабочий прототип. С другой стороны, меняются ожидания пользователей от того, каким должен быть продукт. Мне кажется, мы лишь слегка коснулись этой темы, особенно в потребительском сегменте. Возможность описать свою потребность и получить готовое решение, возможно, благодаря агентам, работающим в фоне, без необходимости изучать интерфейс и осваивать инструменты.
Нет сомнений, что стоимость создания вещей рухнула. Теперь не так сложно набросать концепцию и попробовать её реализовать; это дает огромную гибкость. Но стоимость принятия решений не изменилась совсем. Понять, что строить, стало важнее, чем когда-либо прежде.
Разработка продукта — это цикл. Раньше кто-то приходил с идеей (это не обязательно должен быть вы; в хорошей компании идеи могут исходить откуда угодно). Вы пробуете её. Пишете спецификацию, продуктовый бриф или как там называется этот документ у вас. Есть предварительные затраты: оценка объема, дизайн, споры — всё, что должно произойти до того, как будет потрачено драгоценное время инженеров. Это ритуалы, которые мы придумали, чтобы защитить время разработки от плохих решений. Потому что раньше вы успевали пройти этот цикл всего шесть-восемь раз в год.
Затем создание вещей стало невероятно дешевым. Не немного дешевле, а на порядок дешевле. И произошло нечто действительно интересное. Старый цикл никуда не делся — он просто перестроился в новом порядке.
Старый цикл выглядел так: идея, спецификация, оценка стоимости, определение скоупа, всё остальное, и только потом разработка. Теперь:
- Сначала берете идею и быстро реализуете её с помощью ИИ, просто чтобы посмотреть, как это работает и ощущается.
- Вы играетесь с этим, понимаете, как это вписывается в общую картину. Прототипы всегда лучше гипотетических «а что если».
- Затем вы занимаетесь дизайном. Теперь, когда вы поигрались с продуктом, вы знаете, что это такое, и можете реально обсудить, что нужно, чтобы превратить это из прототипа в полноценный продукт. Под дизайном здесь я имею в виду оба смысла: визуальный и UX-дизайн, а также архитектурный дизайн.
- Затем вы выпускаете продукт и учитесь на обратной связи.
Это полностью переворачивает процесс: от «спецификации и скоупа» к «разработке и тестированию». Я думаю, что это меняет управление продуктом больше, чем любой другой текущий тренд.
Это окончательно означает, что спецификация больше не является главным результатом работы; по-настоящему. Вам больше не нужно начинать с написания длинного документа и пытаться предусмотреть всё на бумаге. Раньше это было верно скорее в идеале, но теперь это очевидная истина буквально.
Но я хочу быть осторожным, потому что существует равная и противоположная ошибка.
Демо-версии теперь почти бесплатны. Работающие продукты — нет. Я постоянно наблюдаю обратную сторону нового подхода: «Отлично, давайте сразу выкатим это в прод». Так дело не обстоит. Мы все еще должны уважать тот факт, что путь от прототипа до реального продукта требует времени.
Есть стереотип о продакт-менеджерах, будто их главная задача — спрашивать: «Впишется ли это в график?» Забудьте об этом. Самый важный вопрос звучит иначе: Впишется ли это в продукт?
У всех нас есть отличные идеи, и теперь у всех есть агенты, которые могут писать код за нас. Решение о том, что строить, официально перестало быть вопросом ресурсов. Это вопрос влияния. Выбор между «этим» и «тем», а не между «этим» и «ничего». Вкус и кураторство становятся критически важными, когда у вас есть видение и вы четко понимаете, что хотите дать миру. Но система, которую вы строите, все равно должна ощущаться целостной.
Моя главная тревога по поводу ИИ заключается в том, что он позволяет нам двигаться быстрее, и поэтому мы начинаем запихивать в продукт всё подряд. Мы говорим об «AI slop» (цифровом мусоре) в контенте; вот что это значит для продукта. Я уже видел это в нескольких местах, и думаю, что все мы немного обеспокоены этим. Когда любой может создать что угодно, решение о том, что создавать, становится всей работой. И это проблема сторителлинга. Какую историю вы хотите рассказать? Какую историю должны понять ваши клиенты? Какая история должна жить у них в голове?
Ваша задача как PM — не написать спецификацию того, что будет делать продукт. Она заключается в создании общего понимания — общей картины того, что мы делаем и зачем. Почему пользователь здесь? Что он чувствует на каждом шаге и почему это важно? Где продукт впечатляет, а где скучен? Продукту можно быть скучным иногда, если вы знаете, где именно. Но если вы не можете написать хороший сценарий, продукт будет тусклым.
Подарок, который дает вам ИИ, состоит в том, что теперь вы можете проверить это бесплатно и прямо на старте. Вы можете быстро построить прототип, прочувствовать его, поиграть с ним и найти ту самую фразу: что этот продукт делает для человека в его жизни? Потому что если вы можете ответить на это, вы можете ответить на мой вопрос: «Люди действительно пользуются им?» Поскольку теперь вы определили функцию, и вы спрашиваете, выполняют ли они её.
Что не меняется
Что значит иметь «видение» для вашего продукта?
Когда я говорю «видение», я не имею в виду миссию компании. Миссия важна, но это не видение. Видение — это сквозная причина существования продукта для пользователей. У меня есть простая рамка для этого:
- Цель. Почему человек берет ваш продукт и впускает его в свою жизнь?
- Ключевые действия. Что они делают, когда открывают приложение? Может быть несколько действий, и вы должны понимать все.
- Цикл. Какова ожидаемая частота каждого из этих ключевых действий?
На протяжении всей моей карьеры, встречаясь с основателями и другими специалистами по продуктам, я задаю им один вопрос: пользуются ли люди вашим продуктом? И они почти всегда сразу переходят к метрикам. «У нас соотношение DAU/MAU 50%. Мы преодолели отметку в 10 000 регистраций. У нас миллион человек в листе ожидания. Наш ARR составляет миллион. Мы обрабатываем четыре миллиарда токенов в день. Мы заняли 3-е место в App Store».
Является ли хоть что-то из этого ответом на заданный мной вопрос?
Иногда я повторяю вопрос, добавляя одно слово: действительно ли люди используют ваш продукт? И тогда, иногда, они начинают понимать, о чем я спрашиваю.
Целью LinkedIn было найти и быть найденным. Возможно, для некоторых людей ключевым действием было просто отвечать, когда кто-то выходил на связь. Для большинства это не ежедневная активность; это может происходить раз или два в год.
Посмотрите на этот цикл — раз или два в год. Понимание этого было критическим для успеха LinkedIn, потому что сети требовалось очень большое количество людей, готовых быть найденными, и хотя бы некоторые люди, которые занимались поиском.
LinkedIn была социальной сетью, поэтому возникало искушение подталкивать пользователей совершать действия каждый день. Мы этого не делали. Вместо этого в первые дни мы потратили огромное количество времени на то, чтобы люди поддерживали актуальность своих профилей. Было абсолютно нормально, если вас находили раз или два в год, главное, чтобы когда это все-таки случалось, вы переходили по ссылке и понимали: «Кто-то хочет связаться со мной, это здорово».
Когда вы измеряете успешность продукта, важны именно эти ключевые действия. Сосредоточьтесь на прямом трафике: найдите людей, которые буквально пришли к вам сами. Они установили приложение и нажали на иконку, или вручную ввели ваш домен; они пошли к вам по собственной воле. Именно этот трафик важен, в отличие от всех других способов вернуть пользователя в моменте.
А затем считайте только тех, кто выполняет ключевые действия. Не «кратковременно открыл приложение», а реально взаимодействовал с ним. В Discord это было бы: «вошел в живую сессию. Реально читал и отправлял сообщения».
Если вы не можете определить, что такое ваши ключевые действия, то у вас нет продукта, потому что у вас нет того, что вы понимаете.
Теперь одна новая вещь, которая мне очень нравится: в продуктах на базе ИИ, где пользователь общается с системой или отправляет ей промпты, у вас появляется буквальная транскрипция пути пользователя. Вы видите, что люди говорят своими словами. Вы видите точный момент, когда кто-то сдался и переформулировал запрос. Вы видите, чего они ожидали от продукта, но не получили. ЧИТАЙТЕ ЭТО! ИИ отлично выявляет вещи, которые вы раньше не замечали, но нельзя позволять ему резюмировать всё за вас или формировать ваше мнение. Формирование мнения — понимание того, какова история на самом деле, — это и есть работа и искусство управления продуктом.
Онбординг
Онбординг — это самый важный момент, когда вы рассказываете свою историю клиенту. Они узнали о вашем продукте — может быть, через рекламу, вирусное приглашение, статью, да что угодно. Они знают, что вы существуете; им любопытно, и они хотят попробовать. Вы больше никогда не получите от них столько внимания.
В этот момент нужно помнить, что не все приходят в ваш продукт с одинаковой мотивацией. Есть энтузиасты. Они хотят попасть внутрь очень сильно. Они готовы начать. И, чтобы было понятно, если вы работаете в компании, вы живете в стране энтузиастов. Всех внутренних сотрудников нужно рассматривать как энтузиастов; они погружены в продукт каждый день. Проходя онбординг, они думают: «Я знаю, что делаю, это скучно, зачем этот шаг?»
С другой стороны, есть прохожие. Им не особо интересно. Они услышали о продукте, глянули, но сообщение не нашло отклика, и они уйдут.
Эти два типа пользователей — края распределения. Между ними находится большая размытая середина. Это люди, которые пришли по какой-то причине: им любопытно! Они хотят узнать больше! И вы действительно можете превратить их в основных пользователей вашего продукта. Это те люди, вокруг которых нужно строить продукт. Энтузиасты останутся с вами в любом случае. Середина — это те, кого нужно понять.
Предполагайте, что ваши пользователи мотивированы и любопытны. Уделите время представлению продукта шаг за шагом. Больше простых шагов лучше, чем меньше сложных. Я доказал это A/B-тестами в нескольких компаниях за последние годы. Если каждый шаг дискретен и прост, если ясно, о чем вы просите и чему учите, это работает лучше, чем большие экраны или сложные выборы, сделанные ради сокращения количества шагов. Каждый раз.
Так как же это построить?
Начните с повторения ключевого сообщения: Вот для чего это нужно. Обозначьте контекст внутри продукта. Можно запрашивать базовые данные — email, пароль, телефон. Для всего остального объясняйте, почему вы спрашиваете и как это связано. Затем разбейте продукт на ключевые концепции, каждая с четким действием для пользователя.
Продукты на базе ИИ усложнили это, а не упростили. Вы получаете пустое поле для промпта. В некотором смысле это худший экран онбординга из когда-либо созданных. Это волшебная коробка. Она может делать всё. Так... что вы хотите сделать?
Многие продукты сейчас начинаются с: «Привет, я здесь, чтобы помочь, спроси меня о чем угодно!» Отвечая за себя, скажу, что в такой момент я не самый красноречивый и креативный человек. Нужно обучать возможностям концепция за концепцией. «Если вы спросите что-то подобное, я смогу это сделать». И пусть продукт это сделает. Быстро доведите пользователя хотя бы до одного ценного кейса использования, желательно с его собственными данными, чтобы это было реально полезно для него.
Иногда меня спрашивают: при более длинном флоу не отвалится ли больше людей? Да! Но те, кто пройдет до конца, гораздо чаще начнут реально пользоваться вашим продуктом. Если вы тестируете два разных флоу онбординга, НЕ смотрите на то, сколько людей дошли до конца. Смотрите на то, сколько вернутся на следующий день или на следующей неделе, и сколько совершат ключевое действие. Если спросить их в этот момент: «Что это за продукт?», они должны дать примерно правильный ответ. Ваши данные по удержанию с этого момента — это ваша табель успеваемости.
История из Twitter
Я завершу всё это, рассказав историю из Twitter.
Я присоединился к Twitter в конце 2009 года. У нас была проблема с ростом — хотя на самом деле это была не проблема роста. Twitter постоянно был в новостях. О нем писали блогеры, говорили СМИ, и многие спрашивали: «Что это за Twitter? Мне нужно разобраться и зарегистрироваться». И миллионы это сделали. Но они не возвращались.
Проблема заключалась в том, что никто не мог объяснить, что такое Twitter. Я могу это доказать:
Подпись: «в итоге мы вышли на первое место».
Мы проводили онбординг так: люди регистрировались и видели опции «Найти друзей» или «Подписаться на 20 случайных людей». Большинство пропускало этот этап и попадало на страницу, которая выглядела так:
Это довольно ужасно! Это большой пустой ящик. Люди смотрели на него и думали: «...Мне нечего сказать». И уходили. Если бы вы спросили их в тот момент: «Что такое Twitter?», они бы сказали: «Думаю, это про то, чтобы сказать что-то миру? Или найти друзей? Не знаю».
Поэтому мы перестроили онбординг за пару лет и нашли то, что сработало — Learn Flow. Мы учили их Twitter, одна концепция за раз, как историю. И это улучшило удержание больше, чем любой другой релиз того года.
Learn Flow, экран за экраном
Первый экран — новая домашняя страница: «Добро пожаловать в Twitter». Мы не пытались разместить там контент, только надпись: «Узнайте, что происходит прямо сейчас с людьми и организациями, которые вам интересны». Честно говоря, это хорошее описание Twitter.
Затем: Это твит. Это короткое сообщение, до 140 символов, оно может содержать ссылки. Теперь вы знаете, что твиты — это единица измерения этой платформы.
Далее вам нужно построить свою ленту. Поэтому мы показывали вам ленту. Мы заставляли вас нажимать «подписаться» на людей слева. И когда они нажимали «подписаться», их твиты появлялись справа. Таким образом, вы схватываете всю идею одним движением: Я нажимаю «подписаться», появляются твиты, это моя лента. Это и есть настоящая концепция Twitter — твиты, подписки и лента.
И, наконец, ваша лента. Вы узнавали каждый аккаунт в ней, потому что вы сами на них подписались.
Онбординг — это ваша история.
Правильный продукт для ваших пользователей
Ваша задача как продакт-менеджера — помочь вашей команде и компании выпустить правильный продукт для ваших пользователей. В мире ИИ сам выпуск продукта перестал быть главной проблемой. Понимание того, какой продукт является правильным, и кто ваши пользователи, так же важно, как и всегда. Если не важнее.
Всегда спрашивайте, действительно ли люди используют ваш продукт. Понимайте, что это значит. Думайте о цели, ключевых действиях, цикле. Тратьте на онбординг больше времени, чем кажется разумным. Это место, где вы конвертируете размытую середину, и это место, где вы действительно рассказываете историю вашего продукта.
Используйте ИИ, чтобы быстрее делать прототипы, — но не ускоряйте принятие решений. Не отказывайтесь от своего суждения. Не говорите просто: «Ну, давайте протестируем и посмотрим». Так получается небрежный продукт. Сохраняйте свое суждение везде. Самая сложная часть работы по-прежнему заключается в балансе между всем нашим творчеством как продакт-менеджеров и всеми данными, к которым у нас теперь есть доступ.
Удачи!
