Table of Contents

SaaS market research tells you if a problem worth solving exists in a market who has it, how big it is, and what they're already using. SaaS product research tells you how to solve it, what features to build, in what order, for which users.
Market research comes first. Product research builds on top of it. Most SaaS teams do them in the wrong order or conflate them entirely and that's where timelines blow out and launch-day silence happens.
A B2B SaaS founder spent 11 months building a project management tool for construction teams. He ran surveys. He joined forums. He talked to contractors. On launch day, he had 47 sign-ups and zero paid conversions. Not because the product was bad but because he'd been asking the wrong questions the entire time.
He was doing market research when he needed product research. And he had no idea there was a difference.
That's the real problem in SaaS research. Not a lack of data but research done in the wrong order, at the wrong stage, answering the wrong questions.
What is SaaS Market Research?
SaaS market research is about the landscape outside your product. It answers one core question: is there a real, paying, reachable group of people who have a problem bad enough to pay for a solution?
That means digging into TAM/SAM/SOM to understand market size, mapping your ideal customer profile (ICP) before you touch a wireframe, running win-loss analysis if you already have competitors in the space, and understanding churn rate patterns in adjacent tools your audience is already using.
Market research answers four questions. If you can't answer all four clearly, you're not ready to build:
- Who specifically has this problem? (Not 'construction teams' - '3-to-15-person subcontractor crews in the US who job-cost manually')
- How are they solving it today, and what does that cost them per month in time or money?
- What have they already tried and abandoned and why?
- Is there expansion revenue potential will this customer segment grow into more seats or higher plans over time?
What is SaaS Product Research?
SaaS product research starts after you've confirmed the market. It answers a different question: what does the solution need to look like and in what order should it be built?
Think of it this way. Market research tells you your ICP has a 3-hour-a-week problem with invoice reconciliation. Product research tells you whether they want that fixed in a dashboard, an automated workflow, a Slack notification, or all three and which one they'd pay for first.
SaaS product research covers three layers:
- Feature prioritization research - user interviews, feature voting, Jobs-to-be-Done (JTBD) sessions to decide what lands on the roadmap
- Usability research - prototype testing, session recordings, first-click analysis to make sure the product actually works for real users
- Behavioral analytics research - cohort analysis, feature adoption tracking, heatmaps to understand what users do versus what they say
Product Research vs Market Research
Market research always comes first because product research assumes you already know your user. It goes deep on specific behaviors, preferences, and workflows. But if you haven't confirmed who that user is and why they'd pay you you're just doing very expensive guesswork with better-looking research.
The sequence that works for B2B SaaS founders and scale-ups:
- Market research (pre-build): Confirm the problem, the segment, the size, and the competitive gap. This is your go-to-market strategy foundation.
- Customer discovery (pre-build): 15–20 qualitative interviews with your ICP to validate the pain is real and costly enough. This sits between market and product research.
- Product research (MVP stage): Now build. Use JTBD interviews, usability tests on prototypes, and behavioral data from early users to shape what gets built next.
- Continuous product research (post-launch): NPS vs CSAT tracking, retention research, cohort analysis, and feature adoption data run on a continuous loop from here on.
When to do Market Research in SaaS
There are four specific triggers in a SaaS company's lifecycle when market research pays off and two moments when doing more of it is actually delaying you.
- You're validating a new market before committing 6+ months of engineering time
- You're expanding into a new customer segment or geography and need to rebuild your ICP
- A competitor just raised $20M+ and you need to understand how the market perception is shifting
- Your churn rate is above 3% monthly MRR and the exit interviews are all pointing at the same feature gap
B2B SaaS Research Methods That Actually Work
The research method matters less than the research moment. The same user interview done at the wrong stage gives you useless data. Here's what works at each point:
Before product-market fit:
- Qualitative user interviews (15–20 calls, 45 minutes each) ask about the problem, not your solution. The moment you describe your product, the data gets contaminated.
- Buyer persona development builds this from interviews, not assumptions. Who approves the budget? Who blocks the deal? In B2B SaaS, the user and the buyer are rarely the same person.
- Win-loss analysis if you have any competitors, call 5 people who chose them over you and 5 who chose you. One hour of calls like this beats a month of market research reports.
After your first 50 users:
- Cohort analysis group users by signup month and track retention week by week. If month-3 cohorts are dropping off at week 6, you have a product problem, not a marketing problem.
- Feature adoption research track which features users activate in week 1 and correlate with 90-day retention. Your highest-retention users are your ICP; understand exactly how they use the product.
- Behavioral analytics session recordings, heatmaps, and funnel analysis show you what users actually do. What they tell you in surveys and what they do in the product rarely match.
- NPS vs CSAT use NPS quarterly to track overall sentiment trend. Use CSAT immediately after specific interactions (onboarding, support, new feature release) to get granular signals.
The Research Mistakes are kill SaaS Scale-Ups
These aren't beginner mistakes. Scale-ups with $2M ARR make them constantly.
Mistake 1: Treating customer interviews as product research
Talking to 20 people about which features they want is not market research, it's product discovery research done too early. You end up building exactly what a narrow group of early users want, missing the 10x bigger segment right next to them.
Mistake 2: Confusing high NPS with product-market fit
A 72 NPS score from 18 users means your 18 users like the product. It says nothing about whether a $10M+ market segment would adopt it. PMF is about segment density, not individual satisfaction. Use the Sean Ellis PMF question ('how disappointed would you be if this product disappeared?') with a statistically meaningful sample at minimum 40 responses.
Mistake 3: Running market research without a product roadmap
Research without a decision to inform is just expensive curiosity. Before you commission a competitive analysis or send a user survey, write down: 'Based on this research, we will decide whether to do X or Y.' If you can't name the decision, you don't need the research yet.
Mistake 4: Doing saas product research before building
Pre-launch interviews give you hypotheses, not truths. The product research that actually guides your roadmap comes from real usage data MRR movement, CAC trends, LTV by cohort, and feature adoption rates at 30/60/90 days. What users say they'll do and what they actually do after you charge them $299/month are completely different things.
How to Build a Research Sequencing Strategy for B2B SaaS
Research sequencing is the discipline of knowing which type of research to run, at which stage, using which method. It's what separates scale-up teams from early-stage ones still trying to answer market-level questions with product-level data.
A workable research calendar for a B2B SaaS team between $500K and $3M ARR:
- Monthly: Cohort retention analysis, feature adoption dashboards, MRR/churn breakdown by segment
- Quarterly: 5 - 8 user interviews (mix of your best-retained and recently-churned), NPS pulse, 1 win-loss interview
- Bi-annually: Full market sizing refresh, ICP review (does your actual best customer still match the ICP you wrote 6 months ago?), competitive landscape update
- As-needed: Usability testing before major feature launches, customer segmentation research before pricing changes, go-to-market strategy review before entering a new vertical
Final Thoughts
Ask yourself one question: can you name the exact type of person who will pay you, the exact problem they have, and the exact reason they haven't solved it yet?
If the answer is no or if it takes you more than 30 seconds to give a concrete answer you need market research first. Go talk to 15 people in your target segment.
Not a survey. Phone calls. Ask about their workflow, their tools, their frustrations, and what they tried last year to fix it. If you can answer that clearly, and you have at least 10 paying users, shift your research energy to the product layer.
Run cohort analysis. Watch session recordings. Interview your churned users with one specific question: 'What was the moment you decided this wasn't working?'
The best B2B SaaS teams don't do more research. They do the right research at the right time and then act on it immediately.
Frequently Asked Questions
What is SaaS market research?
SaaS market research is the process of validating that a specific customer segment has a real, recurring problem that's large enough to support a software business. It covers market sizing (TAM/SAM/SOM), competitive analysis, ICP definition, and buyer behavior all before product decisions are made.
What is the difference between user research and market research in SaaS?
Market research looks outward at segments, competitive positioning, and market opportunity. User research (a subset of product research) looks inward at how specific users interact with your product, what they struggle with, and what they need next. Both are essential, but market research informs whether to build at all; user research informs what to build.
How do you do market research for a SaaS product before building?
Five steps that work for pre-build SaaS market research:
- Define your ICP hypothesis on paper (industry, company size, job title, the specific workflow where the pain lives)
- Run 15–20 discovery calls with that specific ICP - no pitching, only listening
- Map the competitive landscape: who are they paying now, what do they hate about it
- Estimate bottom-up TAM: number of companies in this segment × average contract value you could charge
- Validate willingness to pay - ask directly: 'If something fixed this, what would $X/month be worth to you?'
What's the difference between product discovery and market research?
Product discovery is the earliest stage of product research; it's where you test solution hypotheses through prototypes, concept tests, and early user interviews. Market research sits upstream of it. You do market research to confirm the problem and segment; you do product discovery to confirm the solution shape.
When should a SaaS scale-up stop doing market research and focus on product research?
When you have 10+ paying customers with a consistent ICP, validated PMF signals, and a clear go-to-market motion. At that stage, additional market research produces diminishing returns. Your fastest growth lever shifts to product-led signals: retention research, feature adoption data, and churn analysis not more market sizing exercises.
What SaaS metrics should inform product research?
The metrics that tell you most about what to build next:
- Activation rate by cohort - what % of new signups reach the 'aha moment' in week 1?
- Feature adoption at day 30 - which features correlate with accounts that renew at month 3?
- LTV:CAC ratio by segment - which customer type is actually worth acquiring?
- Expansion MRR - are users upgrading organically, or are you fighting for every renewal?
- Churn reason codes from exit interviews - the top 3 exit reasons are your product roadmap priorities.









