They Said They Loved It. They Meant 'Interesting.'

I once booked twelve calls in a week because I was sure I had found my next product. Invoice follow-ups for freelancers. Everyone I knew said freelancers hated chasing payments. I had a landing page draft open in another tab and a Stripe product name already typed into a notes file. Call three ended with a freelancer saying, "Yeah, that sounds useful," while scrolling his phone. Call seven was warmer. Call nine was the one that stuck with me: she walked me through the last overdue invoice, showed me the exact email thread, and then admitted she would never switch off the spreadsheet she had used for six years because it already worked well enough.

I closed the notebook. Not because the idea was stupid. Because I had finally stopped pitching long enough to hear the real answer.

That is the whole point of micro-saas customer interviews. Not to collect quotes for a landing page. Not to hear people say your idea is cool. To find out whether a specific person has a painful, frequent problem they are already trying to solve, and whether your solution would beat the messy workaround they already tolerate.

If you have been reading about how to validate a micro-SaaS idea, you already know interviews sit near the center of that work. This piece is the interview playbook itself. How to find people. What to ask. How many calls are enough. How to read your notes without lying to yourself. I will use made-up but realistic examples when I need numbers. I will say when they are hypothetical.

I am not arguing that interviews replace money tests. They do not. A deposit still beats a notebook full of quotes. What interviews do is stop you from pricing a fantasy. They tell you which fantasy was never going to clear the checkout page.

Revenue is still the only validation that counts. Interviews are how you get close to that truth before you spend a month building something polite people never buy.

Micro-saas customer interviews: stop pitching and start listening

A customer interview is a short conversation where you learn how someone currently deals with a problem. You are not selling. You are not demoing. You are not fishing for a compliment that lets you open Cursor with a clean conscience.

That sounds obvious until you are on the call. Then your brain does what founder brains do. It fills silence with features. It answers questions nobody asked. It hears "interesting" and translates it into "build it."

I have done that. More than once. The pattern is always the same. I talk for the first five minutes. The other person is polite. I leave the call energized. Two weeks later I have a repo and no buyers.

The useful version of micro-saas customer interviews has a different shape. You talk less than a third of the time. You ask about the last time the problem happened. You stay in past behavior. You write down their words, not your interpretation. You end without a pitch, or with a pitch so late and so soft that it cannot contaminate the first twenty minutes.

Think of it as evidence collection. You are trying to answer four questions. Does this problem happen often enough to matter? Is the current workaround expensive in time, money, or stress? Do people already spend money or hours trying to fix it? Would a better tool displace what they already use?

If you cannot get clear answers to those, you do not have validation. You have a vibe.

This is different from a sales call, a demo, or a user test of a prototype. Those come later, after you have a reason to believe the problem is real. Interviews come first because they are cheap and because they force you to face language that is not yours. Competitors and App Store listings can show you what exists. Competitor research tells you what other products claim. Interviews tell you what people actually do on a Tuesday afternoon when nobody is watching.

One more distinction that saves people time: a support call with an existing customer is not the same as a discovery interview with a prospect. Support is about unblocking someone who already chose you. Discovery is about whether anyone should choose you in the first place. Mix them and you will overfit your roadmap to the loudest paying user while still not knowing if the market is wider than that one inbox thread.

Why most "user research" is just you fishing for compliments

Most founders I talk to believe they have already "talked to users." What they usually mean is they mentioned the idea to three people who like them, got encouraging noises, and treated that as green light.

That is not research. That is comfort.

Compliment fishing looks like this. You describe the product. You ask if they would use it. You ask if the price feels fair. You ask if they would pay $29 a month. They say maybe, or sure, or "I'd probably try it." You write "strong interest" in your notes. You start building.

The problem is that hypothetical future intent is almost worthless. People are bad at predicting their own behavior, and they are especially bad when a founder they like is watching their face for approval. "Would you use this?" is a question that invites a soft yes. "Walk me through the last time this broke for you" is a question that invites a story. Stories have edges. Soft yeses do not.

