MSP security console

US B2B-інструмент для MSP: Web SaaS для адміністраторів і Chrome-розширення для користувачів. Адміни бачать діяльність співробітників і керують DLP, паролями й відвідуванням сайтів — щільна security CRM.

Планка: кожна задача адміна має короткий time-to-complete, і нова фіча не ламає вже зібрані налаштування. Roadmap — у Head of Product. Моє: формулювання проблеми, scope зрізу і аргумент за чи проти. Три зрізи вийшли на цьому аргументі — Rules wizard, щотижневий PDF клієнту і text-to-policy.

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

Часто при додаванні нових функцій чи зміні старих я знаходив накладання логіки на legacy-логіку чи особливості фіч, які можуть конфліктувати чи взагалі ламати акуратно curated налаштування, які адміни створили раніше.

Іноді мій вплив результував у зміну логіки фічі — і це, звісно, відображалося на дизайні консолі. Для таких проблем доводилося або пропонувати новий флоу повністю, або обмежуватися текстом із поясненням. Рішення брав виходячи з кількості використань фічі: для якої кількості користувачів це може стати суттєвою проблемою. Часом можна було просто обмежитися текстом із поясненням обмеження чи іншим попередженням для користувача.

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

Продукт містив кілька типів правил, які адмін може створювати та комбінувати для бажаного ефекту. Наприклад, можна заборонити відділу маркетингу відвідувати розважальні сайти. Але Адам із маркетингу потребує цього для роботи зараз, тому йому можна дозволити. І тільки з 10:00 до 15:00, і виключно з робочого акаунту. Це одна з десятків можливих комбінацій.

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

Як я це вирішив: AI text-to-security-policy. Я підключив Claude Code до документації, дистилював її і попросив у lead-інженерів JSON-файли Policy як приклади. Через кілька ітерацій стало зрозуміло, що цей підхід може виправити не лише «не можу передати клієнта іншому адміну MSP», а й загалом пришвидшити роботу з правилами в Policies.

На стороні користувача продукт — це веб-розширення для браузерів Chrome, Opera і інших leading-in-corporate браузерів. Розширення обмежувало свою функціональність попапами з попередженнями про діяльність у вебі на окремих сайтах, виходячи з Rules, які створюють адміни.

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

Пропозиція: користувачі завчасно отримують персоналізовані новини від своєї компанії про зміни в Policy; плюс аналітика на робочому місці — продуктивний час, обмеження й залишок часу на окремих сайтах тощо. За цими плюсами я бачив зміну моделі стосунків між company admins, MSP admins і extension users: замість розширення, що карає і сварить, — більш етичний, але й дещо хитрий підхід: здобути довіру до системи безпеки.

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

Я почав працювати у Figma через Claude Code ще до Figma AI. Figma Make і десятки ручних прототипів ще до Make. Мене цікавила напівавтоматизація та еволюція дизайн-процесу. Серед іншого:

Інтерфейс правил нетиповий і складний для новачків у MSP. Прототип у Cursor: текст замість кліків по всьому редактору. Підключена документація продукту — модель розуміла логіку. На виході чернетка для revise process, не фінальні правила. Після кількох текстових проходів людина вже знає, як зробити це в справжньому UI, щоб потім не виправляти. Дешевий quick win, не ідеал. Лишилось прототипом.

Окремий експеримент у живій консолі: вставка з Slack → запропонований набір правил кібербезпеки.

LLM-пошук для інцидентів — «що юзер X робив у вівторок о 14:00?». На словах сенс був. Згорнули. Тиснув на обережне поступове ШІ. Супротив: «для розробників це нове, не хочемо витрачати час розбиратися» плюс «хто платитиме за токени?». На обсязі продукту з лімітами це не million dollars worth of tokens. Могло зняти біль відсутності мобільної версії веба: якщо текст працює — Slack із телефона. Витіснити MSP як прокладку між безпекою і клієнтом — тут я сам дав би червоне світло.

Я провів сотні годин демо і воркшопів із C-level, провів безліч модерованих тестів із клієнтами, використовував PostHog і AI для дослідження поведінки користувачів (глибина, тривалість сесій) і створював дизайн, що лягає на технічні обмеження.

Сотні 1:1 із продакт-менеджерами. Щотижня CEO та інші C-level.

Цікаво було, поки лишались логіка, інтерв’ю, тести.

Завершили співпрацю, коли дизайн відокремили від продуктових розмов. Execution-only без product loop не цікавить — я хочу володіти тим, що будуємо і чому — не лише дизайн-файлом.