Validate the task before choosing the tool
Before building an AI skill from your book, investigate one reader problem: a recent situation, an attempted solution, and a consequence that matters to the reader. Then try helping with that task manually and check whether an AI version is something they would actually use.
An audience gives you people you may be able to learn from. It does not establish demand for every product you could make from your expertise.
You can start with five reader conversations and a small manual trial. Five is a manageable first research batch, not a number that proves a market exists. The aim is to decide whether to stop, revise the idea, or invest in a limited prototype.
This process separates three questions:
- Is the reader encountering the problem you suspect?
- Does your method help with a concrete part of it?
- Is an AI skill an acceptable way to deliver that help?
Keep the answers separate. A useful method can deserve a better worksheet even when an AI version is the wrong next step.
Write a hypothesis you could reject
Start with one paragraph, before interviewing anyone:
I think [specific readers], when [situation occurs], struggle to [complete a task]. They currently [workaround or response]. My method could help them produce [reviewable result]. I would reconsider if [contrary evidence].
For example, imagine you wrote a book about documenting team processes:
I think small-team managers, when preparing a handover before leave, struggle to turn their working knowledge into instructions a colleague can follow. They currently send scattered messages or walk the colleague through the job. My method could help them create one usable handover guide. I would reconsider if existing templates already solve the problem or readers mainly need access permissions I cannot provide.
This is a fictional hypothesis used throughout the article. It is deliberately narrower than “readers want an AI version of my book.” It gives you a situation to recruit for, a result to inspect, and an alternative explanation to investigate.
If you need a definition of the proposed format, Agent Skill 101 explains how skills package instructions and supporting material. You do not need to build that package to investigate the reader's task.
Recruit people with a relevant situation
For a first batch of five, seek readers who recently faced the task or will face it soon. Include different experiences: someone who succeeded with another approach, someone still struggling, and someone who chose not to use your method.
Your newsletter, existing reader replies, or workshop alumni may be starting points. Ask about the task in the invitation; announcing a new AI product first would recruit for a different interest.
A draft invitation could say:
I'm researching how readers prepare a work handover before taking leave. If you've done this recently, I'd value a 30-minute conversation about what you tried and what happened. This is research, not a sales call; you do not need to have used my approach or liked it.
Finding the right people can itself take work. In a nonfiction beta-reading discussion, author u/Salt_Ruby_9107 wrote:
“And I'm having a harder time than I thought finding a group of five people I can trust to read it with fair or honest feedback.”
The author was seeking feedback on a parenting/education manuscript and explicitly did not want people putting it into AI. Their concern is about trustworthy reader feedback, not interest in an AI companion. Preserve that distinction when using public discussions to learn about authors or readers. Read the original post.
If all five volunteers are close friends or enthusiastic fans, record that limitation. Their experiences can still be useful, but you have not heard from less engaged readers. If nobody qualifies, reconsider the situation or recruitment channel before interpreting silence as a verdict on the idea.
Ask about an actual attempt before showing the idea
Plan roughly 30 minutes for a focused conversation, and tell the participant what you will record. Ask permission before recording or retaining their examples. A redacted document or verbal walkthrough may provide enough detail.
Use the same core topics across conversations, while allowing follow-up questions. The GOV.UK Service Manual recommends open, neutral questions and a focus on stories and real examples rather than how things should happen. It also recommends planning and testing a discussion guide. GOV.UK interview guidance.
Here is an interview guide for the handover example:
| Question | What you are trying to understand |
|---|---|
| Tell me about the last time you prepared work for someone to cover. | A specific event and its context. |
| What did you need the other person to be able to do? | The reader's desired result. |
| Walk me through what you did, starting at the beginning. | Actual steps and existing tools. |
| Where, if anywhere, did it become difficult? | A problem without assuming one existed. |
| What happened because of that? | Consequences, including “nothing significant.” |
| What did you try next? | Workarounds and help already sought. |
| What worked well enough that you would keep it? | Alternatives your proposed skill must respect. |
| Did anything from the book enter into the process? | The method's current role, without assuming use. |
Follow “it took forever” with a request for the sequence or an approximate duration. Do not turn an uncertain recollection into an exact time-saving claim.
When someone describes a different problem, let them finish. The interview can invalidate your hypothesis. Avoid coaching them toward the answer your planned product needs.
At the end, ask whether they have another relevant task coming up and would consider trying a small exercise. That invitation is a request for a next step, not proof that they will complete it.
Turn broad enthusiasm into a question you can investigate
Public reader discussions can help you find language and recruit ideas, but a broad request is not a product brief.
In a book recommendation thread, u/Psychological_Yak792 asked for:
“books that motivate you and guide you with practical advice, mindset shifts, or tools you can apply.”
That passage expresses interest in useful reading. It does not identify a particular task, establish willingness to use AI, or prove demand for your method. Read the original request.
The useful research question is what “tools you can apply” means in the person's circumstances. Preparing a handover, choosing a project, and structuring a difficult conversation would require different support.
The same applies to praise from your own readers. Record “I would love this” as stated interest. Keep it separate from a recent attempt, an example of a failed workaround, or participation in a trial. None of those observations alone establishes a viable business, but they answer different questions.
Record evidence and uncertainty after each conversation
Use a simple table. Keep the reader's account separate from your interpretation.
| Field | What to record |
|---|---|
| Situation | Date or approximate recency; what triggered the task. |
| Attempt | What the participant says they did; any artifact they chose to show. |
| Difficulty | Their description, including an absence of difficulty. |
| Consequence | What changed or failed to happen; uncertainty preserved. |
| Existing solution | What already works and what remains unresolved. |
| Method fit | Which part of your method might help, and which part cannot. |
| Contrary evidence | Anything that weakens your original hypothesis. |
| Next step | Offered, accepted, scheduled, completed, or declined. |
Do not label every repeated complaint “validated demand.” The UK government's guidance on qualitative interview studies notes that interviews can describe a range of views without showing how common each view is. That guide addresses digital health evaluation; the relevant limitation here is about interpreting qualitative accounts, not a clinical claim. GOV.UK qualitative interview guidance.
Review the five conversations together. If they concern five unrelated tasks, narrow the question and recruit again. If one recurring situation has clear examples and consequences, it may deserve a manual trial. The strength of the next step should match the evidence.
Try the useful part manually
Invite one or two suitable participants to a small, clearly described trial. These numbers are planning suggestions, not a research validity threshold.
For the fictional handover method, ask a willing manager to choose one routine task. Give them your existing checklist and help them create a draft guide. Explain that you are personally helping; do not present your own work as an automated system.
Define the intended result before you begin: a colleague should be able to identify the next step, required access, and who to ask when something is missing.
Ask the manager to review the draft for correctness. With the colleague's agreement, have them inspect or try a low-risk part of it. Record where you had to intervene. If permissions prevent the task, preserve that blocker instead of counting a polished document as success.
This trial tests whether a bounded piece of your method is useful with human assistance. It does not show that an AI system can reproduce your judgment. Before adapting it into a skill, list every decision you made: which question to ask, what to omit, and when to stop. Those decisions become candidates for explicit instructions and later testing.
If a one-page template solves the problem adequately, you have found a useful intervention. There is no requirement to turn every useful intervention into software.
Make a stop, revise, or proceed decision
Complete the following worksheet after the interviews and trial. These are editorial decision rules for a small exploratory project, not statistically validated thresholds.
| Decision | Evidence that would support it | What to do next |
|---|---|---|
| Stop this version | Qualified readers describe adequate existing solutions; the proposed result does not matter; or the problem lies outside your method. | Keep the notes and stop building this particular offer. |
| Revise and research again | A real difficulty exists, but the reader, task, timing, or expected result differs from your hypothesis. | Rewrite the hypothesis and investigate that narrower situation. |
| Proceed to a limited prototype | Concrete accounts support the same task; a manual trial produces a useful, reviewed result; suitable readers agree to try an AI version. | Build only the tested task and schedule observation of actual use. |
| Remain undecided | You cannot reach suitable participants, accounts conflict, or no trial has been completed. | Name the missing evidence and choose one step to obtain it. |
Write down the strongest contrary example alongside your decision. A supportive majority should not erase a boundary that could make the skill unsuitable for part of the audience.
A completed fictional decision note
Imagine the handover interviews produced the following findings. These counts and outcomes are invented for illustration; no interviews or trials were conducted for this article.
- Two managers described recent handovers where the covering colleague needed repeated clarification.
- One manager already had a template that worked well.
- One person's main difficulty was missing system access.
- One could not recall a relevant recent attempt.
Suppose a subsequent manual trial helped one of the first two managers make the steps clearer, but still required the author's help to identify exceptions. That supports further investigation of exception handling. It does not establish that a fully automated handover tool is ready.
The decision note could read:
Revise: Focus on drafting routine-task instructions and making exceptions visible. Exclude access setup. Next, test whether the manager can use a written exception checklist without the author's coaching. If that works and the participant wants an AI version, build a limited prototype for the same task.
This decision is more useful than counting everyone who said the idea sounded good. It identifies what to learn before making a larger commitment.
Ask about the AI format explicitly
After learning about the task, explain what an AI trial would involve: the information participants would provide, the draft they would receive, what they must review, and what the system would not do.
Ask whether that fits how they work. A reader may want the result while declining the format because of workplace restrictions, privacy preferences, or a preference for paper. Record the reason without trying to talk them out of it.
Do not treat a scheduled trial as repeat use, or repeat use as willingness to pay. Pricing, distribution, and commercial viability need their own evidence. At this stage you are deciding whether a specific reader task deserves a prototype.
Once built, the prototype also needs execution checks. The agent skill testing guide covers actual runs and blocker behavior. A successful manual trial cannot substitute for those checks.