Build in Public Day 1: Idea Validation — From Interview to Insight

Everything starts with a conversation.

I sat down with the owner of a small law firm — a friend — and what he told me changed the direction of my next product. His attorneys were losing 10 to 50 percent of their billable revenue because they simply couldn't track their time accurately. Nobody at the firm liked doing it, it was painfully slow, and it was pulling them away from the actual legal work they were supposed to be doing. But it was critically important to their business model because that's how they charge.

His frustration wasn't mild. It was visceral. And that's exactly the kind of signal you want when you're looking for a problem worth solving.

The Process: Interview to Structured Insight

Here's how I turned that one conversation into a structured foundation for a SaaS product.

Step 1: Record with an AI notetaker. I use Fathom, which captures the full transcript of every call. This is important because your job in the interview is to be present and listen — not scribble notes. Copy the full transcript afterward.

Step 2: Paste into Claude. I created a new Claude project specifically for this SaaS build. Having a project means Claude retains context across multiple chats as we progress through each step. I pasted the full transcript along with a prompt asking Claude to extract specific categories of information.

Step 3: Extract the key categories. My prompt asked Claude to identify the primary pain point, secondary pain points, how the firm currently tries to solve the problem, how well that existing solution works, what their dream solution would look like, and some early thinking on how we might wire it up technically.

What Claude Found

Claude came back in seconds with incredibly useful structure. The primary pain: "throwing money out the window." The secondary pain: the firm owner genuinely hates time tracking. The existing solution: barely functional — they're doing it manually and inconsistently. The dream scenario: something passive, automated, that just works in the background.

It even started surfacing early roadmap elements and technical considerations for how the solution might work, including what a V1 might look like to get into users' hands as quickly as possible.

Why This Matters

I now have a real person with a real problem, documented and structured. Not a hypothetical persona. Not a guess. A real business owner who told me in his own words what's broken and what he wants instead.

This structured output becomes the foundation that everything else gets built on — the landing page copy, the solution design, the feature set, the pricing strategy. Every decision traces back to this conversation.

The Technical Viability Check

One thing I like to do early — even at this stage — is a basic technical viability test. We don't need to solve every engineering problem, but I want to know that what I'm planning to build is actually possible. In this case, I explored whether we could integrate with the email platforms and notetakers that law firms use to capture the context we'd need. A quick API check confirmed we could access the data we'd need from platforms like Microsoft Outlook and Fathom.

We can't ship magic. It might look like magic to users, but it needs to work technically, consistently, and reliably. Confirming technical viability early prevents you from selling something you can't actually build.

Your Takeaway

Use an AI notetaker for every customer interview. Paste the full transcript into Claude and ask it to extract the pain, the existing solution, the dream scenario, and the early technical ideas. That single conversation — structured properly — is the foundation your entire SaaS gets built on.

Don't skip this step. Don't start with a feature list or a tech stack. Start with a real person and a real problem.

Next in the series: Day 2 — Market Validation. We take this one conversation and find out if it's an industry-wide pattern.

Start the free 5-day email course

Watch the Build in Public Series on YouTube