Основні виклики у роботі продакт-менеджера і як їх подолати. Частина 1

Привіт, мене звати Олег Свірський. Я — продакт-менеджер в американському InsurTech стартапі Matic з офісами у Сан-Франциско, Лос-Анджелесі, Коламбусі і Львові. Ми змінюємо традиційну галузь страхування — одну з найбільш консервативних і регульованих індустрій в США. За лічені хвилини ми допомагаємо клієнтам підібрати оптимальний варіант страхування їхнього майна. Я відповідаю за розробку власної CRM.

За роки роботи продактом я отримував різні професійні виклики: деякі з них повторювались, а деякі були специфічними для продукту чи компанії, в якій я працював. Тож вирішив проаналізувати ці складнощі і систематизувати набуті в процесі вирішення проблем знання.

Щоб переконатися, що ці професійні граблі не є унікальними для мене, я поспілкувався з понад 20 колегами-продактами, які працюють в Україні й за кордоном (Zalando, Booking, Vimeo, Grammarly, Badoo, ZeoAlliance, Tickets.ua, Edunav, Matic).

Ця стаття може бути особливо корисною для тих, хто тільки починає працювати продактом, думає про перехід в цю професію або працює над продуктом в стартапі.

Що складніше: продукт чи менеджмент?

Почнемо з того, що загалом робота продакт-менеджера виглядає нескладно. Роби, як пишуть в усіх книжках про продукт чи стартап: знайди проблему, провалідуй гіпотези, сформулюй рішення, збери метрики, ітеруй... ПРОФІТ!

Що ж може піти не так?

З моєї практики, трохи більше, ніж все.

Я запитав продакт-менеджерів, що працюють над крутими продуктами в Україні і світі, з якими найбільшими викликами вони стикаються у щоденній роботі. А головне, що у роботі продакта є складнішим: продукт чи менеджмент*?

*під «менеджментом» маю на увазі активності, пов’язані з керуванням і розвитком команди, менеджментом стейкхолдерів, менторством чи керуванням підлеглими, а «продукт» — це робота над продуктом — візія, стратегія, взаємодії з користувачами, партнерами, процес розробки і виведення продукту на ринок і таке інше.

Отримав цікавий результат: 90% опитаних сказали, що менеджмент є складнішим.

Чому так? Що саме є найбільшими викликами у менеджменті для продактів? Як їх вирішити? У цій статті я хочу дати відповіді на ці питання, базуючись на власному досвіді.

Перший виклик — це stakeholder-менеджмент

Так виглядає типовий день продакт-менеджера: балансування

Якщо звести суть роботи продакт-менеджера до одного слова — це балансування. Ти постійно балансуєш між очікуваннями користувачів і вимогами менеджменту, між стратегічним баченням розвитку продукту і вимогами контракту з зовнішніми партнерами... You name it.

Складність у комунікаціях

Продакти взаємодіють з Engineering, QA, Design, Sales, Marketing, Support, Customer Success, Finance, Legal та багатьма іншими людьми, залежно від структури компанії. Кожен зі стейкхолдерів має власні очікування від продукту, що знаходить відображення в численних запитах до вас. З ростом організації керувати цими очікуваннями і пріоритезувати запити стає все складніше. Тож затрати часу на комунікацію зі стейкхолдерами, зазвичай, зростають за експонентою.

Саме тому типовий день продакт-менеджера може включати шість годин мітингів. Колеги дивуються, запитуючи, а коли ж я встигаю «робити роботу»? Власне, це і є моя робота, бо комунікації — це значна частина обов’язків продакт-менеджера.

Зростання організації має ще одну побічну дію, пов’язану з комунікаціями: появу і посилення політичних процесів. Про це чудово писав Володимир Мірненко.

Політика — це, напевно, найнадокучливіше явище, на яке скаржаться продакти у всьому світі (Alpha product management report).

How much time do you spend on politics?

Балансування інтересів користувачів і стейкхолдерів

З одного боку, ваш продукт буде успішним у випадку, коли задоволені клієнти і користувачі. З іншого ж, кар’єра менеджера залежить від того, наскільки задоволені вашою роботою ключові стейкхолдери: команда та керівництво.

