COMPLY Case Management

COMPLY is a compliance platform for financial firms — the system that helps firms monitor employee trades, manage pre-clearance requests, and demonstrate to regulators that they're actually watching for violations, not just claiming to. Get it wrong and a firm faces fines, or worse; get it right and the process is easy to use and mostly invisible.

I was the sole product designer supporting four product managers across COMPLY's platform — in the room for user stories, enterprise deal calls with our sales and solutions engineers, and everything between. It came up on call after call: compliance officers had nowhere in COMPLY to flag a violation and track it to resolution, and nowhere to build the kind of flexible, custom pre-clearance forms their compliance programs actually needed. They were doing both in spreadsheets, disconnected from the trade data that made COMPLY valuable in the first place. Competitors said they had case management. We didn't — and it was costing us our highest-value accounts in the book.

The System Map

With sales pressure mounting, there was a real pull to start building immediately. But the deeper problem was that no one could agree on what we were actually building — leadership, sales, engineering, and support were each describing something different, and customers weren't landing on the same idea either. So I ran four discovery interviews, including one with a prospect who'd already walked, and checked what I heard against COMPLY's own history: a platform stitched together from four merged brands that had never agreed on a shared vocabulary for its own compliance processes.

Before any wireframe, I built a single diagram: every compliance module COMPLY had, mapped against how they actually connected. The diagram itself was the aha moment — the same modules everyone already knew, but for the first time laid out as one shared reference instead of four competing versions in people's heads. That artifact stopped sales, product, and support from circling the same word without ever agreeing on what it meant. It changed how the company talked about its own product, and once that shared language existed, the real scope of "case management" became clear.

Two Build Tracks

Compliance officers didn't think in forms. They thought in jobs: "I'm tracking a violation" and "I'm filling out a trade pre-clearance request" were two entirely different tasks — different goals, different outcomes, and at larger firms, often different people handling each one. Every competitor solution I looked at treated them as the same thing anyway — one unified "case" concept, filtered and sorted for whatever the user needed. It's a clean engineering answer, and internally, I argued it was the wrong one: it would reproduce the exact language confusion that was already costing COMPLY deals. I split the build into two tracks instead.

True case management — breach tracking and remediation — became a new entity type in the platform. Flexible pre-clearance became a separate effort, replacing a legacy module that had been locked to eight fixed form types for years. Matching the build to how people actually thought about the work, instead of how the codebase wanted to organize it, shaped everything that came after.

Phasing The Build Under Pressure

We shipped in two phases, under real pressure to stay competitive in an active sales cycle — knowing the first phase wouldn't be enough for our highest-value segment. The legacy database underneath the platform hadn't been touched in years; extending it without breaking existing client data took the kind of careful, behind-the-scenes engineering that doesn't show up in a feature list. Mid-market adopted the first phase immediately. Enterprise needed the full launch before the tool clicked — and that gap was the right call for most of the business, even though it cost us time with the segment that mattered most.

Outcome

Reflection

This is what customer discovery looks like when it's taken seriously: a lost deal becomes a research source, an internal language gap gets treated as seriously as an external one. The project ran through three PM transitions and two C-suite changeovers. What held steady wasn't a spec — it was the problem framing, the two-track insight, and the reasoning behind each decision. I saw it through to make sure the right thing got built, not just a thing with the right name.

The one call I'd revisit: choosing speed over completeness in Phase 1. It was the right call for the business at the time, but the underlying problem was never about individual tasks — it was about how COMPLY's modules connected to each other, which was the whole point of the system map to begin with. A more complete first phase would have honored that connection instead of shipping around it, and closed the enterprise gap sooner too. If I had it to do again, I'd argue harder for completeness over speed.