Four Launches, One Engineering Bench
Prioritization Frameworks for a Capacity-Constrained Program
Four white-label learning apps, built for global testing and credentialing organizations, all targeting launch inside the same nine-week window — against one shared QA owner and an engineering bench split across every project. I owned launch readiness across the portfolio: the frameworks that decided what got built, the dashboards that made delivery state legible, and the analysis that identified what was actually blocking us.
The Problem
Four customer programs, each proving a different layer of the platform to a different marquee partner, all with binding or near-binding dates in the same window. The bottleneck wasn't any individual project's backlog. It was that the same handful of people appeared on all four critical paths simultaneously, and no surface in the company made that visible until a date was already at risk.
Research & Discovery
Read the same three hygiene gaps — stale status updates, unreconciled launch dates, and unassigned client-decision tickets — repeating across all four launches, which reframed them as one systemic problem rather than twelve individual ones
Traced a launch date that read as three different values across three systems, which is the clearest possible signal that no one had a shared definition of 'done'
Found that severity labels had stopped being meaningful because the team had been asked to stop over-flagging, so most real bugs sat at no priority. Any dashboard inferring severity from labels alone would have been confidently wrong
Strategy
Launch Gate
Four questions, stop at the first yes. Signed and date-binding beats strategic and unsigned until the contract closes.
WSJF-Light
A stack rank for the next free engineer, published with its own known flaw stated up front.
Legible Delivery
A program overview drilling into per-launch swim lanes, built so a partner could read it without translation.
Find the Real Constraint
Per-project views hid the shared bench. Portfolio-level analysis found the one person on three critical paths.
Key Decisions
Published the WSJF ranking with an explicit warning that it was wrong in one specific way: the formula rewards 'cheapest to finish,' which floated a nearly-done project above the flagship launch with the nearest binding date. Naming the flaw made the framework usable; hiding it would have made it a liability the first time someone followed it off a cliff
Overrode the ranking with the Launch Gate where a date was genuinely immovable, and said so in writing. A prioritization framework that can't be overridden by judgment is a bureaucracy, not a tool
Designed the QA dashboard to read from agent-refreshed snapshot files rather than a live API. Snapshots meant a partner-facing board could never surface a half-written ticket, and refreshing was a deliberate act with a human in the loop
Kept the dashboard local-only and declined to deploy it, because the same view that made delivery legible internally also aggregated information that should not sit behind a shareable URL
Logged client-owned blockers as tracked dependencies with an internal chaser assigned, rather than leaving them as verbal 'waiting on the customer.' It made the board honest about who the action was actually on
Results & Impact
4
Concurrent Launches
8M+
Annual Test-Takers
9wk
Convergent Window
- Authored the Launch Gate, a four-question decision rule that resolves any ticket, request, or 'should I do this' by stopping at the first yes — signed and date-binding beats strategic and unsigned, every time, until the contract closes
- Built a WSJF-light stack rank for allocating the next free engineer across the portfolio, using open-issue count as an effort proxy and flagging that proxy as a data gap rather than hiding it
- Shipped a QA/UAT program dashboard: a portfolio overview with a health pill and top risk per launch, drilling into a client-facing swim-lane board that showed partners what was in our inbox, in flight, and resolved
- Ran the capacity analysis that identified the actual constraint — one QA owner carrying the sign-off pass on three launches inside the same nine-day window, plus two engineers split across two-plus projects each — and reframed the conversation from per-project status to shared-bench sequencing
- Consolidated cross-project delivery hygiene into batch fixes after finding the same three gaps repeating on every launch, so nine separate to-dos collapsed into three