Скоротили запуск експериментів з тижня до 10 хвилин. Кейс, який допоміг продакту налагодити взаємодію з інженерами

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

Привіт! Я Богдан Гудзенко, Product Manager у Howly by SKELAR. У бізнесі відповідаю за розвиток продукту BetterCV, який допомагає користувачам створювати професійні резюме, мотиваційні листи та досягати карʼєрних цілей.

Я перейшов у продуктовий домен з позиції Operations Manager. Тоді мої технічні знання обмежувалися курсом HTML+CSS п’ятирічної давності. Я не розумів технічної мови, якою спілкуються розробники, не міг коректно оцінити терміни виконання завдань та надати чіткі плани стейкхолдерам.

Та один робочий кейс на початку шляху навчив мене будувати ефективну взаємодію з інженерами. Далі ділюся ним із вами.

Виклики у співпраці продактів та розробників

Думаю, чимало продактів впізнають ці ситуації:

• Нерозуміння технічної мови. Розробники оперують специфічними термінами. Спочатку фрази на кшталт «деплойнути фічу на стейджинг» чи «закінчити спринт комітом у репозиторій» звучали для мене як набір незрозумілих слів. Через це було складно обговорювати рішення — я не завжди розумів, про що йдеться. Та найбільша помилка в тому, що я соромився перепитати, що означає та чи інша пропозиція. Результатом цього були некоректні висновки.
• Хибні оцінки термінів виконання та необхідних зусиль. Без базових знань технічних аспектів я недооцінював складність завдань. Здавалося, що «маленьку зміну» можна дуже швидко втілити, хоча на практиці вона вимагала тижня роботи, тестування та деплойменту. Це нерозуміння призводить до формування нереалістичних дедлайнів або тиску на команду з метою «прискоритися».
• Запізнє залучення розробників. Маючи поверхневе розуміння, як усе працює «під капотом», я схилявся до того, щоб самотужки прописувати вимоги та рішення, а вже потім приносити їх команді. Виходило, що розробники отримували майже готовий план реалізації, в який не могли внести суттєвих правок. Згодом я зрозумів, що варто одразу підключати технічного ліда чи інженерів до обговорення, тому що вони знаються на всіх нюансах, можуть підказати кращий підхід або вчасно попередити про «підводні камені».

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

Спроба № 1: рефакторинг бекенду на події (та чому це не спрацювало)

Контекст. Howly — це мультипродуктова компанія і в кожному нашому продукті велике значення мають комунікації з користувачами. Наприклад, сповіщення клієнтів про оновлення чи нові повідомлення, нагадування, акційні пропозиції тощо. Тому ми часто запускаємо A/B-тести та експерименти з SMS/email-розсилками, щоб підвищити залученість користувачів.

Рік тому на запуск експерименту замість бажаних 1-2 днів ми витрачали близько тижня. Чому так довго? Тоді всю логіку комунікацій було захардкоджено в продукті. Аби змінити текст листа, додати новий тригер чи послідовність повідомлень, потрібно було залучати розробників: писати код, проходити код-рев’ю, чекати деплойменту. Тому експерименти накопичувалися в беклозі, а спробувати «щось новеньке» оперативно ми не могли.

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

Lesson learned: цей досвід навчив мене чітко формулювати бізнес-потребу у вимірюваних показниках — не просто «хочемо швидше», а, наприклад, «запускати Х експериментів на тиждень».

Недоліком стало те, що я не дізнався в інженерів достатньо деталей: на скільки саме це прискорить процес, що зміниться для бізнесу та чи зможемо ми реально зменшити time to test. Ми запланували роботу, поставили поточні тести на паузу — і розпочали переробку. На цей рефакторинг ми заклали близько місяця роботи бекенд-команди.

Зрештою базову event-driven інфраструктуру ми реалізували, але очікуваного прискорення це не дало. Після завершення рефакторингу зʼясувалося, що швидкість зросла лише на 10%, а не X2 чи X3 як очікувалося. Як і раніше, під кожен новий експеримент доводилося писати код, тож цикл від ідеї до готового тесту все ж тривав дні або й тижні.

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

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

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

Lesson learned: якщо гіпотеза не спрацювала, краще це визнати й рухатися далі. Вчасно прийняти помилку й шукати нове рішення, а не триматися за ідею лише тому, що на неї вже витрачено ресурси.

Спроба № 2: інтеграція Customer.io — швидкий та ефективний результат

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

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

Ми зробили крок назад та вирішили «не винаходити велосипед». Так ми звернули увагу на Customer.io — це SaaS-платформа для автоматизації маркетингових комунікацій (email, SMS, push), спеціалізована саме на гнучких сценаріях розсилок.

Ми витратили трохи часу, щоб під’єднати Customer.io до наших систем: налаштували передачу даних про івенти та користувачів через API, синхронізували список контактів. Тепер замість того, щоб додавати новий код для чергового експерименту, ми можемо налаштувати потрібну розсилку через зручний інтерфейс без жодного рядка коду.

У результаті час запуску експериментів значно скоротився. Наприклад, експеримент з SMS-нагадуванням неактивним користувачам, який раніше реалізовували тиждень, тепер запускаємо за 5–10 хвилин роботи. А команді розробки більше не потрібно залучатися до реалізації кожної маркетингової ідеї.

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

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

Мої висновки — та поради для продакт-менеджерів без технічного бекграунду

Як я дію тепер:

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

2. Формулюю завдання через бізнес-метрики.
Коли формулюю виклики для команди, завжди пояснюю, який результат ми хочемо отримати в цифрах: підвищити конверсію з X до Y, зменшити час на запуск експериментів втричі тощо. Завдяки цьому ми уникаємо непорозуміння, а члени команди можуть самостійно пропонувати рішення та зберігати фокус на меті.

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

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

5. Відверто обговорюю помилки.
Якщо щось не спрацювало, ми говоримо про це відверто та одразу. Без звинувачень та пошуків «винного». У SKELAR це частина культури: кожен досвід ми сприймаємо як джерело інсайту. Коли відчуваєш, що тобі довіряють і ти можеш самостійно ухвалювати рішення та нести за них відповідальність, зʼявляється простір для сміливих експериментів.

Чого більше не роблю:

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

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

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

4. Не ігнорую сигнали команди.
Якщо інженери кажуть, що є ризики — то вони дійсно є. Часто вони бачать те, що не помітить PM. Моя робота — створити середовище, де розробники можуть відкрито сказати «це не спрацює». І я дослухаюся.

5. Не тримаюся за гіпотезу тільки тому, що на неї вже витрачено зусилля.
Якщо гіпотеза не підтвердилась — окей, значить ми отримали нові знання та розуміння, що не спрацює, та зекономили ресурси на майбутнє. Наша історія з Customer.io чудово це продемонструвала. Якщо перед вами стоїть суто технічний виклик, як-от оптимізація процесу чи впровадження певної функціональності — дослідіть ринок інструментів. Можливо, існує продукт або бібліотека, які розв’яжуть проблему значно швидше. Головне — не відкидати новий варіант тільки тому, що ви мало про нього знаєте чи вже погодилися на попередній.

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

Сподобалась стаття? Підписуйтесь на автора, щоб отримувати сповіщення про нові публікації на пошту.