I used to keep a private rule after a bad run of false positives: if I explained my solution before minute fifteen, the call did not count. Harsh? A little. Effective? Extremely. It forced me to earn the right to talk about the product by first proving I understood their world.

Another trap: interviewing people who are adjacent to the problem but not inside it. You build for freelance designers. You interview a design agency owner who "works with freelancers all the time." He is thoughtful. He has opinions. He is not the buyer. His advice will sound sophisticated and still miss the daily pain.

Or you interview people who already solved the problem with a tool they love. They can describe the space. They will not buy you. That conversation is useful for market research, not for demand.

There is also the survey trap. You send a Google Form with twelve questions, get thirty responses, and feel scientific. Surveys can help you size themes later. They are weak at the beginning because they flatten stories into checkboxes. You learn that 64% "somewhat agree" the problem is annoying. You still do not know what they did last Thursday when the invoice sat unpaid. Interviews recover the Thursday.

The compliment version of research feels productive because it is social and affirming. Real interviews feel slower and ruder. Someone will tell you your framing is wrong. Someone will say the problem is real but not urgent. Someone will say they already hacked together a Notion board and they are fine. Those are the calls that save you months.

Pick the right people, or the answers are noise

Bad sampling wrecks good questions. If you talk to the wrong people, every answer is a false signal dressed up as insight.

Start with a narrow ideal customer, not a market. "Small businesses" is not a customer. "Solo bookkeepers who send more than twenty invoices a month and chase late payments by hand" is a customer. Write that sentence before you schedule anything. If you cannot write it, you are not ready to interview. You are still shopping for an idea.

Friends and family will ruin your signal

Use friends for one thing only: practicing the script until you stop sounding like a podcast host. Then throw the answers away.

People who love you will protect you. They will soften hard truths. They will invent interest to be kind. I once asked my brother if freelancers would pay for invoice follow-ups. He said absolutely. He is a teacher. He has never sent an invoice in his life. That conversation taught me nothing about freelancers and everything about how desperately I wanted permission.

If your only interviewees are people who already want you to succeed, you are running a pep rally.

Ideal customers vs convenient strangers

Convenient strangers are people who reply quickly because they hang out in the same Discord as you. Ideal customers are people who match the job, the workflow, and the pain frequency you wrote down.

Sometimes those overlap. Often they do not.

I prefer slightly inconvenient people. Someone who fits the ICP and takes three days to book a call is usually more valuable than a friendly indie hacker who will chat for forty minutes about anything. The indie hacker is practicing founder empathy. The bookkeeper is living the problem.

A quick filter I use before I accept a call: do they personally do the job I am studying, or do they only manage people who do? Did the problem happen to them in the last thirty days, or is it theoretical? Are they already spending time or money on a workaround? Would they plausibly pay for software in this category, even if not mine?

If two or more answers are no, I still might talk to them for context. I will not count them toward my validation total.

One practical note on titles. Job titles lie. "Operations manager" at a five-person agency can mean they still send every invoice. "Founder" at a twenty-person shop can mean they have not touched the workflow in two years. Ask what they personally did last week. Roles on LinkedIn are marketing. Behavior is the filter.

Finding strangers who will actually talk to you

This is where most people stall. They accept that interviews matter, then freeze because they do not know who to message.

You do not need a huge network. You need a repeatable way to get ten conversations with the right strangers.

Where I look when I have no network

I start where the problem already has a paper trail.

Reddit threads where people complain about the exact workflow. LinkedIn search for the job title plus a recent post about the tool they hate. Indie Hackers comments under related launches. Facebook groups for a niche profession. Review sites for competitors, especially one-star and three-star reviews where someone describes what broke. Twitter or X searches for "does anyone else" plus the pain phrase.

If there is a competitor with a public community, lurk first. Do not pitch. Look for people describing workarounds in their own language. Those phrases become your interview vocabulary later.

