SaaS customer research is useful only when it changes a decision. A folder full of interview recordings may look impressive, but it means little if the same assumptions still control the product roadmap.
I see research as a way to understand the problems customers face, the conditions around those problems, and the cost of leaving them unresolved. It is not a process for asking customers what the company should build next.
Customers understand their own work better than anyone. They do not necessarily know which solution will work across different accounts, roles, and use cases. That judgment still belongs to the product team.
How Does SaaS Customer Research Shape a Product Roadmap?
SaaS customer research shapes a product roadmap by replacing assumptions and isolated feature requests with evidence about who has a problem, how often it occurs, and what it costs them. Start with a specific roadmap decision, speak to the customer roles affected, and combine interviews with product usage, support, sales, and churn data. Ask about recent behavior rather than promised future use. Then compare opportunities by reach, severity, strategic fit, evidence confidence, effort, and risk. The chosen roadmap item should state the customer problem, intended outcome, and success metric so the team can verify after launch whether customer behavior actually improved.
Start With the Roadmap Decision
Vague research goals produce vague findings. “Learn what customers think about reporting” may lead to an interesting conversation, but it gives the team no clear way to act.
A more useful objective would be: Determine whether reporting limitations are preventing finance teams at mid-sized customers from completing monthly reconciliation.
This version identifies the customer, the suspected problem, and the decision the research needs to support.
Before contacting participants, I would define:
- The roadmap decision that needs to be made
- The assumption being tested
- The customer segment involved
- What the team already knows
- What evidence is still missing
- How the findings could affect the decision
- Which metric would show whether a future solution worked
It is also worth reviewing the evidence the company already has. Support tickets, sales notes, product analytics, cancellation feedback, onboarding calls, renewal conversations, and failed deals can expose useful patterns.
These sources have limits. Support tickets overrepresent people who reported a problem. Product analytics can reveal where users abandon a task but not why. Sales calls may uncover buying objections without explaining the daily experience of end users.
The goal is to find what appears consistent, what remains uncertain, and who can help close the gap.
Talk to the Right Customers
In B2B SaaS, “the customer” is rarely one person. A daily user may understand the workflow in detail but have no influence over the renewal. An administrator may care about permissions, integrations, and setup. A buyer may focus on cost, risk, and business value. Security and procurement teams may introduce different requirements again.
Depending on the decision, useful participants may include:
- Daily users
- Account administrators
- Internal product champions
- Economic buyers
- New customers still onboarding
- Trial users who did not convert
- Customers with declining usage
- Recently churned accounts
- Prospects that selected a competitor
Not every study needs every group. The participants simply need to have the right experience to answer the research question.
I would also avoid relying only on enthusiastic power users and large accounts with responsive customer success managers. They are easier to reach, but they may not represent quieter users, struggling customers, or the market the company wants to serve next.
Choose Evidence That Fits the Question
No single research method can answer every product question. Interviews help explain motivations, workflows, workarounds, and consequences. Contextual observation adds another layer by showing how people complete a task in their usual environment.
Product analytics is better for measuring what users actually do. It can reveal adoption, frequency, conversion, abandonment, and differences between customer groups.
Surveys can help estimate how widely a known problem is experienced. They are less useful when the team has not yet worked out what it needs to measure. A survey filled with broad, open-ended questions is often a sign that interviews should have happened first.
Usability testing answers another question: can people understand and use a proposed solution? It does not prove that the underlying problem is important enough to justify building that solution.
For an important roadmap decision, I would normally combine evidence. Analytics can show where a pattern occurs and how many users it affects. Interviews can help explain what is happening behind the numbers.
Ask About What Actually Happened
Customers are generally better at describing past behavior than predicting what they might do in the future.
Questions such as “Would you use this feature?” invite speculation. A participant may like the idea, want to be helpful, or imagine using something that never becomes part of their routine.
Questions tied to a recent experience are more revealing:
- “Walk me through the last time you did this.”
- “What triggered the task?”
- “What did you try first?”
- “Where did the process become difficult?”
- “What workaround did you use?”
- “Who else had to be involved?”
- “What happened when the task was delayed?”
- “How often does this situation come up?”
- “Could you show me how you handle it today?”
Follow-up questions matter more than having an elaborate script. If someone says a task was frustrating, ask what made it frustrating. If they mention a workaround, find out how often they use it and what it costs in time, money, or risk.
The aim is not to persuade customers that a problem exists. It is to understand whether the problem already changes their behavior.
Run Small, Focused Research Rounds
There is no universal number of interviews that proves a SaaS opportunity is worth pursuing.
Four to eight carefully selected participants from one customer group can be a sensible first qualitative round. The team can then review the findings, improve its questions, and conduct another round if meaningful uncertainty remains.
Different customer groups should not be blended into one convenient pattern. Administrators and daily users may experience the same product limitation in completely different ways.
Small interviews provide depth and context. They cannot reliably show how common a problem is across the market. That requires broader behavioral data, a properly designed survey, or another suitable quantitative method.
The point is to build confidence in stages, not to chase a supposedly perfect interview count.
Treat Feature Requests as Clues
Feature requests should not move directly from a support ticket to the roadmap. Suppose several customers ask for scheduled CSV exports. The obvious response is to build an export scheduler. But the request does not explain the full job.
Further research may reveal that finance teams manually prepare the same report every Monday because colleagues cannot access the product. The real need might be scheduled reporting, restricted viewer access, an accounting integration, or a better API. A scheduled export is only one possible solution.
When a customer asks for a feature, I want to understand:
- What they are trying to accomplish
- What prevents them from doing it today
- How they currently work around the limitation
- How often it happens
- Who is affected
- What the consequence is
- Why their requested solution feels appropriate
This respects the customer’s knowledge without handing over responsibility for product design.
Turn Raw Evidence Into a Clear Opportunity
Research becomes unreliable when observations, interpretations, and recommendations are treated as the same thing.
Consider this example:
- Observation: Three administrators export the same report every Friday.
- Interpretation: They may be compensating for limited sharing permissions.
- Recommendation: Investigate scheduled reporting and restricted viewer access.
The first statement describes what happened. The second offers a possible explanation. The third proposes a next step. Keeping them separate stops assumptions from looking more certain than they are.
Each important finding should remain connected to its source. Record the customer role, account segment, lifecycle stage, observed behavior, underlying problem, current workaround, consequence, and date. Contradictory evidence belongs in the record too.
If six participants want more automation and three worry about losing control, that disagreement may reveal different roles, responsibilities, or risk levels. Removing the minority view would make the findings cleaner but less useful.
AI can help transcribe interviews, suggest tags, and search a large research library. Important themes should still be checked against the original evidence. Automated summaries can flatten disagreements or make a weak pattern appear stronger than it is.
Recordings and transcripts may also contain personal or commercially sensitive information. Participants should know when a session is being recorded and how the material will be used. Access should be restricted, unnecessary personal information removed, and research data shared only with approved systems.
Prioritize Opportunities, Not Customer Votes
A product roadmap is not a customer election. The most requested feature does not automatically deserve the most development time.
The number of mentions is useful, but it needs context. I would also consider:
- How much of the intended market experiences the problem
- How frequently it occurs
- How serious the consequence is
- Whether it supports the product strategy
- Its possible effect on acquisition, retention, or expansion
- The quality of the supporting evidence
- Development effort and technical dependencies
- Security, compliance, and operational risk
- What the company must delay to pursue it
A request from one large customer may expose a broader enterprise need. It may also be expensive custom work with little value elsewhere. Revenue matters, but so do repeatability, strategic fit, and opportunity cost.
Scoring frameworks can help structure the discussion. They should not create the illusion that a product decision can be solved by arithmetic alone.
Connect Research to the Roadmap, and the Result
A research-backed roadmap item should explain more than what the team intends to build. It should identify:
- The customer problem
- The affected segment
- The supporting evidence
- The business objective
- The intended outcome
- The remaining uncertainty
- The next validation step
- The success metric
When uncertainty remains, I would put the problem or desired outcome on the roadmap rather than committing too early to a detailed feature. That gives designers and engineers room to find a better solution.
The evidence should remain accessible after planning ends. Months later, anyone on the team should be able to ask, “Why are we doing this?” and find a clear answer.
Research also continues after launch. Shipping a feature does not prove the original assumption was correct. The team still needs to examine whether the intended customers adopt it, complete the task more successfully, reach value sooner, or abandon the workaround that first exposed the problem.
If the expected behavior does not change, the team should revisit the decision. The feature may be difficult to discover, aimed at the wrong segment, poorly designed, or solving a less important problem than expected.
Customers who contributed should receive an honest update as well. Closing the loop does not mean promising to build every request. It means showing that their time informed a real decision.
Make Research Answerable to Decisions
Good SaaS customer research does not produce a roadmap containing everything customers requested. It creates a clearer understanding of which problems matter, who experiences them, what those problems cost, and where the company has a credible opportunity to help.
My standard is simple: every important roadmap bet should connect to a customer problem, a strategic reason, and a measurable outcome. If the research cannot influence a decision, the team may be collecting information rather than learning.
Frequently Asked Questions on SaaS Customer Research
1. How many customers should I interview for SaaS research?
A focused first round often includes four to eight people from one relevant customer group. Continue if new interviews are still changing your understanding. Small qualitative samples provide depth, not statistical proof.
2. How often should a SaaS company conduct customer research?
Research should follow meaningful product decisions rather than an arbitrary interview quota. A regular cadence helps, but every study should answer a question the company is prepared to act on.
3. Should popular feature requests automatically go on the roadmap?
No. Repeated requests identify an area worth investigating. The team still needs to understand the underlying problem, affected segment, strategic value, expected outcome, and cost.
4. How should I balance feedback from large and small customers?
Consider account value alongside repeatability, target-market fit, retention risk, evidence quality, and opportunity cost. Large customers deserve attention, but they should not control the roadmap automatically.
5. Can AI replace customer interviews?
No. AI can assist with transcription, organization, and early analysis. It cannot replace direct customer context, responsible judgment, privacy controls, or human verification.