Один із поширених стереотипів, що продакт-менеджер — це голос клієнта у компанії, його адвокат. Звучить красиво, але в реальності продакт постійно балансує між інтересами клієнтів і потребами бізнесу.

Приклад абсолютно пересічного питання для продакта: інвестувати в покращення UX чи працювати над інфраструктурою для збору додаткових метрик для Sales?

Потреба у крос-продуктовій взаємодії

Важливо завжди пам’ятати, що ви не будуєте продукт, перебуваючи у вакуумі. Напевно, кожен із менеджерів потрапляв у ситуацію, коли цілі його команди залежали і були заблоковані роботою іншої команди.

Із ростом компанії ми зіткнулися з ускладненням залежностей між продуктами і департаментами. Нижче розповім про спосіб вирішення цієї проблеми, який ми використовуємо у Matic.

Другий челендж менеджера — лідерство

У Маtic немає традиційних проджект-менеджерів, і, формально, продакт-менеджер не відповідає за ефективність процесу розробки. Водночас, продакт — це саме та людина, якій «більше за всіх потрібно».

Продакт — це, напевно, єдиний менеджер, який не є менеджером у класичному розумінні: він не керує людьми. Як правило, продакт-менеджери не мають важелів впливу на команду. Вони не звільняють і не наймають людей, не визначають рівень компенсації й не приймають рішення про підвищення. Продакт-менеджер не є керівником інженерів, дизайнерів, QA чи маркетологів — всіх тих людей, від яких залежить успішність продукту. Водночас, саме продакт-менеджер є відповідальним за продукт.

Тому кожен продакт, особливо в організаціях, де ця роль є новою, зіткнувся з мовчазним (іноді, ні) запитанням: «Хто цей чувак і чому він командує?».

Тож супер-виклик для кожного продакта — знайти спосіб вести команду і керувати, водночас, не починаючи «війн за територію» з функціональними керівниками (проджектами, тім-лідами). За цих умов, єдиний спосіб для продакта домогтися бажаного — неформальний вплив.

Неформальний вплив означає постійно аргументувати і мотивувати, і, найважливіше, — «запалювати». Справжні продуктові лідери одержимі успіхом продукту. Вони з ентузіазмом сприймають нові можливості для змін, діляться, пояснюють та відстоюють свої ідеї; вони підтримують культуру інновацій, обмін інформацією та співпрацю.

Це надихає. Коли люди вірять у ваше бачення продукту, вони активніше залучаються, стають його частиною і, зрештою, частиною успіху продукту. Таким чином, учасники команди зростають, досягають успіху і визнання, розвиваються як лідери.

З цього випливає одне цікаве, але парадоксальне відкриття: чим більше рішень ви дозволяєте прийняти команді самостійно, тим кращим продакт-менеджером ви є. Тому продакт-менеджеру потрібно «продавати» ідею команді, надавати максимальну кількість контексту й інформації, щоб команда могла прийняти рішення самостійно. Щоправда, це складно і незрозуміло: скільки можна делегувати без ризиків? Як спокійно спати, не контролюючи всіх і вся? Про це розповім нижче.

Третій челендж продакт-менеджера: Mr. No

Ми, продакт-менеджери, сотні разів змушені говорити «ні» — команді, стейкхолдерам, керівництву і користувачам продукту. Усе тому, що ми несемо відповідальність за складні трейд-офи і змушені обирати, що є достатнім, а не ідеальним рішенням проблеми. Таким чином, ми, з одного боку, руйнуємо мрії дизайнерів й інженерів про seamless UI і user flow, відсутність технічного боргу й найновіші ліби. А з іншого боку, — мрії кожного кастомера про вирішення продуктом його персональної проблеми вже наступного тижня. Як комфортно працювати з таким реноме?

Рішення

Отже, у вас немає формальної влади, зате є купа стейкхолдерів, інших продактів, команда і повна відповідальність за продукт. Що ж робити?

Жартують, що на таке питання існує єдина правильна відповідь: it depends. Тож поділюся тим, що спрацювало для мене.

Впровадьте чи вдоскональте існуючу систему постановки і моніторингу цілей. Визначне залежності між цілями

