Від розробника до продакт-менеджера: які скіли потрібні та як їх отримати

Мене звати Денис Латиш, я продакт-менеджер EdTech стартапу Headway. До ІТ прийшов шість років тому на позицію розробника. Світчинг із цієї сфери в продакт-менеджмент здається квантовим стрибком: ти звик днями з музикою в навушниках працювати над кодом, а тут потрібно генерувати та тестувати гіпотези і глибоко вивчати поведінку та потреби користувачів. Мій перехід з однієї сфери в іншу був органічним завдяки двом «зупинкам» на позиціях тимліда та продакт-оунера.

У цій колонці я розповім про досвід світчингу, які хард- і софт-скіли опановував, якi помилки робив та як вони допомагали мені рухатися далі. Матеріал буде корисним розробникам, які цікавляться світчингом у продакт-менеджмент.

Точки А-B: від розробника до тимліда

Мій шлях у розробці розпочався з позиції Python Back-end Developer та роботи над функціональною складовою IPTV платформи інтернет та ТВ-провайдера. Згодом працював в іншій компанії над продуктом, пов’язаним із розумним репрайсингом. Це SaaS-продукт, який дає ритейлерам та вендорам рекомендації щодо ціноутворення. Коли компанія почала рости, я став тимлідом невеликої команди розробників. Основним завданням було збирати дані, робити це якісно, ​​швидко та перманентно. Саме тоді я вперше почав фокусуватися на менеджменті команди та стежити за бізнес-метриками.

Спочатку поєднував ролі розробника та тимліда 50 % на 50 %. Згодом сфокусувався на менеджменті команди, операційних процесах та продуктових показниках. Частиною роботи був аналіз проблемних чи вузьких місць у роботі: неправильне планування, затягування термінів, відсутність бажаних результатів, мало ітерацій. Так запити від клієнтів могли висіти кілька днів без реакцій, або ми місяцями розробляли якусь фічу, яка потім виявилася непотрібною. Це впливало на командні метрики. Тому для мене було цікавим челенджем впровадити певні крос-командні процеси, прокачати управлінські й комунікаційні навички, а також вміння пояснювати завдання та цілі, аргументувати навіщо й чому вони важливі.

Нові обов’язки, що з’явилися на позиції тимліда:

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

Ключові навички, що необхідні на позиції:

• people-management;
• комунікаційні навички: уміння слухати, домовлятися;
• проактивність — не чекати на завдання, а брати відповідальність за результат;
• вміння чітко пріоритизувати завдання;
• презентація та аргументація ідей.

Книги, які допомогли з новими викликами на цьому етапі:

• «Deadline. Роман про управління проєктами», Том Демарко;
• «Scrum. Навчись робити вдвічі більше за менший час», Джефф Сазерленд;
• «Як завойовувати друзів і впливати на людей», Дейл Карнегі;
• «Коучинг-лідерство», Майкл Бенгей Стейнер;
• «Історії про життя, смерть і нейрохірургію», Генрі Марш.

Точки B-C: від тимліда до продакт-оунера

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

Умовно ці позиції можна розділити так:

Продакт-оунер — роль із методології Scrum, що відповідає за беклог продукту.

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

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

Як було в мене: компанія та продукт розвивалися, разом із нею змінювалася і стратегія, розширювалася зона відповідальності тимліда. І за півтора роки я став продакт-оунером однієї з трьох частин продукту — Data Delivery у продукті Competitive Data.

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

Один із нових викликів для продакт-оунера — відповідальність за продуктові показники та фінансовий результат. Тут знадобиться вміння об’єднувати команду навколо спільних цілей, і здатність сприймати проєкти цілісно, а не лише на рівні окремих завдань.

Нові обов’язки, які з’явилися на позиції продакт-оунера:

