Product management — це мистецтво розповідати історії. Тому дозвольте мені поділитися тим, як я думаю про управління продуктом, і як ШІ змінив цю сферу, розповівши вам одну таку історію.
Питання на співбесіді, яке я ніколи не забуду
Я почав свою кар’єру інженером у RealNetworks, і за кілька років став відповідальним за продуктову та інженерну команди для RealPlayer. На той час це був досить значущий споживчий продукт: він мав сотні мільйонів користувачів і допоміг принести аудіо та відео в ранній інтернет. Я сидів на нарадах з людьми з бізнес-відділу, які пропонували ідеї на кшталт: «Ми повинні показувати рекламу щоразу, коли запускається плеєр». Я знав, що це погана ідея, але не мав аргументів проти їхніх електронних таблиць Excel, де було показано, скільки грошей ми заробимо. Я хотів стати справжнім продакт-менеджером і дійшов висновку, що мені варто піти до бізнес-школи.
Я вступив до бізнес-школи Berkeley, і невдовзі після приїзду побачив у списку розсилки свого колишнього університету, що LinkedIn шукають людей. Я подав заявку й опинився на співбесіді з Рідом Гоффманом (Reid Hoffman). Він сів і поставив мені питання, яке я ніколи не забуду:
«Отже, ти хочеш бути продакт-менеджером. Що є артефактом, який створює продакт-менеджер?»
Він уточнив думку. У інженерів є артефакт: код. У відділі розвитку бізнесу є артефакт: підписані контракти. Дизайнери створюють візуальний вигляд та графіку. У CEO є організаційна структура, план фінансування та бачення, яке об’єднує всіх. А що ж продакт-менеджер?
Я сказав йому, що не впевнений, чи справді продакт-менеджери мають такі «артефакти», але фундаментальна річ, яку ми робимо, — це збираємо все, що відбувається, і записуємо це в специфікацію. Специфікація — це креслення. Це місце, де ми визначаємо вимоги та все, що будемо робити, і вона стає одним із найважливіших документів у компанії, оскільки дає кожній команді змогу почати розробку.
Я явно хвилювався. Думаю, він помітив це, тому заспокоїв мене, сказавши, що відповідь цілком прийнятна. Зрештою, я отримав роботу, покинув бізнес-школу, щоб приєднатися до LinkedIn, і з того часу постійно думаю про те питання.
Еволюція від специфікації до історії
Тому що я дав неправильну відповідь.
Це ще була ера Waterfall (водоспадної моделі) у розробці програмного забезпечення. У LinkedIn ми намагалися переосмислити платформу вакансій у межах соціальної мережі: щоб рекрутери могли бачити заявки на роботу в контексті спільних контактів, а кандидати — переглядати вакансії та шукати шляхи через свою мережу зв’язків, щоб потрапити на очне інтерв’ю. Під час цього процесу дослідження я написав 120-сторінкову специфікацію, яка визначала весь досвід взаємодії та вимоги до нього.
За роки, що минули, я багато про це думав. Бо ця специфікація, очевидно, не є найважливішим артефактом. Найважливіша — це історія.
Специфікація описує систему, що вона має робити та які галочки потрібно поставити, перш ніж вона буде готова. Це не мистецтво управління продуктом. Управління продуктом — це розповідь історії про людей, які використовуватимуть продукт, і про те, чому це важливо для їхнього життя. Вона має бути зрозумілою миттєво, незалежно від того, кому ви її розповідаєте. І вона має бути повторюваною — люди повинні мати можливість передавати її далі без спотворень, навіть якщо вас немає в кімнаті.
Це абсолютно інший документ і абсолютно інша робота.
Десять років тому я прочитав доповідь про управління продуктом, і люди досі надсилають мені посилання на неї; це або лестить, або свідчить про те, що сфера не рухається вперед. Я допускаю обидва варіанти. У будь-якому разі, вся доповідь зводилася до одного речення: «Продакт-менеджер допомагає своїй команді (та компанії) випускати правильний продукт для своїх користувачів.» Більшу частину доповіді я витратив на розбір цього речення слово за словом.
- Допомагає своїй команді. Ви не лідер. Багато хто вважає, що продакт-менеджер — це лідер. Ви — людина, яка допомагає зробити справу. А це означає, що ви повинні…
- Розуміти вашу команду та вашу компанію. Ваша команда — це ваша територія: ви повинні її розуміти! І ви повинні розуміти, як вона вписується у загальну картину, щоб служити цілям компанії, а не лише вашим власним.
- Випускати (Ship). Ми можемо говорити скільки завгодно, але в кінці дня важливо лише одне: доставити продукт клієнтам.
- Правильний продукт для ваших користувачів. Нарешті ми дійшли до суті роботи: визначення того, що насправді означає «правильний».
Наскільки це змінюється у світі ШІ?
Що змінюється
Очевидно, щось змінилося, навіть кілька речей. З одного боку, змінюється те, як ми пишемо код, і як швидко ми можемо перейти від ідеї до працюючого прототипу. З іншого боку, змінюються очікування користувачів щодо того, яким має бути продукт. Мені здається, ми лише торкнулися цієї теми, особливо в сегменті B2C. Можливість описати свої потреби та отримати продукт, який їх задовольнить, можливо, за допомогою агентів, що працюють у фоновому режимі, без необхідності вивчати інтерфейс.
Немає сумнівів, що вартість створення речей різко впала. Тепер не так складно окреслити задачу та спробувати її реалізувати; це надає величезної гнучкості. Але вартість судження не змінилася взагалі. Визначення того, що саме будувати, зараз важливіше, ніж будь-коли.
Розробка продукту — це цикл. Раніше хтось мав ідею — і це не обов’язково мали бути ви; у хорошій компанії ідея може прийти звідки завгодно. Ви пробуєте її. Ви пишете специфікацію, продуктовий бриф або як там називається цей документ у вас. Є певні початкові витрати: окреслення обсягу робіт, дизайн, суперечки — все, що має статися, перш ніж витрачати дорогоцінний час інженерів. Це ритуали, які ми винайшли, щоб захистити час інженерів від поганих рішень. Бо ви робили лише шість-вісім циклів на рік.
Потім створення речей стало абсурдно дешевим. Не трохи дешевшим, а на порядок дешевшим. І те, що сталося, дуже цікаве. Той старий цикл нікуди не зник — він просто перебудувався в новому порядку.
Старий цикл виглядав так: ідея, специфікація, кошторис, окреслення обсягу, решта деталей, і потім розробка. Зараз:
- Спочатку берете ідею і швидко будуєте її за допомогою ШІ, просто щоб побачити, як це працює і які відчуття викликає.
- Ви отримуєте можливість погратися з цим, зрозуміти, як це відчувається і як вписується в загальну картину. Прототипи завжди перемагають «а що, якщо...».
- Тоді ви займаєтеся дизайном. Тепер, коли ви погралися з ним, ви знаєте, що це таке, і можете реально обговорити, що потрібно, щоб це стало більше, ніж просто прототип. Я маю на увазі дизайн в обох сенсах: візуальний та UX-дизайн, а також архітектуру системи.
- Потім ви випускаєте продукт і навчаєтеся.
Це повністю інвертує процес: від «специфікація та обсяг робіт» до «розробка та тестування». Я думаю, що це змінює управління продуктом більше, ніж будь-що інше, що відбувається зараз.
Це нарешті означає, що специфікація більше не є головним результатом роботи; справді. Вам не потрібно починати з написання довгого документа та досягнення ідеальності на папері. Раніше це було правдою радше в ідеалістичному сенсі, але тепер це очевидна правда в буквальному розумінні.
Але я хочу бути обережним, бо можна припуститися помилки, протилежної за знаком.
Демо-версії тепер майже безкоштовні. Працюючі продукти — ні. Я постійно бачу зворотний бік цього нового підходу: «Чудово, просто випускайте це». Так це досі не працює. Ми всі все ще маємо поважати той факт, що відстань від прототипу до реального продукту все ще потребує часу для подолання.
Існує стереотип про продакт-менеджерів, ніби їхня робота полягає переважно в питанні: «Чи вкладається це в графік?» Відкиньте цю ідею повністю. Найважливіше питання: Чи вкладається це в продукт?
У нас усіх є чудові ідеї, і тепер у нас усіх є агенти, які можуть писати код за нас. Вирішення того, що будувати, офіційно перестає бути дискусією про ресурси. Це дискусія про вплив. «Це або те», а не «це або нічого». Тут дуже важливі смак та кураторство, коли у вас є бачення і ви точно знаєте, що хочете зробити для світу. Але система, яку ви будуєте, все одно має відчуватися завершеною.
Моя найбільша тривога щодо ШІ полягає в тому, що він дозволяє нам рухатися швидше, і тому ми просто запихаємо в продукт усе підряд. Ми говоримо про «AI slop» (ШІ-сміття) у контенті; ось що означає «AI slop» для продукту. Я вже бачив це в кількох місцях, і думаю, що всі ми трохи занепокоєні цим. Коли будь-хто може створити будь-що, вирішення того, що будувати, стає всією роботою. І це проблема історії. Яку історію ви хочете розповісти? Яку історію ви хочете, щоб зрозуміли ваші клієнти? Яку історію ви хочете, щоб жила в їхніх головах?
Ваша робота як PM — не писати специфікацію того, що робитиме продукт. Вона полягає у створенні спільного розуміння — спільної картини того, що ми робимо і чому. Чому користувач тут? Що він відчуває на кожному кроці і чому це важливо? Де продукт вражає, а де нудний? Продукт може бути нудним іноді, за умови, що ви знаєте, де саме. Але якщо ви не можете написати гарний сценарій, продукт буде тьмяним.
Подарунок, який дає вам ШІ, полягає в тому, що тепер ви можете дізнатися про це безкоштовно, одразу на початку. Ви можете швидко побудувати це, відчути його, погратися з ним і визначити ту одну фразу: що цей продукт робить для людини в її житті? Бо якщо ви можете відповісти на це, ви можете відповісти на моє питання: «Чи люди насправді ним користуються?» Бо тепер ви сказали, що він робить, і питаєте, чи роблять вони це.
Що не змінюється
Що означає мати «бачення» (vision) для вашого продукту?
Коли я кажу «бачення», я не маю на увазі місію компанії. Місії важливі, але вони не є баченням. Бачення — це кінцева причина існування продукту для користувачів. У мене є проста рамка для цього:
- Мета. Чому хтось бере ваш продукт і впроваджує його у своє життя?
- Ключові дії. Коли вони його беруть, що саме вони роблять? Їх може бути кілька, і ви повинні розуміти всі.
- Цикл. Яка очікувана частота кожної з цих ключових дій?
Протягом усієї своєї кар’єри, спілкуючись із засновниками та іншими продуктовими фахівцями, я запитую їх: чи люди користуються вашим продуктом? І вони майже завжди одразу переходять до даних про користувачів. «У нас коефіцієнт DAU/MAU становить 50%. Ми досягли 10 000 реєстрацій. У нас мільйон людей у черзі очікування. Наш ARR — мільйон. Ми обробляємо чотири мільярди токенів на день. Ми зайняли 3-тє місце в App Store.»
Чи є щось із цього відповіддю на моє запитання?
Іноді я повторюю питання, додаючи одне слово: чи люди справді користуються вашим продуктом? І тоді, іноді, вони починають розуміти, про що я питаю.
Метою LinkedIn було знаходити і бути знайденим. Можливо, ключовою дією для деяких людей було просто відповідати, коли хтось звертався до них. Для більшості це не щоденна дія; це може статися раз чи двічі на рік.
Подивіться на цей цикл — раз чи двічі на рік. Розуміння цього було критичним для успіху LinkedIn, оскільки мережі потрібна була дуже велика кількість людей, готових бути знайденими, і принаймні деякі люди, які здійснювали пошук.
LinkedIn був соціальною мережею, тому вас могло спокусити змушувати користувачів діяти щодня. Ми цього не робили. Натомість ми витратили величезну кількість часу на ранніх етапах на те, щоб переконатися, що люди підтримують свої профілі актуальними. Було цілком нормально, якщо вас знаходили лише раз чи двічі на рік, за умови, що коли це все ж таки траплялося, ви переходили за посиланням і розуміли: «Хтось звертається до мене, це чудово».
Коли ви вимірюєте ефективність вашого продукту, саме ці ключові дії мають значення. Фокусуйтеся на прямому трафіку: знайдіть людей, які буквально прийшли до вас. Вони встановили додаток і натиснули на іконку, або вручну набрали ваш домен; вони пішли до вас, з власної волі. Саме цей трафік важливий, на відміну від усіх інших способів повернути людину в моменті.
І тоді рахуйте лише тих, хто виконує ключові дії. Не «коротко відкрив додаток», а реально взаємодіяв з ним. У Discord це означало б: «увійшов у живий сеанс. Насправді читав і надсилав повідомлення».
Якщо ви не можете визначити, що таке ці ключові дії, то у вас немає продукту, тому що у вас немає чогось, що ви розумієте.
Тепер одна нова річ, яка мені подобається: у продуктах на базі ШІ, де користувач спілкується з продуктом або використовує запити (prompts), у вас тепер є буквальний транскрипт вашого користувацького шляху. Ви можете бачити, що люди кажуть своїми словами. Ви можете бачити точний момент, коли хтось здався і переформулював запит. Ви можете бачити, чого вони очікували від продукту, але він цього не зробив. ЧИТАЙТЕ ЦЕ! ШІ чудово підсвічує речі, яких ви б не помітили раніше, але ви не можете дозволити йому резюмувати все за вас і формувати вашу думку. Формування власної думки — визначення того, якою насправді є історія — це і є робота та мистецтво управління продуктом.
Онбординг
Онбординг — це найважливіший момент, коли ви маєте розповісти свою історію клієнту. Вони дізналися про ваш продукт — можливо, через рекламу, вірусне запрошення, статтю чи якось інакше. Вони знають, що ви існуєте; їм цікаво і вони хочуть спробувати. Ви ніколи більше не отримаєте від них такої уваги.
Ви повинні пам’ятати, що на цьому етапі не всі приходять до вашого продукту з однаковою мотивацією. Є ентузіасти. Вони хочуть потрапити всередину так сильно. Вони готові діяти. І, щоб було ясно, якщо ви працюєте в компанії, ви живете в країні ентузіастів. Всіх внутрішніх співробітників слід вважати ентузіастами; вони занурені в продукт щодня. Коли вони проходять онбординг, вони думають: «Я знаю, що роблю, це нудно, навіщо цей крок?»
З іншого боку, є випадкові перехожі (fly-bys). Їм просто не так уже й цікаво. Вони почули про це, перевірили, але повідомлення не спрацювало, і вони скоро підуть.
Ці два типи користувачів — це крайні точки розподілу. Посередині є велика розмита середина. Це люди, які прийшли з причини: їм цікаво! Вони хочуть дізнатися більше! І ви дійсно можете перетворити їх на основних користувачів вашого продукту. Це ті люди, навколо яких вам потрібно будувати. Ентузіасти залишаться з вами в будь-якому разі. Середина — це ті, кого вам потрібно зрозуміти.
Припускайте, що ваші користувачі мотивовані та цікаві. Знайдіть час, щоб представити продукт крок за кроком. Більше простих кроків перемагають менше складних. Я довів це A/B-тестами в кількох компаніях за роки. Якщо кожен крок дискретний і простий, і чітко зрозуміло, про що ви просите і чому вчите, це перемагає одиниці великих екранів чи складні вибори заради зменшення кількості кроків. Щоразу.
То як же це насправді побудувати?
Почніть з повторення основного повідомлення: Ось для чого це. Оголосіть контекст всередині продукту. Нормально просити базові дані — email, пароль, телефон. Для всього іншого поясніть, чому ви це питаєте і як це пов’язано. Потім розбийте свій продукт на ключові концепції, кожна з яких має чітку дію для користувача.
Продукти на базі ШІ ускладнили це, а не спростили. Ви отримуєте порожнє поле для введення запиту. У деякому сенсі це найгірший екран онбордингу, який коли-небудь створювали. Це магічна коробка. Вона може робити все. Тож… що ви хочете зробити?
Багато продуктів сьогодні починаються зі слів: «Привіт, я тут, щоб допомогти, запитайте мене про що завгодно!» Говорячи за себе, я не найбільш красномовна чи креативна людина в той момент. Ви повинні навчати можливостям концепція за концепцією. «Якщо ви запитаете щось таке, я можу це зробити». А потім дозвольте продукту це зробити. Доведіть користувача до хоча б одного цінного кейсу використання швидко, бажано з їхніми власними даними, щоб це було дійсно корисно для них.
Люди іноді питають мене: при довшому флоу, чи не відмовиться більше людей? Так! Але ті, хто пройде до кінця, набагато, набагато частіше будуть реально користуватися вашим продуктом. Якщо ви проводите A/B-тестування двох різних потоків онбордингу, НЕ дивіться на те, скільки людей дійшло до кінця потоку. Дивіться на те, скільки людей повернуться наступного дня або наступного тижня, і скільки з них виконали ключову дію. Якщо ви запитаєте їх у той момент: «Що це за продукт?», вони мають дати приблизно правильну відповідь. Ваші дані про утримання (retention) з цього моменту є вашою табелем успішності.
Історія з Twitter
Я об’єднаю все це разом, розповівши вам історію з Twitter.
Я приєднався до Twitter наприкінці 2009 року. У нас була проблема зі зростанням — хоча насправді це не була проблема зі зростанням. Twitter постійно був у новинах. Люди писали про нього в блогах, медіа обговорювали його, і багато хто питав: «Що таке цей Twitter? Мені треба розібратися і зареєструватися». І мільйони з них це зробили. Але вони ніколи не поверталися.
Проблема була в тому, що ніхто не міг сказати вам, що таке Twitter. Я можу це довести:
Підпис: «зрештою ми вийшли на перше місце».
Наш онбординг виглядав так: люди реєструвалися і бачили опції «Знайти друзів» або «Підписатися на 20 випадкових людей». Більшість пропускала це і потрапляла на сторінку, яка виглядала ось так:
Це досить жахливо! Це велика порожня коробка. Люди дивилися на неї і думали: «...мені нема що сказати». І потім вони йшли. Якби ви запитали їх у той момент: «Що таке Twitter?», вони б відповіли: «Гадаю, це про те, щоб сказати щось світу? Або знайти друзів? Не знаю».
Тому ми перебудували онбординг протягом кількох років і знайшли те, що спрацювало — Learn Flow (Навчальний потік). Ми навчали їх Twitter, одну концепцію за раз, як історію. І це підвищило утримання більше, ніж будь-що інше, що ми випустили того року.
Learn Flow, екран за екраном
Спочатку нова домашня сторінка: «Ласкаво просимо до Twitter». Ми не намагалися розмістити там контент, лише: «Дізнайтеся, що відбувається прямо зараз із людьми та організаціями, які вам небайдужі». Це досить добре описує Twitter, чесно кажучи.
Потім: Це твіт. Це коротке повідомлення, до 140 символів, і воно може містити посилання. Тепер ви знаєте, що твіти — це базова одиниця цієї штуки.
Далі вам потрібно побудувати свою стрічку. Тому ми показали вам стрічку. Ми змусили вас натиснути «follow» (підписатися) на людей ліворуч. І коли вони натискають follow, їхні твіти з’являлися праворуч. Таким чином, ви отримуєте всю ідею одним рухом: Я натискаю follow, твіти з’являються, це моя стрічка. Що і є справжня концепція Twitter — твіти, підписки та стрічка.
І нарешті, ваша стрічка. Ви впізнавали кожен акаунт у ній, тому що ви самі на них підписалися.
Онбординг — це ваша історія.
Правильний продукт для ваших користувачів
Ваша робота як продакт-менеджера — допомагати вашій команді та компанії випускати правильний продукт для ваших користувачів. У світі ШІ процес випуску (shipping) менш проблемний, ніж був раніше. Визначення правильного продукту та розуміння того, хто ваші користувачі, є таким же важливим, як і завжди. Якщо не важливішим.
Завжди питайте, чи люди справді користуються вашим продуктом. Розумійте, що це означає. Думайте про мету, ключові дії, цикл. Приділяйте онбордингу більше часу, ніж здається розумним. Саме там ви конвертуєте розмиту середину, і саме там ви насправді розповідаєте історію вашого продукту.
Використовуйте ШІ, щоб швидше робити прототипи — але не прискорюйте ваше судження. Не відмовляйтеся від свого судження. Не кажіть просто: «Ну, давайте протестуємо і подивимось». Так ви отримаєте недбалий продукт. Зберігайте своє судження всюди. Найскладнішою частиною роботи залишається баланс між нашою творчістю як продакт-менеджерів і всіма даними, до яких ми тепер маємо доступ.
Успіхів!
