8 Squads, 3 Designers
From zero discovery to customer evidence in every brief: requirements validated 30–40% faster
Head of Product Design · CourtReserve · 2025–2026 Racquet club and facility management SaaS, Mainsail Partners – backed.
The situation
I joined CourtReserve as its first ever design hire, one of a handful of leaders brought in right after the company’s first round of funding to help it scale and put distance between encroaching competitors. Product development ran through a black-box engineering org: the CTO was the single point of contact for the rest of the business on any work requested, and design meant UI work outsourced to an agency. There were already eight product managers. I was told the company had that many because it was trying to build faster and needed more help defining projects to keep engineering busy.
The new VP of Product and I looked at the staff we had and restructured product development into cross-functional squads, each with a PM, a dev lead, and a UX lead.
Eight squads. Eight PMs, most of them early in the discipline. No research practice. No design system. And budget for three designers.
That ratio was a huge problem, and it wasn’t solvable by working harder.
The decision
There were three ways to play it:
Ask for headcount. A fair ask, and I made a version of it. But even a successful headcount case lands six to twelve months out, and it doesn’t answer what happens in the meantime. Staffing toward one designer per squad also meant asking a growth-stage company to roughly triple its design spend to reach parity with an org structure that had just been invented.
Triage. Put designers on the squads shipping the most visible work, let the rest run uncovered. The outcome is predictable: the loudest squad wins, and quality splits into two tiers that get harder to reconcile every quarter.
Build leverage. Accept that eight squads will never each have a designer in the room, and make it so they don’t need one in order to reach validated requirements.
I chose leverage. The bet was that customer evidence and design decisions could reach a squad as infrastructure rather than as a person’s time. A PM with good evidence and good components makes better calls than a PM waiting in a queue for design.
What that cost
The choice was right for the constraint. It was not free.
Craft depth in some surfaces. The design system did work a designer would otherwise have done. That produces consistent and correct; it doesn’t produce distinctive. In a few places distinctiveness would have been worth more than consistency, and we didn’t get it.
Partnership. Some squads never had sustained design partnership. They had evidence and they had components. That is not the same thing as having someone in the room, and I wouldn’t pretend otherwise to anyone who worked in those squads.
My own time. I spent a large share of it building systems rather than developing the three senior designers I’d hired. I’d make the trade again given the ratio, but it was a real cost and they felt it.
Standing maintenance. Systems are not a one-time build. A research layer that nobody curates degrades into a search index over stale interviews. Choosing leverage means committing to ownership, permanently, and that commitment has to be staffed like any other.
What I built
A squad operating model. What a UX lead owes a squad, what the squad owes back, and what “ready to build” means in writing. Before this there was no shared definition, which meant every disagreement about readiness was a matter of opinion instead of a process question.
A research practice, from nothing. Over the engagement the squads generated 100+ customer interviews, 12 advisory board sessions, two surveys at 200 respondents each, and a continuous read on thousands of support conversations. I also put designers in front of customers at two user conferences. Interviews and advisory sessions were recorded and transcribed at the source rather than written up from notes afterward, which is the difference between a research layer that holds evidence and one that holds summaries.
A UXR Brain. Interviews, surveys, and advisory sessions ingested into a vector-searchable research layer that any PM could query directly. The design constraint was that it had to be useful to someone who had never run a study. Answers come back with the evidence attached, not as a summary you have to take on faith.
A Voice-of-Customer engine. Support and feedback channels synthesized into themed, quote-backed evidence. A VoC pull became a required input to every product brief.
Evidence-gated briefs. The gate is the mechanism that made the rest matter. A brief doesn’t advance without customer evidence attached, which converts research from something a team requests when it has time into something the workflow won’t proceed without.
A design system. 50+ desktop and mobile React/TypeScript components built on Ant Design, documented in Storybook, adopted by all eight squads, with semantic tokens extended to React Native through a shared-token monorepo.
A Product Agent, co-architected with our VP of Product: 15+ interoperating agent skills wired into Linear, Slack, Supabase, Google Drive, Intercom, and UserEcho, adopted by every PM across 30+ projects. I owned the research and design intelligence layer of it end to end.
What changed
Every product brief now carried customer evidence, because the workflow wouldn’t advance without it. That’s a different thing from teams valuing research. They valued it before. They skipped it anyway, because nothing stopped them.
Time to a validated requirement dropped 30–40%. I’d treat that as a conservative floor rather than a measured result: there was no clean baseline, because there was nothing to baseline against.
Adoption is the number I’d actually point to. Every squad on the design system. Every PM on the Product Agent, across 30+ projects. Systems that only their author uses aren’t leverage; they’re a hobby.
What I'd do differently
I identified the measurement gap early and said it out loud. I still got the sequence wrong.
My view then and now: validation tends to happen either before you build or after you ship, and “after” only works if you’ve built the instrumentation to measure it. Most teams that choose “after” haven’t. CourtReserve hadn’t. There was no measurement foundation at all, which meant “we’ll learn it in production” wasn’t a strategy so much as a hope.
I was right about that, and I argued for the validation layer first. In hindsight I should have built the instrumentation layer first. Same systems, same conviction, different order, and a completely different argument. Building post-ship measurement first would have made me the person accelerating the speed agenda rather than the person advocating for the more deliberate model. It’s much easier to make the case for pre-development validation when you can show, with numbers, what shipping without it costs.
That’s the lesson I carry into the next org: lead with the instrumentation. Earn the argument with evidence rather than winning it on principle.