Ні батога, ні пряника: чим і як керує Product Manager

Product management, або управління продуктом — це відносно молода дисципліна. І на теренах України фахівців-продуктоводів донедавна практично не було, тому закономірно виникає плутанина між поняттями project manager (менеджер проекту), product manager (менеджер по продукту) і product owner.

І якщо з проектним менеджером все зрозуміло, то різниці між product manager і product owner часто не можуть пояснити навіть самі роботодавці (до речі, не тільки в Україні). Втім, ще гірше, коли вони не можуть пояснити власних очікувань від цієї позиції. Саме про це, а також про керування продуктом за відсустності керма піде мова нижче.

Але на все свій час. Для початку давайте з'єднання ясуємо, звідки виникла професія менеджера по продукту.

Походження спеціальності

Подекують, що історія бере початок ще в 1931 році, коли пан МакЕлрой — на тій годину молодший керівник однієї рекламної кампанії Procter&Gamble, а пізніше президент всієї компанії — написав замітку , в якій окреслив роль так званих бренд-менеджерів (brand man). Як маркетологи ці люди займалися виробленням та втіленням стратегії розвитку бренду. Вони тісно співпрацювали з регіональними менеджерами та продавцями і відповідали за зміст, бюджет і результат рекламних кампаній.

Хоча поняття маркетолог та менеджер з маркетингу виникли на початку ХХ століття, якщо вірити журналу Journal of Marketing , в нашому словнику вони почали з'єднання являтися тільки на початку 90-х років. Але, зрештою, краще пізно, ніж ніколи.

Що ж сталося, і чому менеджери по продукту відокремилися з маркетингу? Тому сприяло кілька чинників. По-перше, стрімкий розвиток IT-галузі в цілому та Кремнієвої долини зокрема. По-друге, впровадження системи ощадливого виробництва (lean manufacturing) Тойотою, а точніше запозичення цієї практики інженерами з Кремнієвої долини. В результаті маркетологи почали більше спілкуватися з розробниками, виступаючи в ролі голосу користувачів.

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

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

Обов'язки менеджера по продукту

Менеджер по продукту у сфері розробки програмного забезпечення знаходиться на перетині трьох вимірів: UX (user experience), технологій та бізнесу. До останнього відноситься і маркетинг в тому числі.

Щодо безпосередніх обов'язків, то нижче я спробував навести список найбільш зповсюджених активностей, які перепадають на частку менеджера по продукту:

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

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

— Аналіз конкурентів (Competitor analysis) — відслідковування нових можливостей в конкуруючих продуктах та задоволення користувачів від них. Потрібно для того, щоб запозичувати ті, що працює, і не вкладатися в ті, що не працює. Щоб розуміти потреби та вподобання користувачів і задовольняти їх краще за конкурентів.

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

— Оцінка привабливості бізнес-можливості (Business case evalution) — аналіз потенційного ефекту від нового чи поліпшеного функціоналу, приведення його до кількісних показників та порівняння із витратами на розробка. Потрібно для того, аби працювати над тім, що приносити грошову або іншу вигоду.

Приклад:розробка мобільного додатку під Windows коштуватиме $50,000. Прогнозований прибуток — $10,000. Сальдо: -$40,000.

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

Приклад:лютий 2017 — підтримка нових методів оплати. Березень 2017 — вихід кабінету користувача. В залежності від масштабів оновлення продукту можуть містити більше поліпшень.

— Планування та наповнення релізів (Release scoping and planning) — планування нових версій та наповення їх актуальним для бізнеса завданнями. Потрібно для того, щоб викладені в дорожній мапі плани втілювалися в життя.

Приклад:підтримка завантаження фото в кабінеті користувача. Можливість зробити фото для профіля за допомогою камери смартфона. Конкретні формулювання залежатимуть від обраної методології розробки.

— Формулювання вимог (Requirements elaboration) — більш детальніше-формулювання того, як має виглядати нова фіча, прецеденти користування, прототипи тощо. Потрібно для того, аби передати технічній команді своє бачення.

Приклад:співвідношення сторін фото має буту 4:3. Максимальний розмір — 5 Мб. Знов-таки, формулювання залежатимуть від методології та складу команди. Якщо в команді є бізнес-аналітик, він (вона) може деталізувати вимоги.