Ми у Маtic використовуємо фреймворк ОКR. На початку року і щокварталу топ-менеджмент встановлює цілі на рівні компанії, а продакт-менеджери визначають цілі продукту і команди. На цьому етапі треба знайти відповіді на такі запитання:

• Які стратегічні теми і бізнес-цілі є ключовими для нас у наступні 3 місяці?
• Як розвиток продукту допоможе досягти ці цілі?

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

• Наскільки збалансовані задачі команд між собою?
• Які проекти задіюють різні продукти? Чи враховано це у їх роадмапі?
• Чи достатньо сил і ресурсів у команд для реалізації цих цілей? Чи потрібно змінювати конфігурацію команд?

Наприклад, коли одна з команд Маtic працювала над ключовим проектом компанії, інші команди включили у список своїх key results підтримку цього проекту і розв’язання залежностей. Узгодивши цілі між командами, ми уникли ризику почути від сусіднього проекту: «Чому ми це повинні робити і яка нам з того користь?», який міг би мати власні, неузгоджені з нами цілі.

І, наостанок, встановіть періодичність відслідковування прогресу цілей. Наприклад, наша команда оновлює прогрес з OKR раз на два тижні, перед кожним плануванням спринта. Так ми переконуємося, що в спринті заплановані задачі, які безпосередньо впливають на виконання OKRs. Якщо ж ми відстаємо від цілей, це сигнал для продакт-менеджера переглянути пріоритетність задач.

Керуйте очікуваннями

Продакт-менеджера постійно бомбардують запитами на реалізацію нових фіч й ідеями. Природне бажання бути «хорошою людиною» підштовхує нас до того, щоб відповідати «так» на такі запити. Це дуже простий шлях. Але не варто обіцяти неможливого. Адже «так» сприймається стейкхолдерами і юзерами як негайна готовність до реалізації фічі, а зовсім не як те, що ви додали фічу в беклог. І вже після наступного релізу вас запитають з неприємним подивом: «А де ж фіча, яку ви мені обіцяли два тижні тому?».

Тому я виробив наступний формат відповідей щодо часу реалізації фіч:

• якщо запитують про задачу, яка запланована і пріоритезована, та не є критичною, повідомляю, що фіча буде зроблена за наступні 1-2 спрінти (2-4 тижні);
• якщо задача допоможе досягти OKR, але не потрапляє у наступні 2 спрінти, то відповідаю, що фіча запланована у нинішньому кварталі;
• якщо фіча є не терміновою і не узгоджується з ключовими цілями на квартал, то повідомляю, що фіча додана в беклог.

У будь-якому разі обов’язково подякуйте за ідею, адже людина витратила свій час для того, щоб надати вам фідбек чи підкинути ідею. Якщо проігноруєте — наступного разу ви теж не отримаєте бажаного фідбеку.

Резюмуючи: прийміть ідею чи запит і не відповідайте негайно. Спершу розберіться в його потребі, терміновості й можливому впливі на ключові результати. У відповіді щодо строків реалізації, не прив’язуйтеся до жорстких дат, а повідомте можливий діапазон. Це дає уявлення про те, коли приблизно фіча буде реалізована, і залишає команді простір для маневру.

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

Підтримуйте комунікацію

Постійно повідомляйте стейкхолдерам і команді про апдейти: зміни у роадмапі, дати релізів, статуси фіч. Дізнались, що реліз фічі відкладається або довелося змінювати пріоритети? Задача продакта — вчасно и зрозуміло пояснити це зацікавленій особі. З мого досвіду, це суттєво зменшить фрустрацію з її боку.

Як же не загубитися у комунікаціях і не забути повідомити усіх зацікавлених про важливі події? Як на мене, якщо в компанії працює понад 50 людей, продакту саме час розробити RACI-матрицю.

Спілкуючись зі стейкхолдерами усно або письмово, завжди персоналізуйте меседж і задавайте собі питання: what’s in it for me? Яку цінну для себе інформацію реципієнт отримує з вашого повідомлення? Як новини від вас можуть вплинути на його роботу, на терміни її виконання? Які деталі варто включити у ваше повідомлення з огляду на це? До речі, ось класний Телеграм-канал, який допоможе покращити email-комунікацію.

Захищайте команду

