Company
KualiResearch administration · IRB
Shipping the features that saved a deal.
Kuali had sold Protocols — its IRB research-compliance product — to UC San Diego. Then UCSD audited it, found real feature gaps, and didn't want to buy. As Lead Product Designer, I helped close the gap: shipping validated features fast enough to turn a walking-away customer into a signed one.
3 days
On-site with UCSD to hash out the plan
Deal saved
A walking-away customer, signed
4 major
Validated features shipped under deadline
Res. leadership
Seat I earned on the research team
The challenge
A signed deal about to fall apart.
In January 2020 my team pivoted off internal identity work to rescue the UCSD deal. UCSD had agreed to buy Protocols, then found gaps that made it unusable for how their researchers actually work. I flew to San Diego with Kuali's General Manager and Head of Engineering and spent three days with the UCSD research team. We reached a deal: if we could deliver the highest-priority features soon and keep closing the gap, UCSD would become a customer.
Then it was on us to deliver — fast, and on a domain most of us barely knew.
Why it was hard
Speed, a hard domain, and a tiny team.
01
Many features, little time
We had to ship a lot, fast, with an unhappy customer watching — and no room to ship the wrong thing.
02
Real needs, not just requests
Speed couldn't mean guessing. Every feature had to be validated with the people who'd use it.
03
A complex, unfamiliar domain
IRB / human-subjects compliance is dense — many personas, edge cases, and regulations to ramp on quickly.
04
A very small team
A handful of developers, one PM, and one designer — me — carrying the whole effort.
What I led
Strategy to shipped screens.
I owned the design end to end and worked as a strategic partner to the PM and engineering, not just a screen-maker.
I personally produced
- User research — interviews with UCSD admins and end-users
- The designs for Single IRB, Ancillary Review, Advanced Filtering, and Action Items
- Rapid prototypes I iterated live with customers
I directed
- Feature prioritization and the delivery roadmap with UCSD
- The "parking lot" of medium/low-priority work
- Design validation before engineering committed
I influenced
- The 3-day UCSD strategy sessions (with GM & Head of Eng)
- Scope decisions under deadline pressure
- How the team read and prioritized user needs
The team delivered
- Continuous delivery of the shipped features
- A sharp dev lead who clarified technical constraints
- Daily collaboration with PM and engineering
Key decisions
The decision ledger.
How we moved fast without shipping the wrong thing.
The decision
Get UCSD to agree on a short list of high-priority features and a delivery roadmap, with a visible "parking lot" for medium and low-priority work — so everyone shared one plan.
Alternatives
Try to close every gap at once, or let UCSD's longest wish-list drive the roadmap.
Evidence
The deal hinged on delivering a few things that mattered soon — not everything, slowly.
Tradeoff
Saying "later" to real requests, in exchange for a credible, deliverable plan.
Who
UCSD admins, Kuali GM, Head of Engineering, PM, and me.
Result
A shared roadmap both sides believed in — the basis for the signed deal.
What I'd change now
Get written agreement on what "done" means per feature, so scope can't quietly erode under deadline pressure.
The decision
Interview UCSD admins and end-users up front, then design → meet customers → iterate → repeat, so speed never turned into guessing.
Alternatives
Build straight to the feature list to save time, and hope it landed.
Evidence
In a domain this complex, a plausible-looking feature can still miss the real workflow.
Tradeoff
Time spent in interviews and iteration, bought back by not building the wrong thing twice.
Who
UCSD users, the dev lead (for feasibility), PM, and me.
Result
Features that were fast and validated as real needs.
What I'd change now
Nothing about the loop — but I'd protect design's finished spec better against last-mile shortcuts (see the reflection).
The decision
Focus design on the features UCSD's work actually depended on: Single IRB (sIRB) management for multi-site studies, Ancillary Review management, Advanced Filtering (conditional logic, column management, saved filters), and Action Items to guide researchers to compliance.
Alternatives
Spread thin across many smaller requests instead of the load-bearing ones.
Evidence
Interviews surfaced these as the workflows that blocked adoption.
Tradeoff
Depth on the critical few over breadth across the many.
Who
UCSD researchers & admins, PM, engineering, me.
Result
The gap closed on the features that mattered most to the deal.
What I'd change now
Ship the Action Items "conversation" capability I designed — users needed it, and it kept getting deprioritized.
Collaboration & leadership
A partner in the room, not a service desk.
I wasn't handed a spec — I was in the strategy sessions with the GM, the Head of Engineering, and UCSD's leadership, helping shape what we'd commit to. Day to day I ran the research, iterated live with customers, and met daily with my PM and developers. A sharp dev lead helped me understand the technical and process constraints, which made the designs buildable under pressure.
That's why the outcome wasn't just a signed deal: I earned a seat on the research leadership team and the trust of both Kuali and UCSD leadership.
Product evolution
The shipped surfaces.
A gallery of the Protocols work — Single IRB, Ancillary Review, Advanced Filtering, and Action Items.
Loading gallery…
Outcome
What changed.
UCSD signed
A customer who'd audited the product and balked became a signed deal — a marquee research-university logo and new revenue.
A gap closed with real features
Single IRB, Ancillary Review, Advanced Filtering, and Action Items — validated, not guessed.
Leadership trust earned
I joined the research leadership team and earned the trust of both Kuali and UCSD leaders.
A team forged under fire
The kind of bond a small team builds shipping something hard, together, on a deadline.
Reflection
What I took from it — honestly.
What worked
Delivering value fast without skipping validation. Prioritizing ruthlessly with the customer in the room kept everyone aligned.
What I'd do differently
Protect the finished design better. Under deadline, development sometimes shipped less than the validated solution, meaning to "come back to it."
What I learned
How to balance priorities under real pressure, and how much a hard domain rewards talking to actual users early.
What was left undone
My PM and most of the devs later left; I ramped a junior PM. The Action Items conversation feature users needed still hadn't been prioritized.
More of the Kuali story
Protocols was one product. See the design system underneath it — and the product I brought back from churn.