— Відслідковування ефективності (Performance tracking) — аналіз ключових показників (конверсія, щоденні актівні користувачі тощо) та впліву оновлень на них. Аналіз використання нових фіч. Потрібно для того, щоб упевнитись у ефективності виконаної роботи.

Приклад:зміни на екрані оплати підвищили конверсію на 2%.

— Покращення досвіду користування (user experience improvement) — аналіз запитів користувачів, відслідковування останніх тенденцій у сфері UX. Потрібно для того, аби зробити інтерфейс більш інтуїтивним, фукнціонал зрозумілим, оплату легшою.

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

— Мультиваріантне тестування та тестування зручності (Multivariate testing and usability testing) — тестування різних варіантів екрану (набір елементів та їхнє розташування) на різних групах користувачів, а також особисте спілкування з користувачами, збір зворотнього зв'язку на основі прототипів. Потрібно для того, щоб підтвердити (або спростувати) висунуту гіпотезу щодо ефективності фічі або покращення досвіду користування.

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

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

Позиція в ієрархії компанії

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

CEO (chief executive officer) — генеральний директор;
CTO (chief technical officer) — технічний директор;
CIO (chief infrastructure officer) — директор з інфраструктури;
COO (chief operating officer) — операційний директор;
CSO (chief sales officer) — директор з продаж;
CMO (chief marketing officer) — директор з маркетингу;
CFO (chief financial officer) — директор з фінансів;
Ну і CPO (chief product officer) — директор з продукту.

Усі абревіатури натякають на те, що кожен із директорів відповідає за певну вертикаль і має підлеглих. Звісно, бувають різні варіації на тему, особливо в невеликих компаніях (до 50 працівників), де різні позиції суміщаються або немає штату працівників, тобто замість CPO буде менеджер з продукту, а замість CMO — маркетолог.

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

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

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

Натомість він має абстрактну сутність (продукт), якою має керувати, і ряд обов'язків, які ми вже розглянули.

Тож як відбувається це управління? В ідеальному світі, де існують налагоджені процеси визначення і пріорітезації вимог, різні підрозділи компанії не конфліктують між собою та функціонують як єдиний організм, це виглядає приблизно так:

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

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

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

Забезпечення професійного розвитку

Що ж робити менеджеру по продукту, щоб не стати жертвою політичних інтриг?

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

До soft skills входять як базові комунікативні вміння (активно слухати, висловлювати думки, вести конструктивний діалог), так і більш продвинуті, на кшталт переконувати, розташовувати людей до собі, організовувати людей та вести за собою.

Б ' юся об заклад, що ви зустрічали людей, у яких це все виходить легко та невимушено від народження. А може, ви й самі належите до цих везунчиків. То ж знайте: мі — решта — вам заздримо і вас за це не любимо. Жартую, звісно. Хоча ні, таки трохи заздримо. Альо якщо ві не є здібним політком від природи, не засмучуйтеся, бо всі (чи майже всі) навички можна в собі розвинути, добряче попрацювавши. Як — це питання не до мене, з цього приводу написано багато книжок і складено безліч тренінгових програм.

Що ж по-одному? Навчайте та виховуйте людей навколо себе. Менеджер з продукту володіє інформацією з трьох площин, пам'ять пам'ятаєте? Бізнес, UX та технічної. Не скупіться — діліться нею з колегами: пояснюйте маркетологам та продажникам, як працює продукт, розповідайте розробникам про стратегічні цілі компанії та зміни бізнес-пріоритетів тощо.

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

Для прикладу я намалював схему подібного процесу:

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

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

P. S. На початку я також згадував про різницю між product manager і product owner. Аби не витрачати багато часу, просто зверну вашу увагу на те, що product owner — це термін, який відноситься до методології Scrum і визначає роль людини на конкретному проекті в конкретній команді. Більше того, первинні обов'язки в компанії і професійний досвід не обов'язково пов'язані з розробкою. Простіше кажучи, product owner може бути людина, яка займає будь-яку позицію в компанії, яка дозволяє їй керувати пріорітетами та допомагати з вимогами стосовно продукту.

Буду радий відповісти на запитання та, якщо буде зацікавленість, написати про щось..

Опубліковано: 31/10/16 @ 10:50
Розділ Різне

SEO Блог