Product Digest #4: чому технічні знання та перемога над календарним пеклом — must have для PM

💡 Усі статті, обговорення, новини про продукти — в одному місці. Приєднуйтесь до Product спільноти!

Привіт, ком’юніті! Мене звати Макс Галійов, я Head of Product at Brighterly by SKELAR. У новому випуску дайджесту для фахівців, які створюють і розвивають продукти, я зібрав поради, перевірені на власному досвіді (іноді позитивному, іноді навпаки).

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

Якщо вам знайомий вічний пошук спільної мови з розробниками або ви тонете в мітах, які з «давайте швидко на 10 хв» магічно перетворюються на півторагодинні сеанси екзистенційної кризи — цей дайджест точно для вас. Наполегливо рекомендую не пропускати!

Що розглянемо в цьому випуску?

• Технічний бекграунд для продактів — не просто «було б корисно», а must have. Розберемо статтю Коліна Метьюза, автора курсу «Technical foundations for product managers». На основі його матеріалу «Become a more technical product manager» розглянемо, чому розуміння технічних основ — це не опція, а життєва необхідність.
• Як вибратися з нескінченних мітингів і не зламати свій тайм-менеджмент. Дослідимо, як позбутися «календарного пекла», разом із партнерами SVPG Крістіаном Ідіоді та Крісом Джонсом та їхнім подкастом «Product Therapy».

Ці теми провалідовані продактами й інженерами та мають статус «скарбів» серед усього контенту на ринку. Тож сьогодні дайджест — про реалії, інсайти та корисні фішки, які можна впроваджувати вже зараз. Заварюйте каву чи чай і вривайтеся!

Навіщо продакт-менеджерам технічні знання

В сучасному світі продуктового IT існує так багато розгалужень за специфікою роботи продактів, як гілок у метро в Токіо.

Серйозно? AI PM, Tech PM, UX PM, Digital PM, Visionary PM — це ж база для будь-якого продакта. А от далі список тільки розширюється: API product managers, Design product managers, Associate PM, Analytics/Data PM... І це далеко не все. Та якщо існує стільки розгалужень, то хто такий класичний продакт-менеджер і що він має знати?

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

У своїй статті «Become a more technical product manager» Колін Метьюз наголошує на базових, але суперважливих моментах, які в сучасному світі продакт-менеджменту почали відходити на другий план. Особливо серед спеціалістів «нової школи продактів», які дотримуються підходу «я відповідаю за бізнес-цілі, а технічні деталі — не моя справа».

«Технічні знання — це суперсила для продактів»

З цієї цитати Коліна починається стаття — я не можу з нею не погодитися.

Технічний бекграунд — це ключова перевага для продакт-менеджерів, особливо зараз, коли AI проникає в кожен цифровий продукт. Базові технічні знання дозволяють PM:

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

Що мені також сподобалося в статті «Become a more technical product manager». Вона добре пояснює базові технічні поняття та є особливо корисною для продакт-менеджерів, які не мають глибокого технічного бекграунду. Приклади з Airbnb та OpenAI роблять матеріал зрозумілим і наочним, а акцент на API — дуже влучний, адже саме API є основою інтеграцій у сучасних продуктах.

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

• Список ресурсів для навчання (курси, книги, статті).
• Практичні рекомендації, які технічні навички першочергово освоювати.
• Конкретні кроки для PM, які хочуть стати більш технічно обізнаними.

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

Мій досвід та спостереження

Як людина, яка в продуктовому ІТ починала кар’єру з операційного менеджменту, а потім перейшла в QA, можу впевнено сказати: базові технічні навички — це must have. Водночас я все частіше зіштовхуюся з ситуаціями, коли продакти кажуть: «моє завдання — виконувати бізнес-цілі, а не порпатися в технічних деталях». Щиро кажучи, я не бачу в цьому нічого поганого. Але якщо ми говоримо про продуктового менеджера майбутнього, то це не просто людина, яка координує команди, а фактично CEO свого продукту. Він має розбиратися в усьому, щонайменше на базовому рівні.

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

Висновок

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

Тож якщо ви ще не знайомі з технічним світом, моя порада: паралельно з читанням статей беріть і вчіться. SQL, API-запити, архітектура застосунків, основи DevOps — це знання та вміння, які зроблять вас сильнішим продактом.

Як не «спамити» колег мітами

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

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

• Команда залишається в контексті й ніхто не випадає з процесів.
• Можна одразу розібрати слабкі місця та розвʼязати нагальні проблеми.
• «Живий» сінк зміцнює командний дух (якщо, звісно, не перетворюється на корпоративний stand-up без punchline).
• Якщо команда тільки розпочала спільну роботу, такий спосіб реально найшвидший.

Але як казав дядько Бен Паркер із «Людини-павука» — «з великою силою приходять ще більші проблеми». Якщо використовувати формат зідзвонів без здорового глузду, на вас чекає:

• Переривання роботи інших, бо що ж може бути важливіше, ніж ваш терміновий мітинг?
• Зниження якості рішень: люди просто не хочуть гаяти час на обговорення, тому погоджуються на першу-ліпшу пропозицію.
• Втрата сенсу, тому що 90% ваших «обов’язкових» мітингів могли б просто бути імейлом або повідомленням у Slack.

Якраз про це розповідають гуру продуктового ком’юніті з Кремнієвої долини Крістіан Ідіоді та Кріс Джонс у випуску свого подкасту «Coaching Time Manegement».

Вважаю це скарбом для продактів Senior+ грейду. У таких спеціалістів робота переважно перетворюється на нескінченне коло мітів, між якими немає часу зробити перерву на каву та перезавантажити мозок. Та в цьому відео Крістіан Ідіоді та Кріс Джонс не тільки розкривають поради про організацію мітингів та про те, що з ними робити. Вони шерять інші свої практики:

• Як зрозуміти, куди йде найбільша частина твого робочого часу. Спойлер: все-таки потрібно бути data-driven не тільки в бізнесі, а й у власному тайм-менеджменті).

• Як не потрапити в пастку «термінового міта». Найкорисніше, що змінило ритм моєї роботи та знизило рівень фрустрації від постійних дзвінків — перелаштування календаря. Я розробив такий план, щоб у дні з великою кількістю зустрічей у мене було від 15 до 30 хвилин між мітами на виконання завдань.
• Як не бути тим колегою, який любить спамити мітами. Ідіоді та Джонс обговорюють, які 3 найважливіші запитання потрібно поставити собі, перш ніж сетапити черговий міт. Якщо ви таке не практикуєте, рекомендую переглянути випуск і взяти ці поради собі на замітку.

P.S. Я також рекомендую продактам для ознайомлення:

• Книгу «Domain-Driven Design» про бізнес мовою девелоперів.
• Подкаст Метта Мулленвіґа, кофаундера WordPress та CEO Automattic, про культуру texting у цих компаніях.

Сподіваюся, що цей дайджест допоможе вам будувати дійсно круті продукти, а не розтягувати свій робочий день до нескінченності. Зустрінемося в наступному випуску!