Від «зроби як на скрині» до партнерства: як PD і PM можуть перестати гальмувати один одного

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

Наприклад, у мене був показовий кейс з текстами в інтерфейсі. Формально UX-копірайтинг був «на PM», але це постійно блокувало весь робочий процес — PM фізично не має часу сісти і накидати всі тексти для кожного стану кожного екрану, ти як дизайнер не можеш закінчити макети без текстового наповнення, і все зависає в якомусь дивному підвішеному стані.

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

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

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

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

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

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

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

Немає одного правильного шляху — і це нормально

Важливо розуміти фундаментальну річ: різні PM — це різні підходи, різні темпи, різні очікування, різні стилі комунікації. Хтось дуже структурований, любить процеси і чекає детальних макетів із описами кожного стану. Хтось фокусується на швидких ітераціях, схематичних скетчах на папері та готовий ризикувати заради швидкості. Хтось живе в аналітиці й не приймає жодного рішення без A/B-тесту, хтось більше покладається на інтуїцію та якісний фідбек від користувачів.

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

Будьте в контексті на 200% — це не про контроль, а про якість

І найважливіше правило здорової співпраці. Класична ситуація, яку я бачила безліч разів у різних командах: PM знає 100% інформації про проєкт, контекст, обмеження, політику. Він фільтрує з неї приблизно 90%, вважаючи частину несуттєвою або «технічною». Дизайнер отримує ці 10%, а насправді розуміє лише 5%, бо навіть ця інформація приходить без повного бекграунду.

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

Але дизайнер має ставити питання. Завжди. Багато питань. Навіть якщо здається, що ви вже дістали PM своїми «чому» і «навіщо». Якщо щось незрозуміло, якщо відчуваєте, що не бачите повної картини — це проблема відсутності або неповної передачі контексту.

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

Водночас дизайнер повинен вимагати аргументації від PM — так само як PM має повне право вимагати обґрунтування кожного дизайнерського рішення. Це не конфлікт, не недовіра, а нормальний здоровий процес командної роботи: «Чому ми робимо саме так, а не інакше?», «На яких конкретно даних базується це рішення?», «Що саме ми хочемо виміряти після впровадження цієї зміни?», «Який ризик і наслідки, якщо зробимо по-іншому?», «Чи тестували ми це припущення?»

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

Партнерство замість ієрархії — ось де справжня цінність

Якраз це і є те справжнє партнерство, яке так критично важливе для успіху продукту. Бо, давайте чесно, продукт тримається не на красивих макетах у Figma, не на ідеально заповненому списку задач у Jira, не на правильно проведених спринтах і навіть не на досягнутих KPI. Все це важливо, але вторинне.

Продукт насправді тримається на людях і на тому, як вони вміють працювати разом. На довірі, на відкритості, на готовності слухати та чути один одного.

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

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

Коли в парі PD і PM з’являється взаєморозуміння, постійний обмін контекстом і спільна відповідальність за результат, а не за «мій блок роботи», — продукт перестає бути «ще одним проєктом». Він стає простором, де росте команда, бізнес і ти як фахівець.

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

І так, ви реально здивуєтесь, наскільки легше й швидше розвивається продукт, коли PD і PM «синхронні та дивляться в один бік».