Через факапи до зірок. Як у межах одного продукту створити супутній і завоювати довіру користувачів

Привіт! Мене звати Олексій Янчук, я Product Lead у продукті Mailtrap компанії Railsware. Це платформа для доставлення імейлів, яка зʼявилася 2011 року після внутрішнього факапу: команда випадково відправила тестові листи реальним користувачам.

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

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

Для контексту: про продукт

Mailtrap був першим продуктом Railsware і, по суті, виріс із внутрішнього петпроєкту — sandbox для тестування імейлів. Спочатку над ним працював лише один інженер (і то не весь свій час). Як розумієте, ресурсів було малувато, тому старалися максимально використовувати що маємо, аби закрити якомога більше больових точок наших користувачів. У свої перші роки це був безплатний інструмент, який органічно зростав завдяки «черезтинному радіо» в спільноті.

І через вісім років, коли продукт уже мав до мільйона юзерів та платні плани, команда вирішила додати до Mailtrap ще й надсилання листів — Email API/SMTP. Як ми прийшли до цього? Виходили з основного юзкейсу в Testing і супутніх потреб:

  • Облікові дані (credentials) для нашого fake SMTP застосовуються на дев-оточенні. Користувачі відправляють там усе що завгодно, а ми робимо «пастку» (звідси і «trap») — вона перехоплює імейли, не доставляючи їх адресатам. Далі команди вручну перевіряють листи або автоматизують процес через наш API.
  • Компанії, які користуються тестуванням, все ж використовують якесь рішення для доставки імейлів своїм користувачам на проді.
  • Ми самі послуговувались одним із популярних рішень для відправлення транзакційних імейлів і постійно натрапляли на проблеми: раптове блокування акаунту; підтримка відповідає лише через кілька днів (і не по суті); складність інтерфейсу та статистики, які не дають зрозуміти, що і чому відбувається.
  • Інтервʼю з користувачами підтверджували, що не всі задоволені своїми поточними сервісами й готові розглядати альтернативи.
  • У нас завжди були користувачі, які питали, чому їхні листи не доходять до адресатів через наш fake SMTP :-)

Тому ми зробили логічне розширення для виходу за межі виключно sandbox-рішення:

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

Зокрема, для його реалізації обрали маловідоме, але гнучке MTA-рішення (Mail Transport Agent, софт, який відповідає саме за доставку через SMTP). Чому так?

  1. розробка власного MTA — це довго, дорого та потребує глибокої експертизи;
  2. вибір на користь популярного опенсорс-рішення закладав би потенційні складнощі з підтримкою, адже найчастіше це продукти зі значним legacy;
  3. планування на перспективу — ми хотіли врахувати потреби користувачів та зберегти високу продуктивність під час масштабування.

Окремим питанням стала робота з логами: історія відправлених листів та пов’язані з ними події (коли відправлені чи відкриті, кліки по лінках тощо). Ця функція відсутня на етапі тестування, але критично важлива для надсилання імейлів і подальшого аналізу. Ми протестували кілька баз даних та зупинилися на Redshift для зберігання логів (спойлер: вибір виявився не найкращим).

Тепер, коли ви краще розумієте продуктовий контекст, поїхали розбирати наші факапи.

Про факапи та рішення

Помилка № 1 — розділення продукту

Коли я долучився до команди Mailtrap, якраз почалася робота над другою частиною продукту — Email API/SMTP. Тоді було ухвалено рішення працювати над тестуванням та надсиланням імейлів в окремих репозиторіях і розділених на рівні VPC проєктах. На погляд інженерів, така ізоляція мала б покращити зручність продукту та спростити розробку. Проте з часом почали виникати проблеми. І ми зрозуміли, що створення комунікації між інтерфейсами через gRPC-протокол чи AWS SQS забирає ресурси команди.

Наприклад, щоб отримати дані користувачів з одного інтерфейсу, потрібно звернутися до іншого проєкту і надіслати запит. Або коли після впровадження змін в одному проєкті їх необхідно дублювати в іншому. Це створює складнощі під час масштабування продукту або підлаштування його роботи в різних регіонах, наприклад у Європі чи США. Проте об’єднання цих сервісів наразі неможливе через обмеження ресурсів. Тому ми продовжуємо працювати за цією схемою і плануємо змінювати поточну архітектуру поетапно.

Lesson learned ⬇️

