NVEX: від мікроменеджменту до самостійності у командних рішеннях

Хочете, щоб команда самостійно приймала рішення й брала відповідальність за результат? Для цього недостатньо просто дати людям свободу — потрібно ще й навчитися довіряти їхнім рішенням, навіть якщо ви самі зробили б інакше. Як не піддатися спокусі мікроменеджменту й розвивати автономію в команді, радить Євгеній Борисов, Head of Product у NVEX — міжнародній продуктовій IT-компанії у сфері Health & Fitness Tech, яка створює продукти, що змінюють життя людей у всьому світі.

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

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

Але якщо йти цим шляхом, згодом настає момент, коли кожне рішення проходить через одну людину. Команда чекає на її фідбек, погодження, правки. Швидкість усієї системи поступово стає рівною швидкості менеджера, а він витрачає дедалі більше часу на локальні рішення й дедалі менше — на стратегічні.

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

Автономія — це не «робіть що хочете»

Автономія — це не просто сказати: «Тепер вирішуйте самі». Поясню на прикладі своєї команди. Щоб Product Manager міг самостійно приймати нормальні рішення, Head of Product має:

• надати йому повний бізнес-контекст (що відбувається з компанією, які її цілі, чому вони саме такі, які основні проблеми, обмеження, залежності й пріоритети);
• синхронізувати вектор руху РМ-а з цілями чи стратегією компанії.

Як це працює на практиці?

1. Спочатку мені потрібно зібрати контекст із різних частин компанії, звести його в одну картину й розкласти бізнес-цілі організації на цілі для продукту.

2. Далі ми з командою декомпозуємо продуктові цілі на два напрями: проблеми й потенційні рішення. Команда приносить свої дані, результати досліджень і гіпотези. Разом ми складаємо дерево рішень, які будуть контрибьютити в загальну ціль. І це командна робота, а не автономне завдання кожного продакта. Наприклад, якщо потрібно збільшити revenue, ми декомпозуємо це таким чином:

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

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

Саме так ми й намагаємося будувати роботу продуктових команд у NVEX: не навколо окремих завдань чи постійних погоджень, а навколо відповідальності за конкретний результат. Для мене важливо, щоб PM не просто реалізовував рішення, а розумів, на що він впливає і чому це має значення для продукту та бізнесу.

Як рівень автономії залежить від сеньйорності людини

Приклад: senior-фахівець

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

Далі проводжу регулярні зустрічі 1-on-1 (раз на 1–2 тижні), на яких продакт може поставити запитання, попросити про допомогу, підсвітити блокери чи порадитись — залежно від його потреб. Я виступаю для нього в ролі ресурсу за запитом, а не менеджера.

Фінальний етап — обговорення отриманого результату. Тут важливо зрозуміти дві речі:

• чи зробив продакт висновки для себе особисто, чи є просування з погляду розвитку;
• що отримані результати означають для бізнесу — чи треба змінювати пріоритети, планувати нові завдання, залучати інші команди тощо.

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

Якось під час роботи над калькулятором залежності LTV від поведінкових метрик користувачів PM помітив невідповідність: 30% юзерів скасовували підписку до платежу, а списати кошти ми намагалися з 68% — разом майже 100%, але не 100%. Замість того щоб проігнорувати різницю, він почав розбиратися й виявив значно більшу проблему в tracking і billing logic, хоча це й не стосувалося його безпосереднього завдання. Для мене це і є ownership — саме такій людині можна делегувати роботу над важливими аспектами продукту та відходити від регулярного контролю.

Приклад: junior-фахівець або новачок у команді

Новому ж або джуновому PM-у я не дам у роботу частину продукту зі словами: «Побачимось через три місяці». Спочатку він отримає менші завдання: з низькою ціною помилки та потенційно швидшим результатом.

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

• чи бачить реальну проблему;
• чи може декомпозувати її на завдання;
• чи дивиться на дані;
• чи здатна дешево перевірити гіпотезу;
• чи здатна заделіверити рішення на прод.

Це дозволить або скорегувати дії людини на ранніх етапах, або пересвідчитись, що вона робить усе правильно.

