It seems sometimes that you do one thing and the other PM does something totally different from you! Then you hear another talk and see another perspective from yours again. It's so confusing, it's not clear what a product manager really does! It may even ruin your confidence that you are a true product manager.

There is no one ideal product manager, trust me;) But you can find what works best for you. There are a lot of product manager types - each type defines a list of competencies required for different jobs. That's why the first step is to review the possible product manager's types and understand what is suitable for you and brings you joy!

This is what we are going to talk about during this presentation;)

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

Чому так виходить, як пов'язаний ваш ресурс та горизонт планування та наскільки "заряджена батарейка" в середньому по галузі, розбиратимемося під час доповіді.

У процесі перших контактів із (потенційним) замовником ми часто фокусуємося на виявленні його цінностей, бізнес-цілей тощо. Цьому присвячені тисячі праць BA та PM, і більшість із них, звичайно ж, вірні та робітники. Однак, далеко не часто ми готові піти далі, взяти на себе сміливість кинути на терези сумнівів вже виявлені цінності, дати їм (об'єктивну) оцінку, наприклад, з точки зору продукту для клієнта, сміливо модифікуючи та розвиваючи їх. Поділюсь тим, що я знайшов там, «за стіною» виявлення, що виходило, а що – не дуже.

Найприкріші і найдорожчі помилки з якими я стикався у своїй практиці менеджера і які бачив у людей в своєму оточенні ставалися не через брак розуміння технологій, agile-практик або вміння працювати з певними інструментами. Найчастіше диявол криється в нюансах комунікації, розуміння ситуації і прийняття правильних рішень в умовах обмеженої інформації і часу. Як уникати таких помилок - не пишуть в підручниках і не вчать на дводенних сертифікаціях по Скраму. Зазвичай хист робити речі правильно приходить через пережиті проблеми і ескалації. Отже, я би хотів поділитись з вами своєю підбіркою із топ-10 ситуацій в роботі проектного менеджера, на які варто звернути особливу увагу. Тільки практика і реальні кейси.

Participants: Anatolii Vintsyk, Anna Mamaieva

Три ключові слова, які описують управління в компанії. Мій досвід їх поєднання в одній системі. Наскільки ми отримали синергію? І де було складніше всього?

How to build a great culture in remote environment

There was a project initially planned for 1 year which was delayed for 5 month with no confidence to run on production in the nearest few months.

In my presentation I'll share the main decisions and actions performed to deliver the project in 30 days.

Participants: Dmitriy Khudenko, Aleksandr Fedotov

7-9 crazy stories (and tips how to deal with that) about managing projects and people that happenned with me and my colleagues.

1. What is risk in change environment;
2. Risk management life cycle;
3. Practices, tools and approaches for effective risk management end to end.

Поговоримо про важливі аспекти Product Development Flow:

• Про тісний зв'язок між Теорією Черг, яку почали описувати більше ніж 100 років тому, та сучасною розробкою програмного забезпечення.
• Як знайти оптимальний batch size потоку.
• Чому фокус на ефективність може мати катастрофічні наслідки для швидкості роботи.

Фасилітація великої команди онлайн.

Як ми проводили брейнсторм та воркшопи великої команди Mobile Competency Center (>30 осіб), коли дуже мало часу. ±2 години.

Якщо ви працюєте в проектній організації, і статус відстежується за виконаними діями (або відсотком виконаних робіт), ви, ймовірно, більше орієнтовані на Output. Якщо ви плануєте результати, яких хочете досягти, і використовуєте стратегію, в якій ми можемо продовжувати перевіряти та адаптуватися до бажаного результату, незалежно від того, скільки речей ви можете відзначити в колонці Done на цьому шляху, тоді ви зосереджені на Outcome. Outcome Based Planning допомагає відповісти на питання користі для кінцевого клієнта в результаті спільної роботи команд. На доповіді я розповім про теорію OBP, ми зіграємо у квіз і я покажу практичний кейс використання OBP у великій міжнародній організації.

1. Where we started from. Environment and main issues
2. Steps taken and reaction. Success and failures
3. Developing the right habit. It's not just for Scrum team but for Scrum Extended one.
4. 2 years since the experiment start, what helps stick to the right behaviour?
5. Additional material and how to get started changing the culture

У цій доповіді я хочу поділитися:

• Різниця між роботою "багатьма командами Scrum" і "багато-командним Scrum"
• Що таке Продукт, а що ні? Чому LeSS рекомендує використовувати ширше визначення продукту
• Чому Feature Teams, а як щодо спеціалізації розробників? А як щодо залежностей?
• Хто є справжнім Власником Продукту і що він повинен робити?
• І як завжди кілька історій, метафор та жартів :)

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

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

We will take a deep dive into the thought process behind defining what is a "high performing" team, and will explore the KPI's that contribute to building and developing a high performance culture.

MVP та "бойова" архітектура продукту; як уникнути "роботи до столу" проектуючи складні системи? скільки коштують помилки на старті, через декілька років?

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

Розповім про підходи, які допоможуть завоювати світ бізнесу та зробити його кращим ;)

У ході роботи (і не тільки) нам всім часто доводиться візуалізувати дані — поділитися досягненнями компанії з командою на All Hands, закрити корпоративну роботу або побудувати дашборд для простого юзера. За допомогою грамотної візуалізації можна чітко і ясно донести факти, аргументи, ідеї.

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

Zero-coding дозволяє будувати продукти без коду або з мінімальним його використанням: від сайтів до мобільних додатків.

Перегави підходу у валідації гіпотез та створення MVP у найшвидший та найдешевший спосіб. Це дозволяє зрозуміти: чи варто витрачати гроші, час, та наймати технічну команду для повноцінної розробки?