Cold email still works when it is short and specific. Not "I'd love to pick your brain." That phrase deserves to die. Something closer to: "I am researching how freelance bookkeepers chase overdue invoices. Could I ask you ten questions about the last time a client paid late? Fifteen minutes. Happy to send a $20 gift card."

That ask is clear. It states the topic. It states the time. It offers a thank-you. It does not pretend this is a networking coffee.

The ask that gets a yes without sounding salesy

Response rates climb when three things are true. The person recognizes themselves in the first sentence. The request is small. You are not selling a product in the invite.

I schedule on Calendly with a fifteen or twenty minute slot. Longer invites scare people. You can always run over if the conversation is good. You rarely need forty-five minutes for a first problem interview.

Record with permission, or take notes live if recording makes them stiff. I usually take notes. Typing keeps me quieter. Quiet is the skill.

If someone says no, thank them and ask one more question: who else deals with this weekly? One warm referral from a no is often better than another cold yes.

A simple weekly cadence works better than a heroic binge. Five outreach messages a day for four days beats twenty messages on Sunday night and then nothing. People reply at odd hours. Your job is to keep the pipeline warm until the calendar fills.

You will feel awkward the first ten asks. That awkwardness is not a signal that the method is wrong. It is a signal that you are doing founder work instead of founder cosplay.

Customer discovery interviews saas founders run like demos

I need to name a failure mode that is almost universal in customer discovery interviews saas founders schedule with good intentions.

The call starts. The founder spends two minutes on context, then opens a Figma file, a Loom, or a half-built app. "I just want to show you something real quick so you can react." The rest of the call becomes a critique of the mock. Useful for design. Useless for demand.

A demo contaminates the interview. Once people see your solution, every answer bends toward your frame. They will tell you which button is confusing. They will not tell you whether they would have sought this product on their own. You traded problem discovery for product feedback before you earned product feedback.

If you already have a prototype, run two separate conversations. One problem interview with no screen share. One prototype session later with different people, or with the same people only after the problem conversation is done and noted.

Another demo-shaped failure: leading with your origin story. "I built this because I was frustrated with X." Now the interviewee is cast as your therapist or your cheerleader. They will help you feel understood. That is not the same as confirming a market.

The discipline is simple and uncomfortable. Keep the first fifteen minutes sterile. No product name. No feature list. No "we are building." Just their world.

If they ask what you are working on, you can say, "I am still deciding whether this problem is worth solving with software. I wanted to understand how you handle it today." That sentence protects the call. It also happens to be honest.

Founders who come from engineering often treat the interview like a requirements meeting. They jump to edge cases, data models, and integrations. Slow down. You are not collecting a backlog yet. You are checking whether the backlog deserves to exist. Requirements meetings assume the product should be built. Discovery interviews question that assumption out loud.

Problem interview questions saas: the ones that surface real pain

Scripts help when you are nervous. They hurt when you recite them like a robot. Keep a short list of prompts, then follow the story wherever it goes.

Here is the spine I use for problem interview questions saas conversations. Not every question every time. Enough of them to keep myself honest.

Open with the last time it happened

"Walk me through the last time you had to deal with [problem]."

That sentence does more work than any clever framework. It pulls the person into a specific memory. Specific memories have details: tools, timestamps, emotions, workarounds, who they blamed.

Follow with quiet. Let them talk. When they finish, ask what happened next. Then ask what they tried first.

If they cannot remember a recent example, that is data. A problem that never rises to memory is usually not painful enough to fund a subscription.

Dig into workarounds, cost, and urgency

Once you have a story, dig sideways:

• What are you using today to handle that?
• What is annoying or expensive about that workaround?
• How often does this come up in a normal month?
• Who else gets involved when it goes wrong?
• What happens if you ignore it for a week?
• Have you paid for any tool or freelancer to help with this?

Listen for dollars, hours, and embarrassment. Those are the currencies that turn a mild inconvenience into a product category.

