How to Run Customer Interviews When You Don't Have Customers Yet

You don't need paying customers to run a real customer interview — you need people who already have the job-to-be-done your product would address: people using a spreadsheet, a competitor, or a painful workaround today. Find them, apply the Mom Test, and code what they say as forces of progress, not feature requests.

Quick Answer: Skip "my users" — you have none yet. Interview people who currently feel the pain your product targets, screen them with Mom Test discipline, and log every answer as a push, pull, anxiety, or habit force rather than a wish-list item.

Stop Looking for "My Users" — Look for the Job-to-Be-Done

The fix is a one-word swap: replace "user" with "job-holder." Anyone currently hiring a workaround, a spreadsheet, a competitor, or a manual process to get the job done that your product would eventually do is a legitimate interview subject — whether or not they've ever heard of you.

This isn't a workaround for not having customers. It's closer to how customer discovery is supposed to work in the first place. Steve Blank's Customer Development methodology — the model behind the "get out of the building" mantra taught in accelerators worldwide — was built explicitly for the pre-product state, not retrofitted for it. Blank's argument is that founders who wait for a shippable product before talking to anyone have the sequence backwards: the interviews are supposed to shape the product, not validate one that already exists.

Reframing who counts as an interview subject changes what you ask, too:

• Wrong framing: "Would you use my app that does X?" — a hypothetical question to a hypothetical user, answered with a polite hypothetical yes.
• Right framing: "Walk me through the last time you needed to do X. What did you actually use?" — a factual question to someone who has lived the problem, answered with what really happened.

This distinction matters because most PM literature on customer conversations assumes an existing user base to sample from. The founder-pm reality is different — the complete guide to being a founder-PM covers how the role compresses research, prioritization, and delivery into one person, and interviewing is usually the first of those three you're forced to do without a safety net. Discovery has to run ahead of delivery, not alongside it — a sequencing point covered in more depth in why pre-PMF teams should prioritize discovery over delivery.

Who Actually Qualifies as a Job-Holder

Before you source a single name, write down the job in one sentence — not a feature, a job. "Reconcile expense reports before the monthly close" is a job. "Wants an expense app" is a feature wish already smuggled in. Once the job is written down, three groups usually qualify:

1. Active strugglers — people doing the job today with a manual process, a spreadsheet, or a stitched-together set of tools.
2. Switchers — people who tried a tool for this job and abandoned it, which is often more informative than someone still happily using one.
3. Adjacent professionals — people one step removed from the job (a manager, a downstream consumer of the output) who feel its consequences even if they don't perform it directly.

Where to Source Interview Subjects When Your Product Doesn't Exist

Sourcing without an existing list comes down to three channels, and each trades speed for signal quality differently: communities where the job-holders already congregate, warm introductions through your existing network, and cold outreach to strangers who match the profile. Run all three in parallel rather than picking one.

Communities are the highest-leverage starting point because job-holders self-select into them. A subreddit for freelance bookkeepers, a Slack group for DevOps engineers, a LinkedIn group for procurement managers — these are places where people already describe their pain in their own words, unprompted, which doubles as free problem validation before you've asked a single question.

The table's practical takeaway: start with communities and warm intros to get your first five conversations fast, then deliberately layer in cold outreach once you have a working script — cold responses are the ones least likely to be padded with courtesy, and courtesy is exactly what distorts a founder's early signal.

A Sourcing Cadence That Doesn't Stall

1. Week 1: Post in 2-3 relevant communities (after lurking enough to know the norms) and message 10 warm contacts.
2. Week 2: Send 20-30 cold outreach messages to people matching the job-holder profile, referencing something specific about their situation, not a generic pitch.
3. Week 3 onward: Mine reviews of adjacent tools for recurring complaints, and use those exact phrases as cold-outreach hooks — "I noticed a few people mention X being painful in [tool]..." converts noticeably better than a blind ask.

Founders who skip straight to a beautifully designed landing page before doing any of this are usually avoiding the harder, less controllable work of a live conversation — a pattern the founder-is-the-HiPPO problem describes well: it's easier to trust your own judgment than to expose it to a stranger who might disagree.

The Mom Test Rules That Keep Enthusiasm From Lying to You

Rob Fitzpatrick's Mom Test — named for the idea that a good question survives even your own mother's instinct to be supportive — exists to fix one specific failure mode: people are polite, they want to be helpful, and they will tell you your idea is great even when they'd never buy it. Without a discipline for this, pre-launch interviews reliably produce false positives.

The Mom Test reduces to three rules:

• Ask about their life, not your idea. Questions about the past ("tell me about the last time...") get facts. Questions about the future ("would you...") get fiction, politely delivered.
• Ask about specifics in the past, not generics or hypotheticals. "How do you currently handle X?" beats "How do you usually handle X?" — specificity forces a real memory instead of a generalized self-image.
• Talk less, listen more. The moment you start explaining your idea, you've started coaching the answer you want to hear.

Fitzpatrick's core warning, paraphrased: compliments, hypothetical enthusiasm, and vague future promises ("I'd definitely use that") are the three most common false signals in a founder's first interviews — and all three feel identical to real validation in the moment.

