PitchBook

2025

Rebuilding access management to save $4M operational costs and unlock enterprise growth

TL;DR: PitchBook sells financial data to the world's top investors. Clients paid but couldn’t use the product immediately. I fixed the system causing the wait.

Result: Clients waited less. Deals closed faster. $9M in business impact followed.

TL;DR: PitchBook sells financial data to the world's top investors. Clients paid but couldn’t use the product immediately. I fixed the system causing the wait.

Result: Clients waited less. Deals closed faster. $9M in business impact followed.

My Role

Product Designer

Sole Designer

Team

1x Product Manager

10x Engineers

2x Engineers

Scope

End-to-end 8-month system redesign

Research through production

Problem Area

Support reps were handling 200+ access requests per week. Every one required an Engineering ticket. Average turnaround: 5 days. Clients waited and churned.

Research | Root Cause

Most teams saw a workflow problem. I traced it to four deeper layers.

Key INSIGHT

The legacy system had permissions stored as flat boolean flags tied directly to user IDs. Any change required direct database writes by Engineering, with no audit trail and no rollback.

Design goals

The goal wasn't to remove Engineering from the workflow. It was to make Support reps confident enough to never need them. Fast enough to act in minutes. Forgiving enough that mistakes get caught before they land. Structured enough that a new rep on day one can set up a complex enterprise account alone.

Solution Overview

Support can now assign, update, and audit access end-to-end without Engineering

Strategic Decision

I won stakeholder buy-in on throwing out the legacy system entirely and building a new platform.

Explored

Cleaner UI on legacy system

Flat binary data model unchanged

No permission hierarchy. No self-service possible.

Patch the legacy tool

Pro: low effort to build
Con: still require engineering resource, hard to create self-service, lack flexibility

Selected ✓

New role-based data model

Support owns full lifecycle

Engineering removed from routine workflow

Build a new platform

Pro: eliminates the root cause, easy to scale with client and business needs
Con: longer timeline, harder sell to Engineering.

I evaluated each direction against three questions:

Can it scale with clients need and business growth?

Does it solve the root cause or just the symptom?

Does it remove the Engineering dependency entirely?

Challenge 01

First, HMW make the system structured enough that a new Support rep can set up a complex account on day one?

Explored - Duplicate a similar account

Existing Account 1

12 roles · 48 permissions

↓ clone all settings to ↓

New Client Account

12 roles · 48 permissions

✗ clones copy errors silently

Selected ✓ - Presets + customize

Choose preset

● Preset 1: Standard

○ Preset 2: Basic Access

○ Preset 3: Premium

○ Preset 4: Education accout

✓ scales safely with speed

PitchBook
AccountsRolesAudit
New account setup
Enterprise Standard
12 roles
Basic Access
4 roles
Research Only
6 roles
Custom
Start empty
RoleTypeAccessStatus
Research - Full3PRRead, DLActive
Research - Deny3PRNoneActive
Ratings - AllowPlatformReadActive
Ratings - DenyPlatformNoneActive
1 role customized
Apply configuration
1
Select a preset
Support picks from standardized starting points. 80% of accounts match one of four presets — no guesswork.
2
System pre-fills configuration
Roles, permissions, and access levels auto-populate based on the preset. The rep sees exactly what the client will get.
3
Customize and apply
Adjust what needs adjusting, leave the rest. One click to apply. Full audit trail. Done in under 5 minutes.

I noticed 80% of new accounts fell into the same four configurations. Reps were reinventing the wheel every time. That's wheree presets help standardize setup efficiently.

Support handles hundreds of accounts. Bulk action helps distribute access across multiple accounts simultaneously.

When I reviewed Support incidents, three out of five were the same mistake: right config, wrong account. This confirmation step helps Support validate account accuracy before execution

Challenge 02

HMW give Support the confidence to act without calling Engineering?

I realized everyone said "access". Nobody meant the same thing. I had to fix the vocabulary first.

Support's model was the simplest: "this client needs access to this resource." But the backend didn't work that way. I chose the option matching Support's mental model but respected Engineering's data structure.

1. Access relationships, visible at a glance — no backend knowledge needed

2. See the full impact of a role change before committing to it

Support can finally see and understand the full access landscape.

Challenge 03

Finally, HMW let Support move fast without letting mistakes slip through silently?

1. Help user catch mistakes before they happen

2. Impact visibility

Outcome

From manual bottleneck to scalable infrastructure

5 min

Access setup time

was 2–5 days

0

Eng tickets for access

was 40+/month

78%

Reduction

in Support Tickets

0

Compliance incidents

6 months post-launch

"Before this redesign, I'd spend half my Monday mornings filing tickets just to set up new client accounts. Now I pick a preset, adjust what I need, and I'm done before my coffee gets cold. I don't even think about the old system anymore."

Sarah M., Senior Support Operations Lead

What I learned

When I started, the problem looked like a workflow issue. It turned out to be a language problem.

Fixing that first, before any UI work, is what made everything else possible. The conflict detection. The bulk ops. The self-service. None of it works if the mental model is broken.


The hardest design problem didn't show up in any brief. And the work to solve it didn't happen in Figma. It happened in the three weeks of meetings before I opened it.

What I learned

When I started, the problem looked like a workflow issue. It turned out to be a language problem — two teams using the same words to mean different things.

Fixing that first, before any UI work, is what made everything else possible. The conflict detection, the bulk ops, the self-service — none of it works if the underlying mental model is broken.

The hardest design problem was one that didn't show up in any brief. That's usually where the real work is