I care less about whether they "hate" the current tool and more about whether they have already spent money trying to escape it. Spreadsheets are fine until someone is paying a VA ten hours a month to maintain them. Then you have a budget hiding in plain sight.

What I never ask until the end (if at all)

I avoid these early, and often entirely: would you use a product that does X, how much would you pay, do you like this idea, and if I built this would you sign up.

Those questions feel efficient. They produce answers that feel decisive. They are contaminated by politeness and imagination.

If the conversation has been rich and they ask what I am exploring, I may float a one-sentence offer near the end. Not a pitch deck. One sentence. Then I shut up and watch whether they lean forward or change the subject. Curiosity after a problem conversation is a better signal than praise after a pitch.

I also ask who else I should talk to. Referrals from people inside the pain are gold. Referrals from people outside it are noise.

A few more prompts that unlock details when someone stays abstract. Ask if they can show the last email or message about it. Ask what they tried before settling on the current workaround. Ask which tool they open first if it breaks again tomorrow morning. Ask who gets annoyed first when it goes wrong, them or someone else.

You do not need all of them. You need enough curiosity to leave the abstract cloud and land in a real workflow.

How many customer interviews before building (and when to stop)

People want a number. Fair.

For a typical micro-SaaS bet in a niche you somewhat understand, five strong interviews with matching strangers is a minimum. Ten is better if the niche is new to you or the problem is fuzzy. I have rarely needed more than fifteen before I knew whether to keep going, narrow hard, or kill the idea.

The number is not the point. Pattern recognition is the point.

You are listening for repetition. Same pain language. Same workaround. Same trigger that makes the problem show up. Same reason they have not fixed it yet. When interview eight sounds like interview three with different names, you have a pattern. When interview eight invents a new problem category entirely, you do not have a product yet. You have a collage.

How many customer interviews before building also depends on what "building" means. If the build is a weekend experiment you are willing to throw away, three sharp conversations plus a fake door page might be enough. If the build is four weeks of auth, billing, and edge cases, you want stronger evidence. Cheap builds can afford lighter validation. Expensive builds cannot.

Stop conditions matter as much as start conditions.

Stop and build (or move to a paid test) when you can describe the problem in their words without looking at notes, when several people independently named the same workaround pain, when someone asked when they could try a solution without you pitching hard, and when you have a credible next step toward money: deposit, pre-sale, or a priced waitlist with real intent.

Stop and change the idea when every interview needs heavy prompting to recall the problem, when people have workarounds they are oddly loyal to, when the pain is real but annual rather than weekly, or when nobody can point to time or money currently spent on the mess.

Do not keep interviewing forever because it feels safer than deciding. Endless research is another way to avoid risk. Five honest nos are more useful than twenty polite maybes.

Say you finish eight interviews in a niche. Six people describe the same weekly scramble. Two are indifferent. That is not a failed study. That is a signal with noise around it. Dig into the six. Ignore the fantasy that every conversation must glow.

If you want a structured score alongside the conversations, use something like the Idea Validation Scorecard. Interviews feed the score. They do not replace judgment.

Solo founder customer interviews after you already shipped

People treat interviews as a pre-build ritual. That is incomplete.

After you ship, solo founder customer interviews become a retention and roadmap tool. Your early paying customers know where the product is sharp and where it is theater. Recent cancellations know what broke the relationship. Trial users who never activated know which promise failed in the first session.

I schedule these differently. Shorter. More specific. "You signed up three weeks ago and have not created a second project. Can I ask what got in the way?" That email is uncomfortable to send. It is also one of the highest-ROI messages a solo founder can write.

Post-launch interviews are where you learn the difference between requested features and necessary features. People will ask for integrations, dashboards, and AI summaries. Watch what they currently export to spreadsheets or Slack instead. The workaround after signup is usually the real roadmap.

I also interview people who almost bought and did not. Lost deals teach pricing and positioning faster than happy customers do. Ask what they compared you against. Ask what almost got them over the line. Ask what made them wait. Then go fix the page or the offer before you invent a new module.

