Case Study · 2013 – 2014 · LegalTech · 0→1 Venture Build

From Blank
Whiteboard
to $1.8B

Company — Primeclerk (now Kroll) Role — Principal Product Architect · Founding PM Domain — Bankruptcy & Restructuring Administration

A group of attorneys walked in with funds, a business idea, and no technology. What followed was one of the most complete 0→1 builds of my career, and a platform that became the industry standard for restructuring administration in the United States.

Outcome
$1.8B Business valuation at
Kroll acquisition
Acquired · became
industry standard
0→1 No code, no design,
no process on day one

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.


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.


Two decisions
that defined
the build.

Decision 01
QR Codes Over Barcodes for Physical Claims Processing
The platform needed to handle incoming physical proof-of-claim forms, paper documents mailed in by creditors. The original design called for barcodes to pre-populate claim data, allowing creditors to either accept the pre-filled information or update it by hand. The problem was reliability. Barcode scanning at the time was highly sensitive to print quality; a faded or slightly misaligned barcode from a home printer could cause a read failure, which in a legally deadline-driven environment meant a rejected claim and a creditor dispute. I identified this failure mode before it reached production and drove the decision to use QR codes instead. QR codes offered significantly higher fault tolerance for variable print quality and environmental conditions. The switch was a proactive call made on technical grounds before a single form had been mailed.
Outcome → Eliminated a class of processing failures before they could affect live cases
Decision 02
Yielding on Data Validation: Knowing When Not to Impose Standards
Our organization came from an engineering culture that placed significant emphasis on data integrity checks, validating source data before it entered any system. When Primeclerk's model became clear, ingesting creditor lists directly from the debtor company and using them as-is without independent validation, our instinct was to push back and build a verification layer. We didn't. The reason was a careful reading of the legal and liability model. In bankruptcy administration, the debtor company is legally responsible for the accuracy of its own creditor list. If a creditor was missed due to bad data, the liability sat with the debtor and their counsel, not with the notice agent. Overlaying a data credibility check would have added cost, complexity, and timeline to the build while solving a problem that wasn't ours to solve. It was one of the first times I consciously chose to suspend a technical best practice because the domain context made it irrelevant.
Outcome → Faster build, lower complexity, correct alignment with client's legal liability model

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.

$1.8B Kroll revenue · platform is a core asset
Acquired · industry standard in restructuring administration
Still live Platform built from zero continues in active commercial use
Reflection

"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.

← Back to Portfolio