The Situation
A business idea.
Nothing else.
Primeclerk arrived as a group of attorneys who had identified a gap in the bankruptcy administration market and raised the funds to fill it. They wanted to build an online platform to manage the full lifecycle of a corporate restructuring case, from the moment a company files for bankruptcy through to the final distribution of assets to creditors.
What they didn't have: a single line of code, a design, an engineering team, an internal process, or a product person. There was no existing system to study, no competitor to benchmark against, and no prior art inside the organization. The engagement started with a whiteboard, a marker, and a room full of legal domain experts who knew exactly what the problem was; they had simply never been asked to articulate it as a buildable system.
My role was to change that. As the founding PM on this engagement, I was responsible for translating a complex, deadline-driven legal process into a product architecture that could be designed, built, and eventually trusted with multi-billion dollar restructuring cases.
The Approach
Getting smart
fast enough
to lead.
I entered the domain cold. Bankruptcy administration is a specialized, highly regulated space governed by federal court rules, statutory deadlines, and legal liability at every step. Getting up to speed fast enough to lead structured discovery, without losing credibility in the room, required a specific approach.
We started with high-level process mapping: the major phases of a bankruptcy case represented as boxes on a whiteboard. First cut only. From there, each phase was broken into sub-processes, actions, escalations, and notifications across multiple sessions. I leaned heavily on the 5 Whys; not asking the attorneys what they wanted to build, but asking what kept going wrong, what caused delays, and what created legal risk. The product emerged from the problem space, not from a feature wishlist.
"Most people don't know what they want. They know what the problem is. The PM's job is to close that gap."
I structured a small team of two junior product analysts to work alongside me, because extracting structured requirements from domain experts is intensive, parallel work. One person cannot lead a discovery session, capture decisions, track open questions, and maintain continuity across weeks of sessions simultaneously. Building that capacity early was one of the more important structural decisions of the engagement.
The UI design was handled by a separate agency. Our team owned the process architecture and worked directly with our engineers on the technical build and architectural decisions. That meant I was simultaneously the translator between three groups: attorneys who owned the legal logic, designers who owned the visual surface, and engineers who owned the system. Holding the integrity of the original process design across all three required constant alignment and a single source of truth that only the PM could maintain.
The Hard Calls
Two decisions
that defined
the build.
The Outcome
Industry standard.
Twice acquired.
Primeclerk launched to the restructuring industry at a major event in New York, where the platform was demonstrated to attorneys, financial advisors, and corporate clients across the bankruptcy and restructuring space. It was received as cutting-edge for its time; a fully digital, end-to-end case administration platform in an industry that had been running largely on manual processes and disconnected tools.
The platform went on to handle some of the largest corporate restructuring cases in the United States. Primeclerk became the market leader in notice and claims administration, was acquired twice, and is now a core revenue component of Kroll, a global risk and financial advisory firm reporting $1.8B in revenue. The platform built from that whiteboard is still running.
"What I'd do differently."
If I were starting this engagement today, I would not assume that technical design standards transfer cleanly across business domains. The instinct to apply best practices, whether data validation, system checks, or process guardrails, is a good instinct. But best practices are derived from specific contexts, and when the context changes, the practice may no longer apply. Bankruptcy administration taught me that domain literacy isn't just about understanding the process. It's about understanding the liability model, the regulatory framework, and the business relationships that determine where the real risks actually live. A standard that protects you in one domain can add friction and cost in another. The faster you can make that distinction, the better the product you'll build.