Two behavioral tells separate a Mom-Test-passing conversation from a politeness trap: does the person volunteer specific numbers, dates, or tool names unprompted, and do they ask you a question back (genuine curiosity is harder to fake than encouragement). If ten interviews produce enthusiasm but zero specifics, you've collected opinions, not evidence.

Code Answers as Forces of Progress, Not a Feature Backlog

The fastest way to waste a good interview is to leave it with a list of requested features. The fix, borrowed from Clayton Christensen and Bob Moesta's Jobs-to-be-Done research, is to code every answer against the four Forces of Progress that explain why someone would actually switch to something new: the push of their current situation, the pull of a better solution, the anxiety of change, and the habit/inertia holding them in place.

Feature requests describe a solution someone imagined on the spot; forces describe the actual mechanics of why they would or wouldn't move. A prospect who says "it would be cool if it had dark mode" has given you almost nothing. A prospect who says "I've missed two deadlines this quarter because of this, and I've already looked at three alternatives but none of them talk to our existing spreadsheet" has just handed you push, pull, and anxiety in one breath.

Coding interviews this way also protects you from Teresa Torres' well-documented "solution in search of a problem" trap described in her continuous-discovery work: teams that skip straight to evaluating proposed features never build the causal map of why a switch would happen at all, so every roadmap decision downstream is a guess dressed up as a plan. Forces of progress make that causal map explicit, interview by interview.

This is also where a structured tool earns its keep instead of a pile of call notes. Prodinja's Customer Jobs module builds Forces of Progress directly into how you log a conversation — push, pull, anxiety, and habit are the tags you assign to what a prospect says, so a jobs story starts forming before you have a single line of product built. It's designed to help you probe what pushes and pulls someone toward a new solution well before your product exists to pull them toward.

None of this replaces reading the complete guide to Jobs-to-Be-Done if the framework itself is new to you — Forces of Progress is one layer of JTBD theory, not the whole thing, and the underlying "job" concept is worth understanding before you start coding interviews against it.

Running the Interview: Structure, Cadence, and When to Stop

A pre-launch interview should run 20-30 minutes, follow a past-tense structure borrowed straight from the Mom Test, and end with a request for a referral — the single highest-leverage question most founders forget to ask. Structure beats improvisation because it's the only way to compare answers across conversations.

A workable script, in order:

1. Warm open (2 minutes): Confirm context, not your idea. "You mentioned you handle X for your team — how long have you been doing that?"
2. Story extraction (10-12 minutes): "Walk me through the last time you dealt with this." Follow with "then what happened," repeatedly, until the story runs dry.
3. Cost and workaround probing (5-7 minutes): What do they currently use, what does it cost in time or money, what have they already tried and abandoned.
4. Forces probing (5 minutes): Push, pull, anxiety, habit questions from the table above, only after the story has already surfaced most of the material naturally.
5. Close and referral (2-3 minutes): "Who else do you know who deals with this?" Never skip this — it's how sourcing stops depending entirely on cold outreach.

How Many Interviews Is Enough

There's no fixed number that applies everywhere, but a useful rule of thumb from qualitative research broadly (not specific to product) is to watch for saturation — the point where new interviews stop surfacing new problem language or new workaround patterns. For most narrow B2B jobs, that shows up somewhere in the 8-12 interview range; broader consumer problems often take longer to saturate because the population is more varied.

• Fewer than 5 interviews: too early to draw any conclusion — treat everything as a hypothesis, not a finding.
• 5-10 interviews with a consistent pattern: enough to commit to a direction worth prototyping.
• 10+ interviews with persistent disagreement: the job may be too broadly defined — narrow the segment rather than adding more interviews to the same wide net.

Keep a single log across every conversation rather than scattered notes per call — that's what makes patterns visible instead of buried in a dozen separate documents, and it's the same discipline that carries forward once you're mapping how a prospect's experience evolves across a full customer journey after launch. The habits you build interviewing zero customers are the same habits that keep discovery honest once you have customers to protect you from your own assumptions.

If you're a first-time founding PM building this muscle from scratch, pace yourself — the first 90 days of a founding PM role covers roughly how much of that window should go to talking to job-holders versus building anything at all, and the honest answer is: more than most new PMs expect.

Key Takeaways

• Replace "my users" with "job-holders" — anyone actively struggling with, or having abandoned, a workaround for the problem you're targeting is a legitimate interview subject before you have a single customer.
• Source in parallel, not in sequence: niche communities and warm intros get you fast early signal; cold outreach and review mining add rigor once you have a working script.
• Apply the Mom Test rigorously: ask about specific past behavior, not hypothetical future intent, and treat compliments and "I'd definitely use that" as noise, not validation.
• Code every answer as a force of progress — push, pull, anxiety, or habit — instead of collecting it as a feature request; this is what turns a stack of call notes into an actual causal story.
• Always close with a referral ask — it's the cheapest sourcing channel you have, and most founders forget to use it.
• Watch for saturation, not a magic number — stop adding interviews to the same segment once new conversations stop surfacing new problem language, typically somewhere around 8-12 for a narrow B2B job.
• Log everything in one place so patterns across interviews are visible, not scattered — the same discipline pays off again once you're tracking a real customer journey post-launch.