Нову стратегію підтримали не всі. AI-ініціативу саботують. Архітектор просить ще два квартали. Маркетинг хоче запуск уже наступного тижня. Знайомо? Проблема в тому, що ми часто очікуємо від інших людей тієї ж логіки, яку маємо самі. Але у продуктовому бізнесі поруч працюють різні “види”: ті, хто захищають людей; ті, хто захищають експерименти; ті, хто захищають стабільність; ті, хто захищають результат. І поки ми не навчимося бачити ці відмінності, будь-яка стратегія ризикує залишитися красивим слайдом. На прикладах із продуктових команд та AI-трансформацій розберемо, як працює фреймворк конкуруючих цінностей і як використовувати його для впливу, переговорів та управління змінами. 📌 Ключові тези: Кожен стейкхолдер захищає раціональну для себе цінність. “Кожен правий — але частково”. Як читати мотиви за словами та запереченнями. Чому найсильніші продакти вміють перемикати мови впливу. Як зменшувати опір змінам без тиску. Як створювати підтримку навколо продуктових рішень.

AI уже став частиною сучасної engineering-реальності, але в production highload-системах усе значно складніше. GenAI добре працює в демо та copilots, проте чи готовий він до real-time processing, великих навантажень і критичних production-сценаріїв? На панельній дискусії поговоримо про те, чому AI досі майже не став стандартом для highload-архітектур, де проходить межа між ML та GenAI, чому inference коштує дорого, а FinOps стає новим болем engineering-команд. Обговоримо on-prem vs cloud для AI workloads, реальні production-обмеження.

Практико-орієнтована архітектурна доповідь про інтеграцію AI-агента в операційний workflow highload data pipeline. Розглянемо сценарій каскадного збою: у пайплайн потрапляють пошкоджені дані, зависають черги Kafka, зростає навантаження на storage, тисячі Kubernetes pod’ів починають падати та пересоздаватися, деградує etcd, а PostgreSQL стає додатковою точкою навантаження. Також покажемо, як AI-агент, побудований на базі AWS Bedrock AgentCore, LangChain та MCP/Gateway, може виявляти ранні сигнали інцидентів, ізолювати corrupted messages, пропонувати human-approved remediation steps, захищати стабільність кластера та перетворювати noisy telemetry на конкретні кроки для відновлення системи.

Ще вчора AI був просто “помічником”, а сьогодні — впливає на найм, зарплати, кар’єрний ріст і саму роль developer-а. Junior-позиції зникають, code generation стає дешевшим, а компанії все частіше оцінюють не роки досвіду, а швидкість адаптації та вміння працювати з AI. На панельній дискусії поговоримо без рожевих окулярів: чи справді AI забирає роботу, чому senior-досвід більше не гарантує перевагу, хто виграє в новій AI-гонці — engineers чи prompt-native спеціалісти — та чи не перетворюється software engineering на зовсім іншу професію. Обговоримо, що буде цінуватись у developer-а через 2–3 роки, чи стане middle новим junior та чи встигає український IT-ринок адаптуватися до змін швидше за світ.

Що варто делегувати AI вже зараз, а що все ще потребує людини? На прикладі стрімінгового продукту поговоримо, як за допомогою AI-copilots оптимізувати QA-командам технічну рутину, масштабувати тестування, пришвидшувати релізи та залишати людям простір для дослідження продукту, UX і складних користувацьких сценаріїв

Більшість систем починаються з push, бо це здається природним — сервер знає, коли щось змінилось, і одразу повідомляє клієнтів. Але у масштабі push містить прихований множник витрат: підключені користувачі × відкриті об'єкти × частота оновлень. Кожна мілісекунда свіжості даних оплачується кожним підключеним користувачем — навіть тим, хто не дивиться на екран. Доповідь побудована на реальному production-кейсі у DraftKings. Розглянемо, як модель доставки даних визначає форму кривої витрат, а не лише профіль затримок. Пройдемо: — оригінальну push-систему та те, як вона накопичувала складність роками — точки болю при масштабуванні, які зробили її нежиттєздатною під піковим навантаженням — процес оцінки альтернатив, який привів до short polling — стратегію міграції без downtime у чотири фази Результати виявились контрінтуїтивними: pull-архітектура з коротким polling-ом показала кращу актуальність даних під піковим навантаженням при суттєвому зниженні споживання CPU та витрат на інфраструктуру. Доповідь завершується практичним фреймворком: коли обирати push, коли pull, і яке питання поставити першим.

Комунікація - одна з ключових навичок product-менеджера, яка напряму впливає на якість рішень, швидкість команди, довіру стейкхолдерів і карʼєрне зростання. Часто її сприймають як щось очевидне: ми всі щодня пишемо повідомлення, проводимо зустрічі, пояснюємо задачі, даємо фідбек і домовляємося з людьми. Через це багатьом здається, що з комунікацією в них усе добре. На практиці саме в комунікації часто ховаються найбільші втрати: нечіткі очікування, погано сформульований фідбек, зайві конфлікти, розмиті домовленості, рішення без buy-in та відчуття, що команда «не так зрозуміла». Для product-менеджера це особливо критично, бо його робота значною мірою тримається на здатності пояснювати, слухати, узгоджувати, впливати й допомагати іншим рухатися в одному напрямку. У доповіді Рей розбере, як виглядає сильна комунікація в product-менеджменті: як оцінювати власний рівень чесніше, де найчастіше виникають помилки, як говорити складні речі простими словами, та як давати фідбек так, щоб він справді допомагав людині й команді ставати сильнішими.

У цій доповіді ми розглянемо практичний кейс впровадження ефективного автоскейлінгу інфраструктури з використанням HPA, VPA та Cluster Autoscaler. Працюючи зі стандартним VPA, ми зіткнулися з обмеженнями: нестачею гнучкості в налаштуванні інтервалів обчислення та конфліктами при одночасній роботі з HPA. Тому ми вирішили створити власний кастомний VPA-контролер. У новому рішенні ми: - Забезпечили коректну спільну роботу VPA та HPA на одних і тих самих ресурсах. - Реалізували механізм фільтрації короткочасних піків CPU на етапі запуску подів. - Оптимізували архітектуру: об'єднали функціонал трьох стандартних компонентів у єдиний под. - Використали нові можливості In-Place Pod Resize, які з'явилися у Kubernetes 1.33. Головний результат: оптимізація споживання ресурсів та зменшення вартості інфраструктури на 20–40%.

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

Про що: - Які growth-челенджі визначатимуть 2026 рік. - Як AI змінює швидкість запуску MVP і продуктових експериментів — і чому швидкість без стратегічного фокуса не створює sustainable growth. - Чому для масштабування вже недостатньо CRO та performance-маркетингу. - Як використовувати AI для research, прототипування, продуктових драфтів і швидшого запуску рішень.