MSP security console

US B2B tool for MSPs: a web SaaS for administrators, and a Chrome extension for end users. Admins see employee activity and manage DLP, passwords, and which sites people visit — a dense security CRM.

The bar I held: every admin task should have a short time-to-complete, and a new feature should not break settings already coupled to it. Roadmap owner: Head of Product. Mine: problem framing, scope of the slice, and the case for or against. Three slices shipped on that argument — the Rules wizard, the weekly client PDF, and text-to-policy.

Besides the three cases above, I sat in planning and discussion of every new feature. A simple product on the surface, with several modules that are extremely complex in logic.

When we added features or changed old ones, I often found overlap with legacy logic — or feature quirks that could conflict with, or even break, the carefully curated settings admins had already made.

Sometimes that argument changed the feature logic, and the console design followed. To solve those problems I either proposed a new flow entirely, or stayed with explanatory copy. I chose based on how many people used the feature — how many users this could actually hurt. Sometimes a constraint explanation or a warning was enough.

This is a web admin for creating enterprise information-hygiene “Rules.” Besides tracking employee web activity, admins could see workplace productivity, limit access to web resources for groups or individual users, set password-creation rules, and much else.

The product had several types of rules an admin could create and combine for the effect they wanted. Example: ban the marketing department from entertainment sites. But Adam in marketing needs that for work right now, so allow him. And only from 10:00 to 15:00, and only from the work account. That is one of dozens of possible combinations.

Once there are dozens of rules, it is easy to get lost in them — and almost impossible to hand creation or editing to another MSP employee who may not know that client well yet.

How I approached it: AI text-to-security-policy. I connected Claude Code to the documentation, distilled it, and asked lead engineers for Policy JSON files as examples. After a few iterations it was clear this could fix more than “I cannot hand a client to another MSP admin” — it could speed up work with rules in Policies overall.

On the user side the product is a browser extension for Chrome, Opera, and other leading-in-corporate browsers. It limited itself to pop-ups warning about web activity on particular sites, based on the Rules admins create.

After using the extension myself and hearing client feedback, I proposed adding a full web page so users would have a work hub of their own.

The pitch: users get personalized news from their company about Policy changes ahead of time; plus workplace analytics — productive time, limits and remaining time on particular sites, and so on. Behind those extras I saw a shift in the relationship between company admins, MSP admins, and extension users: instead of an extension that punishes and nags, a more ethical — and slightly cunning — move: earn trust in the security system.

I prototyped the idea and presented it to management. They rejected it: “for the user we should be invisible.” In my view the extension was already very visible — it just caused irritation. The idea stayed unshipped, with no chance to run moderated tests and see how users would react.

I started working in Figma through Claude Code before Figma AI existed. Figma Make, and dozens of hand-built prototypes before Make. I cared about semi-automation and evolving the design process. Among other things:

The rules UI is atypical and hard for MSP newcomers. I prototyped in Cursor: type instead of clicking the whole editor. Product docs were connected, so the model understood the logic. Output was a draft for a revise process — not final rules. After a few text passes, someone would know how to do it in the real UI without correcting later. Cheap quick win, not perfect. Stayed a prototype.

Separate experiment in the live console: paste a Slack thread, get a suggested set of cybersecurity rules.

LLM search for incidents — “what did user X do on Tuesday at 14:00?” Made sense out loud. Killed. I pushed gradual AI. Resistance was “this is new for developers, we do not want to spend time learning it,” plus “who pays for tokens?” At the product’s user count, caps would not have been a million-dollar burn. Could also have been a pain reliever for no mobile web: if text works, Slack from a phone. Displacing the MSP as the middleman between security and the client — I would have red-lit that myself.

I spent hundreds of hours on demos and workshops with C-level, ran many moderated tests with clients, used PostHog and AI to study user behavior (depth, session length), and designed so it actually mapped onto the technical constraints.

Hundreds of 1:1s with product managers. Weekly with the CEO and other C-level.

The interesting part lasted while there was still logic, interviews, tests.

We ended the collaboration when design was split off from product conversations. Execution-only without a product loop does not interest me — I want to own what we build and why, not only the design file.