Привіт,
Вітаю на каналі kostrub.online!
Сьогодні я хочу поговорити про таку уже досить популярну професію, яка, як на мене, активно набирала оберти останній декілька років - Product Manager (менеджер продукту) в ІТ.
Наразі сама працюю на цій позиції і чесно зізнаюся, — просто обожнюю те чим займаюся. Сьогодні я розкажу як прийшла до цього, що знадобилося аби почати кар’єру в цьому напрямку (через те, що по суті у мене інша спеціальність), які бувають менеджери у відділі розробки, в чому їх різниця, як воно працювати продактом в різних країнах, а також як проходить співбесіда на цю роль в інтернаціональній компанії?
В кінці статті я поділюся практичними прикладами задач, які траплялися особисто мені на етапі інтерв'ю.
Отож погнали....
По-перше, раніше ця професія була не настільки популярна як, скажімо зараз.
По-друге, менеджери буваю дуже різні і їх обов’язки можуть дуже сильно відрізнятися (я зараз не про sales, а про менеджерів у відділі розробки).
Бувають:
- project managers
- program managers
- delivery managers
- product managers, які в свою чергу поділяються на technical and marketing managers.
По-третє: мій досвід, досвід моїх колег та загальні спостереження кажуть про те що, в університетах немає виділеної конкретної спеціалізації, яка навчає продакт менеджменту. Тому часто в цю професію приходять з абсолютно неочікуваним бекграундом: від технарів до гуманітаріїв (в залежності від ролі).
Дуже коротко про себе і свій досвід.
Навчалася я в політехнічному університеті і маю технічну освіту.
Спеціальність — автоматизоване управління технологічними процесами. Тобто, на папері я інженер-автоматизатор! Паралельно на заочному відділенні здобувала освіту на факультеті маркетингу.
Як і думаю більшість людей, я майже не працювала напряму за спеціальністю.
Основний фокус моєї професії — налаштування, запуск та програмування контролерів, які керують такими системами як, наприклад, система контролю температур, кондиціонування та вентиляції. Тобто, це не зовсім класичний софт, до якого всі звикли в ІТ.
Програмування у нас було, але я ніколи не була фанатом написання коду.
Тому в Україні моя перша серйозна робота була зв’язана більше з маркетингом, аніж з моєю основною освітою.
Я почала працювати у відділі продажів реклами в одному тревел-журналі на позиції менеджера продажів.
Була я там досить довго: як виявилося комунікація, робота з клієнтами - це те що в мене виходить досить непогано.
Але з часом мене не покидала думка про ІТ, тому що бачила і кар’єрну перспективу і фінансову перспективу саме в цій сфері.
Тому через деякий час я почала моніторити вакансії — і уже досить скоро почала працювати у відділі підтримки продажів в продуктовій ІТ компанії.
Через деякий час, в тій же компанія я стала Account manager.
Мої основні зони відповідальності були:
- продаж софту
- робота з корпоративними клієнтами (b2b маркет)
До розробки продукту я по суті не мала ніякого відношення.
Primary skill (основна необхідна навичка) - це було:
- вміння переконувати
- продавати та спілкуватися з клієнтом на такому рівні аби забезпечити гладкий процес комунікації, підписання договору та імплементації продукту.
Але моя технічна освіта не давала мені спокою і мені з часом захотілося не просто продавати, але й бути частиною розробки програмного забезпечення.
Тому після переїзду в штати (стаття про те чому і як ми туди переїхали тут) було прийнято рішення, мені час перекваліфікуватися, тому що продавати софт людям з абсолютно іншим менталітетом та ще й англійською (яка була на рівні розмовної, але бажала бути кращою) - це був ще той виклик.
Переїхали ми в Каліфорнію, а якщо точно в Кремнієву долину — місце де створюються всі технології, функціонують найбільш відомі корпорації світу, кожен метр просочений стартап атмосферою, - тому тут якби гріх не почати саме тех кар’єру.
І я почала можна сказати з нуля!
Відразу стала копатися в ролях аби зрозуміти на якому етапі життєвого циклу продукту я можу застосувати свої вміння.
Життєвий цикл продукту — це перше, на що я рекомендую звернути увагу людям, що хочуть побудувати кар'єру в ІТ.
Ви повинні розуміти весь процес аби мати уявлення про те як створюється продукт та скільки різних ролей над ним працює (основні ролі в ІТ також уже описані у статті).
Після досить поверхневого аналізу, я, якби банально це не звучало, вирішила що “вайті в айті” я зможу лише як тестер.
Чомусь цей шлях мені здався найлогічнішим і найлегшим, тому що програмістом я себе не бачила, інші ролі я толком не розуміла, а тестування здалось більш менш зрозумілим з точки зору обов’язків.
Процес навчання на QA:
Я прочитала декілька базових книг:
- "Testing Computer Software", Cem Kaner
- "Lessons Learned in Software Testing", Cem Kaner
- "Code Complete", 2nd Edition, Steve McConnell
- "Software Testing Techniques", Boris Beizner
Поговорила зі своїми знайомими QA, вони в свою чергу порекомендували мені онлайн курси.
Пройшла досить великий цикл задач на coursera.org. Взяла собі 3 модулі:
- Quality Assurance course
- Sofware testing course
- Control Quality
При щоденному навчанні я витратила на це декілька місяців.
Зробила резюме і відразу почала бомбити резюме в різні компанії.
Але у відповідь — тиша.
Мені не те щоб відмовляли, зі мною не зв'язувалися навіть рекрутери. Тому я сотні разів переробляла резюме, почала прокачувати Linkedin і зв'язуватися з рекрутерами сама, але все одно далі phone screening я не особливо просувалася.
Паралельно підступав відчай, тому мій чоловік порекомендував мені розглянути на всякий випадок інші ролі - наприклад scrum master.
Scrum Master
Варіант здався цікавим, і поки рекрутери мовчали, я почала вивчати agile методології.
Пройшла знову ж таки декілька книг:
- "The Scrum Guide" Ken Schwaber and Jeff Sutherland
- Маніфест - agilemanifesto.org
- "Getting started with Agile: Succeeding with Agile" Mike Cohn
- "Scrum: The Art of Doing Twice the Work in Half the Time" Jeff Sutherland
Подивилася відео курси, почала ходити на мітапи на цю тему (в долині їх купа) і дізналася про те що скрам майстер може пройти сертифікацію.
https://www.scrum.org/ - один з найбільш популярних ресурсів.
Там можна пройти сам процес навчання, а потім складати екзамен і отримати сертифікат.
Крім нього є купа інших ресурсів та шкіл які готують до сертифікації. Можете глянути в інтернеті.
Короче кажучи, підготувала я ще одне резюме і, паралельно з резюме в якому я QA, я почала відправляти резюме де я скрам майстер.
Але все одно job offer не наближався.
Мені не вистачало практичного досвіду. Ніби в теорії я багато розумію, але на практиці після інтерв'ю мені казали одне: “ми вам передзвонимо!”
В той момент, мені так сильно хотілося на роботу, що я вирішила — раз мене не беруть із-за нестачі реального досвіду, треба створити свій продукт і почати свій проєкт для того щоб його отримати!
Тому разом зі своїм чоловіком розробником ми почали писати свій стартапчик.
Головна задача, яку я поставила перед собою — навчитися на практиці створювати софт.
До речі всі знання які я отримала в процесі підготовки до ролі QA та Scrum Master - були реально супер корисними (можливо вони стали ключовими для отримання фінальної ролі)
В процесі брейншторму, обговорення ідей та плану реалізації - довелося прочитати про стратегії розвитку, про аналіз даних, про аналітику, про процес імплементації та запуску. Та і маркетинг не на останньому місці.
З цим проєктом ми навіть брали участь в Y combinator. Це супер відомий в долині інкубатор стартапів, який у випадку якщо ідея класна виділяють гроші та ресурси на реалізацію (інвестиції ми не отримали, але було реально круто). Це просто нереальний досвід.
Ми пройшли навчання в школі, поспілкувалися з купою розумних людей, знайшли нові професійні знайомства.
На презентаціях їли буріто просто разом з засновниками інкубатора (в долині це нормальна практика), говорили з засновником Pinterest, та тех. директором Майкрософт.
Після цього досвіду я чітко зрозуміла хто я в ланцюжку розробки софта.
Хочу бути Product Manager і ніким іншим.
Мітапи, конференції та Y Combinator дали свої плоди і мене нарешті почали запрошувати на співбесіди.
Я навіть проходила співбесіду в facebook, але на жаль отримала відмову перед останнім етапом.
Паралельно у мене був запущений процес інтерв’ю в іншу (трошки меншу) продуктову компанію, які врешті решт дали мені оффер на позицію product manager. Хоча попрацювати там мені не судилося, тому що процес був занадто довгим — і ми вже прийняли рішення переїздити в Європу (про те чому саме є стаття).
Зате по приїзду в Берлін, у мене вже було чітке розуміння того чим я тут буду займатися. Плюс у мене був досвід співбесід та реальний досвід роботи на реальному продукті.
Тому після отримання робочих документів, я почала відправляти резюме.
Чесно скажу, отримала багато відмов. Пройшла понад 40 інтерв'ю допоки мене запросили на роботу. Весь процес пошуків зайняв 3 місяці, в порівнянні з попереднім досвідом не так і багато.
Отже, хто такий product manager і які основні етапи середньостатистичної співбесіди на цю роль?
Штука в тому що навіть якщо зараз ви запитаєте команду продактів, що робить Product manager, я більш ніж впевнена, що ви отримаєте багато дуже різних версій.
Так що робить продакт менеджер? - Правда в тому що чітку відповідь дати досить складно.
Воронка обов'язків продакта — вона досить складна і на це є 3 причини.
- У 2012 році Ben Horowitz сказав що product manager це CEO продукту і це стандартним визначенням на багато років вперед. Тому в обов'язки входило все починаючи від:
- Мотивації команди
- До визначення та вирішення проблем споживачів
- Друга причина це team culture (культура команди)
- Тут спочатку потрібно відповісти на запитання яким чином команда робить свою роботу. Тому що процес та підхід дуже сильно відрізняється в залежності якраз таки від команди та компанії.
- Наприклад: в маленькій компанії, продакт повинен зробити все щоб робота була виконана, тобто покрити всі етапи від аналізу ринку, розробки імплементації та аналітики результатів.
- Тоді як у великій компанії є окремі команди які займаються лише research (аналізом).
Отже, в залежності від того маленька чи велика організація, задача продакта вміти бути навігатором серед всіх цих підходів компанії, вміти пріорітизувати, тримати баланс між потребами бізнесу та користувачів і тим самим досягати створення успішного продукту.
- Ну і третя причина яка створює додаткові питання це власне обов'язки.
- Одне з питань яке виникає в процесі — визначення що робить product manager і product owner?
- PM відповідальний за:
- Mission - місію
- Vision - бачення
- High level problems - високорівневі задачі
- How success looks like - як виглядатиме успіх
- В той час PO бере mission and vision і транслюю їх (дробить) на щоденні задачі:
- Визначає вимоги
- Перекладає їх на stories (задачі)
- Та менеджерить беклог
Також інша штука яка теж впливає на вимоги до продакта це:
Відома діаграма Мартіна Еріксона ->
Поєднання:
- User experience
- Технологій
- Бізнесу
По його теорії - продакт знаходиться посередині.
Так що це означає?
Діаграма каже про те, що повинен бути хтось хто працює між трьома різними департаментами.
І в реальності одна з активностей яку повинен робити продакт щодня дуже складна, тому що потрібно постійно приймати рішення, які допоможуть тримати баланс між
User experience, технологіями - тобто бути впевненим, що ми можемо це зробимо і це реально точки зору реалізації... ну і в той самий час задовольняти бізнес вимоги.
Якщо підсумувати, то продакт менеджер відповідальний за продукт та його успіх.
Він мусить вміти правильно донести ідею та контекст до команди та бути сильним лідером в прийнятті рішень.
В продакт менеджменті немає білого та чорного, тому що обов'язки та задачі можуть змінюватися в залежності від багатьох факторів, починаючи від специфіки продукту закінчуючи розміром компанії.
Тому і бувають більш тех орієнтовані продакти, які не пишуть код, але верхньорівнево розбираються в ньому (часто це колишні програмісти чи автоматизатори).
Є більш бізнес орієнтовані продакти (часто це аналітики чи бізнесмени в минулому, чи люди які просто розуміють специфіку конкретного бізнесу та мають в ній експертизу) або ж продакти фокусом яких є маркетинг на промоушен.
Тобто як бачите, в цю професію можна прийти з абсолютно різними базами.
А тепер про процес інтерв'ю.
Він може відрізнятися від компанії до компанії, а також від фокуса ролі - чи то тех чи то бізнес, але в цілому структура співбесіди схожа.
Основні етапи які я виділила на власному досвіді (а я пройшло їх цілу купу, тому уявлення у мене є)
Як і для будь-якої іншої ролі в ІТ:
Етап 1
- Після відправлення резюме з вами зв'язується рекрутер і проводить phone screening.
Етап 2
- Тест або задача-задачі (іноді їх декілька) онлайн на які виділяється певний час (ви наперед букаєте слот коли вам зручно почати і рекрутер активує посилання на цей конкретний час).
- Якщо цей assessment ви пройшли, то вас або відразу запрошуються в офіс або ж з вами зв'язується hiring manager і ставить уточнюючі питання по assessment, просить аргументувати ваші припущення (це буває не дуже часто).
Етап 3
- Інтерв'ю в офісі.
1. Деякі компанії наперед презентують вам якусь проблему і ваша задача підготувати презентацію про продукт який вирішить цю проблему. Приїхавши в офіс вам дається час на презентацію перед аудиторією. Це hiring manager та інші продакти, які після презентації задають запитання.
2. Або ж вас відразу запрошують в офіс без завдання та інтерв'ю складається з декількох раундів з різними продактами (іноді запрошують дизайнерів та скрам майстра якщо такий є).
В основному питання на виявлення:
- Problem solving skills - як ви вирішуєте проблеми.
- Питання про процес розробки та життєвий цикл продукту, а також які підходи краще використовувати з такими чи такими вхідними даними.
- Як ви працюєте з запереченнями і приймаєте рішення.
- І також питання про те як працює якийсь конкретний продукт (це може бути супер відомий продукт як наприклад google docs, spotify, uber і тд), яка по вашому там архітектура або які фічі ви б могли запропонувати для його покращення.
Відразу скажу, ці питання не мають правильних відповідей - вони розраховані на те щоб подивитися як ви мислите.
Якщо це співбесіда в корпорацію будьте певні, що будуть питання на основі принципів компанії.
Етап 4
- Якщо ви пройшли цей етап - то знову ж таки в залежності від розміру компанії може бути ще один кол чи зустріч з CTO та CEO (коли компанія дуже велика - цього етапу немає) де вони просто хочуть з вами познайомитися і зрозуміти просто хто ви.
Етап 5
- Ну і офер :)
Через те, що я проходила співбесіду в Німеччині я дуже переживала з приводу того чи буде проблемою те що я не розмовляю німецькою?
Так от, як показує практика, це не дуже велика проблема.
Я встигла попрацювати уже в 2-х різних компаніях, обидві німецькі - але і там і там офіційна мова англійська.
Хоча на теперішньому місці роботи, якщо для роботи з командою та інженерами німецька не потрібна взагалі, бо команда супер інтернаціональна (в першій компанії було біля 40 різних національностей, в теперішній трішки менше, але все одно багато) - то з клієнтами часто мова потрібна (так що я вчу).
Тому знання німецької будуть для вас великим плюсом, але не стануть критичним в прийнятті рішення брати вас на роботу чи ні (принаймні у великих інтернаціональних компаніях), якщо у вас є релевантний досвід.
Щодо оформлення, оскільки ми переїздили по контракту чоловіка - у мене не було проблем з документами. По приїзду, мені як дружині, видали національну візу, що дозволяє проживати та офіційно працювати в країні.
Якби ж документів на роботу не було - я могла б на загальних основах оформити blue card.
Для цього потрібна вища освіта, диплом переведений на німецьку та підписаний контракт з німецькою компанією (про набір документів я розказала тут)
Якщо вам цікаво отримати список запитань, які особисто я отримувала під час співбесід на продакта в Німеччині, пишіть в коментарях “Хочу список питань (interview questions)”, я підготую word чи excel файл і поділюся ним з вами.
Всі свої питання про процес теж задавайте в коментарях, я з радістю відповім!
Якщо ви вже працюєте на позиції продакта і маєте бажання поділитися власним досвідом - буду рада поспілкуватися ближче!
Відео:
Підписуйтесь на канал, тому що далі буде!
0 Коментарі