Performance Pilot
The Performance pilot came to me mid-stream. Design work already existed — but it wasn't connecting. Executive and stakeholder mental models of what the experience should be weren't aligning with what had been built. The existing work was crowded, unfocused, and missing key elements of the program's philosophy. The team had been restructured, timelines were at risk, and the initiative carried real visibility — CTO and executive-level attention meant the cost of continued misalignment was high.
The work wasn't starting over. It was figuring out what was actually trying to be said, and finding a way to say it clearly.
The first move was translation. Executive stakeholders had a clear instinct about what this experience needed to feel like — but it was living in their heads, not on a screen. I took those mental models, reconciled them with the existing research and design rationale, and turned them into wireframes and direction the team could actually align around. Not blindly executing a vision, but finding the version of it that was grounded in what we already knew about the people going through this experience.
When alignment on direction kept stalling — stakeholders going back and forth on what was "right" — I made the call to stop making boardroom decisions and put it in real stores. Internal testing gave us a controlled environment, but it wasn't going to answer the questions that actually mattered. Real environments would. That decision kicked off our in-store testing phase and shifted the whole initiative from theoretical to empirical. Everything we've learned since came from that move.
When the team restructure threatened timelines, I got hands-on — building screens directly to keep the project moving. The principal move isn't always the strategic one. Sometimes it's just doing what the work needs.
As the pilot moves through its stagegates, foundational work is running in parallel. Three streams, all connected.
The most significant is a framework designed to outlast this pilot. It sets expectations for the experience, gives coaches a basis for how to train and deliver consistently, and creates a foundation that future iterations of this product can build on. The intent is to make sure that whatever comes next has something real to build on top of — not starting from scratch every time.
The second is a scalable training model — how do you train employees to deliver a consistent experience without flattening their individual style? How do you do that at scale, without being one-on-one with everyone? Working with our Experience Delivery Lead to build the frameworks employees need without turning them into scripts.
The third is an end-to-end communications map. Working across Marketing, Performance, and Scheduling to map every touchpoint — what communications set expectations, build anticipation, nudge, re-engage. What's needed now for the pilot, and what belongs in a broader go-to-market strategy.
The path forward is defined if not yet certain. Testing is underway, moving through stagegates — each one designed to answer the questions the previous one couldn't.
My role through all of it is less about driving the product work directly — the product team owns that — and more about making sure the strategic threads stay connected. That the training model keeps pace with what's being tested. That the communications framework is ready when the experience is. That the framework we're building now is flexible enough to hold whatever the pilot teaches us.
The work isn't finished. But the foundation is being laid deliberately — which is the only way to make sure what gets built on top of it actually holds.