Product Manager Mentorship | Записи з менторства продакт менеджера ч.6

Попередня частина була дуже давно (6.08.2021). За цей час менторства менше не стало, на відміну від бажання про нього писати.

На днях, з’явилась крута нагода продовжити серію — потрапив на менторство до Олексія (CGO Livebeam в SocialTech, у минулому — COO Keiki в Genesis) через Genesis Product Community.

Тут я в ролі учня. Можливість супер топ; перша зустріч це довела, а далі — більше.

Мої задачі на меторство

Це не якесь сво, щоб міняти їх кожен день. Тому залишу тут.

1. Виростити оберти продукту в ~2 рази.
   + Досягнути конкретних бізнес цілей;
2. Прокачатись в менеджменті і продукті.
   + Керування командою (бізнес цілі і ріст);
   + Метрики продукта. Обговорити аналітику в продукті. Почати все міряти ще більше;
   + Перейти до важливих і продуктових задач (віжн, стратегія і все таке);
   + Виростити команду (це не мета зарази мети, а органічне продовження експансії);
3. Прокачатись в комунікації і “поставити себе”.
   + Перейти (прийняти) в роль лідер і менеджер команди;
   + Я “мʼякий менеджер”, “свій пацан” — іноді мені це заважає. Хочу стати більше “поважним”;
   + Лідерство (у всіх сенсах);
4. Навчитись презентувати результати своєї роботи (на колег, на ревью, етс).

Зустріч 1: знайомство

Інтро: поговорили про наш досвід і точки інтересу в менторстві. Тобто як ми можемо о бути корисні один одному в менторстві.

Мені від Олексія цікаво дізнатись за аналітику з точки зору менеджменту, ріст продуктів в моделі маркет плейс, менеджмент і селф.

Проблема: не відчуваю себе реальним лідером команди. Не вдається досягати запланованих цілей.

Мій стиль керування (дружній, лайтовий, зелено-бірюзовий) не працює (= не є ефективним на мою думку).

Мій запит: як будувати робочі відносини в команді та з іншими менеджерами. Як змінити свій стиль, на більш “підприємницький, структурний, керуючий”. Як перейти від “ремесла” до “керування”.

Ще я розказав які у нас процеси, команда, чому саме такі.

Крос команда — робота співробітників з різних департаментів (dev, qa, anl) над конкретними окремим напрямками (продуктом).

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

Люди вільні прийти до свого керівника (ліда департаменту) і сказати: «мені тут не ок, хочу в іншу команду».

Ментор формалізував запит до:

1. Як змінити стиль менеджменту з «свій чувак» на «партнери»;
2. Як будувати горизонтальні стосунки з менеджерами інших команд (лідами dev, qa, anl, am). Це рівень N;
3. Як будувати вертикальні стосунки — всередині команди. Це рівень N-1 (умовно, тому що вони не прямі підлеглі, але певний вплив є);

Пізніше, в мене виникло питання як будувати стосунки з N+1.

1 — Як змінити стиль менеджменту?

Кожен з нас несе на собі безліч ролей. Треба вміти переключатись між ними і швидко “відстрілювати” в якій з ролей я знаходжусь зараз.

Стиль менеджменту — це стосунки з іншими: з С-лвл керівниками (N+1), колегами одного рівня управління (N, це ліди напрямків, менеджерм), та колегами з команди (N-1, це учасники / гравці команди).

Слово підлеглі мені тут взагалі не подобається, в нас “спортивна команда”, а не казарма.

Тому, теми 2 і 3 про стосунки — спойлер відповіді на це питання.

Шлях до змін один — усвідомлено міняти (будувати) свою комунікацію.

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

Мій стиль менеджменту зараз — “свій пацан” (ліберальний, трохи демократичний): я не можу наказати; мені ок домовитись; мене можна “прогнути” і “винудити” до свого рішення; для мене важливі стосунки і атмосфера в команді; я не схильний до конфронтації і конфлікту.

Я це розумів, але боявся назвати своїми іменами.

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

Опис: https://uk.wikipedia.org/wiki/Стиль_керівництва або https://www.valamis.com/hub/management-styles

якась картинка про стилі менеджменту

Стиль до якого я прагну прийти — Ілон факін Маск (ні).

2 — Як будувати горизонатльні стосунки?

Горизонтальні — це коли у нас один рівень (відповідальності).

Наприклад: dev <> dev, dev <> qa, team_1_pm <> team_2_pm.

Модель що добре працює для таких стосунків — партнерство:

• Спільна мета (= “проектна взаємодія”): у нас з тобою є задача (вигода, інтерес), ми моємо виконати її разом;
• Спільна відповідальність з фіксацією зон: ось тут ти, тут я, а тут ми разом;
• Чіткі домовленості “ти робиш а — я роблю б”;
• Прямий контакт (без посередників, без “муток”);

