Why SOM (Serviceable Obtainable Market) Matters More Than TAM for Startups
Most founders obsess over TAM — the Total Addressable Market.
It looks great on a pitch deck, sure.
But if you’re building a real product, TAM doesn’t help you ship code, talk to users, or find traction.
That’s where SOM (Serviceable Obtainable Market) comes in — the market slice you can actually reach, serve, and win right now.
TAM vs SAM vs SOM — The Quick Breakdown
TAM (Total Addressable Market) → The big dream. If everyone on Earth used your product.
SAM (Serviceable Available Market) → The people you could reach given geography, channels, or tech stack.
SOM (Serviceable Obtainable Market) → The ones who will actually buy from you in the next 6–12 months.
In dev terms:
TAM = idea, SAM = scope, SOM = deployable build.
Market Validation: Start Where the Pain Hurts Most
Take Airbnb.
They didn’t start with global hospitality TAM.
They started by validating if anyone would pay to sleep on an airbed in a stranger’s home.
That was their first SOM — a few dozen budget travelers in one city.
They built the MVP manually, not the app.
As devs, that’s like running a concierge MVP before writing backend logic.
Manual validation > premature scaling.
Pro tip:
Ask yourself, who feels this pain the most and how can I test it with minimum code?
🧠 Engineering Experiment: Can the Tech Actually Scale?
Google didn’t have to prove people wanted search.
They had to prove that the PageRank algorithm could handle load at scale.
That was their SOM — users who cared about better search quality, not just more search options.
Your version might look like this:
Can your AI model handle 10k daily inferences?
Can your API scale without latency killing UX?
Can your app maintain uptime under real-world traffic?
Before scaling to TAM-level markets, define your engineering SOM — the segment your tech can support without burning down servers.
Imagination Experiment: The Trap Zone
This is where most startups waste time.
You’ve got a cool idea. You start building. But there’s no data, no validation, no real users.
That’s not an experiment — that’s wishful thinking in production.
Common failure patterns:
Overengineering features no one validated.
Building the perfect architecture for imaginary scale.
Labeling untested ideas as “experiments” to make failure sting less.
Pro tip: Run fake door tests, prototype experiments, or limited beta releases before investing in long dev cycles.
Measuring SOM: Real Feedback, Not Gut Feeling
Startups that last — like Dropbox, Figma, and Notion — didn’t guess their markets.
They tested hypotheses in small, measurable ways.
Build a waitlist MVP and measure conversion.
Add feedback loops in product development.
Use analytics tools early — see what users actually do, not what they say.
Each iteration defines a smaller, more profitable SOM.
In dev terms: feedback loops = continuous integration for market learning.
The SOM Playbook for Tech Builders
- Identify the segment that’s screaming for your solution.
- Run a small, testable MVP (even a fake one).
- Measure retention, not reach.
- Scale when your experiment repeats successfully.
That’s experiment-driven growth in action — not just code iteration, but market iteration.
Final Thought
TAM looks nice on slides.
SOM builds working code, real users, and revenue.
If you can’t clearly define who you’re building for, why now, and what they’ll pay for — you’re not validating; you’re guessing.
So next time you ship, ask yourself:
👉 “What’s my SOM, and am I coding for it?”
Top comments (0)