Design for Delight

The tracker was the program

Design for Delight is Intuit's customer-driven innovation method—deep customer empathy, going broad to go narrow, and rapid experiments with real customers. Inside Credit Karma it existed as something certain teams had heard of and nobody knew how to get.

1. A teams tracker that made the program decidable

The document I'd point to first is the least glamorous one. It held every product team against what they'd actually received: who had been coached, who hadn't, who had asked. Alongside it, who had completed Innovation Catalyst training and who had gone through D4D Champion training, which was a separate program I tracked rather than ran.

That intersection is what made the program run on decisions instead of instinct. It told us who to approach for catalyst training, and which team took priority for coaching next. Without it, "who needs D4D?" was a question you answered from memory.

2. A front door, and the socializing that made anyone walk through it

I built a coaching request form and a catalyst training intake, so teams could ask for support through a defined path instead of knowing the right person. The form is the part that's easy to point at, and the smaller half of the work. A request form only gets filled out if people already know the program exists, what it does, and why it's worth their time—so most of the effort went into socializing D4D through the channels where those teams actually pay attention.

3. Operations for the coaches

I ran operations for our 2 D4D coaches and for the Intuit-side program managers who brought the deep framework expertise. Scheduling, sequencing, tracking, and the FY26 roadmap and program one-pager that let a sponsor describe the program in one sentence to their peers.

4. A plan to break the coaching bottleneck

Our 2 coaches were at capacity, which capped how many teams could be onboarded no matter how much demand the socializing generated. So I put the constraint through a structured decision: a brainstorm to generate options, a 2x2 on impact and feasibility to narrow them, and a vote on what was achievable by fiscal year end.

Innovation Catalyst certification makes someone an advocate for the practice, not a coach—so more catalysts was never going to solve this. The question was which role could realistically carry coaching on top of the job it already had. The ops team was the answer, because we were already being embedded into product teams. One person could be a team's ops manager and its D4D coach at the same time, which meant capacity could grow without new headcount and without handing a team a coach who disappears when the engagement ends.

The roadmap ran through full Innovation Catalyst certification as a foundation, an apprenticeship as assistant coaches at in-person training, tiered "2nd chair" then "1st chair" rotations to build confidence with real teams, senior coach office hours for troubleshooting, and a competency framework defining what a D4D coach who is also an ops manager is accountable for.

Make the practice visible, then make it decidable

The order mattered. Before the tracker, before the intake form, teams had to know the program existed and believe it was worth an hour a week. That's socializing, and it isn't a launch announcement—it's showing up in the channels where those teams already talk, repeatedly, with something specific to offer.

Once demand existed, it needed somewhere to go. The intake gave me a queue I could prioritize, and a record of what teams were actually asking for, which turned out to be the best signal I had for what the program should offer next. The tracker turned that queue into decisions.

And once the queue got longer than 2 coaches could serve, the constraint stopped being awareness and became capacity—which is when a program manager's job changes from promotion to structural design.

A program nobody knows how to request is a favor, not a program.

Teams don't skip customer research because they don't value it

They skip it because the delivery calendar is real and the research is optional, and because running a good experiment is a skill nobody teaches you on the job. Both of those are structural problems, and both are solvable with structure: a defined method, someone trained to facilitate it, and a request path short enough that asking isn't its own project.

Co-coaching a team through 8 experiments taught me more about that than any amount of program design. The first experiment is always the hardest, not technically but socially—a team has to accept that they might be wrong in public. After a couple of rounds, the practice stops feeling like a detour and starts feeling like how you find out what to build.

The bandwidth problem is the same lesson at a different altitude. Two excellent coaches is not a program; it's 2 people's calendars. A program is when the capacity to coach lives in a role that's already there.

Six teams coached, and coaching designed into the ops role

Over the year I ran the program, 6 product teams came through the practice, and the org grew past 30 Innovation Catalysts. I co-coached one of those teams through 8 experiments end to end. I'm a certified Innovation Catalyst myself, which meant I coached the practice while also being accountable for it as a program—useful, because the friction a team hits in a session is the same friction that shows up in the program's design.

The scaling strategy was approved and we started executing it. In April we ran in-person Innovation Catalyst training in Charlotte, where I co-facilitated for 21 people and ops members who'd completed their own certification served as assistant coaches. That was the apprenticeship stage working exactly as designed.

Nobody had finished the path to embedded coach by the time I left, and a second in-person session was still in planning. What was settled was the answer to the question underneath all of it: how a program serves more teams without hiring more coaches.