В термінах кольорового менеджменту — помаранчева.

Тому, мені як керівнику крос-команди, важливо почати:

1 — Будувати здорові партнерські стосунки з керівниками інших крос-команд та лідами напрямків.

Від якості цих стосунків дуже сильно залежить результат (всіх команд і бізнесу).

Як це має відбуватись:

• Регулярна синхронізація цілей: “в тебе є така ціль, в мене така. Ось тут вони співпадають. Давай зробимо це разом”.
• У нас має бути win-win і спільні цілі. Точніше, бізнес задачі в рамках яких ми партнери.
• В партнерстві ок приходити і питати як там справи, показувати своє фе, пропонувати зміни.

2 — Приділяти цьому повноцінний час.

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

З агендою: статус справ, рух до цілей (ОКР), фідбек на результати роботи працівників (це їх прямий керівник), ємоційний стан в команді, комунікація про спільні цілі та інше.

3 — Проявляти ініціативу по питаннях, які мене турбують, не влаштовують і подобаються, радують.

4 — Допомогати один-одному досягати цілей.

Хороше питання:

Чи мають бути стосунки всередині команди горизонтальними? Тобто рм, розробник, qa — всі на одному рівні.

Я отримав відповідь що ні, не мають.

Наприклад: Є фіча. Її робить ряд людей: менеджер готує бізнес вимоги і ТЗ, команда разом валідує, dev реалізує, qa тестує, аналітик знімає результат, менеджер фіксує рішення.

Ці стосунки не можуть бути горизонтальними, тому що у всіх різна відповідальність. Якщо dev відповідає за технічну частину і “якість роботи фічі”, то замовник — за конкретний бізнес результат від впровадження.

3 — Як будувати вертикальні стосунки?

В вертикальних стосунках завжди є ієрархія (вона може бути неявною) та ролі “замовник” та “виконавець” (“керівник” — “підлеглий”).

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

Я, як “виконавець” маю зрозуміти вимоги і вкласти весь свій досвід (експертизу) щоб їх реалізувати (тут ми допускаємо що в комм. все ок, вимоги ок і всі чудово роблять свою роботу).

Тому, тут можна “питати за результат”, ставити точки контролю і тд.

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

Відповідальність за це на замовнику (бо він вище в ієрархії).

Можилві 4 варіанти:

сам малював схему

• Вимоги норм, реалізація норм — все працює як треба і “транзакція в партнерствв“ успішна. Всі задоволені, рівень довіри росте і команда рухається далі.
• Вимоги норм, реалізація хуйня — питання до виконавця;
  + тут “замовник” може ставити “не зручні” питання (спочатку до виконавця, якщо це часта ситуація — до ліда) та викликати наслідки (від розмови 1–2–1 до більш серйозних штук);
  + поки до того не дійшло, варто цікавитись статусом (але не як чайка), проводити регулярні обговорення і синхронізацію (очікування співставляти);
• Вимоги хуйня, реалізація норм — питання до замовника та моменту виявлення проблем в вимогах;
  + якщо проблему в вимогах знайшли одразу — збс, внесли правки і рухаємось далі;
  + якщо з цим стикнулись під час роботи, або при тестувані — це дуже погано; про наслідки можемо не говорити;
  + на практиці це буває рідко: команда пропустила “мутні” вимоги і зробила мо ним шось добре? — звучить як сюр;
  + поки пишу, дуже дивне відчуття: виконавця за помилки “карають”, а замовника — ні, просто дають час все виправити ;)
• Вимоги хуйня, реалізація хуйня — “без зрозумілого ТЗ — результат ХЗ”.

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

Коли варто залучати 3тю сторону?

1. Говоримо 1–2–1 (замовник та виконавець) про проблему що виникла;
2. Фіксуємо домовленосіт і наступну зустріч;
3. Починаємо спостерігати і збирати факти по темі;
4. Якщо змін немає — залучаємо 3тю сторону;

Хто може бути 3ю стороною?

1. Людина, яка маю довіру від обох сторін;
2. Як правило це вищий керівник;

Ризик скотитись в дружбу

В горизонтальних стосунках він вищий.
А в вертикальних — є більш небезпечним.

Дружба для роботи створює ризики і скоріше є поганим чинником. З людини в ролі “друга” спитати за результат набагато важче ніж з “виконавця” / “гравця команди”

Як його зменшити: тут я хз.

Робота має бути на роботі, а неформальні стосунки поза нею.

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

Завів ТГ канал: https://t.me/+i5xVx0f5njdmM2Fi

Питання, пропозиції та поговорити: https://t.me/alekseisnuff