Introduction
Feedback in a B2B SaaS company arrives from everywhere: sales calls, support tickets, churn interviews, analytics, account conversations. The trouble starts afterwards. The reasoning behind a product decision gets scattered across five or six tools and as many handoffs.
Atlassian's own customer, CloudBees, describes this problem in terms of feedback coming from internal teams, customers and multiple channels. Shorter Loop's FlowDesk example makes it concrete: 41 pieces of feedback sat across three systems and nobody had analysed them together.
This article explains product discovery as a continuous way to reduce uncertainty, validate customer problems, and connect evidence to decisions, delivery and outcomes.
Key Takeaways
- Discovery means learning which problems matter, for whom, and under what conditions, not logging feature requests.
- Buying groups, workflows, integrations, security and commercial limits all shape B2B evidence.
- Useful discovery links evidence, assumptions, decisions, delivery and post-launch outcomes.
- AI speeds up synthesis, but humans still verify sources and own the judgement.
What Is B2B SaaS Product Discovery?
A B2B product is sold to or used by organisations. NIST defines SaaS as provider applications running on cloud infrastructure that customers reach through a browser or program interface. B2B SaaS, then, is cloud software that helps businesses run a process, make decisions or coordinate work.
B2B SaaS product discovery is the continuous process of understanding customer problems, testing assumptions, exploring solutions, and deciding what is worth building, before and during delivery.
Discovery and delivery are linked, not separate
Discovery addresses four risks: value, usability, feasibility and business viability. Delivery turns validated decisions into working software.
Discovery doesn't stop at launch. Usage and outcomes become evidence for the next decision.
Shorter Loop's chain reflects that cycle: customer evidence, insight, strategy, decision, delivery, outcome, then back to new evidence.
What discovery produces
- Problem statements and customer segments
- Workflow maps and assumptions
- Opportunity areas and hypotheses
- Experiment results and decision records
- Outcome measures
Those outputs only help if you keep four things apart. Otherwise every request becomes a roadmap item:
- Evidence: what you observed or were told, with context
- Interpretation: what you think it means
- Customer request: the solution a customer proposed
- Implementation-ready requirement: a decision that survived testing
Why B2B SaaS Product Discovery Is Different
Many stakeholders, conflicting needs
End users, economic buyers, administrators, champions, procurement, security and finance all have a stake. Gartner's research finds buying groups of 5 to 16 people across up to four functions, and 74% show unhealthy conflict. Those figures describe B2B buying overall, not SaaS alone.
The same split shows up inside your feedback. In FlowDesk's case, the operations manager pays while the dispatcher uses the product daily. A champion may have influence but cannot sign the cheque.
Security and integration matter early too. Gartner Digital Markets found that 46% of software buyers cite security certification, reputation or data privacy as a leading consideration. Another 34% want integration with other technology.
Account and workflow context
Don't ask only whether a customer wants your proposed feature. Investigate:
- Map their current process and workarounds
- Trace systems, handoffs and triggers
- Measure how often the problem occurs
- Assess the risk and consequence when it goes wrong
Account context helps, but it can mislead. A sales rep may push hardest for the feature that lost the last deal, not the one that wins the next hundred. Weigh requests by segment, severity and evidence, not by the loudest voice or the biggest contract.
The scaling problem
Evidence can sit across roughly 15 systems: CRM, support desk, analytics, research repository, ticket tracker. When ownership is unclear, teams repeat research or ship work that no longer matches the original evidence.
Involve product, design, engineering, customer-facing teams and subject-matter experts early. Shared understanding is cheaper to build before the debate than during it.
A Practical B2B SaaS Product Discovery Process
1. Frame the decision and desired outcome
Define the inputs that will steer the work:
- Customer segment and business outcome
- Decision, constraints and assumptions
- Evidence that would change your mind
Write a focused discovery question, not "Should we build feature X?"
FlowDesk's vision focused on shift scheduling for mid-sized logistics operators, with objectives of 400 accounts and reduced churn. That gave its research a target.
2. Map stakeholders, workflow and context
Identify who feels the problem, who influences the purchase, who approves it, and who administers the product. Then document the current state:
- Workarounds and tools
- Dependencies and failure points
- Security or compliance considerations
- Where the problem causes measurable cost or risk
3. Gather evidence from several sources
Combine interviews and observation with support conversations, sales notes, win/loss feedback, usage analytics, churn insights and prototype tests.
- Recruit real or representative users, and ask about past behaviour rather than predicted use, as Nielsen Norman Group advises.
- Avoid leading questions.
- Record enough context to tell a repeated problem from a one-off preference.
- Treat the five-user guideline as a rule for qualitative usability testing, not a universal interview sample size.
Data protection matters in the Netherlands. Under GDPR, consent is one of six lawful bases, not a requirement for every research activity. Where consent applies, it must be freely given, specific, informed and unambiguous, and withdrawal must be as easy as giving it. In practice:
- State your purposes and minimise the data you keep.
- Tell participants about retention and their rights.
- Delete or anonymise recordings when you no longer need them. The Autoriteit Persoonsgegevens notes GDPR sets no single fixed retention period.
Check your own legal basis with your data protection officer.
4. Synthesise into opportunities and hypotheses
Separate customer language and observations from interpretations, requests and solutions. Group patterns by segment, workflow, severity, frequency, strategic relevance and evidence strength. Don't count every request equally.
Write hypotheses that state the expected customer or business change and what you need to learn before committing real effort. FlowDesk's 14 churn interviews showed dispatchers were central to daily use, something its 95%-complete persona, built without a single interview, had missed.
5. Test directions before scaling investment
Use the lightest method that fits: a prototype review, usability test, concierge experiment, technical spike, workflow simulation, pilot or limited release. Usability prototypes test interaction; feasibility prototypes investigate technical risk. A usability pass alone doesn't prove willingness to buy.
Before you run anything:
- Define success and failure signals
- Include feasibility and viability checks
- State the next action for each result: proceed, revise, investigate further or stop
Then record what you learned and what remains uncertain.
Research Methods, Evidence, Tools and AI
Build a usable evidence record
For each insight, capture:
- Source and date
- Account or segment, and role
- Workflow context and customer problem
- Supporting evidence and confidence
- Linked opportunity and related decision
Focus on making important evidence findable, comparable and connected to action, not on growing a larger feedback database. GitLab's handbook shows one approach: research insights backed by clips, quotes and statistics, with insight issues linked to evidence, discussion and action.
Where AI helps, and where it doesn't
AI works well for transcription, summarisation, clustering, theme detection, retrieval and spotting unanswered questions. A human should verify every output against the original source.
Watch for these risks:
- Hallucination: NIST notes generative AI can produce confidently inaccurate content and amplify bias.
- Provenance: a theme with no traceable source is a guess.
- Confidentiality: under GDPR, an AI vendor processing customer research needs a data processing agreement, documented instructions and confidentiality commitments.
- Transfers: a data processing agreement doesn't replace the rules for sending data outside the EEA.
- False validation: a generated theme is not a validated insight.
Shorter Loop's Sage follows this logic: responses trace back to evidence, and it declines to draft recommendations when the supporting data is thin.
Choosing a discovery stack
Don't start with a tool list. Judge each tool on:
- Traceability from insight to decision
- Account context, such as CRM data
- Permissions and interoperability
- Adoption and searchability
- Decision history
Each tool answers a narrow question:
- A research repository shows what customers said
- A delivery system shows whether something shipped
- Analytics show what happened
None of these shows whether a decision still rests on its original evidence. Tools support an operating model; they can't fix unclear questions, weak research practice or missing decision owners.
From Evidence to Prioritised Bets and Outcomes
Prioritise problems, not popularity
Weigh the factors that decide whether a problem deserves a bet:
- Customer value and strategic fit
- Evidence confidence and affected segments
- Commercial and retention relevance
- Feasibility, risk and the cost of delay
Frameworks such as RICE (reach x impact x confidence / effort), ICE, WSJF and opportunity scoring can help. But Intercom is explicit that RICE scores are not hard-and-fast rules. Use scores to make assumptions visible, not to manufacture precision.
Preserve the reasoning
For each significant decision, record:
- The problem and supporting evidence
- Assumptions and alternatives considered
- Decision owner, date and confidence
- Dissenting views
- Conditions that would trigger a review
Decision records end repeated debates and help new team members see why a roadmap bet exists.
Connect to strategy, delivery and outcomes
Link validated opportunities to objectives, initiatives, delivery work, owners and dependencies. Treat the roadmap as a set of informed bets and learning commitments, not permanent feature promises.
Close the loop after release
Pick measures that match the original hypothesis. Useful signals include adoption, task completion, workflow performance, support demand, expansion, retention, conversion and customer-reported value.
Compare the observed outcome with the expected one, and note whether the evidence supports, weakens or changes the decision.
Where a connected system helps
When discovery, strategy, roadmap and delivery live in different tools, the seams are where reasoning gets dropped. Shorter Loop is one example of a system built for that problem. It links customer evidence, strategy, decisions, delivery work and outcomes, so a team can inspect why a bet exists and what happened after it shipped. Claims are labelled as claimed, corroborated, unsupported or contradicted, with connections to Jira, Linear and HubSpot. EU data residency is available, which is relevant for Dutch teams.
Frequently Asked Questions
What is product discovery in B2B?
It is the process of understanding organisational customer problems, testing assumptions, evaluating solution options, and deciding what to build based on evidence.
What is a B2B product?
A product sold to or used by organisations to support a business process, decision, workflow or operational need.
What are examples of B2B products?
CRM platforms such as Dynamics 365 Sales, analytics tools like Power BI, cybersecurity tools, billing systems like Stripe Billing, and developer platforms such as GitLab.
How is B2B SaaS discovery different from B2C discovery?
B2B involves multiple stakeholders, longer buying processes, account context, integrations, security and procurement review, and organisational workflows.
What are the main steps in B2B SaaS product discovery?
Frame the problem, research stakeholders and workflows, synthesise evidence, test hypotheses, prioritise, then learn after launch.
How do you measure B2B SaaS product discovery?
Measure learning quality and outcomes: validated assumptions, decision confidence, adoption, task success, retention or customer value tied to the original bet.
