Why live questions say more than a survey
A question asked in the heat of a live class has an advantage over anything gathered afterward through a cold survey: it comes without filters. I asked the audience directly, in the chat, to write down which day-to-day processes consumed the most time and energy inside their businesses, without giving them time to polish an answer.
The answers arrived in real time, in the exact vocabulary of people dealing with the problem every day. One person wrote about report structuring. Another wrote about having to reply to emails using the tools available for birthday party bookings. Another, more lightly, said they run their own ads. None of these answers were rehearsed or prepared, they were typed in the moment, with the direct language of people who feel the problem daily.
I watched these messages accumulate live and treat this kind of information as far more useful than any structured survey put together before the event. This contrast between what people say when they have time to think and what they write in the heat of the moment explains, in practice, the difference between forced data and spontaneous data.
To prepare your next step, explore Build and grow an online training business.
Collect everything before you organize anything
The first step is to collect everything without judging what looks relevant or irrelevant at first glance, saving any analysis for later. I explained that the next step would be to export the entire chat from the session, including messages from the open channel and the questions that had received the most votes from the audience.
This export step is simple but often skipped. If you delete or ignore messages just because they look repetitive or unimportant, you lose the raw material the AI needs later to detect patterns. I was clear about the order of things: I observe first, and only afterward decide what to automate or where to add artificial intelligence. I describe this cycle as something that always starts with observation, before any tool or platform choice.
In practice, this means resisting the urge to start solving the problem that seems most obvious right away. Before deciding anything, I leave the raw text intact, repetitions and all, because that mass of data is what later lets me compare frequency against severity, without biasing the analysis too early.
Let the AI isolate patterns, without letting it make things up
Once you have the full text exported, the next step is to ask the AI to detect relevant patterns within those responses, without asking it for opinions or letting it guess what is not written there. I said directly that I would ask the AI to isolate whatever was most relevant among everything the audience had written.
There is one caution worth keeping in mind here: if you only ask the tool to count frequency, you risk treating anything mentioned only a few times as noise. A problem mentioned by fewer people can come from a different segment, with a different budget and different urgency. This caution was not a rule given in this part of the session, but it is sensible to apply when you run the exercise yourself.
The central point, which I stressed elsewhere in the same session, is that artificial intelligence is only as good as the data it receives. Without enough data and context the machine starts guessing, and guessing is not what anyone wants from a tool meant to bring facts and concrete context instead.
Explore this decision further: How to Turn Support Replies into a Useful AI Knowledge Base.
The criteria I use to decide where time is worth spending
I worked through, elsewhere in the same session, what I call cost per decision: how much every repeated decision a team makes on the same type of task costs in human time, error, and delay. This criterion helps separate a popular topic from one worth solving first.
I gave a hypothetical example, adjustable by anyone, where a lead handled manually cost around 19.44 euros per decision, adding up human time, infrastructure cost, error cost, and latency cost. With AI inserted into that same process, the cost per decision dropped to around 3.79 euros. In a hypothetical company handling 500 leads a month, that difference amounted, in the example's own numbers, to more than 7,800 euros of monthly difference in cost per decision alone, before other business costs, without even counting the extra revenue from closing more deals by responding faster to the right people. It is an illustrative exercise, not a guaranteed result.
This is the kind of reasoning I apply when I look at questions collected from my own audience: a topic that comes up often but costs nobody any money is just curiosity, while a topic that comes up less often but is tied to wasted paid hours, lost sales from slow response, or repeated error deserves attention first, even when it looks less popular at a glance.
Separating who just comments from who would actually pay
The fact that several people write about the same problem in chat shows interest, but it does not show willingness to pay for a solution. That distinction is usually the most expensive one to skip when building a product without checking it first.
A simple way to check it is to talk to a few of those people individually and ask directly whether they have already spent money, team time, or hired any tool trying to solve that problem without success. This recommendation was not part of the session itself. The more useful question is what they have already tried to fix it and how much that has already cost them so far.
If the answer is no, the problem may be real but is not yet urgent for that person, and it is not worth building a paid solution for them right now. If the answer is yes, you have a much stronger signal than any comment count in chat: the difference between saying something is annoying and showing that money or work hours have already been spent trying to get around it.
Moving from signal to test, without building everything at once
After collecting the responses, I asked the AI to identify the most relevant patterns. I then chose one of the main challenges for a practical demonstration in the next part of the session. That gave me a concrete next step to explore with the people who had raised the problem.
This is the step that people who want everything perfect before showing anything tend to skip. I went from the collected signal straight to a practical demonstration of solving one concrete problem, without waiting months to design a full program around it. The next product does not need to be born complete, it needs to be born solving something already validated as a real pain point by the people listening, even if small and narrowly focused.
Explore this decision further: The value ladder: linking every offer without inventing extra products.
Turning this into a habit, not a one-off event
The exercise I ran live can easily become a simple routine inside any business: listen to customers and team regularly, log what comes up frequently, and cross that against the real financial impact of each problem, instead of letting that information disappear after each conversation.
It does not need to happen only at big events with hundreds of people writing at once. It can happen through any channel where your audience or customers already write to you every day, whether support, comments, or questions asked in a smaller session. What matters is building the habit of exporting, grouping, and comparing frequency against severity before deciding where to spend your next block of time, even if you start small and refine the process as you go.
At Laboratório da IA I run two mentoring sessions a month, reviewing students’ projects and working on practical applications of AI and online business. You can bring a concrete question to a session: what need emerged, what you have already tried and what decision you need to make.