Stop Your
Feature Factory
Сергій Матчук, �Product Lead, Kismia, Quarks
[ DOU Mobile Meetup ]
Українська IT-компанія, що створює продукти
й технології у галузі Social Discovery & Dating. Допомагаємо мільйонам людей по всій планеті об’єднуватися та будувати стосунки
>180
людей в команді
>20
країн по всьому світу
United in movement
Київ
офіс
Sense Super App
2M+ Installs
Alfamobile Ukraine
2M+ Installs
Portmone
1M+ Installs
Apps I’ve been working on:
Сергій Матчук, �Product Lead, Quarks Tech
9 років
досвід роботи
з продуктами
7+ років
саме з мобільними додатками
з них
Kismia
50M+ Regs
міжнародна онлайн-платформа
для пошуку нових знайомств
US, UK, LatAm, Ukraine, PL
5+ ГЕО
200K
активних користувачів щодня
3 платформи
iOS, Android, Mobile Web
Англійська, Іспанська (ES, US, MX),
Португальська, Польська, Німецька,
Французька
8 мов локалізації
18
Person
Team
iOS Engineer x2
Android Engineer x2
QA x2
iOS & Android Team
Recommendations
Moderation Team
Platform Team
Copywriter
Golang Eng
Web Engineer x2
QA
Product Manager
Designer
Product Analysts
Product Manager
Designer
Product Analysts
Product Lead
QA Automation
Payments Team
Notification Team
Web Team
Ми працюємо в дуже конкурентному ринку і змагаємось за аудиторію
з такими гігантами, як-от Match Group, Bumble, що є лідерами по доходу в App Store та Google Play
$5+
Ціна залучення користувача
для дейтинг-додатку в US
Тому для нас важливо рухатись і будувати продукт максимально ефективно, щоб залишатись конкурентноспроможними
Як показують дані,
це в нас добре
виходить
Динаміка виручки, мобільних додатків
2021 Q2
2021 Q4
2022 Q2
2022 Q4
2023 Q2
2023 Q3
10+ років �на ринку (з веб-продуктом)
Чим поділюсь сьогодні?
01
Підходом до контрольованого покращення продукту, щоб залишати в продукті лише зміни
які дійсно мають цінність і які варті їх підтримки
03
Форматом роботи мобільних інженерів в Kismia,
що дозволяє інженеру мати більше впливу
на продукту і отримувати більше задоволення
від своєї роботи
02
Процесами та інструментами
для покращення якості продуктових рішень
та зменшення кількості непорозумінь
в команді
Процес розробки продукту сильно залежить від �цілі і контексту
Корпорації
Disclaimer
* все це на основі нашого досвіду в Kismia
Бізнес-
модель
Зрілість
бізнесу
Ринок
Ніша
Обмеження
Поточний фокус компанії
*
Kismia
Android
початок
Ціль - запустити мобільний додаток.
Команда - 1 PM, 1 Sr Engineer, 1 Designer, 1 QA
Рішення – сформувати скоуп, якісно пріоритизувати, вирішити всі залежності, поставити обмеження в термінах, рухатись ітераційно,
Надзвичайно ефективна робота Android розробника!
Результат - дейтинг додаток в Google Play через 2.5 місяця 🎉
Стабільний і ефективний процес розробки – це важливо.
Але з кожним наступним релізом,
ми робили велику кількість роботи, але динаміка покращення показників була не такою стрімкою
Більшість змін, які ми робимо
в продукті, не мають впливу або
лише роблять продукт менш ефективним з погляду створення цінності для користувача чи бізнесу
Negative impact
Positive impact
Impact
No
impact
Але в нас же є бачення, експертиза, дослідження…
Solution delivery
Solution shaping
Problem definition
Problem discovery
Так, ми проводимо Discovery & Ideation, щоб зменшити ризики і покращити якість рішення які ми приймаємо.
Але це все рівно, залишається нашим припущенням…
Жодна продуктова команда не може спрогнозувати,
як користувачі відреагують на ту чи іншу зміну в продукті
% успішних продуктових змін (експериментів)
10%
10%
33%
25%
15%
13%
Це підтверджує наш досвід
і досвід найкращих технологічних компаній
Source: A/B Testing Intuition Busters, Common Misunderstandings in Online Controlled Experiments�https://bit.ly/ABTestingIntuitionBusters
Наповнюємо продукт неефективним функціоналом і змінами
Збільшуємо кодову базу, ускладнюємо підтримку
та подальший розвиток
+
Погіршуємо загальний UX
і простоту використання продукту
+
Команда втрачає мотивацію
і розуміння куди рухається продукт
+
Середньострокові та довгострокові наслідки
Закриття проєкту і звільнення
RIP
Lack of Trust
Fear of Conflict
Lack of Commitment
Avoiding
Accountability
Inattention
to Results
Дисфункціональна, вигорівша команда без довіри всередині, мотивації і розуміння, куди рухається продукт
Продукт з купою функціоналу, який не приносить цінності, його складно підтримувати
“The product”
customer
emm..
Яка альтернатива?*
It Takes Practice
Долучати інженерів
до продуктового процесу
01
Формувати розуміння ключових показників і метрик продукту
02
Сприймати продуктові зміни як гіпотези,
що перевіряються експериментом
03
*по версії Kismia та Quarks
Долучати інженерів
до продуктового процесу
[ DOU Mobile Meetup ]
Інженер є невідʼємною частиною продуктовою команди
Product
Manager
Designer
Engineer
Product
Analyst
Customer
Success
Product
Marketing
QA
Eng
Eng
Copywriting
Формування продуктових цілей
Планування
Генерація гіпотез і рішень
Пріоритизація рішення
Ревʼю і фідбек щодо дизайну рішень
Регулярна робота з роудмепом
Процеси до яких залучаємо інженерів
Product Manager
Шукає точки зростання через
продуктову роботу
Спільний контекст, довіра, відповідальність та проактивна комунікація
Sr Engineer
Проектує та реалізує продуктові зміни
оптимальним способом
Ефективний тандем �Product Manager та Sr. Engineer
Product Manager
Фокусується на досягненні цілі
і пріоритизації
Sr Engineer
Проектує та реалізує продуктові зміни
оптимальним способом
Звісно, бувають проблеми і неефективність, з якими ми стикаємось. Однак проактивна комунікація з боку продакта та інженера, регулярні ретро, зустрічі по покращенню процесів допомагають нам вирішувати їх оперативно і без негативу
Переваги
Можливі складнощі
У продакт-менеджера більше часу на роботу з продуктом
+
За рахунок спільного контексту можна створювати менше артефактів
+
Інженер організовує роботу в спринті так, як потрібно йому і технічній команді,може пріоритизувати технічні допрацювання
+
Менше людей і комунікації, у нас немає скрам-майстра, проджект менеджера.
Все закриває або інженер, або продакт
+
Більше можливостей розвитку
та росту для інженера
+
-
Комунікація як додаткове навантаження на розробників
Наймаючи middle+ спеціаліста, особливо зважаємо на софт-скіли, гнучкість і продуктове мислення
-
Формувати розуміння ключових показників
і метрик продукту
[ DOU Mobile Meetup ]
Шаблон презентації
Команда розуміє, над якими метриками ми зараз працюємо і що вони для нас означають
Шаблон презентації
У всіх в команді є доступ до динамік
основних метрик і звітності
Щоденні автоматичні моніторинги в Slack
Моніторинги в Slack
від аналітиків
Автоматичні альорти
про відхилення метрик
Для візуалізації продуктової роботи ми використовуємо підхід Opportunity Solution Tree by Teresa Torres
Команда розуміє на яку метрику і проблему впливає конкретна задача яку ми зараз робимо
Opportunity
Opportunity
Opportunity
Desired Outcome
Opportunity
Opportunity
Opportunity
Opportunity
Opportunity
Opportunity
Opportunity
Solution
Development Task
Experiment
Experiment
Experiment
Experiment
Experiment
Experiment
Solution
На всю команду
шеряться результати наших продуктових змін. Кожен розуміє результат своєї роботи
Шаблон презентації
FAILURE
GROWTH
LEARNING
Сприймати продуктові зміни як гіпотези,
що перевіряються експериментом
Шаблон презентації
Розуміти командою, що ви проводите експерименти,
тому подальші ітерації – невідʼємна частина роботи.
До того ж, ймовірно, ми відмовимось від даного функціоналу
Ідея
Гіпотеза
Експеримент
Функціонал, який підтримуємо
/ Unit-тести
/ Додаємо функціонал� до чеклістів
/ Авто-тести
Ітерації
Зі сплітом чи без спліта?
No
experiments
Потрібно шукати здоровий баланс
Everything is experiments
Наперед закладати очікуваний результат і success metrics,
щоб уникнути confirmation bias
Feature Flagger
Управляти фічами в розрізі сегменту користувачів без залучення користувачів (гео, гендер, платформи, вік, тощо)�
Проводити ефективніше A/B тести�для нових користувачів�
Спрощувати автоматизацію тестування
Experimentation Platform (A/B Test)
та адмінка тестів
Намагаємось не тримати експерименти активними більше місяця. Маємо альорти, які нагадують про експерименти, по яких довго не ухвалювали рішення
Інструменти
для тестування.
Дебаг меню в додатках
з експериментами
і фічами
Features
Splits
Network Sniffer
WebSocket Events
Subscriptions Mocks
Analysts Debug
Logs
Проводимо негативні тести, прибираючи функціонал, яким юзери не користуються
Negative A/B Tests
Автоматизації нагадувань про видалення
непотрібного коду і оновлення дизайну
для забезпечення Source of truth
Feature Removal
Design Update
[ Процеси, які покращують взаємодію
і якість продуктових рішень ]
Design Review
[ Процеси, які допомагають покращити якість рішень і швидкість фідбеку ]
Demo & Implementation Review
01
Інколи рішення не мають ідеальну архітектуру одразу, і ми свідомо погоджуємось на проміжні рішення
02
Інколи в продукті проводиться забагато експериментів на один функціонал, що ускладнює його підтримку
Складнощі
Шаблон презентації
Всі ці інструменти і процеси покращують взаємодію в команді та допомагають бути впевненими що ви створюєте цінність
Кількість експериментів
2021 Q2
2021 Q4
2022 Q2
2022 Q3
2023 Q1
2023 Q3
2021 Q2
2022 Q1
2023 Q2
2022 Q4
21
33
50
39
59
50
22
20
61
45
+ 25% Win Rate
Thanks
Any questions?
email: serhii.matchuk@quarks.tech