Дивіться якомога ширше на заплановані зміни. Перш ніж ухвалити рішення про розділення, ми обговорювали його з різних боків, але цього виявилося недостатньо. Варто виділити трохи більше часу, але продумати всі можливі ризики та edge cases. Особливо це важливо для продакта, який має аналізувати ідею під різними кутами огляду, а не фокусуватися виключно на технологічній, маркетинговій чи візуальній складовій. А ще ставте більше запитань, щоб уникнути подібних помилок у майбутньому.

Для того щоб найкраще проаналізувати всі можливі сценарії, можете використовувати різні фреймворки та інструменти. Наприклад, проводити BRIDGeS-сесії. Нещодавно зібралися всією командою офлайн, щоби якомога ефективніше дослідити виклики, можливості й проблеми.

Помилка № 2 — вибір бази даних

Навіть якщо ви думаєте, що зібрали максимум інформації перед ухваленням рішення, вибір необовʼязково буде правильним. Ми перевірили це на собі, коли працювали з Redshift. Щобільше, перед використанням її в продукті провели відповідні тести (масштабування, вартість, перфоманс) — і це нам здалося найкращим рішенням (якщо цікаво, то також розглядали PostgreSQL, DynamoDB, BigQuery).

Однак ми не врахували, що не маємо власного досвіду реального використання. Це і завадило передбачити виклики саме для нашого продукту. Наприклад, з часом виникла проблема із затримкою в логах. Це критично для Mailtrap, оскільки користувачам важливо, щоб відправлений імейл відображався в логах відразу, а не через 10 хвилин. Ми витратили багато часу на оптимізацію і зменшили цей час до однієї хвилини. Проте це все одно було задовго, та й обсяг даних зростав би в майбутньому.

Тому повернулися до аналізу альтернатив. А ще — почали шукати консультантів, які мали значний досвід роботи з Redshift. Нам здавалося, що ми просто неправильно нею користуємося. Але розмови з експертами довели, що Redshift не підходить для нашого проєкту.

Розглянувши інші опції, вибрали Elasticsearch, який в екосистемі Amazon працює як Amazon Opensearch. І цього разу негайно ж звернулися до тих, у кого є великий реальний досвід використання цієї платформи. Додам, що тут добре допоміг сам Amazon. З 2022 року вони оновили команду, яка відповідає за Україну, і рівень підтримки відчутно зріс. Зокрема, їхні архітектори безпосередньо нас консультували. Завдяки цьому швидко зробили MVP на основні наших даних — і побачили, що це для нас працює. Дані про відправлені імейли дуже швидко з’являються в логах, немає проблем з агрегаційними даними, і все добре масштабується.

Lesson learned ⬇️

Якщо довго щось не виходить, не витрачайте час на постійну оптимізацію. Під час вибору технологічного стеку недостатньо вивчити наявні опції. Варто оцінити й те, як ті чи інші рішення працюватимуть саме у вашому продукті. Звісно, це можна зробити і методом спроб та помилок (як вийшло у нас). Але якби ми спочатку поспілкувалися з командами, що мають реальний досвід, то заощадили б рік, який витратили на розвʼязання цієї проблеми.

І це веде нас до наступного вивченого уроку.

Помилка № 3 — покладання лише на власну експертизу

Хай яка класна у вас команда, ви не можете знати все. Особливо коли йдеться не про «базовий» набір експертизи в команди продукту, а про нішеві питання. Як, наприклад, було з Redshift. Або візьмімо high-load та high-reliability сервіси з доволі складною архітектурою. Ще один приклад — актуальна для Mailtrap тема ефективності доставки імейлів (deliverability): у ній теж є чимало нюансів, та про них не дізнаєшся через просте дослідження питання.

Крім того, коли ваш продукт зростає, може зʼявлятися потреба і в додаткових фахівцях. Наприклад, у нас тривалий час не було окремої DevOps-функції: інженери самі закривали ці завдання та імплементували зміни. Але на певному етапі стало зрозуміло, що потрібен фултайм-спеціаліст.

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

Lesson learned ⬇️

Розумний крок — купляти час сторонніх експертів, аби заощадити свій. Важливо чітко сформулювати свій запит, щоб знайти необхідного спеціаліста. Наприклад, ми визначаємо очікування всередині команди й передаємо їх нашим people management. Вони формують пул потенційних співрозмовників, наприклад з LinkedIn та інших платформ. Відтак ми організовуємо короткі ознайомчі дзвінки, щоб оцінити фаховість і відповідність нашому запиту. Якщо всіх усе влаштовує, підписуємо документи про умови співпраці. Для точкових питань цілком підходить погодинна співпраця.