Коли я бачу, що людина стабільно приймає адекватні рішення, кількість контролю буде стрімко зменшуватися. Якщо ж є помилки, такому РМ-у треба приділяти більше уваги, пояснювати причини, підсвічувати помилки й спонукати до саморефлексії — це його підґрунтя для розвитку і моя інвестиція в його майбутню автономію.

У NVEX мені близький саме такий підхід до розвитку команди: давати людям можливість поступово брати на себе більше відповідальності, пробувати, помилятися й робити власні висновки. Адже професійне зростання відбувається не лише через нові завдання, а й через можливість самостійно впливати на рішення та бачити їхні наслідки.

Порада для менеджерів: менше відповідей, більше питань

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

Наприклад, якось РМ прийшов з ідеєю давати новому користувачеві welcome gift після реєстрації, щоб збільшити ретеншн. Питання «Навіщо саме welcome gift?» дозволило виявити глибшу проблему, яку ми вирішуємо. Якщо вона в тому, що люди скасовують підписку одразу після покупки, подарунок має дати відчутну цінність тут і зараз. Якщо ж ідеться про тривале утримання, потрібен подарунок, який дає причину повертатися через тиждень, два або місяць. Слово «подарунок» те саме, але за ним можуть стояти дві різні бізнес-проблеми та два різні рішення.

Інший приклад: PM хоче запустити опитувальник після скасування підписки й запитати, чому саме люди це зробили. Варіанти: «Дорого», «Не користуюся продуктом», «Пішов до конкурента». Я пропоную зробити логічну вправу: припускаємо, що 70% юзерів оберуть «Дорого». І що з цього? Чи змінимо ми після цього вартість? Точно ні. Отже, опитувальник у такому вигляді нам не підходить.

Моє завдання — не відповісти замість PM-а, а навпаки — навчити його самостійно ставити собі запитання, щоб докопатися до реальної проблеми й заздалегідь зрозуміти, що він робитиме з результатом. Ця навичка значно пришвидшує продакта на шляху до автономії.

Коли починається справжня автономія

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

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

Мій прогноз справдився: результат був слабким. Чи втратили ми частину потенційної цінності для бізнесу? Безумовно. Але важливо також подивитися на масштаб цієї невдачі: вона була локальною, дешевою і контрольованою. Зате PM сам прийняв рішення, побачив наслідки й отримав досвід, якого не було б, якби я просто сказав: «Зроби ось так».

Якщо PM може приймати лише ті рішення, з якими менеджер уже погодився, це не автономія. Це просто довгий процес узгодження.

За деякий час у нас із тим самим PM виникла дзеркальна ситуація. Щоб покращити промо, він запропонував варіант, у який я не сильно вірив, але не міг довести, що він помиляється. У такому разі рішення логічно залишити людині, яка безпосередньо веде ініціативу. Вона ближче до проблеми, має більше локального контексту і може бачити щось, чого не бачу я. Досвід Head of Product має вагу. Але він не перетворює мою думку на істину.

Тож ми пішли його шляхом і знайшли варіант, який показав приблизно втричі вищу конверсію, ніж дефолтний. А якби не було першого «невдалого» кейсу, то в РМ-а не було б сміливості відстоювати свою позицію в другому.

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

Якщо підсумувати, то в автономній команді Head of Product не зникає з процесу, він просто перестає бути людиною, через яку проходить кожне рішення. Його завдання — зібрати бізнес-контекст, перетворити його на зрозумілі цілі для продукту, разом із командою визначити, які проблеми справді варто вирішувати, допомогти їх пріоритизувати й окреслити межі ризику. А далі PM залежно від своєї сеньйорності отримує відповідний простір для самостійних рішень.

У NVEX ми створюємо міжнародні Health & Fitness Tech продукти й будуємо в Україні команду, де можна брати відповідальність, впливати на рішення та зростати разом із бізнесом. Якщо вам близький такий підхід до роботи, знайомтеся з нашими напрямами та відкритими вакансіями на кар’єрній сторінці.

Джерело новини: happymonday.ua