If people visit, sign up, or try your product but do not convert, do not guess why. Use founder-led conversations to learn what users expected, where they got stuck, and what they would pay for.
June 4, 2026
A lot of early products have attention before they have clarity.
People visit the website.
Developers fork the repo.
Users create accounts.
Someone tries the free plan.
A few people ask questions.
Most disappear.
From the outside, this can look like traction. From the inside, it is confusing.
You can see that people are interested, but you still do not know the important things:
Analytics can tell you where people dropped off.
It cannot tell you what they misunderstood.
That is why early teams should talk to the people who are already showing intent.
The goal of the 100 Conversations Method is simple:
Before you rebuild the product, rewrite the website, or change pricing, get 100 conversations with people already visiting, using, evaluating, or abandoning your product.
Not 100 survey responses.
Not 100 anonymous pageviews.
Not 100 AI-generated summaries detached from the original user.
100 real conversations.
Some will be short. Some will be shallow. Some will be support questions. Some will not be useful at all.
But a small number will change how you think about the product.
Those are the conversations you are looking for.
The 100 Conversations Method is:
Turn high-intent product traffic into conversations, turn conversations into evidence, and turn evidence into decisions.
The output is not “we had 100 chats.”
The output is:
The method works because early product teams usually do not lack opinions.
They lack enough direct evidence from people who are already close to using or buying.
100 is not a magic number.
You can learn something from 5 conversations. You can often see early patterns after 20. By 50, you should have real signal. By 100, repeated patterns become much harder to ignore.
The reason to use 100 is that it creates a serious enough target.
If you only talk to 5 people, you may overfit to whoever happened to reply first.
If you aim for 100, you are forced to build a repeatable learning loop:
Use 50 as the first milestone and 100 as the full method.
At 50 conversations, ask:
At 100 conversations, ask:
Research on qualitative learning supports the general idea that small numbers of well-targeted conversations can produce meaningful insight. A systematic review of qualitative saturation found that many studies reached saturation with 9–17 interviews when the audience was relatively homogeneous and the research objective was narrow. Usability research has also long argued that small batches of qualitative sessions can reveal many important usability problems, especially when teams iterate between rounds.
The 100 Conversations Method is not about statistical proof.
It is about finding the patterns that are obvious once you finally hear users explain them in their own words.
Stand is human-first website chat with AI stand-ins and live human takeover.
You install a lightweight chat widget on selected pages of your site. Visitors can talk to a real person when someone is available. When the founder, rep, or expert is away, busy, or at capacity, a named AI stand-in answers transparently and can hand the conversation back to a human.
For this method, Stand is useful because it is not just a generic support bot. It helps you run a product-learning loop from real website conversations:
The method does not require Stand. You can do customer discovery manually.
Stand makes the loop easier to run on the traffic you already have.
Useful Stand guide chapters:
The 100 Conversations Method works best when you already have some kind of interest, but not enough revenue clarity.
Good signals include:
This is especially useful for:
The method is less useful when there is no traffic, no audience, and no plan to create a traffic spike.
Even then, the smaller version still matters:
Do not waste the few high-intent visitors you already have.
Most visitors will not start a conversation.
That is normal.
Public live-chat benchmarks vary a lot by product category, traffic quality, page placement, prompt, and whether the chat invitation is passive or proactive.
One older live-chat benchmark reported that about 1.6% of website visitors became chatters on average, with proactive invitations increasing engagement materially. Another live-chat operator describes reactive live-chat engagement around 2% of site traffic and proactive engagement above 7% in its cited benchmark.
For early B2B products, a conservative planning assumption is:
100 high-intent visitors → 1 conversation
That gives you a simple planning model:
| High-intent visitors | Conversations at 1% | Conversations at 2% | Conversations at 5% |
|---|---|---|---|
| 500 | 5 | 10 | 25 |
| 1,000 | 10 | 20 | 50 |
| 2,500 | 25 | 50 | 125 |
| 5,000 | 50 | 100 | 250 |
| 10,000 | 100 | 200 | 500 |
Do not treat 1% as destiny.
Treat it as a conservative starting point.
The rate can be significantly higher depending on:
This is something to optimize during the campaign.
Track the funnel:
| Metric | What it tells you |
|---|---|
| High-intent visitors | Whether the page has enough opportunity |
| Widget shows | Whether Stand is actually being seen |
| Greeting opens | Whether the greeting creates curiosity |
| Chat starts | Whether visitors are willing to engage |
| Useful insights | Whether conversations are producing PMF signal |
| Follow-ups | Whether there is commercial or research value |
| Product changes made | Whether learning is turning into action |
The goal is not to maximize chats at any cost.
The goal is to maximize useful conversations with the right visitors.
Not every conversation will produce PMF insight.
Some visitors will ask simple support questions.
Some will be curious but not serious.
Some will want something outside your product direction.
Some will not reply after the first message.
That is fine.
A practical working assumption is:
5 conversations → 1 useful founder insight
That means:
| Conversations | Expected useful insights |
|---|---|
| 10 | 2 |
| 25 | 5 |
| 50 | 10 |
| 100 | 20 |
Your numbers may be better or worse.
The important thing is to measure insights, not just conversations.
A useful insight is something that can change a decision.
Examples:
| Insight type | Example | Decision it affects |
|---|---|---|
| Positioning | “I thought this was for solo developers, not teams.” | Homepage, use-case pages, onboarding |
| Onboarding | “I connected the repo but did not know what to do next.” | Checklist, empty state, setup flow |
| Packaging | “We would need team permissions before paying.” | Pro or Enterprise plan design |
| Pricing | “This is useful, but I do not know what is included.” | Pricing page, FAQ, plan names |
| ICP | “The real buyer is the platform team, not individual engineers.” | Target segment, outbound, messaging |
| Docs | “I could not find an example for my framework.” | Docs structure, examples, guides |
| Sales | “We need security information before introducing this internally.” | Trust page, follow-up, procurement materials |
| Roadmap | “Everyone asks for the same integration before they can use this.” | Roadmap priority |
The output of the method is not a research report.
The output is better decisions.
Do not place Stand everywhere on day one.
Start where a silent visitor hurts.
Good first surfaces include:
Visitors on the pricing page are already evaluating value, packaging, budget, or fit.
Good greeting:
Founder here — wondering which plan fits? Tell me what you are trying to do.
What you learn:
Docs traffic can be high-intent, especially for devtools, APIs, infrastructure, and open-source products.
Good greeting:
Trying to set this up? Tell me what you are building — I can point you to the right example.
What you learn:
Onboarding is where expectations meet reality.
Good greeting:
What were you hoping to get done today?
What you learn:
A dashboard visitor has already shown more intent than a homepage visitor.
Good greeting:
Founder here. If this page is not showing what you expected, tell me what you were looking for.
What you learn:
This is where willingness to pay becomes concrete.
Good greeting:
What is missing before this would be worth paying for?
What you learn:
People who leave often know exactly what did not work.
Good greeting:
What made this not worth continuing?
What you learn:
Launch traffic disappears fast.
Good greeting:
Founder here during launch — what were you hoping this would help you do?
What you learn:
A QR code, demo page, or event landing page can turn offline interest into follow-up.
Good greeting:
Met us at the event? Tell us what caught your attention and we’ll follow up with the right next step.
What you learn:
A generic chat prompt says:
How can we help?
That is okay for support.
It is weak for product discovery.
A founder-led prompt says:
Founder here — what were you hoping this would help you do?
That is much better.
The prompt should make the visitor feel that a real person wants to understand their situation.
In Stand, the identity around the conversation matters. Use the visible parts of the chat experience deliberately:
For example, a founder can make the invitation more credible by using a real photo, a title like “Co-founder,” and a greeting that explains why the conversation exists.
Good prompts:
Do not ask all of these at once.
Start with one question.
The best default opening is usually:
What were you hoping to do with this?
It is simple, non-salesy, and reveals the gap between your positioning and the user’s expectation.
The greeting is not just copy.
It is a positioning experiment.
Try three or four variants and judge them by useful conversations, not just opens.
Founder here — what were you hoping this would help you do?
Use when you do not yet know why people arrive.
Trying to use this for a real project? Tell me what you are building.
Use when you want to separate curiosity from real intent.
Stuck in setup? Tell me what you are connecting and I’ll help.
Use on docs, onboarding, API, integration, and configuration pages.
What is missing before this would be worth paying for?
Use on pricing, upgrade, and paywall pages.
Evaluating this for a team? Tell me what requirements matter before you can adopt it.
Use when you suspect team or enterprise demand is hiding inside free usage.
Keep the greeting that creates the most useful conversations.
Not necessarily the one that creates the most conversations.
The goal is not to pitch immediately.
The goal is to understand.
Use this simple flow.
Ask:
What are you trying to get done?
Listen for:
Ask:
What did you expect this product to do when you arrived?
Listen for:
Ask:
What stopped you from continuing?
Listen for:
Ask:
If this worked the way you wanted, who would pay for it and why?
Listen for:
Ask:
Would it be useful if we showed you how to solve that with the current product?
or:
Can I send you a short setup path for your use case?
or:
Would you be open to a 15-minute call so we can understand this better?
The best conversations often turn into onboarding, sales, roadmap clarity, or messaging changes.
But only after you understand the user.
A PMF campaign does not need a complex setup.
Start with one clear surface, one clear invitation, and one review rhythm.
Start with one of these:
Pick the page where the visitor’s question is most valuable.
Use real identity when possible.
For a founder-led campaign, the visitor should immediately understand that the conversation is with someone close to the product.
Use:
This matters because “Support bot” creates one kind of conversation.
“Co-founder here — what were you hoping this would help you do?” creates another.
The AI stand-in should not try to interview everyone immediately.
A good instruction is:
Help the visitor first. If they are evaluating the product, stuck in setup, describing a use case, or asking whether this fits their workflow, ask for permission to understand their situation and collect product discovery evidence.
Give the agent:
Do not ask for every possible insight at once.
Choose up to three current questions.
Examples:
The narrower the research question, the easier it is to learn something useful.
Labels are useful when the volume starts to grow.
Good labels for this method:
high-intent-buyerconfused-evaluatorpricing-blockersetup-blockermissing-integrationunexpected-use-caseenterprise-signalwilling-to-paycompetitor-comparisonfollow-up-neededA good label should make the next action obvious.
Bad label:
Product feedback
Better label:
Pricing blocker
Best label:
Team pricing blocker
The goal is not to classify everything.
The goal is to notice the conversations a founder or product lead should review or join.
Some conversations should become follow-ups.
Use follow-up capture when the visitor:
Do not force every visitor through a lead form.
Capture contact details when there is a reason.
You do not need to sit in the dashboard all day.
Let the AI stand-in handle the first layer.
Join when it matters:
In Stand, a human can take over, offer to join with the visitor’s consent, or start typing and hand the conversation from AI to human.
Use that deliberately.
Do not rely on memory.
Review the conversations.
Look for repeated:
Use filters and labels to focus on the conversations that matter.
Export matching conversations as JSON when you want to analyze them in your favorite AI tools.
A useful prompt for analysis:
Analyze these product discovery conversations. Identify repeated use cases, repeated blockers, pricing or budget signals, onboarding confusion, missing integrations, and exact phrases we should reuse in website copy. Separate strong evidence from weak signals. Recommend the top 5 changes to messaging, onboarding, pricing, or roadmap.
The AI analysis is not the source of truth.
The conversations are.
Do not wait until the end to learn.
Use a review cadence.
Ask:
Change placement and prompts if needed.
Ask:
Change the prompt, the page, or the AI stand-in instructions.
Ask:
Make one meaningful change.
Examples:
Ask:
By 100 conversations, you should have enough repeated signal to make sharper decisions.
Not perfect decisions.
Sharper ones.
At the end of the first 50 conversations, write a short memo.
Do the same again at 100.
Use this format.
Example:
18 solo developers, 12 startup founders, 9 platform engineers, 6 product managers, 5 enterprise evaluators.
Example:
Most visitors came for setup help, GitHub integration, internal workflow automation, or pricing clarification.
Example:
The top blockers were unclear onboarding, missing examples, uncertainty about team use, and lack of visible security information.
Example:
The strongest paid signals were team collaboration, SSO, audit logs, priority support, managed hosting, and implementation help.
Example:
Visitors did not say “workflow intelligence.” They said “review bottlenecks,” “manual checks,” “GitHub cleanup,” and “getting our team to actually use it.”
Example:
Do not produce a 30-page research report.
Produce decisions.
Do not promise yourself 100 conversations in two weeks unless your traffic supports it.
Use the traffic you have.
A simple forecast:
| Formula | Meaning |
|---|---|
| Expected conversations per week = high-intent visitors per week × expected chat rate | How many conversations you can expect |
| Weeks to 50 = 50 / expected conversations per week | Time to first meaningful milestone |
| Weeks to 100 = 100 / expected conversations per week | Time to full method |
Example:
| High-intent visitors per week | Chat rate | Expected conversations per week | Time to 50 | Time to 100 |
|---|---|---|---|---|
| 250 | 1% | 2–3 | 17–25 weeks | 34–50 weeks |
| 500 | 1% | 5 | 10 weeks | 20 weeks |
| 1,000 | 1% | 10 | 5 weeks | 10 weeks |
| 2,500 | 1% | 25 | 2 weeks | 4 weeks |
| 5,000 | 1% | 50 | 1 week | 2 weeks |
Low traffic does not mean the method fails.
It means the mode changes.
Use this when you have enough traffic or a planned spike.
Good examples:
Goal:
50–100 conversations in 2–6 weeks.
Use this when traffic is modest.
Goal:
Never waste a high-intent visitor.
You may only get a few conversations per week.
That is still useful if you review them properly.
For a low-traffic product, one good conversation can be worth more than 500 silent pageviews.
Use this when you do not have enough organic traffic.
Create high-intent moments:
The key is to add Stand before the spike.
Launch traffic disappears fast.
Capture it while attention is highest.
More pages do not automatically mean better conversations.
Start on one high-intent surface.
Learn.
Then expand.
“How can we help?” is not wrong.
It is just weak for product discovery.
Use a prompt tied to the visitor’s moment.
Visitors did not come to your site to become research participants.
Help first.
Then ask discovery questions when the conversation earns it.
A campaign with 100 shallow chats can be worse than a campaign with 25 useful ones.
Measure useful insights.
A feature request is not automatically a product decision.
Ask:
The value is often in the wording.
Visitors tell you how they think about the problem.
Do not reduce everything to tags too quickly.
If an AI stand-in is answering, be clear.
The point is not to pretend.
The point is to keep the conversation moving until a human should join.
A conversation campaign is only useful if it changes behavior.
After every review, make one change.
The method should stand on its own before pricing enters the conversation.
First, decide whether talking to current visitors is useful.
Then decide how much capacity and routing you need.
A practical path:
Stand’s Base plan is designed to let teams start this loop without a credit card. It includes 15 chats per week, live takeover, AI stand-ins, lead capture, chat history, and product discovery reports.
Teams with more traffic, faster campaigns, or a need to avoid watching every conversation manually can move to Pro. Pro includes more monthly chat capacity and custom labels that can notify the right person when an AI-handled conversation looks worth joining.
The point is simple:
Pro should feel like a continuation of useful signal, not a leap of faith.
Do not use Stand only to answer questions.
Use it to ask better ones.
A support mindset asks:
How quickly did we resolve the issue?
A PMF mindset asks:
What did this conversation teach us about why people do or do not want the product?
Both matter.
But if you are still searching for product-market fit, the second question is more important.
You do not need a perfect research process.
Start with:
The default greeting:
Founder here — what were you hoping this would help you do?
Then listen.
Label the important conversations.
Follow up when the visitor gives you a reason.
Review the transcripts.
Export the conversations when you want deeper analysis.
Change the product, messaging, onboarding, pricing, or follow-up based on what repeats.
That is the 100 Conversations Method.
Not more chat.
More clarity.