Про виклики, які могли стати проблемами

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

Виклик № 1 — поспішати тоді, коли не варто

Надійність продукту — це фундамент довіри наших користувачів. Mailtrap заробив гарну репутацію на ринку в інженерів ще до запуску маркетингових активностей по Email API/SMTP. Наприклад, нас рекомендували у Twitter (так, тепер Х), коли в когось був факап з імейлами. Тому ми не хотіли її втратити. Погані відгуки в соцмережах могли звести нанівець інвестиції та зусилля нашої команди в розвиток напряму Email API/SMTP. Адже здобути довіру важко, а втратити легко.

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

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

Близько восьми місяців ми зосереджено покращували процеси. Зокрема:

  • Перейшли на blue-green деплоймент.
  • Розширили системи моніторингу.
  • Додали підтримку з боку DevOps-команди.
  • Покращили роботу інженера on duty: оптимізували систему оповіщення, щоб швидко реагувати та запобігати аналогічним проблемам клієнтів.
  • Отримали сертифікацію безпеки — ISO 27001.
  • Застрахувалися на випадок кіберінцидентів чи збоїв у роботі системи.

Lesson learned ⬇️

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

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

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

Виклик № 2 — змінити сприйняття юзерів складніше, ніж видається

Після запуску Email API/SMTP ми очікували, що користувачі швидко долучаться і до нової частини продукту. Але, як ви здогадуєтеся, цього не сталося. Завдяки своїй репутації Mailtrap багато в кого досі асоціюється виключно з тестуванням імейлів. Ми з командою обговорювали ідею ребрендингу, але швидко її відкинули, адже назва Mailtrap не має обмежувати нас однією функцією. До того ж є інші приклади компаній, де це не стало проблемою.

Тому ми взялися вивчати причини, чому користувачі не поспішають випробовувати нову функцію відправлення імейлів:

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

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

Lessons learned ⬇️

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

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

У нашому випадку ми звернули увагу на проблеми Multi-tenant SaaS-продуктів, зокрема на керування доменами. Коли один з доменів користувача блокується, це може заблокувати весь обліковий запис. Тож ми сфокусувалися на вирішенні таких питань через технічні зміни та підтримку, допомагаючи клієнтам з налаштуваннями. Із запитів у нашу службу підтримку і розмов з декількома клієнтами стало зрозуміло, чого їм бракує з погляду сервісу та яких функцій не пропонують наші конкуренти. Тобто в цьому сегменті ми можемо мати перевагу як для конвертування наявних юзерів Testing, так і залучення нових.

Mailtrap, як ви памʼятаєте, — продукт Railsware, проте компанія має і напрям розробки на замовлення. Тому ми на власному досвіді розуміємо, що було б зручно сервісним компаніям. Тож наша команда створила пропозицію для software houses, щоб вони могли ефективно використовувати тестування та відправляння імейлів для своїх клієнтів.

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

Тому ми інвестували в спеціалістів і команду, щоб забезпечити ефективну доставку (deliverability) імейлів. Адже погана deliverability — це велика проблема, яку потрібно вирішувати на всіх рівнях. До того ж зараз, коли вже завершуємо роботу над новим компонентом продукту — Email Marketing, запустили його для обмеженої кількості користувачів.

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

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

Оптимізуйте процеси. Використовуйте інструменти для автоматизації. Наприклад, ми активно працюємо над автоматизацією комплаєнсу: оцінюємо, наскільки ризиковано, щоб користувач почав відправляти листи через Mailtrap. Для цього застосовуємо інструменти штучного інтелекту, що покращує захист від шахрайства та спаму в електронних листах.

І, звісно, постійно вдосконалюйте свій продукт.

Замість висновку: немає ідеальних рішень

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

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

За 13 років досвіду ми стали швидшими й кращими. Та наша команда продовжує вчитися на власних помилках. Помилятися властиво всім, але головне — робити висновки та рухатися вперед.

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

👍ПодобаєтьсяСподобалось6
До обраногоВ обраному1
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Сподіваюсь вам було цікаво, з радістю відповім на питання.
Якщо комусь треба відправляти багато (чи не дуже) transactional/bulk імейлів — звертайтесь 😉

Підписатись на коментарі