By Night Watcher · Examples are fictional and illustrate a research method.
Collect recurring problems before naming products
Start with a group whose work you can observe. Look for recurring exports, repeated corrections, handoffs between tools and reports assembled by copying the same information. Record the trigger, frequency, person responsible and consequence of getting it wrong.
Public discussions can suggest questions, but a vocal complaint is not a representative market sample. Ask permission to observe real workflows, respect community rules and avoid collecting private customer data. You need to understand the task, not own everyone's records.
Narrow the buyer, outcome and starting point
A small product still needs a clear outcome. ‘Automate admin’ is too broad. ‘Prepare a weekly missing-document checklist from the exports a particular type of agency already uses’ identifies a task, input and deliverable. Narrowing the workflow makes it easier to test before building a broad platform.
Find out why existing tools have not solved it. The answer may be a missing integration, a complicated setup or a deliberate security restriction. Some gaps exist because the task is too rare or expensive to support. Treat the gap as a question, not automatic proof of opportunity.
Screen the economics and dependencies
Ask who can approve a purchase, how often the outcome matters and how you can reach that person. Estimate support, hosting, API and onboarding costs. A modest subscription can be unattractive if each customer needs hours of custom work.
List dependencies that could prevent delivery: access to source data, platform policies, required approvals, unreliable exports or a third-party feature you cannot control. Start with problems you can test safely and lawfully. If the core workflow requires access you cannot obtain, pause before investing in a polished interface.
Worked example: a missing-document checklist
In a fictional agency workflow, an operations manager manually checks five folders before a weekly client review. A proposed tool creates a checklist from a user-supplied export. Before integrating every storage provider, you could test whether a manually prepared checklist changes the manager's next action.
If the manager finds the report useful only once, a subscription may be the wrong model. If several managers ask for it every week but each export has a different structure, the risk may be implementation cost rather than demand. Those findings should shape the next experiment, not be hidden behind an opportunity score.
Keep a shortlist with reasons to reject ideas
For each candidate, write one supporting observation and one unresolved risk. Rank your next experiments by what you can learn cheaply, not by an invented precise market score. Test one uncertain claim at a time: recurrence, buyer access, willingness to pay or reliable delivery.
Use the validation guide to turn your strongest candidate into a pilot. Keep an archive of rejected ideas and the evidence behind each decision. A changed platform capability or a different buyer segment may make an old question worth revisiting later; a fashionable keyword alone should not.
Your worksheet
Copy these prompts into your own notes. No signup is required.
Micro-SaaS problem log Observed group and role: Recurring task: Trigger and frequency: Current workaround: Cost of failure: Input data available with permission: Smallest useful output: Existing alternatives: Buyer and route to reach them: Delivery/support cost assumptions: Dependency or policy risk: Cheapest next test: Reason to reject or revisit:Download the text worksheet
Test your assumptions
Use the related free calculator, then compare the scenario with evidence from actual buyers.
For company and search-demand research, explore Night Watcher plans.