Find the audience hiding in your customer data.

What the AI will do

• Read complaints alongside actual use, purchases and workarounds to find an overlooked audience or need.
• Trace promising patterns back to customers and develop an offer implication and a way to learn from real users.

What you can provide

• Your company or product and accessible support, sales, usage or customer records.
• A small export or pasted sample works when direct access is unavailable; broader records make a recurring audience easier to establish.

Where you'll take part

• Explain unfamiliar product or customer context and correct the proposed audience.
• Choose which supported opportunity is worth exploring and review the proposed real-customer test.

What you'll get

An evidenced picture of an overlooked audience, what it is trying to do and a concrete way to test an offer for it—or an honest account of what the available records do not establish.

Activity context

A complaint can tell you what someone needs—and reveal who is using your product. Nontechnical people may be wrestling with a technical interface. Technical users may want to take a simple product apart. A supposedly finished object may be the starting point for something its owners want to customize. Look for the customers your existing categories make hard to see.

For the user

Name the company or product. The AI will search the customer records it can read, starting with complaints and unusual uses, and bring you the patterns worth discussing. The accompanying unexpected-audience research offers examples; paste its text if your AI cannot open it. The activity also includes examples and a complete search method on its own.

Guidance for the AI

These are general instructions, not a description of this user's particular AI system, tools, access, or circumstances. Adapt the method to the user's goal and the capabilities you can actually use, while preserving the activity's essential sequence, review points, and intended result.

Start with the activity and the user's context

Read the complete activity and guide the user through it. Use the activity prompt yourself; the user does not need to paste it again. Keep the responsibilities of the user, the AI, and any colleague clear.

Begin with what the user has already supplied. Establish the intended result and resolve missing context through focused questions when needed. Work within the activity's stated scope, permissions, required confirmations, and stopping points, including any deliberate order for introducing information. Make progress with the available information and reasonable, clearly identified assumptions where the activity allows them.

Check the capabilities needed for this work

Inspect relevant available tools, connectors, and data. Use small, relevant, non-destructive checks to establish whether necessary access or a capability actually works. Naming a product does not establish access to it. Let this activity determine what needs checking; do not impose a universal preliminary questionnaire or a full system audit.

When useful access is missing:

• Explain what you cannot reach and how that material would help.
• Investigate practical setup, connection, export, or other access alternatives before asking the user to gather material or troubleshoot.
• If progress depends on access, request only the specific user action or permission needed to enable it or provide the material another way. Continue useful independent work while awaiting the response.
• Offer to walk the user through an export or upload. Welcome files, links, copied text, rough notes, or an interview as supported by your system and the activity, and use the best available route. If the missing access is optional, continue with what is available.

Ask focused questions and respect the answers

Ask questions only when necessary to complete the work well or satisfy the activity's required review points. Build on answers already supplied. Ask one question at a time, or a small group of closely related questions. Wait on work that depends on the answer, and continue useful work that does not. Explain unfamiliar language with examples where helpful.

Confirm answers or decisions you supply on the user's behalf before treating them as the user's final answers or decisions. This does not require separate approval of every sourced finding; follow the activity's specific review requirements.

Keep evidence and independent contributions distinct

Distinguish evidence, inference, and missing information. Check your work against the source material.

Use independent agents when your system actually supports delegation and independent investigation or review would improve the work:

• Give each agent a bounded brief and the context appropriate to its role.
• Keep discovery independent until synthesis where the activity requires it. Preserve any requirement for the user or colleagues to contribute before seeing other explanations.
• Follow the activity's stated fallback and any required confirmation when independent agents or fresh contexts are unavailable. Preserve reviewer isolation where required; describe shared-context or sequential passes accurately.

Produce, check, and revise the result

Do the substantive investigation and production. Carry the activity through to the most complete, usable result within its scope, rather than ending with a plan or handing the main work back to the user. When missing information does not prevent useful work, proceed with clearly identified assumptions where the activity permits them.

Check the result against the activity's completion criteria. At each substantive delivery, state what is complete and any material unfinished work, assumptions, helpful missing information, and remaining uncertainty. Explain how these affect what the user can use, and help the user revise the result.

Preserve the activity's stopping point. Do not turn a rehearsal, investigation, or test-design activity into execution that the user has not authorized.

Your AI prompt

Help me find an audience hiding in our customer data: people whose needs, use or willingness to adapt the product do not fit how we currently describe our customers. Use complaints as clues to both the unmet need and the person behind it. Ground the result in this company and industry.

Establish the product and available evidence

Use what I have supplied and accessible product pages, positioning documents, sales material and customer research to establish what we sell, whom we intend to serve and what our existing segments mean. Inspect and try access to support tickets and their replies, complaints, reviews, CRM and account records, sales notes, transactions, returns, product-use data, community discussions and relevant email, chat or meeting records. Look for actual users and workflows, not only the account purchaser.

Explain which sources you can actually read, their period and what is missing. Investigate useful connection or export routes before asking me to gather material. Help me supply a sample if direct access is unavailable, preserving enough context to connect an issue with its customer and outcome. If we have only a few anecdotes, we can develop a candidate to investigate, but cannot establish a recurring audience or estimate its size from them.

Ask focused questions about company or industry context when they materially change the inquiry. Establish a workable product and period before searching broadly.

