«Від того, що ти сам це вигадав та створив — море кайфу»: чи може розробник стати продакт-менеджером (і навіщо йому це)

Головні ролі у будь-якому проєкті відіграють архітектор та менеджер продукту.

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

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

Звідки беруться менеджери продукту? Хто може ним стати? Може, колишній провідний розробник? Спробуймо розібратися.

Хто такий продакт-менеджер

Менеджер продукту по функціоналу перетинається з іншими ролями на проєкті. Найчастіше він виконує завдання керівника проєкту. І може робити щось до і після цього.

Ось короткий опис його обов’язків:

1. Аналізує, що може знадобитися користувачам, та досліджує ринок. Вигадує ідеї нових проєктів та виставляє пріоритетність.
2. Спільно з командою розробки обирає технічне рішення.
3. Прораховує економіку продукту та визначає, чи варто цим займатися.
4. Збирає робочу групу, ставить завдання архітекторам та іншим ключовим особам проєкту.
5. Слідкує за всім-всім щодо організації, відповідає за взаємодію з партнерами та вендорами.
6. Після впровадження супроводжує продукт, займається його розвитком та удосконаленням мінімум рік.
7. Іноді прокидається вночі з палаючими очима та ідеєю нового продукту.

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

Найкрутіше в такій роботі — це разом із класною командою робити масштабні проєкти, які злетять. Це почуття окрилює. Але й проблем у роботі чимало.

Важливо: тут і далі ми говоримо про роботу менеджера продуктів у сервісі, а не в розробці ПЗ. Це дуже різні обов’язки та завдання.

Як стають менеджерами продукту?

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

Насправді, у 98% випадків на продакта треба вчитися. Менеджером продукту може стати керівник проєкту, тимлід, інженер, рідко — маркетолог.

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

Справа в тому, що ним не потрібно керувати. Це керівник команди, який вміє сам знаходити собі роботу, обґрунтовувати її вигоду для компанії та сам її виконує. Тобто це той, хто рухає бізнес вперед. Звичайно, йому даються для цього ресурси.

Пошук ідеї

Є стратегія компанії, є ринок, є всі ресурси компанії (як матеріальні, так і у вигляді знань та зв’язків) та можна рухати гори. При певній розумовій напрузі 🙂 Тому перше, що робить продакт — це аналізує можливі напрями «куди копати».

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

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

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

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

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

Джерела появи продукту зазвичай це:

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

Захист ідеї

Ідею мало знайти, треба її захистити. Тобто «приземлити» та монетизувати (треба чітко розуміти, як це продавати і кому):

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

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

У підготовці бізнес-кейсу найскладніше — спрогнозувати доходи.

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

Наприклад, є багато PaaS- та SaaS-сервісів. Міні-проєкт може мати такий вигляд: є потреба в об’єктному сховищі з повною підтримкою Amazon S3 API — скільки клієнтів перейде? Зробили оцінку, запросили — почали користуватися.

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

Реалізація

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

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

Далі запускається тестування перед прийманням.

Після приймання

Після приймання продакт проводить навчання для продавців та всім пояснює:

• що за ідея;
• кому потрібна;
• чому крута;
• як продати.

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

Продакт-менеджер їздить на продаж. Перші рази дивиться, що і як. Отримує зворотний зв’язок: як продається, що виправити, як продукт зустрічається з реальним світом. Не можна просто взяти та відправити продукт у вільне плавання.

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

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

Складнощі у роботі продакта

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

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

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

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

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

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

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

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

Буває й кумедне: «А хто вендор? Петренко? Він нашого CSO у школі бив, працювати не будемо». Бувають речі на кшталт «не використовуємо бездротові мережі» , «не працюємо з вендрами на “М”» тощо.

Як оцінюють продакт-менеджера?

• За термінами запуску сервісу. Якщо вчасно не вивести на ринок, компанія зазнає прямих чи непрямих збитків.
• За доходом після запуску товару. Після запуску продакт моніторить продаж та вирішує питання. Якщо не досягається плановий дохід, з’ясовує чому це відбувається (у маркетологів може бути свій план або вони можуть не продати, або саме просування продукту поставлено погано). Якщо проблема у продукті, складається план доопрацювань.
• За ціноутворенням: тарифам, маржинальністю товару.
• Формування метрик SLAService Level Agreement — документ з регламентом рівня обслуговування, який постачальник послуг зобов'язується надати замовнику..

• За якістю ідей нових продуктів. Точніше, ідеї самі по собі нікому не потрібні — за якістю, спочатку, прорахунків та захисту, а потім — реалізації.

Замість висновку

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

Після продакт-менеджера можна стати:

• керівником підрозділу;
• директором портфелю продуктів;
• директором з розвитку бізнесу;
• консультантом;
• бізнесменом.

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