If you are earlier than paying customers, interview waitlist signups who never converted, or people who clicked pricing and bounced. Those conversations sit between validation and launch. They tell you whether your promise matches the problem you studied.

I keep a lightweight log after shipping: who I talked to, date, stage (trial, paid, churned), and one sentence takeaway. Not a CRM novel. Just enough so month three Max can see that four people mentioned the same onboarding dead end. Patterns after launch compound the same way patterns before launch do. You just have better access to the humans.

What "validated" looks like when you read your notes

Validation is not a feeling you get on the walk after a good call. It is a pattern you can point to across several notes.

When I review a stack of interview notes, I look for four layers.

First, language overlap. Are people naming the problem with similar verbs and metaphors without hearing each other? If five freelancers independently say they "hate chasing," you have language. If each one describes a different emotional center, you may have several products hiding under one slogan.

Second, frequency. Weekly pain beats annual pain for subscription software. Annual pain can still work with a different business model. Do not force a monthly SaaS onto a once-a-year tax headache unless you have a reason.

Third, current spend. Time counts. Money counts more. A person who already pays for three overlapping tools is proving budget. A person who complains but spends nothing and delegates nothing may want empathy more than software.

Fourth, urgency. Did they try to fix this recently, or is it a vague someday annoyance? Urgency is what turns a yes into a checkout.

I keep a simple one-page summary after every five calls. Not a twelve-tab spreadsheet. One page: ICP sentence, top three pains in their words, current workarounds, objections, and a go / narrow / kill recommendation. If I cannot fill that page without squinting, I do not have clarity yet.

"Validated" for me usually means I am ready to put a price in front of strangers and ask for a commitment. Interviews alone are not the finish line. They are the permission slip to run a sharper money test. Fake doors, deposits, and early-bird offers still matter. Interviews make those tests honest instead of random.

A concrete example, framed as hypothetical. You talk to nine freelance bookkeepers. Seven describe chasing invoices by hand every Friday. Four already pay for a tool that almost does the job but fails on reminder tone or multi-client views. Three ask when they can try whatever you are exploring. That stack of notes is closer to validated than twenty LinkedIn comments saying "I'd use this." It still is not done until someone pays or commits to pay. The interviews earned you the right to ask.

When the interviews lie to you anyway

Interviews can mislead even when you run them well.

People rewrite history. They remember being more organized than they were. They understate how much they tolerate chaos. They overstate how quickly they would switch tools. That is human. Your job is to weight behavior over aspiration.

Selection bias is always there. The people who agree to talk are often more helpful, more reflective, and more product-curious than the average buyer. That can inflate sophistication. The quiet majority might just want a dumb button that emails a reminder. Do not build for your most articulate interviewee unless that person also matches the volume of the market.

Courtesy bias survives even with strangers. Some people hate disappointing a founder on a call. Watch what they do after the call more than what they say on it. Did they introduce you to a peer? Did they ask for a follow-up? Did they go quiet the moment you mentioned price later by email? Silence after warmth is a signal.

Another lie: consensus theater. You hear the same complaint because you recruited from one subreddit that shares one worldview. Expand the sample. Talk to someone who uses the competitor happily. Talk to someone in a slightly different job title. If the pattern collapses, your niche was a forum mood, not a market.

I also distrust interviews where I did most of the emotional labor. If I had to convince them the problem was serious, it was not serious for them. Pain that needs a sales job in a discovery call is not product-market fit waiting to happen. It is a pitch.

Time-of-day and context matter too. Someone on a rushed lunch break may give you the sanitized version. Someone who screenshares their messy inbox may give you the truth. Prefer the messy inbox. If every call stays at the level of slogans, change how you ask, not how hard you hope.

Turning five calls into a yes, a no, or a narrower bet

After the calls, decide. This is the part founders skip because deciding creates accountability.

Three honest outcomes:

Yes, continue. The pattern is clear. The ICP is narrow enough to market. People are already spending time or money. You can write a landing page headline in their language without inventing drama. Next step is a money test, not another month of "research." Put a price on a page. Ask for deposits. Sell a concierge version. Build only what the paid path requires.

No, kill or shelve. The problem is mild, rare, or already solved well enough. People are polite and inactive. You cannot find a budget. Killing an idea early is a win. It returns your calendar to you. Write one paragraph about why it died so you do not revive it in six months under a new name.

Narrow. This is the most common good outcome. The broad idea is mush. A thinner slice is sharp. Maybe freelancers in general do not care, but freelance bookkeepers with QuickBooks and more than fifteen clients do. Maybe the pain is not invoicing. It is the awkward reminder email tone. Narrowing is not failure. It is the usual path from a slogan to a product.

When you narrow, update the ICP sentence and run a few more interviews inside the smaller box. Do not immediately build the narrow version because it feels more exciting. Confirm the smaller pattern first.

I write the decision down with a date. Sounds ceremonial. It prevents the fog where you half-build while half-doubting. Fog is expensive. A dated note that says "kill invoice follow-ups for general freelancers, revisit only for bookkeepers with 15+ clients" is more valuable than another half-finished Figma file.

If you need distribution thinking later, that is a different job. Interviews tell you whether the problem deserves a product. Marketing tells you how strangers will find it. Do not mix those anxieties in the same afternoon or you will use "channel uncertainty" as an excuse to avoid a clear no.

Stuff people ask me before their first call

How many customer interviews before building a micro-SaaS?

Five honest conversations with strangers who have the problem is a solid minimum. Ten is better if you are entering a niche you do not know well. Stop when you hear the same pain, workarounds, and costs repeating without you prompting them. If every call produces a different story, narrow your ICP and start over instead of adding more random interviews.

What should I ask in a customer discovery interview for SaaS?

Ask about the last time the problem happened, what they did next, what they already tried, what it cost in time or money, and what happens if nothing changes. Stay in past behavior. Do not pitch your product early. Do not ask whether they would use a hypothetical tool. Those questions collect politeness, not signal.

Should I pay people for customer interviews?

A small thank-you helps when you are cold-reaching people with busy jobs. Fifteen to twenty-five dollars as a gift card is common and often doubles response rates. Do not pay friends to tell you your idea is great. Pay strangers for their time, then listen harder than you talk.

Can I validate a micro-SaaS with friends and family interviews?

No. Friends and family are biased toward protecting your feelings. They will say encouraging things even when the problem is not painful for them. Use them to practice your script if you need a dry run, then throw those answers away. Real validation comes from people who match your ideal customer and owe you nothing.

What if people love the idea but nobody will pay?

That means the idea is not validated yet. Politeness is free. Payment is not. Go back to the problem statement, tighten who you are talking to, or test a sharper offer with a price on a fake door page. Love without money is a hobby signal, not a business signal.

Should I interview people after I already shipped?

Yes. Early customers and recent churns are some of the highest-signal conversations you can have. Ask what almost stopped them from signing up, where they got stuck in the first session, and what they still do outside your product. Post-launch interviews are how you stop guessing which feature to build next.

You already know if you're avoiding this

If you have read this far and still have not booked a single conversation with a stranger who has the problem, I can guess why. Building feels like progress. Asking feels like risk. A quiet evening with Cursor will not tell you that your idea is thin. A twenty-minute call might.

That asymmetry is why so many polished micro-SaaS products launch into silence. The code worked. The interviews never happened, or they happened as compliment sessions with friends.

You do not need a perfect script. You need one sentence that describes who you want to learn from, ten asks, and five completed calls where you talk less than they do. Write their words down. Look for the pattern. Decide.

If the pattern is weak, you saved yourself a repo. If the pattern is strong, you earned the right to put a price in front of people and see who reaches for their wallet.

That is the job. Not sounding smart on a call. Not collecting testimonials for a homepage you have not earned. Finding out, early and cheaply, whether the problem is real enough to build around.