Look beyond our usual customer categories

If the accompanying research on unexpected audiences is available, read it for examples and original sources. If you cannot access it, ask for pasted text only if more examples would help; the method below is sufficient to begin.

Use these documented examples to expand the search, not to predict what we will find:

• The Buy Guide's firsthand account describes the Stanley Quencher being merchandised with camping products while women were already using it for work, carpool, exercise and everyday life. Look for a daily routine or setting missing from our marketing. The account does not establish the shorthand story “construction workers to housewives.” The Buy Guide, The Story of The Cup.
• Discord's founders reported in 2020 that users gathered for books, music, art and ordinary conversation, while gaming-focused branding made it harder to invite those communities. Look for people who value the product but struggle to explain that it is for people like them. Discord, Your Place to Talk.
• IKEA's 2018 DELAKTIG announcement describes attention to how people customized furniture and wanted to adapt it. Look for modifications that show customers want to keep designing after purchase. This documents design intent, not the commercial success of customization. IKEA, DELAKTIG announcement.
• Microsoft's 2011 Kinect announcements recognize unexpected nongaming uses and a developer audience wanting access to the underlying capability. Look for requests for raw data, programmable access or ways to build something outside the packaged experience. Microsoft, MIX11 announcement.

Adapt the search to our business. Examine whether a technical product attracts nontechnical users; whether technically capable users want more freedom with a simple offering; whether a fixed-price unit leaves an unmet desire for personalization; or whether an unexpected group has found a different use altogether. These are possible mechanisms, not a required set of findings. A request for an API may mean “I want to program this,” or merely “I need my existing systems to connect.” Find out which.

Follow complaints into actual lives and work

Search concrete phrases in tickets, reviews and correspondence: what people cannot do, wish they could change, do by hand, buy elsewhere, find confusing, or use the product for “even though” it was designed for something else. Include praise and successful workarounds; an overlooked audience may be delighted rather than dissatisfied.

For each promising case, read the surrounding exchange and relevant account or use history. Record the person's evidenced role or situation, buyer versus user, intended job, actual use, obstacle or modification, our response and what happened afterward. Preserve source references and dates. Mark inferred traits as inferences. Do not deduce identity, skill or motivation from a complaint's tone alone.

Connect cases across sources only when the records support the connection. Avoid counting the same customer, syndicated review or repeated ticket as several independent cases. Compare the proposed group with ordinary users and contrary examples. Ask whether the pattern is a separate audience, a lifecycle stage, a common usability problem, one unusually vocal customer or a need that crosses existing segments.

For a large corpus, assign bounded agents different evidence sources or product areas with shared case fields and a coverage record. Have them return source-linked episodes, candidate patterns and counterexamples before reconciliation. Separate first passes help avoid making every source fit the first interesting complaint. Use successive waves or documented sequential passes when capacity is limited; preserve complete exchanges.

Establish the strongest candidate audience

Group cases by the job people are trying to do, the setting and the constraint they share. Then see whether customer characteristics explain the pattern. Do not invent a demographic label first and search only for support.

For each strong candidate, explain who appears to belong, what they need, why the current offer or positioning misses them, and the evidence for recurrence. Use counts only with the available denominator and collection limits; a share of support tickets is not a share of the customer base. Separate observed usage, requests, spending and willingness to pay. Show the best counterevidence and the unresolved question that would most change the conclusion.

Present the small number of candidates the evidence supports, including an unexpected need among existing customers if that is what the record actually shows. Ask me to correct their identity and business context. Where several are credible, help me choose one to develop before writing a detailed proposal. If none is well supported, say so and identify the specific sample or record that could resolve the leading hypothesis.

Turn the finding into something we can test

For the chosen candidate, write a concrete audience portrait based on actual episodes, a plain statement of the job it needs done and the change to the offer that could matter: positioning, onboarding, support, a product variant, personalization, extensibility or another evidence-supported response. Explain what changes in the customer's experience. Preserve the distinction between source-backed needs and our proposed solution.

Design a small real-customer inquiry or test. Identify suitable people from the evidenced group, what to show or ask them, what observation would distinguish this audience hypothesis from its strongest alternative, and what would justify changing the offer. Write a short interview guide or test brief that asks about actual behavior before inviting reactions to our idea. Include a way to learn whether the proposed response matters enough to change use or buying behavior. Do not contact customers or make product changes as part of writing this recommendation.

Deliver the audience finding, supporting cases and source limits, the proposed offer change and the ready-to-use inquiry or test brief. Check the finding against the underlying records, invite my corrections and revise. Use the outside examples as lenses throughout; they are never evidence about our company or proof that complaint analysis will uncover a new market.

Done when

You have a source-supported candidate audience or unmet need, concrete customer episodes, an offer implication and a usable brief for testing it with real people. Any claim of recurrence or audience size matches the records actually inspected.

Research & resources

Read the supporting research. Download research as Markdown.

These instructions were written in September 2026 using the frontier models available at the time. You may now have better tools or models, or restrictions that make some tasks harder. Your AI should adapt to the tools and access you actually have and find the best available way to help. Everything here is a starting suggestion for you and your AI, not a proven best practice for every setup. Feel free to rewrite any of it to better meet your needs.