• забезпечення якості, рентабельності та постійного покращення частини продукту, за яку я відповідав;
• ведення backlog продукту: визначення epics, декомпозиція user story, уточнення та пріоритизація завдань для команди;
• менеджмент команди розробки;
• синхронізація з іншими командами;
• бути «мостом» між Head of Product та іншими стейкхолдерами та командою;
• дотримання балансу між бізнес-вимогами, цінністю, технічними можливостями та стійкістю продукту.

Ключові навички, що необхідні на позиції:

• тайм-менеджмент;
• стратегічне мислення;
• комунікація;
• project-management.

Книги, які допомогли з новими викликами на цьому етапі:

• «Наснага. Побудувати культуру свободи та відповідальності за результат», Петті Мак-Корд;
• «Доставка щастя. Шлях до прибутку, задоволення і мрії», Тоні Шей;
• «Запитай маму. Як спілкуватися з клієнтами та підтвердити правоту своєї бізнес-ідеї, якщо всі навколо брешуть?», Роб Фітцпатрік;
• «На гачку. Як створювати продукти, що формують звички», Нір Еяль, Райан Хувер;
• «Натхненні. Усе, що потрібно знати продакт-менеджеру», Марті Каган.

Точки C-D: від продакт-оунера до продакт-менеджера

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

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

1. У сфері дизайну вивчав створення мокапів, веб- та мобільних прототипів, а також із якими інструментами працює дизайнер, на що звертає увагу. Ці знання дали змогу говорити з ним однією мовою.
2. Що стосується роботи з користувачами: необхідно було розібратися з побудовою Customer Journey Map, проведенням різних видів інтерв’ю, створювати юзер-персони тощо.
3. В аналітиці я працював з амплітудою, google-аналітикою, побудовою воронок. На цій позиції важливо розуміти юніт-економіку продукту, який ти створюєш та випускаєш на ринок.

Нові обов’язки, що виникли на позиції продакт-менеджера:

• розробка нових продуктів;
• створення та перевірка продуктових гіпотез;
• проведення та аналіз A/B-тестів;
• робота з даними та продуктова аналітика;
• аналіз ринку та конкурентів;
• пошук точок зростання для бізнесу.

Ключові навички, що необхідні на позиції:

• продуктове мислення;
• знання основ дизайну;
• знання аналітики;
• розуміння юніт-економіки;
• основи маркетингу.

Книжки, які допомогли на цьому етапі:

• «Бізнес із нуля. Метод Lean Startup для швидкого тестування ідей та вибору бізнес-моделі», Ерік Райз;
• «Чотири кроки до осяяння. Стратегії створення успішних стартапів», Стів Бланк;
• «Як створити продукт, який куплятимуть. Метод Lean Customer Development», Сінді Альварес;
• «Спринт. Вирішуйте складні завдання та тестуйте нові ідеї за 5 днів», Джейк Кнапп, Джон Зерацьки, Брейден Ковіц.

Три помилки, які гальмують перехід

1. Відсутність критичного мислення до власних ідей

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

Втілюючи будь-яку ідею, потрібно перевірити її на чотири гіпотези:

• value — яку цінність створює/потребу задовольняє для користувача;
• usability — чи буде зручно це для користувача, тому що можна зіпсувати класний продукт жахливим дизайном та незрозумілим інтерфейсом;
• feasibility — чи реально це створити, сконструювати та запустити;
• business — чи потрібна ця ідея бізнесу, чи поліпшить продуктові чи фінансові метрики;

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

2. Невміння презентувати ідеї

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

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

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

3. Невміння абстрагуватися від бажань користувача

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

Дотримання балансу в діалозі з користувачем допомагає поглянути на проблему з іншого боку, додати контекст та розширити сферу використання продукту.

Як зрозуміти, що настав час

Найважливіше питання, яке я собі поставив — не «звідки», «куди», «коли», а «навіщо». Потрібно розуміти, навіщо світчитися на роль продакт-менеджера. Якщо більше драйвить розробити швидкий, якісний і масштабований код, це більше про engineering skill. І це чудово: можна й далі розвиватися в цій сфері, і не змінювати напрям. Це одна з найважливіших частин роботи над продуктом.

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