Як замінити десятки продуктових демо однією подією: кейс Research & Engineering Conference в MacPaw

💡 Усі статті, обговорення, новини про продукти — в одному місці. Приєднуйтесь до Product спільноти!

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

Ми зіткнулася з цим викликом в MacPaw і спробували вирішити її через формат внутрішньої конференції — Research & Engineering Conference (REC).

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

Чому звичних демо стало недостатньо

Ідея REC з’явилася у 2024 році як відповідь на досить типову ситуацію: дослідження і розробки в різних командах існували паралельно, але майже не перетиналися. У кожної команди були свої демо, свої результати, свої інструменти — але ці знання рідко масштабувалися. Як наслідок:

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

Формат внутрішньої конференції став способом зібрати ці знання в одному місці й зробити їх видимими для всієї компанії.

Як виглядає формат REC

REC — це одноденна внутрішня конференція, яка об’єднує інженерні демо, ресерч і прикладні кейси.

Остання подія у грудні 2025 року стала найбільшою за весь час: 22 спікери та понад 230 учасників онлайн і офлайн.

З часом формат еволюціонував: від трьохгодинної зустрічі до повноцінної конференції з різноплановою програмою — від AI і дата-інженерії до продуктових рішень і дослідницьких проєктів.

Практичні кейси: що почало працювати після конференції

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

1. AI Code Review

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

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

2. Feedback Triage

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

У результаті інструмент масштабували на рівні всієї компанії з можливістю адаптації під різні потреби та команди.

Що спрацювало: 3 принципи, які варто врахувати

Під час підготовки конференції я виділила кілька речей, які суттєво вплинули на результат.

1. Вихід за межі інженерної бульбашки

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

2. Мікс тем замість вузької спеціалізації

Жорстке розділення на AI / Research / Engineering може звузити аудиторію. Натомість змішаний формат робить програму динамічнішою і утримує увагу. Навіть якщо тема не безпосередньо про твою роботу, вона дає нові ідеї або підходи.

3. Фокус на прикладних кейсах

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

Неочевидний результат: зростання внутрішньої експертності

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

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

Висновок

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

Цікаво, як це працює у вас: чи є у вашій компанії формати, які допомагають командам дійсно вчитися одна в одної?