Customer discovery & product strategy · Developer tools · 2025–present

Replay

Replay had built a vibe coding AI tool that was working. The unresolved question was who needed it most and what problem they were best to solve.

Over the first six months, I conducted 34 structured Bullseye Customer Sprint interviews while the broader team kept talking with customers too, bringing the total research effort to nearly 50 conversations. Each round narrowed the customer hypothesis while the team kept shipping.

By Skipper Chong Warson · Published 20 Jul 2026 · Updated 7 Sep 2026

Replay customer hypotheses narrowing across five research cycles

Where should a small team focus?

The working name for their product was nut.new, it was a fork of Bolt that gave the AI suite access to real runtime data: what the app was doing, what had broken, and why.

In spring 2025, AI tools could generate a working prototype quickly, but would often stall when a change failed. The AI couldn't see what was happening behind the scenes while nut.new could inspect the runtime, debug the problem, run tests, and push a fix through.

Replay's CEO and a small engineering team had a hunch about who needed it most. The decision left was where to focus: who to recruit, which problem had enough teeth, and how to position the product.

The first hypothesis

The first bet was that operations managers needed help automating simple create, read, update, and delete (CRUD) workflows. We framed the hypothesis together, recruited five people, designed the interview guide, and away we went.

In those interviews, they all described real problems:

  • Setup paralysis
  • Fragmented tools
  • The fear of breaking something they could not repair

But across the five interviews, there didn't seem much pressure to change. One operations manager put it plainly: “I’d rather deal with the inefficiency I know than risk configuring something wrong.”

Original Bullseye Customer debrief with Replay

Cycle one: five operations managers described real pain, but little pressure to change

We kept getting narrower with the customer

So we ran another cycle with a different hypothesis, then another. Across more than 10 interviews, a different customer began to appear: someone building for themselves rather than for a team.

Each cycle knocked out another assumption. Being an employee mattered less than we thought. Then being a professional builder mattered less. Eventually technical proficiency dropped out too.

One thing kept holding: they’d already shipped something real. Their problem wasn’t getting to a first prototype anymore, it was what happened next.

In one interview, one customer described an internal app she'd built for contractors to submit work and receive payment. She had written most of it with Claude's assistance after trying Lovable and Replit, and she deployed directly to production most days. When something broke, there was no engineer to escalate to. She had to figure it out on her own, she could ask friends who were developers but those favors run out fast. As she put it, “Now I broke something else, someone's got to debug it anyway.” So it might as well as be her.

That interview, along with others in the cycle, sharpened the distinction: the customer had already started and shipped something. The harder problem was continuing when it broke.

Replay customer hypotheses from cycles 1 through 5

Five cycles moved the bullseye from operations managers to non-technical creators who had already shipped something and couldn't get unstuck

How the team worked

I ran the engagement end to end: hypothesis framing, recruiting, interview design, facilitation, synthesis, debriefs, and recommendation framing. And the Replay team joined the research directly.

Brian, the CEO, participated from the start. Filip joined the early Bullseye framing work. Tom joined the first interviews, and other team members began sitting in as the cycles continued.

We started each with a tighter and tighter hypothesis and ended with a decision about what to keep or change. The team heard the same customers and compared notes after each interview. That direct exposure gave them enough confidence to abandon earlier suspicions when the evidence pointed somewhere else.

The progression was gradual:

  • Operations manager
  • Operations manager with a stronger trigger
  • App builder
  • Solo builder
  • Non-technical creator who had shipped something real and could not get unstuck

Making the research reusable

After the interview rounds, I created a Claude project containing the Bullseye research corpus: 34 redacted transcripts, screeners, interview guides, and a transcript reference key.

Claude project containing Replay customer interview transcripts, screeners, interview guides, and reference materials

The Claude project made an evidence archive, 34 Bullseye Customer Sprint interviews searchable and traceable

Instead of treating research as a static deliverable, the team could query the evidence directly and trace an answer back to the source conversation.

Decisions changed

Across our work together, I could see the Bullseye Customer work inform four types of decisions —

  • Customer: Operations managers dropped out of focus after the first interviews showed real pain with little pressure to c'hange
  • Recruiting: We rewrote the criteria after each cycle as the customer definition got narrower, mostly using userinterviews.com for screening and qualification
  • Audience: Replay moved from a broad app-builder audience toward non-technical creators who had already shipped something real
  • Positioning: The problem moved toward continuation: helping someone understand and fix what broke after they had already built and shipped

Replay’s community manager and developer relations lead put it this way:

“There are moments when you feel like you've built the right product, but you're not sure you're reaching the right people, and that's where Skipper really shines. He has a talent for cutting through the noise, helping teams clearly define their target audience and identify their bullseye customer.”

— Filip, community manager and DevRel lead at Replay

What Replay has shipped

nut.new launched in spring 2025. Replay Builder followed in Dec 2025, Replay QA in May 2026, and MCP integrations with Claude Code and Codex in Jun 2026.

Those launches belong to Replay’s continuing product work. I don't claim them as follow-on effects of my work — customer definition, recruiting criteria, and positioning decisions — but they address the same continuation problems the interviews surfaced.

Where it landed

Across five customer hypotheses and nearly 50 conversations, Replay moved from a broad app-builder audience toward non-technical creators who had already shipped something real and were stuck on what came next.

The team heard those customers firsthand, rewrote the recruiting criteria cycle by cycle, and kept the 34 structured interviews in a research corpus they could return to.

Replay is still building — they just released on Product Hunt — so the customer definition will move again. And it should. The difference now is that the next hypothesis can be tested against customers the team has already heard for themselves.

Other select projects