Як світчнутись з сапорту у PM за 5 місяців

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

Привіт. Мене звати Роман, і це історія мого світчингу з сапорт-лідa в проджект-менеджера продуктової компанії Quarks. Ми працюємо у сфері Social Discovery & Relationship Wellness, маємо 80 млн користувачів у понад 20 локаціях світу. Зараз я працюю Project Manager в Android-команді застосунку нового продукту для пошуку знайомств Catchyy.

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

З чого починався мій професійний шлях та чим займаюсь зараз

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

Коли зрозумів, що хочу свічнутися в продукт

Думки про перехід у продукт зʼявилися задовго до відкриття вакансії. Ба більше — у мене вже була одна невдала спроба світчингу. Тоді компанія змінила вектор розвитку, і потреба в junior-позиції зникла — почали шукати senior-кандидата.

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

Як виглядає процес світчингу

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

Етапи переходу з сапорту в проджекти

Ми почали з формування очікувань, цілей, чекпоїнтів і регулярних зустрічей. Одразу визначили задачі, які потребували негайного вирішення, і налагодили взаємодію з усіма дотичними командами: Legal, Support, Product, Backend.

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

Разом із продактами і розробниками ми розбирали, що таке якісна таска і як її правильно описувати, як будувати трекінг. Я підтягнув SQL, практикувався з Gemini та Codewars. Базово мені потрібно було прокачати розуміння аналітики, маркетингу, ключових метрик і побудови гіпотез.

Скільки часу зайняв світчинг

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

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

Що з сапорту стало суперсилою в PM

Найголовніше — це глибинне розуміння користувача. Коли аналітик бачить +1% до рефандів, PM із бекграундом сапорту бачить за цим кілька тисяч розгніваних юзерів, які зіткнулися з проблемою. Розуміння нелогічності, болів та особливостей різних локацій дозволяє мені приймати більш виважені продуктові рішення. Мій досвід у T&S став ключовим: я бачив методи роботи скамерів, тому знав, куди саме треба бити, щоб перекрити їм кисень.

Маст навички для проджекта

Hard Skills

• Методології (Agile, Scrum, Kanban). Не просто знати назви, а розуміти, як працює спринт, що таке беклог
• Мати технічний бекграунд: не треба писати код, але треба знати, що таке API, чим відрізняється Frontend від Backend
• Аналітика — must have: SQL, Tableau, продуктові фреймворки (Jobs-to-be-Done, North Star Metric), пріоритезація (RICE, ICE, Kano), робота з гіпотезами й A/B-тестами, UX-флоу
• Проєктування (Figma). Робота з макетами на рівні розуміння логіки та можливості залишити конструктивний фідбек дизайнеру

Soft Skills

• Переговори. Вміння аргументувати «навіщо ми це робимо» так, щоб команда повірила в задачу
• Пріоритезація. Навичка казати «ні» другорядним задачам, щоб встигнути головне
• Кризовий менеджмент. Збереження спокою, коли «щось впало» або дедлайни горять (тут досвід сапорту — безцінний)
• Емпатія. Вміння почути і юзера, і розробника, знаходячи компроміс між «зручно» та «технічно можливо»

Кому точно не підійде професія проджекта

1. Любителям конкретики та інструкцій.
2. Інтроверти-самітники (спілкуватись доведеться багато).
3. Тим, хто боїться конфліктів.
4. Людям, яким потрібен миттєвий результат.
5. Прихильникам авторитарного стилю.
6. Тим, хто не готовий до «технічного болю» (це мій найбільший виклик). Треба розбиратись, що і як працює, і чому на одній версії андроїда щось може працювати, а на іншій — вже ні.

Що виявилося складнішим у світчингу, ніж я очікував

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

Окремо виділю два критичні моменти:

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

Поради для світчерів

• Зробіть аналіз навичок. Чітко визначте, куди ви цілитеся, і почніть підтягувати «хвости» заздалегідь.
• Почніть діяти як PM вже зараз. Навіть повідомляючи про баг, намагайтеся писати повноцінну задачу: з кроками відтворення, можливими варіантами вирішення та описом цінності для продукту.
• Заявіть про себе. Ніхто не запропонує вам світчинг, якщо ви про це не скажете. Озвучте своє бажання менеджеру та компанії.
• Знайдіть ментора. Найближча людина — колега з продукту або компанії. Не бійтесь просити допомоги. Відвідуйте події типу DOU Day, щоб знайомитись зі спеціалістами сфери.
• Робіть більше. Виходьте за межі своєї ролі, беріть участь у кроскомандних проєктах. Що частіше вас бачитимуть у справі інші команди, то вищими будуть ваші шанси на успіх.

Корисні ресурси. Книги: «На гачку. Як створити продукт, що чіпляє», Нір Еяль, «Inspired», Марті Каган. Подкаст «Product & Growth Show», подкаст від DOU. Сайт Global Dating Insights про дейтинг-індустрію.