Your most useful product idea may be hiding in the step viewers still struggle with after watching your content. Look for repeated work, confusing decisions, and homemade workarounds. A popular topic is a starting point for research; it is not proof that people will pay for a product.

Our editorial approach is to collect audience evidence, identify one recurring task, and test a narrow solution before choosing a format. You do not need to repurpose an entire content library. You need to understand a specific person well enough to help them finish something.

Start with an evidence log

Review recent comments, questions sent directly to you, live session questions, and replies to your newsletters. Include questions on older evergreen content. Work only with information you are entitled to use, remove identifying details from planning notes, and ask permission before publishing a person's words or story.

Create one row per observation. Do not turn every comment into a feature request. Capture what the person was trying to accomplish and the obstacle that interrupted them.

A product evidence log
FieldWhat to record
AudienceThe person's relevant situation or experience level
TaskThe result they were trying to produce
FrictionThe step they could not complete
Current workaroundWhat they do now, if known
EvidenceA private reference, date, and anonymized summary
UnknownWhat you still need to ask

For example, “Please make a course” is a suggested solution. “I spend Sunday rewriting my meal plan when my shifts change” describes a task and constraint. The second statement gives you more to investigate.

Separate content interest from product demand

YouTube's Trends tab can show audience searches and content gaps, with availability varying by country, language, and device. It helps identify questions worth exploring, but the documentation presents it as content inspiration, not a purchase-demand measurement. Source: YouTube Trends documentation.

Use search interest to widen your list, then return to the person's workflow. Someone searching for a desk setup tour may want inspiration. Someone repeatedly calculating whether equipment fits a small room may need a measurement worksheet or planning tool. You cannot establish the latter from a search phrase alone.

Look at the replies beneath your practical content. Did people describe trying the method? Did they ask for a file they could reuse? Did they explain a constraint your tutorial did not cover? Those details suggest a more specific next conversation than the total view count does.

Group questions by the task they share

GOV.UK's user research guidance recommends defining needs around users' problems and outcomes, grounded in evidence. The setting is public services, but the distinction is useful for creator products: understand the need before prescribing a solution. Source: learning about users and their needs.

Our suggested grouping method is simple. Give each observation a verb: plan, compare, calculate, organize, practice, decide, or review. Then narrow the audience and moment. “Plan content” is broad. “Choose three filming locations for a one-person tutorial shoot” is easier to investigate.

Keep unlike audiences separate even when they use the same words. A beginner asking how to price work may need a worked example. An experienced freelancer asking the same question may need to compare multiple usage-rights scenarios. Combining them too early can produce an offer that satisfies neither.

A hypothetical example: a small-space gardening creator

Imagine a gardening creator finds three kinds of questions: which plants fit a shaded balcony, how many containers will fit, and when to water. These are hypothetical observations, not findings from Creatr Co customer research.

The creator's first idea is a comprehensive gardening course. The evidence suggests smaller possibilities:

  • A short guide to matching plants with light conditions.
  • A printable balcony measurement and layout worksheet.
  • A container planning tool that uses dimensions to compare arrangements.

The creator should not assume the tool wins because it is interactive. Interviews might show that people only plan a balcony once, prefer sketching on paper, or cannot measure the space confidently. The most useful initial product could be a worksheet with a short demonstration.

The next research question becomes: “When someone tries to plan a balcony garden, which decision stops them from buying the right supplies?” That question is specific enough to test without building all three products.

Ask about the last real attempt

GOV.UK's interview guidance emphasizes neutral questions and concrete stories. Apply that by asking people to describe a recent attempt rather than predict whether they would buy your idea. Source: using in-depth interviews.

Here is an editorial discussion guide you can adapt:

  1. What were you trying to finish the last time this came up?
  2. Walk me through what you did first, then what happened.
  3. Where did you lose time or become unsure?
  4. What did you use to work around it?
  5. What happened when you left the problem unsolved?
  6. What would you need to trust a result from someone else's tool or template?

Resist pitching halfway through. If you explain your idea, people may start helping you feel confident rather than describing their own experience. Take notes on contradictions as well as supporting evidence. A person who solved the problem easily with a free resource is giving you useful information.

Turn one pattern into a product brief

Finish your research pass with six sentences: who the product helps, when the problem occurs, the current workaround, the result the product should produce, what it will exclude, and the evidence still missing. Keep the brief understandable without a mockup.

For the gardening example: “This helps apartment renters compare container layouts before buying supplies. It begins with balcony measurements and ends with a printable plan. It does not diagnose plant health or promise a harvest.” That boundary protects the buyer from a vague offer and you from an expanding project.

Choose one candidate to validate with a small experiment. If the task is clear but the delivery method is not, use the product format guide. Your content library has done its job when it leads to a testable problem, not just a longer list of things you could build.