In 1998, Motorola and a group of partners switched on Iridium, a $5 billion network of 66 satellites built to give business travellers a phone that worked anywhere on Earth. They’d sized the market at close to 5 million subscribers by the end of the decade. By the time Iridium filed for bankruptcy in August 1999, it had roughly 20,000. The satellites worked fine, by the way. It was the estimate that failed, not the engineering. The whole network, worth over $5 billion to build, was later sold to a new set of investors for about $25 million (details in the Iridium collapse analysis published by ASU’s W. P. Carey School of Business).
That’s the thing about market sizing nobody tells you early enough. It isn’t a slide you make after you’ve already decided to build something. It’s the cheapest test you can run before you decide, and skipping it is how perfectly good engineering ends up bankrupt.
This guide covers what market sizing actually is, TAM, SAM and SOM without the jargon fog, when top-down lies to you and when bottom-up is worth the extra afternoon, a full worked calculation for the Indian market you can copy into a spreadsheet tonight, and how to hold your number together when someone senior tries to poke holes in it.
What Is Market Sizing?
Market sizing is the process of estimating how many potential customers exist for a product and how much revenue they could realistically generate in a given period. It takes a fuzzy question like “is this a big opportunity?” and turns it into a number built from assumptions you can actually check.
Two distinctions competitors on this topic tend to blur, so let’s not. First: market size is not your revenue. It’s the total spend available in the category, and your actual share of it is almost always smaller than founders like to believe, sometimes embarrassingly so. Second: a market size is not a fact you look up, it’s an argument you build. Two competent analysts working the same market will land on two different numbers. Fine. What makes an estimate good isn’t precision, it’s whether every input is visible enough for someone else to challenge it. This is also the kind of number product managers get asked to defend on a fairly regular Tuesday.
One more thing worth internalising early: for most decisions, you don’t need to know whether the market is worth ₹410 crore or ₹460 crore. You need to know whether it’s ₹40 crore, ₹400 crore, or ₹4,000 crore, because those three answers point to three completely different decisions. Chasing the second decimal place is a waste of an afternoon.
Three Expensive Mistakes That Started With a Bad Market Estimate
Before any framework, three examples, because frameworks are easy to nod along to and hard to remember without a scar attached.
| Company | The estimate | The reality | The sizing error underneath it |
| Iridium (1999) | ~5 million satellite-phone subscribers by decade end; $5bn+ invested | ~20,000 subscribers; Chapter 11 in Aug 1999; network sold for ~$25m | Sized a need (global coverage) instead of a market, and never re-sized as cellular closed the coverage and price gap |
| Quibi (2020) | $1.75bn raised on the premise of a big market for premium short-form mobile video | Shut down about six months after launch | Confused a huge behaviour (people watch lots of video on phones) with a market (people who’d pay a subscription for that exact format) |
| Segway (2001–) | Projected volumes in the hundreds of thousands of units a year | Sales in the low tens of thousands over the first several years | Sized the transport market instead of the buyers who could clear the price tag and had somewhere legal to actually ride one |
(Quibi figures per CNBC’s coverage of the shutdown.)
Pull the pattern out and it’s basically three habits, repeated:
• Sizing a need instead of a market. A problem being real is not evidence anyone will pay to solve it.
• Never re-sizing. Every one of these estimates was defensible on the day it was made and indefensible eighteen months later. Market sizes decay, quietly.
• Skipping the filters. Price, regulation, distribution and plain habit each cut the addressable population down, and each one got left out.
The Indian flavour of this mistake is the “1.4 billion people” TAM. Start from the population, apply a cheerful percentage nobody can trace, and land on a number nobody can falsify either. India’s population is a fact. India’s paying population for any given product is a much smaller, much harder-won number, and Section 6 below shows where to actually go get it.
TAM, SAM and SOM Explained
| Term | Full form | What it measures | Formula | Question it answers |
| TAM | Total Addressable Market | Total annual revenue if every possible buyer bought from you | Total buyers × annual spend per buyer | How big can this ever get? |
| SAM | Serviceable Addressable Market | The slice of TAM your product, geography, language and price actually reach | TAM × share you can serve | How big is the part I can actually sell to? |
| SOM | Serviceable Obtainable Market | The slice of SAM you can realistically win in a defined period | SAM × realistic penetration rate | What should I plan and hire against next year? |
Picture three concentric circles, TAM on the outside, SOM in the middle, each ring shrunk by a specific filter: geography, price, language, distribution, competition. That labelling is more useful than the plain acronym version everyone else draws, because it tells you what’s actually cutting your number down.
Here’s the abuse to watch for, in yourself and in every pitch deck you’ll ever read: “the market is $10 billion, we only need 1%.” That’s not a plan. It’s an admission that no bottom-up work has been done, and any investor worth their carry will read it exactly that way.
The practical point most explainers skip: SOM is the only one of the three that should actually drive a decision. TAM tells you whether the category is worth entering at all. SAM shapes your go-to-market. SOM is what you budget, hire and forecast against, and it’s the number people spend the least time on, which is backwards. Also worth saying out loud: SAM and SOM are estimates stacked on an estimate, so error compounds. State your SOM as a range. Never hand someone a single figure and call it done.
Top-Down vs Bottom-Up Market Sizing
| Top-down | Bottom-up | |
| Starting point | A published total-market figure, narrowed by percentages | Your own unit economics, multiplied up |
| Typical inputs | Industry reports, analyst forecasts, government aggregates | Number of customers × price × purchase frequency |
| Best for | A fast order-of-magnitude read; category-entry calls | Business cases, forecasts, roadmap and hiring decisions |
| How it fails | Inherits someone else’s definition of the market; percentages are arbitrary | Wrong unit assumptions compound; takes more legwork |
| Time to produce | Hours | Days |
| Defensible under challenge? | Weak, you can’t explain how the total was built | Strong, every input is visible and arguable |
The verdict, and we’re not going to hedge on it the way most explainers do: use bottom-up for any decision that costs real money, and top-down only as a rough cross-check, or when you need a same-afternoon read. It’s not that bottom-up is more accurate, both can be wrong. It’s that a bottom-up number tells you which assumption broke when reality diverges from it, and a top-down number just shrugs. Sizing sits inside a wider business analytics process, not as a one-off exercise: define the question, gather inputs, model, validate, decide.
Quick word on the vendor-report trap, since you’ll run into it constantly: a paid research report’s headline number usually uses the broadest possible market definition, because a bigger number sells more copies of the report. Find the methodology note and the market definition before you inherit a number from anywhere. Can’t find it? Don’t use the figure. It’s that simple.
There’s a third, quieter method worth knowing: value-theory sizing, where you size the market by the economic value your product creates for the customer and then estimate the slice you could capture. Nobody on the usual explainer pages mentions it, and it’s genuinely useful when a category doesn’t exist yet and neither top-down nor bottom-up has a denominator to work from.
A Worked Example: Sizing a Paid Tax-Filing App for India
This is the section that actually earns the title of the article, so bear with the arithmetic. No shortcuts, every input labelled as measured or assumed.
The setup: a team has three months of engineering capacity free. Is a paid ITR-filing app, on top of the free government portal, worth building? Sizing the market is a lot cheaper than spending the three months and finding out the hard way.
| Step | Input | Value | Source / assumption |
| 1 | Individual income-tax returns filed per year in India | ~8.5 crore | Income Tax Department; close to the 8.56 crore e-verified for FY 2024-25 |
| 2 | Share who self-file rather than using a CA or agent | 40% → ~3.4 crore | Assumption, tested in the sensitivity grid below |
| 3 | Of those, share who file on a smartphone and can pay digitally | 85% → ~2.9 crore | Cross-checked loosely against TRAI subscriber and NPCI UPI usage data |
| 4 | SAM at a ₹499 annual price | 2.9cr × ₹499 ≈ ₹1,447 crore/year | Arithmetic |
| 5 | Share who’d pay despite the free government portal | 8% | The load-bearing assumption, see below |
| 6 | SOM (realistic, obtainable by year 3) | 2.3m × ₹499 ≈ ₹116 crore/year | Arithmetic |
Compare that to the top-down version of the same question, which takes about ninety seconds: “India’s fintech market is worth $X billion, tax filing is maybe 2% of it, we’ll grab 5% of that.” That number arrives just as fast. Nobody can check it, and worse, if it turns out to be wrong, it gives the team absolutely nothing to go fix.
Step 5 is doing all the work here, so let’s be honest about it. Everything before it is arithmetic on public data. The 8% is a judgement call about human behaviour in the presence of a free alternative, and it swings the final answer by an order of magnitude. General rule worth keeping: find the one assumption that moves the answer the most, and put most of your research effort there. Most people spread their effort evenly across every input, which is exactly backwards.
You can’t desk-research willingness to pay, unfortunately. You get it from a short survey of 200 to 300 actual filers, ideally with a genuinely representative sample, or by looking at a competitor’s disclosed revenue and user counts and back-solving the conversion rate. A survey is only as good as who you asked. Poll a self-selected group of finance-savvy Twitter users and you’ll get a number that flatters everyone except reality.
A few habits worth stealing: state the time period on every number, per year or per month, always. Keep every figure in the same unit, crore or million, and don’t switch mid-document. And round hard. A market estimate carrying two decimal places is quietly lying to you about how precise it actually is.
Sanity-Check It: Triangulation and Sensitivity
An estimate you’ve built one way is a hypothesis, not an answer. Rebuild it a second, independent way and see if the two land in the same ballpark. For the tax-app example, compare your bottom-up SOM against the disclosed revenue of an existing player in the same category. If your number says ₹116 crore and the market leader earns a fraction of that, something in your assumption stack is off, and it’s worth finding where before you commit to it.
Then swap the single number for a grid. Vary the two assumptions that matter most, price and conversion, and read the range in a spreadsheet:
| Conversion ↓ / Price → | ₹299 | ₹499 | ₹999 |
| 4% (downside) | ₹35 cr | ₹58 cr | ₹116 cr |
| 8% (base) | ₹69 cr | ₹116 cr | ₹232 cr |
| 15% (upside) | ₹130 cr | ₹217 cr | ₹435 cr |
The whole point of building this in a spreadsheet rather than on a whiteboard is that you can actually see this: the decision is often the same across the entire grid, and that’s the most useful thing a sensitivity table can tell you. If even the downside cell clears your investment threshold, build it. If even the upside cell doesn’t clear it, don’t. And if the decision flips somewhere in the middle of the grid, congratulations, you’ve just found exactly what you need to go learn before you commit a single rupee.
Where to Get Real Numbers (India Edition)
Keeping this tight on purpose, this is about which sources exist, not a full desk-research tutorial.
| Source | What it gives you | Best used for |
| MoSPI – Household Consumption Expenditure Survey | Actual household spending by category, urban and rural, by state | Consumer-spend denominators, the most under-used dataset in Indian sizing work |
| Census of India | Population, households, age structure, urbanisation | Population denominators and segment splits |
| TRAI | Telecom and broadband subscriber counts, updated monthly | Digital-reach filters |
| RBI – Database on Indian Economy | Credit, deposits, payments, income indicators | Financial-services sizing |
| NPCI | UPI transaction volume and value | Digital-payment adoption filters |
| Income Tax Department | Returns filed, income distribution | Income-band segmentation |
One rule to close this section: prefer the source that counted something over the source that projected it. A government survey of what households actually spent last year beats a consultancy’s forecast of what they’ll spend in 2030, every single time. See the Census, TRAI, RBI’s database, NPCI’s UPI statistics and the Income Tax Department’s direct taxes data directly whenever you need a denominator, rather than trusting whatever number a blog post quoted three years ago.
How to Answer a Market Sizing Question in an Interview
If you’re prepping for a product-based company interview, a consulting case, or an analyst screen, this is the section for you, and it uses the exact same skill as everything above. The interviewer, for what it’s worth, does not care about your final number. They’re watching whether you structure the problem before calculating, say your assumptions out loud, use round numbers you can actually compute in your head, catch it when an intermediate result is absurd, and stay coherent when they change one input mid-answer just to see what happens.
A repeatable method, five steps:
1. Clarify the question. Per year or per month? Units or revenue? One city or all of India? New sales or the total installed base? Ask before you touch a single number.
2. State your structure out loud before calculating anything. “I’ll start from Bengaluru’s population, segment by income, apply an ownership rate, then a replacement cycle.”
3. Use round anchor numbers. India ~1.4 billion people, ~30 crore households, a metro city roughly 1 crore. Round aggressively, you’re being judged on logic, not on mental arithmetic.
4. Sanity-check as you go. If a step implies every household in Mumbai buys four of something a year, say so and fix it. Catching your own error scores higher than never making one.
5. Give the answer, then name its biggest weakness. “Roughly ₹X crore. The number I’d trust least is the ownership rate, I’d validate that first.”
A quick mini-example, deliberately different from the tax-app calculation above: how many electric two-wheelers get sold in Bengaluru in a year? Population, down to households, down to households that own a two-wheeler, down to the share buying new this year, down to the share choosing electric. Same chain, different category, same discipline.
Mistakes that quietly sink otherwise smart candidates: jumping straight into arithmetic before structuring anything, using precise-sounding numbers you can’t actually justify, going silent while you calculate, refusing to commit to a final figure, and defending an obviously wrong intermediate result out of sheer stubbornness instead of just fixing it. This applies whether you’re headed into a business analyst interview or a PM one, guesstimates show up in both.
Five Mistakes That Make a Market Estimate Worthless
6. Sizing the population instead of the market. 1.4 billion people is not an addressable market. Run every filter, income, geography, language, device, distribution, regulation, before you multiply anything by a price.
7. Inheriting a number you can’t reconstruct. If you can’t explain how a figure was built, you can’t defend it, and you definitely can’t update it when the world moves.
8. Double counting. Counting the same rupee at two points in a value chain, or counting a household and every one of its members separately. Pick a unit, person, household, business, transaction, and hold it constant through the whole calculation.
9. Ignoring willingness to pay. The single most common and most expensive error on this list. A large population with a real problem and no budget is not a market. Quibi is the case study, filed under “we should have asked first.”
10. Sizing once and never again. Iridium’s original estimate was reasonable the day it was made. Markets move, so re-run the numbers whenever a big assumption shifts, a new competitor, a price change, a regulation.
How to Defend Your Number
An estimate isn’t finished when you have a number. It’s finished once someone senior has taken a swing at it and it’s still standing.
A brief, honest aside: the first time I presented a market size to a leadership team, the first question wasn’t about the total at all. It was “where did the 8% come from.” Nobody asks about the total first. They go straight for the assumption that looks the softest, so know which one that is before you walk in.
What to actually bring into the room:
• The assumption sheet, not just the answer. Every input, its source, and whether it’s measured or assumed, clearly marked as one or the other.
• A range, not a point. Base, downside, upside. Volunteering the downside before anyone asks buys more credibility than a single confident figure ever will.
• The one number you’d validate next, and roughly what it would cost to validate it. This single sentence is what makes you sound like an operator instead of a student presenting homework.
• A stated definition of the market, in one sentence, before you present anything else. Half of all sizing disagreements are secretly disagreements about what counts as the market in the first place.
Three questions you’ll get, every time, and how to actually answer them:
• “That seems too high.” Point at the input you’d challenge first, and show the downside case. Don’t defend the total, defend or concede the specific number underneath it.
• “Where did this come from?” Name the source and its date. If it’s an assumption, say the word “assumption” out loud. Nothing kills credibility faster than presenting a guess dressed up as data.
• “What if you’re wrong?” “Below ₹X the decision changes, above it, it doesn’t.” Tie the number straight back to the decision it’s meant to inform. That’s the whole point of sizing in the first place.
Every failure in that first table, Iridium, Quibi, Segway, was a number that got made once and never stress-tested. Sizing well is genuinely cheap. Being wrong about the market, on the other hand, is not.
FAQs
What is market sizing?
The process of estimating how many potential customers exist for a product and how much revenue they could generate in a period. It turns “is this a big opportunity?” into a number built from stated, checkable assumptions.
How do you calculate market size?
Multiply the number of realistic buyers by the price they’d pay by how often they’d buy, within a defined period. Build the buyer count from a verifiable population, then filter it down by income, geography, access and willingness to pay.
What is the difference between TAM, SAM and SOM?
TAM is total revenue if every possible buyer bought from you. SAM is the slice your product, geography, price and channel can actually reach. SOM is what you can realistically win in a set period.
What is the difference between top-down and bottom-up market sizing?
Top-down starts from a published total and narrows it with percentages. Bottom-up starts from your own units, price and frequency and multiplies up. Bottom-up takes longer but is far easier to defend, since every input is visible.
Which market sizing method is more accurate?
Neither is reliably more accurate, but bottom-up is more useful. When reality diverges from a bottom-up estimate, you can see exactly which assumption broke. A top-down number just tells you that you were wrong, not why.
Why do companies get market sizing wrong?
Usually because they size a need instead of a market, ignore willingness to pay, inherit a number they can’t reconstruct, or size once and never revisit it as competitors and prices shift underneath them.
How do you answer a market sizing question in an interview?
Clarify the question, state your structure before calculating, use round anchor numbers, sanity-check intermediate results out loud, then give an answer plus the assumption you’d trust least. Structure matters more than the final figure.
Where can I find data to size a market in India?
Prefer official sources that measure over ones that forecast: MoSPI’s consumption survey, the Census, TRAI, the RBI database, NPCI and Income Tax Department statistics. Industry-body summaries are fine for orientation, just trace the number back to the primary source underneath before you use it.
Wrapping Up
A market size is an argument built from assumptions, not a fact you retrieve from a report. Bottom-up beats top-down for anything that costs real money. SOM is the number that actually matters. Ranges beat point estimates. And an estimate isn’t done until it’s survived being challenged.
Back to where this started: Iridium’s satellites worked exactly as designed. The engineering was genuinely extraordinary. The estimate underneath it was never re-tested, and that, not the technology, is what cost five billion dollars.
Sizing is a skill you’ll use in nearly every product decision you ever make. It takes an afternoon to learn and, honestly, a full career to get properly good at.
Market sizing is one piece of a wider decision toolkit, reading data, framing a business case, defending a recommendation under pressure. Scaler’s online PGP in Business & AI builds those skills through structured, project-based work with mentors who make these calls for a living.
