Chapter 06

Learn from visitor conversations.

Product-minded founders do not only need more demos. They need more evidence: what evaluators were trying to do, what confused them, what alternatives they considered, and what problem was urgent enough to ask about.

Stand Guidebook

Chapter 06 of 12

Field guide

What to learn in this chapter

Collect evidence you can examine: help first, ask permission for research, explore real behavior, and check generated findings against their source conversations.

Need an exact capability definition, plan requirement, or limitation? Browse the Feature Reference.

Why this matters

01

Your best early evidence may come from people who never book a call.

Founders usually hear from friendly customers, sales calls, and support tickets. That leaves a gap: evaluators, skeptics, confused visitors, and people comparing alternatives before they are ready to commit.

Their questions can reveal gaps your existing customers no longer notice. Record what visitors actually say, while remembering that people who choose to chat are only one part of your audience.

Example

Confused evaluator

Situation
The visitor asks whether Stand is a chatbot, live chat, or support suite.
Move
Explain what Stand does and leave the factual answer complete. Record recurring confusion for later review. Do not turn a category question into an unsolicited research interview.
Insight
The confusion can reveal a positioning problem and the category the visitor uses in their head.

Example

Migration blocker

Situation
The visitor says they already built custom chat but product cannot learn from the transcripts.
Move
First explain the relevant transcript and review capabilities. If the visitor is willing to discuss that concrete problem, ask permission for a brief interview; after agreement, ask when it last occurred.
Insight
The value is not "chat history." The value is shortening the delay between raw transcripts and product learning.

Interview discipline

02

Ask about reality, not opinions.

The Product Discovery skill should not ask leading roadmap questions. It should ask about the last time the problem happened, what the visitor tried, who was involved, what broke, what it cost, and what happens if nothing changes.

The Stand-in should stop when the visitor becomes rushed, frustrated, terse, or asks for direct help. The goal is learning with consent, not extracting a survey.

Worked example

Follow the problem, then return to help.

This fictional exchange assumes a UI development tool whose documentation explains component mapping. The visitor describes a past problem; the Stand-in offers relevant help, asks permission for two research questions, and stops when the visitor asks for documentation. The example is not a claim about Stand’s capabilities or another real product.

Consent
The Stand-in asks before changing from help to research.
Reality
One visitor describes the recent handoff in a team of two developers and one designer.
Friction
Generated code does not use their extended components, so they abandoned that workflow.
Boundary
A request for documentation ends the interview; a requested follow-up is recorded without promising a response time.
What to read for
  • The questions ask what happened, not whether the visitor would buy a proposed feature.
  • The account contains a workaround and a consequence, which can guide a deeper interview.
  • One report of a problem is a lead to investigate, not proof that all visitors share it.
We stopped generating screens because the output ignored our extended components. Now we build those screens by hand.
A component map can associate the generated grid with your extended grid, so its export control is preserved. Without that mapping, the generator uses the standard grid. May I ask two questions about your previous attempt?
Sure.
What happened the last time your team turned a design into code?
We have two developers and one designer. The designer shared a link in an issue, but the generator used the standard grid instead of ours, which has an export button.
What did your team do after that?
We stopped using the generator for those screens. A developer now builds them by hand. Is there a guide to using our own components?
Let’s return to that. I do not have a verified guide for your setup. Would you like me to request a follow-up from the team about component support?
Yes. I am Alex; use alex@example.com.
I have recorded your request and the component details for the team to review.

Conversation ended

Figure 6-1. An illustrative exchange, not a customer transcript or a claim about another product.

Question design

03

Attach every question to a decision.

A discovery question is only useful if the answer could change something: the headline, the pricing explanation, the docs path, the onboarding promise, the roadmap priority, or who the founder interviews next.

Use these questions only after the visitor has agreed to a research interview. A factual pricing or documentation question still deserves a direct answer, even when the visitor matches your research audience.

PagePricing
What to learnWhat makes the current solution costly?
Useful follow-upWhen did this last cost your team time or money?
PageDocs
What to learnWhat implementation job brought them here?
Useful follow-upWhat were you trying to ship when you got stuck?
PageComparison
What to learnWhich alternative is already in their head?
Useful follow-upWhat do you need the new option to do better?
PageFeature page
What to learnWhat evidence helped them evaluate a similar tool?
Useful follow-upHow did you check that the last tool met this requirement?

Setup

04

Aim the Product Discovery skill at current questions.

Do not ask the Stand-in to learn everything. Give it the current questions that would actually change your next product or positioning decision.

Open Stand-ins → the chosen Stand-in → Edit → Skills → Product Discovery and enable it. Define whom to interview, the learning goal, and up to three research questions. These questions guide the interview; they are not a script the visitor must complete.

Start with Adaptive depth, which follows the visitor’s engagement. Use Light for brief exchanges or Deep for willing participants with a complex story. Set guardrails for subjects to avoid and when to stop; enable notifications only if you can act on an interview in progress. Save, then test an engaged visitor, a refusal, and a request to return to support.

Stand Product Discovery settings with interview audience, research goal, research questions, guardrails, interview depth, and notification setting.
Figure 6-2. The Product Discovery skill works best when the Stand-in knows whom to interview, what the research goal is, which questions matter now, and when to stop.

Choose up to three research questions

  • What are evaluators trying to replace when they look at Stand?
  • Which pages create confusion about whether Stand is a chatbot or live chat?
  • What makes a visitor trust or distrust AI coverage for a named person?
  • Which competitor comparisons show up before a buying conversation?

Review

05

Treat reports as evidence trails.

To receive synthesized Product Discovery findings, open Digest on Pro or Business, enable Add AI insights to my digest, and save. Choose a cadence or send yourself the last seven days. The report draws on relevant conversations available in that digest period and scope; an empty period cannot produce research evidence.

Read the numbered evidence and caveats, then open the cited conversations. Check that the visitor actually described the problem, distinguish their words from the generated interpretation, and look for counterexamples. Several similar confusion reports may justify a copy test; one enthusiastic feature request is a reason for further research, not a roadmap commitment.

Illustrative digest section

Product discovery

3 fictional interviews
One evaluator could not map a custom grid; a second rebuilt generated screens to restore custom controls; a third needed security approval before a trial.
Finding [1,2]
Both component interviews describe manual rework. Investigate whether component mapping is a broader adoption barrier.
Finding [3]
This buyer required security review before technical validation. Check whether other buyers share that sequence.
Caveat
Three interviews is still early. Treat repeated findings as signals to investigate.

Questions

Common reader notes

Is the Product Discovery skill a replacement for interviews?

No. It adds a stream of grounded evidence from visitors who are already evaluating, confused, or comparing. Use strong signals to plan deeper interviews.

Will the Stand-in annoy visitors with research questions?

The skill instructs the Stand-in to help first, ask permission, ask one question at a time, and stop when the visitor wants direct help or seems done. Test those behaviors and review real conversations; AI instructions are not a guarantee that every exchange will be handled well.

Try the guide on one real page.