Before buying another tool, find out whether the service solves a specific problem for someone who can act on it. A useful validation exercise examines recent behaviour, current workarounds and the fit of a small demonstration. It does not turn a compliment into a sale.
Start with a service hypothesis from turn digital skill into freelance service. Keep the first investigation small enough that you can change direction without relying on the idea being correct.
In this guide
Read the text version: Label assumptions, reports, observations and agreements
| Record type | Fictional example or criterion |
|---|---|
| Assumption | A better tool may help. |
| Reported experience | A person says copy approval was late. |
| Observed behaviour | During a test, the reviewer finds the joining step. |
| Explicit agreement | Record a commercial commitment only when actual scope and terms have been agreed. |
These categories are not a mandatory sequence or a guarantee of a sale. Preserve who said or did what, the context and what remains uncertain. A compliment does not by itself establish a paid engagement.
Write an assumption that can be challenged
“Small organisations need design” is too broad. A more useful assumption is: “People coordinating recurring community sessions spend time reformatting approved information for print and screen, and some may want help with that defined task.” It identifies a person, a process and an uncertainty.
Separate what you know from what you infer. You may have observed a confusing information sheet, but you do not yet know whether the organisation sees it as a problem, who controls the budget or whether an existing volunteer handles it. Use check demand for digital skills to inspect actual tasks without treating public listings as proof that every buyer needs your offer.
Decide what evidence would change your mind. If people already have a reliable process, the proposed service may not be useful. If the problem is late approval of copy, a more powerful design tool may not address the cause.
Ask about a recent real task
Invite an appropriate person to a short conversation and explain that you are learning about the process, not conducting a disguised sales pitch. Ask permission before recording. The GOV.UK interview guide recommends neutral questions, specific experiences and follow-ups. Its method is useful here; the examples below are an original adaptation to a small service investigation.
| Question | What it helps reveal |
|---|---|
| Tell me about the last time you prepared this information. | A real process rather than an imagined preference |
| Who supplied the wording and approved it? | Inputs and decision dependencies |
| Which part needed extra effort or rework? | A specific friction worth investigating |
| What did you use or do instead? | Existing alternatives and workarounds |
| Who decides whether outside help is appropriate? | The route to a decision |
| What would you need to inspect before considering help? | Evidence and constraints for a useful next step |
Avoid leading questions such as “Wouldn’t a professional redesign save you hours?” They place the desired answer inside the question. Do not promise a time saving, result or service capability you have not demonstrated.
Build the smallest demonstration that answers the uncertainty
Use invented or authorised material to show one relevant operation. If the question is whether information can be adapted to two formats, create a small print-and-screen example. You do not need to buy an entire automation system or build a complete website to investigate that question.
Ask the person to inspect or use the demonstration. Can they find the information? Does it fit their actual approval process? Which input is missing? A reaction such as “looks nice” is weaker evidence than a specific explanation of how the output would or would not fit the task.
Keep confidentiality and consent proportionate. The GOV.UK research-data guidance links collection and use to the permission obtained. Do not collect private files merely because they might be interesting, and do not publish a participant’s words as a testimonial without the appropriate permission.
Worked example: the tool was not the main uncertainty
Fictional investigation: Asha considers buying a premium layout subscription to offer event-sheet formatting. She speaks with an imaginary community-session coordinator about the most recent event. The coordinator describes late copy approval and uncertainty about the final venue name; the existing tool can already export the required formats.
Asha records the observation without turning it into a universal market conclusion. Her initial assumption was that better layout tools were the central need. The conversation suggests that approval and input organisation may matter more in this particular workflow.
She creates a fictional two-format example using a tool she already has and adds a brief approval checkpoint. The coordinator can identify how the checkpoint would fit, but has not agreed to purchase anything. Asha’s next action is to investigate who approves the copy and whether the defined support task is useful, not to record a sale.
Read the text version: Preserve what a fictional service investigation actually supports
In the fictional example, Asha initially assumes a premium layout tool is the main need. The imaginary coordinator reports late copy approval and uncertainty about the final venue name. The current tool already exports the required formats. Asha therefore creates a fictional print-and-screen sample with an approval checkpoint using a tool she already has. The coordinator can identify how the checkpoint would fit but has not agreed to purchase. The next question concerns who approves the copy and whether the bounded support task is useful. This is a teaching record, not a real study, a representative market finding or a sale.
This example does not report real research participants or measured demand. It demonstrates how a log can preserve the difference between an assumption, a statement, an observation and a commercial commitment.
Use the interview and observation log
| Field | What to record |
|---|---|
| Service assumption | Person, task, problem and proposed help |
| Recent example | The actual occasion described, without unnecessary personal data |
| Current workaround | Tools, people and process already used |
| Observed or reported friction | Exact issue; distinguish what you saw from what you were told |
| Demonstration result | What the person could inspect, use or question |
| Evidence limit | Small sample, unknown decision authority or untested requirement |
| Next decision | Continue investigation, narrow the service, defer spending or stop |
Review several relevant observations before making a broad claim, while recognising that a small informal investigation is not a representative market study. Look for differences as well as repeated themes. A service that suits one organisation may be inappropriate for another with different resources or responsibilities.
Use choose freelance client niche to refine who the offer is for. When the task becomes concrete, use create freelance service packages to define inputs, outputs and review. Buy a tool only when a verified delivery requirement and a manageable cost justify it. Interest, a meeting or a promising comment remains distinct from an agreed paid engagement.
Frequently asked questions
How many interviews prove that a service will sell?
No fixed small number proves that. Conversations reveal needs, language and constraints, but they can be unrepresentative and do not guarantee purchases. Record what each interaction supports and what remains uncertain, then choose a proportionate next test.
Should I ask whether someone would buy my idea?
You can discuss fit, but hypothetical willingness is limited evidence. Ask about a recent task, the current workaround and who makes the decision. If the person expresses interest, clarify the next concrete step without recording it as an agreed sale.
Do I need paid software for a demonstration?
Only if the specific demonstration cannot be made appropriately with your existing permitted tools. Use a small fictional or authorised example first. A tool purchase should address a verified requirement, not substitute for understanding the buyer’s process.
Can I offer a free trial to validate the service?
A bounded demonstration can be useful if expectations, permissions and the ending are clear. Avoid providing an undefined amount of unpaid production work. State what the exercise tests and do not imply that participation commits either person to a later purchase.
What if everyone says the idea sounds good?
Look for concrete evidence beyond politeness: a recent problem, a current workaround, relevant constraints and an appropriate decision route. Ask what would make the service unsuitable. Positive comments alone do not establish urgency, budget or a willingness to enter an agreement.
When should I stop investigating an idea?
Stop or change direction when the evidence repeatedly contradicts the problem assumption, the task exceeds your capability or the costs and responsibilities do not fit. Keep the learning record so you can explain the decision. Continuing to spend is not required to justify earlier effort.
Sources and review notes
Primary sources checked on 27 October 2026 (UTC). Check the current provider pages before relying on a changing feature, policy or price. Worked examples and worksheets are original teaching material; fictional examples are not evidence of client results.