Найчастіше рішення щодо продукту продакт приймає не одноосібно, а в команді. Продакт може бути не згодним з рішеннями команди на всі 100%. Утім, якщо ви не змогли «продати» команді власну ідею, рішення команди стає і вашим рішенням. Тепер ваша задача — якнайкраще пояснити стейкхолдерам чи менеджменту, чому ідея реалізована саме так, як вона є.

Отримали баг на проді, гнівні коменти юзерів і наполегливі повідомлення від менеджменту «негайно пофіксити»? Ваша задача — оберігати від цього команду і взяти кризові комунікації на себе. У спокійній обстановці команда краще впорається з кризовою ситуацією. А ви, тим часом, краще принесіть всім чарку кави ;)

Пам’ятайте, продакт-менеджер, за RACI-матрицею, рідко Responsible й майже завжди Accountable.

Мінімізуйте політику

Срібної кулі проти монстра політичних інтриг, як на мене, не існує. Тож апелюйте до даних, жонглюйте запитами, як гарячою картоплею, керуйте очікуваннями від вас. Пам’ятайте, продукт успішний, якщо задоволені юзери, а продакт — якщо задоволені стейкхолдери.

Будуйте крос-продуктову колаборацію

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

Такий процес швидко приніс результати. Наприклад, обговорюючи функцію ідентифікації клієнтів для мого продукту, ми з’ясували, що цей алгоритм буде корисним і для інших продуктів Маtic. Об’єднавши зусилля команд, ми реалізували функцію швидше і з більш повним функціоналом. Більше того, алгоритм, розроблений в нашій команді, тепер застосовується в інших продуктах.

Розвивайте продуктове мислення команди

Так-так, я знаю, що це легко сказати і складно зробити. Але щоб продакт-менеджер міг перейти від операційної роботи до стратегії і візії, команда повинна перейти від виконання тасків до вирішення проблеми користувача. Це можливо лише у випадку, коли є глибоке розуміння користувача, його потреб і процесів, емпатія до юзера. Продакт-менеджери Маtic інвестують багато часу і сил у розбір цих тем разом із командою.

Важливо пам’ятати, що розвинути продуктове мислення у команди неможливо за місяць чи два — це тривалий і безперервний процес. Причина в різному майндсеті технічних спеціалістів і менеджерів. Девелопери схильні одразу заглиблюватись у вирішення проблеми з боку технологій, оскільки це зона їхньої відповідальності.

Втім, я дуже тішуся, що все частіше чую від членів команди: «Я подумав, що може бути корисно для користувача, і пропоную інший варіант вирішення проблеми, давай його розберемо».

Don’t be an asshole

Так, ми, продакти, постійно кажемо «ні» стейкхолдерам і користувачам, змушуємо команду переробляти дизайн чи фічу, задаємо дурні питання: детально поясніть свою мотивацію і потребу в змінах, аргументуйте даними, і... Принесіть пончики.

Із загальними менеджерськими викликами розібралися. У цій статті я описав те, що вважаю ключовими викликами у своїй роботі і що знайшло підтвердження в словах моїх колег, продакт-менеджерів в Україні та за її межами.

А як щодо того, що є найскладнішим у роботі з продуктом?

Ви вже знаєте правильну відповідь: it depends. За результатами мого опитування понад 20 продакт-менеджерів, я отримав 15 різних варіантів суто продуктових челенджів. І це, напевно, найкрутіше, що є у роботі продакта. З розвитком продукту змінюються активності й ключові задачі, постійно з’являються нові виклики і речі, які тобі доведеться робити вперше. Це вимагає від продакт-менеджера розвивати нові скіли, оскільки, наприклад, продакт у pre-market fit стартапі й B2B Enterprise — це дві зовсім різні людини.

Тож таких проблем і викликів теж набереться на цілу статтю. У другій частині ми розберемо суто «продуктові» виклики і поговоримо про інструменти їх вирішення.

Stay tuned, coming soon, leave your email to get a free copy.

А які типові «менеджерські» виклики є найболючішими для вас? Також буду радий поспілкуватись про продуктові виклики, з якими ви зустрічаєтесь як продакт. Будь-ласка, напишіть в коментарях або стукайте до мене в Linkedin.