Size an opportunity before you build it

Write an opportunity assessment for the idea below, for {{decision_maker}}, so that they can decide whether it earns a place on the roadmap before any design or engineering time goes into it. Judge the problem, not the proposed solution, and say plainly if the evidence is thin.

The idea and the problem behind it:
"""
{{idea}}
"""

Evidence we have (interviews, tickets, sales notes, usage data, requests), each with its source:
"""
{{evidence}}
"""

Numbers we can use for sizing (customer counts by segment, usage, revenue, conversion):
"""
{{numbers}}
"""

Our strategy and current priorities: {{strategy}}
Rough effort, if anyone has estimated it: {{effort}}

Use these headings:
1. The problem: one paragraph from the customer's side, with no solution in it.
2. Who has it: the segment, and who does not.
3. Evidence: a table with the columns Evidence, Source, Strength. Strong means observed behavior or data, medium means repeated in interviews or tickets, weak means a single request or an opinion.
4. Size: reach times frequency times value per occurrence, with the arithmetic shown and each input marked measured or assumed. Give a low case and a high case.
5. Alternatives: what customers do today, including competitors, workarounds and doing nothing, and why they would switch.
6. Fit: why this fits our strategy now, or why it does not.
7. Risks: value, usability, feasibility and business viability, each with what we know and the cheapest way to find out.
8. What success looks like: the metric that should move, the target if one is given, and how soon we would see it.
9. Recommendation: pursue, test first, wait or drop, labeled as the writer's view, with the next step.

Keep it under 900 words, not counting the tables.

For example, the form of one size input: "Reach: 1,400 accounts export invoices each month (product analytics, last 90 days, measured)." This shows the form only; use the real numbers.

A good assessment makes it easy to see which parts rest on evidence and which rest on hope. Do not use market-size figures, growth rates or competitor numbers that are not in the material. Do not treat a count of requests as proof of demand, and do not present an assumed input as measured.

If an input to the size is missing, write [ESTIMATE NEEDED: what] in its place and size only what the numbers support. If all the evidence is weak, say so in the recommendation and suggest the cheapest test before any build.