Sizing an Opportunity Without Inventing Numbers

"This is a $2M opportunity."

Where did that come from? Usually from a chain of multiplications nobody shows, in which one factor was measured, one was estimated, and one was chosen because it made the total look worth doing.

Opportunity sizing is where a spec is most tempted to invent numbers, because the section seems to demand a figure and the honest answer is a range with a hole in it. The hole is fine. A confident number in its place is the same failure as a metric with no baseline, one step earlier: a figure that looks like a decision and rests on nothing anyone chose.

The honest version has four parts. Factors you can name, a range for each, a label saying where each came from, and the word unknown wherever it belongs.

Build it from factors you can name

A top-down market figure answers whether a business is worth being in. That is the question an MRD answers, and by the time you are writing a spec it has been settled. A PRD needs a bottom-up size: this problem, in this product, for these users.

Most bottom-up sizes are a product of four factors:

• Reach. How many accounts or users are in the segment the feature serves.
• Incidence. What share of them have the problem, under a definition you have written down. The "how often" in a problem statement that survives review is this factor.
• Adoption. What share of those would use the fix.
• Value. What each adoption is worth: retained revenue, expansion, time saved, tickets avoided.

Each factor gets a low, a high, and one of four labels: measured (with the source), estimated (from what), assumed (no data), or unknown. The labels are the point. They are what lets a reader see which parts of the total are arithmetic and which are hope.

A worked example

An illustration. Say you are sizing scheduled exports for accounts on a business plan.

Factor	Low	High	Label
Accounts on the plan	1,200	1,200	Measured: billing export, September
Share that repeat the same export weekly	18%	24%	Estimated: logs show 18% repeating one export four weeks running; the high end allows for exports done outside the product
Share that would switch to a schedule	20%	70%	Assumed: no data
Value per adopting account	unknown	unknown	Unknown: no evidence yet that exports affect renewal

Reach times incidence times adoption gives 1,200 × 18% × 20%, about 43 accounts, at the low end, and 1,200 × 24% × 70%, about 202, at the high end.

Three things this shows that a single number would hide.

The range is wide, and that is honest. About 43 to 202 accounts. The figure someone would have written without the table, "around 120 accounts", sits inside it and explains nothing about how it was reached.

One factor is responsible for most of the width. Incidence spans 18% to 24%. Adoption spans 20% to 70%, and it is the one labelled assumed. Pin adoption at its midpoint and the range narrows to roughly 97 to 130. That tells you what to find out next, which is worth more than the size itself.

The value is unknown, so the size is a count of accounts, not money. Say so. It is tempting to multiply 202 accounts by average revenue and write a dollar figure, but that assumes every adopting account's whole contract depends on exports. Nobody believes that, and writing it down makes it look as though somebody does.

One more line belongs under the table: the low end multiplies every low together, and the high end every high, so both ends are less likely than any single factor's low or high. The range is a bound, not a forecast.

Saying "unknown" honestly

Unknowns come in three kinds, and each deserves a different sentence in the spec.

Unknown, and cheap to find. A log query, a billing export, a look at the ticket tags. Go and get it. A gap you could close in an afternoon is not uncertainty; it is an unfinished section.

Unknown, and expensive to find. Keep the range, keep the label, and say what it would cost to narrow. For adoption, that might be a fake-door test: a Schedule option that records interest before the feature exists. Be careful what you expect from interviews here. They tell you how people describe the problem and why it matters to them, and they are planned around a different question from how many people have it.

Unknowable before you build. Some factors only exist once the thing does. Say so plainly, and make the first release the measurement, with a stop condition written in advance: "If fewer than 40 accounts schedule an export within 60 days, we stop investing past the first version."

That third kind is not a failure of research. It is an honest description of where research ends.

Does the decision depend on it?

The most useful question about any size is not "how big?" but "at what size would this be the wrong bet?"

If the build is two weeks and even 43 accounts would justify it, stop sizing and build. The uncertainty is real, and it does not matter. If the build is a quarter and the team agrees it needs around 150 accounts to be worth it, the decision flips inside the range. Then the factor driving the width, adoption here, is the first thing to research, before design starts.

Precision costs time. The precision you need is set by where the decision flips, not by how impressive the section looks.

What not to do

Borrow a number from another population. An industry adoption rate or a competitor's figure measures somebody else's users. The baseline post calls this the wrong population, and it is as wrong in sizing as in metrics.

Convert to revenue by default. Multiplying accounts by average revenue assumes all of it is at stake. If you have a reason to believe some share is, write the share and the reason.

Round the range to its midpoint. The midpoint is the number most likely to be quoted back to you later, and the one nobody actually estimated.

Hide the arithmetic. If a reviewer cannot recompute the size, they cannot challenge it, and an unchallengeable number tends to pass review untouched.

In review

Two questions do most of the work. Which of these numbers did you measure? And at what size would we not build this?

The first sorts the factors into evidence and assumption, and the measured ones deserve the same treatment as anything else in the evidence section: who, how many, when. The second connects the size to the decision it is meant to inform. A size that cannot change the decision is decoration, and the spec is shorter without it.

FAQ

How do you size an opportunity? Reach, incidence, adoption and value, each with a range and a label, multiplied through and reported as a range.

TAM in a PRD? Rarely. The spec needs the size inside your product, not the market.

Really unknown? Say which factor, what it would take to find out, and whether the decision depends on it.

Why a range? It shows the uncertainty and which assumption causes it.