Use public X buyer requests to find out what people need, not to declare that your new product will sell. Record each person’s problem and constraints in their own terms, compare those with your proposed offer, then test the biggest unanswered assumption. If the problem fits but the preferred solution is unknown, test a specific priced offer. If buyers’ requirements conflict with your idea, revise it. If the requests are too vague or sparse, keep researching before you build.
Record the request before interpreting it
Write down your proposed product and intended buyer before reviewing posts. Otherwise, it is easy to read a general request as a request for the thing you hope to sell. For each relevant post, save its wording and context, then complete the fields below. Put your interpretation in a separate field; do not turn an unstated preference into a buyer quote.
- Stated problem: What is the person trying to solve? Copy the relevant words rather than naming your product category.
- Buyer and situation: Who is asking, who is the product for, and when do they need it? Mark anything the post does not say as unknown.
- Stated constraints: Note explicit limits such as budget, ingredients, location, timing or preferred format. Separate hard requirements from casual preferences.
- Proposed solution fit: Can your idea meet the stated need and every hard constraint? Record a match, conflict or unknown, with the reason.
- Assumption to test: What must be true for this person to choose your format and price instead of another way to solve the problem?
A problem is evidence; a purchase is a different test
Consider this fictional request: “Any recommendations for food for a dog with allergies?” A seller considering a monthly pet-food subscription can record the problem as finding suitable food and the dietary constraint as allergies. The post does not identify the allergy, request recurring delivery, name a budget or say the person is ready to pay for a subscription. The seller’s idea may address the problem, but its format, suitability and price remain untested.
A reply such as “I’d try that” would add information about interest, but it would not carry the same weight as someone choosing an offer and proceeding with payment. Strategyzer distinguishes what customers say from what they do and recommends testing critical assumptions through customer actions, including a purchase process. That distinction is especially useful here: an X request describes a need in public, while a purchase test asks someone to accept your particular solution on particular terms.
Before building the fictional subscription, the seller could describe an allergy-appropriate offer that they can actually fulfill, show its contents and an illustrative price of $32 per month, and ask interested people to choose it on those stated terms. If it is a pre-order, make availability and payment or refund terms clear rather than implying the product already ships. Record separately who asks about ingredients, who signs up for updates and who actually orders. Those actions answer different questions; none should be silently counted as a sale.
Choose the next test from the pattern you find
Group the requests by the assumption they challenge, not merely by how many mention your category. Strategyzer advises identifying an idea’s critical hypotheses first, then choosing experiments such as interviews or landing-page actions to test them. Use the pattern below to decide what to do next; a post can establish a problem while leaving the proposed offer unresolved.
For the fictional pet-food seller, the allergy request belongs in the first row only if the planned food could meet the dog’s actual dietary requirements; those details need checking. Suppose another fictional post explicitly asks for a one-time purchase with no subscription. That is a format conflict, not supporting evidence for recurring delivery. If the seller sees only broad pet-care discussion, they have too little evidence about this problem and should seek more specific requests or speak with prospective buyers. In no case does the post count alone establish how many subscriptions the market will buy.
| What requests show | What remains uncertain | Next action |
|---|---|---|
| The problem matches and no stated constraint rules out your offer. | Whether people will choose this format at your price. | Present a specific, fulfillable priced offer and measure choices or orders separately from expressions of interest. |
| A stated requirement conflicts with the proposed offer. | Whether a revised offer could meet that requirement. | Revise the idea or target buyer; test the revised assumption rather than counting the conflicting post as demand. |
| Posts are vague, or there are too few specific requests to interpret. | The buyer’s situation, constraints or preferred way to solve the problem. | Gather more relevant examples or ask prospective buyers about recent attempts to solve the problem. |
Use a scan for examples, not a demand verdict
If you already have a page that represents the proposed offer accurately, ReachFast says it builds a search from a submitted website or store page and presents public X posts with buying-intent scores. It offers one free first-project scan without a card; that first scan reads posts from up to the preceding two weeks. Treat the resulting posts as candidates for your worksheet, including low-ranked or awkward matches you might otherwise overlook. Read the requests themselves: neither a score nor a collection of matches establishes that buyers will choose your new product.
If the idea is still too undefined to describe on a representative page, collect and review requests directly instead of writing a page merely to get a scan. A scan cannot establish that it found every relevant request or that scored posts will become customers. For a different decision—whether public requests suit a product you already sell—see Are People Asking for Your Product on X?. If recurring questions suggest changes to an existing listing, use How to Use Customer Questions to Improve a Product Page.
