When you ask an AI or a researcher whether an idea can make money, the worst answers are fluffy: “it depends,” “there is potential,” or “further research is recommended” with no numbers. Those responses waste time. The fix is not better prompting alone — it is a fixed structure that forces concrete outputs.
This guide introduces a structured income research template with five mandatory fields and explicit bans on vague language. It works for indie hackers, product managers, and teams that use AI (or humans) to evaluate revenue ideas before building.
Why Open-Ended Research Fails
Open-ended questions invite open-ended answers. “Can we monetize X?” often produces a narrative without testable claims. You cannot compare two ideas, prioritize a roadmap, or defend a decision to stakeholders without:
- Named markets — not “everyone who uses apps.”
- Revenue math — price × volume, ARPU, or RPM with stated assumptions.
- Feasibility — a scored judgment with reasons, not vibes.
- Next validation — what you will do this week, not someday.
A template turns research into a checklist artifact you can file, diff over time, and feed into planning tools or AI agents consistently.
The Five Mandatory Fields
Every income research note should fill all of the following. Skip any field and the document is incomplete.
| Field | What to include |
|---|---|
| Scheme name | One line: product, service, or monetization mechanism. |
| Target market | Industry, role, geography, company size — specific enough to find people. |
| Estimated revenue | Numbers + currency + calculation logic (formula and assumptions). |
| Technical feasibility | Score 1–5 plus reasons (stack, risks, team/time). |
| Validation plan | Concrete next steps: interviews, landing page, MVP scope, paid test, etc. |
What to Ban in the Output
- Hedge words without data — “maybe,” “roughly,” “it could work” without attaching numbers or experiments.
- Revenue conclusions without math — any dollar amount must show how it was derived.
- “Recommend more research” as the only outcome — replace with the validation field’s specific actions.
How to Use This With AI Assistants
Paste the template into your system prompt or project docs and ask: “Fill this template for [idea]. If data is missing, state assumptions explicitly and still show the formula.” That keeps the model inside guardrails instead of drifting into essays.
For teams using internal automation (for example research pipelines or “lobster” style batch jobs), storing the template as a single Markdown file in your repo makes every run comparable — same sections, same rigor.
Example Snippet (Abbreviated)
### Scheme name
B2B uptime alerts for Shopify-scale merchants (webhook + SMS).
### Target market
Merchants doing $1M–$20M GMV/year, 2–8 person ops teams, US/CA first.
### Estimated revenue
Year 1 target $90k USD = 30 paying × $250/mo × 12 (assumes 3% trial-to-paid from 1k trials).
### Technical feasibility
4/5 — Webhooks + queue + Twilio are standard; hardest part is noisy alert tuning (2 eng-months).
### Validation plan
10 customer discovery calls + single-page waitlist; ship read-only dashboard in 4 weeks.Takeaways
- Structure beats length: five fields beat ten pages of prose for go/no-go decisions.
- Revenue without a formula is an opinion, not research.
- Pair the template with your favorite developer tools for specs, JSON, and docs — keep artifacts machine-friendly.
Adopt this pattern once, and every “can this make money?” request produces comparable, auditable answers you can stack-rank and ship against.