Skip to main content

What are you looking for?

Explore our services and discover how we can help you achieve your goals

SaaS product discovery questions: what to answer, and what evidence to bring

SaaS product discovery is the short, paid phase in which a founder and a delivery team answer the questions that decide the build: who the first customers are, how tenants are separated, what roles and plans exist, which integrations are essential and how releases reach customers. Each answer needs evidence, not opinion, or it becomes a change request later.

Submit a project See the SaaS workflow

Reviewed by David Nguyen (CEO) · Updated 28 Sep 2026 · 9 min read

star

OutsourcingVN is operated by Netbase JSC, which runs discovery phases like this before most builds and would sell you one. The questions below are the ones that move scope and risk the most, grouped so a buyer can prepare them in advance.

Contents

Why do SaaS products need a different discovery?

A single-customer application answers to one organisation. A SaaS product answers to many at once, and every decision is multiplied: one data model serves every tenant, one release reaches all of them, and one permission mistake exposes somebody else's records. Discovery for SaaS therefore spends less time on screens and more on tenancy, plan states and operating responsibility. The answers set the boundaries that the SaaS product development workflow then builds inside.

Which questions should discovery answer?

Area Question to answer Evidence to bring What changes if it is wrong
Customers Which three organisations will use the first release, and what job does each hire it for? Interview notes, a signed pilot or letters of intent The feature set targets nobody in particular
Tenancy Is data pooled, siloed or mixed, and which tenant needs separation first? Customer security questionnaires, contract clauses Isolation is retrofitted under a live data set
Roles Which roles exist inside a tenant, and what may your support staff see? A role-by-action matrix drafted with a pilot customer Permissions are rebuilt after the first enterprise deal
Configuration What varies between customers, and which variations are configuration rather than code? The top ten requests from early prospects Special cases become forks
Plans Which plan states exist, and what may a tenant do in each? A draft plan table with trial, active, past due and cancelled Billing and access disagree
Integrations Which external systems must connect at launch, and who maintains each connection? API documentation and sandbox access Launch slips on a dependency nobody owned
Data in How does a new tenant bring existing data in? Sample exports from the tools customers use today Onboarding needs a person for every customer
Releases How often will you release, and can a change be held back for one tenant? A release calendar and a rollback rule Every release is an all-or-nothing risk
Operations Who monitors, patches and supports the platform after launch, and in which hours? An on-call plan, support channels, response targets The build team becomes the support desk by accident
Exit How does a tenant export and delete its data? Your privacy commitments and customer contract Offboarding becomes a legal problem

A shorter brief is still useful: the software project brief template covers what to send before discovery starts, and this table covers what discovery must finish.

How do you run a discovery phase?

  1. Name the decision

    Discovery ends in a go, a changed scope or a stop. Write down which, and who decides.

  2. Collect the evidence first

    Customer interviews, sample data, integration documentation and competitor products the pilot customers already use.

  3. Draft the tenant model

    Decide pooled, siloed or mixed storage per module, and name the tenant most likely to demand separation.

  4. Write the role matrix

    Every role against every sensitive action, including your own support staff.

  5. Fix the plan states

    List the states and what each allows; leave commercial numbers out of the software design.

  6. Cut the first release

    Choose the smallest release that a real tenant would pay for, and list what is deliberately excluded using scope boundaries.

  7. Write acceptance

    Each first-release capability gets a testable acceptance criterion.

  8. Estimate and decide

    Scope, milestones and risks go to the decision-maker named in step one.

Netbase's delivery lifecycle: discovery and strategic alignment; team assembly and architecture planning; agile execution with outcome-based milestones; modular components; training and rollout; ongoing support. Discovery is the first of those stages, and its output is the scope the build contract is written against.

Worked scenario: a scheduling product for clinics and salons

A founder plans a booking product for small clinics and beauty salons. She arrives with forty screens designed and asks for a timeline. Discovery replaces the screens with questions.

Three pilot customers are named: two salons and one physiotherapy clinic. Interviews show the clinic needs patient notes that salon staff must never see, which turns tenancy from a detail into the first design decision, and makes a role matrix with a separate clinician role mandatory. The salons both ask for their own booking page colours and a deposit rule; both are configuration, not code. The clinic's existing records sit in a spreadsheet export, so data import becomes a first-release module rather than a later nice-to-have.

The plan table ends with four states and no commercial figures. The first release drops the loyalty scheme and the marketplace listing the founder wanted, because none of the three pilots asked for them. Acceptance is written for booking, reminders, deposits, roles and import. The founder leaves with a smaller first release, a named reason for each exclusion and a build scope she can hold a supplier to.

What does the cloud ERP record show about these questions?

The multi-tenant cloud ERP SaaS record is where Netbase's evidence for this guide comes from. Since 2020, Netbase has worked as offshore development and managing partner on that platform for a US client, and phase one, from 2020 to 2023, served agency SMEs with CRM, real-time messaging, HR, a knowledge base, custom fields and workflows, work and project management, and API integrations. Custom fields and workflows are the configuration answer to the "what varies between customers" question; API integrations are the answer to the integration row.

The recorded stack includes React and Next.js, Laravel and Strapi, PostgreSQL, MySQL, MariaDB and MongoDB on AWS, which shows why the operations row matters: every data engine is something to back up and patch for every tenant.

Which vendor questions test a discovery offer?

  • What decision does your discovery end in, and who signs it off?
  • Which of our customers will you speak to, and how many?
  • How will you decide between pooled and separated tenant data?
  • Will the output include a role matrix, plan states and acceptance criteria, or only an estimate?
  • What will you exclude from the first release, and will you write the exclusions down?
  • Who will be on the discovery team? Netbase project teams draw on business analysis, project management, solution architecture, development, QA and UI/UX roles.
  • How is the build contract agreed afterwards? Most Netbase projects are agreed as fixed-scope contracts after discovery; milestone-based arrangements are also available.

What goes wrong in SaaS discovery?

  • Screens before questions. A polished prototype makes every feature look agreed.
  • No real customer in the room. Discovery answers the founder's assumptions instead of a tenant's needs.
  • Tenancy deferred. "We will add it later" is the most expensive sentence in SaaS planning.
  • Commercial plans mixed into the design. Plan states belong in the software; the figures belong in a spreadsheet that can change weekly.
  • No exit. Nobody asks how a tenant leaves until the first one does.
  • Discovery that never ends. Without a named decision, it becomes unpaid design work.

Where AI fits in discovery

AI can summarise interview transcripts, cluster feature requests and draft a first role matrix for a person to correct. It should not decide the tenant model or the first release. Netbase works with commercial and open-source AI models chosen per project (model-agnostic); no vendor partnership is implied.

How this guide is sourced and where it stops

The question set is editorial guidance drawn from how Netbase scopes projects and from the tenant isolation vocabulary of the AWS Well-Architected SaaS Lens. The only delivery record behind it is the cloud ERP phase one described above: the client and product are not named, no usage, tenant or revenue figure is published, and the retail phase two was planned work when the profile was written and is not presented as delivered. The scheduling scenario is illustrative, not a client. How records are labelled is explained on the methodology page.

Plan the next step for your project

Common questions

Long enough to answer the table above with evidence, and no longer. For a focused first release with pilot customers available, that is usually a few weeks; waiting for customer interviews is the usual cause of delay.

Designs answer what screens look like, not how tenants, roles and plans behave. Keep the designs and run a shorter discovery on the questions they do not answer.

Ask that before discovery for a new build. The custom build versus SaaS guide compares the two routes.

You should. Ask for the role matrix, tenant model, plan states and acceptance criteria as documents you can take to any supplier.

Then it has done its job at the lowest cost. A stop decision with reasons is a valid result.

Bring your discovery questions

Send the three customers you would onboard first and the questions above that you cannot yet answer. A discovery milestone in Custom Product Engineering turns them into a scope, and the project delivery page describes how the build is governed afterwards.

OutsourcingVN is Netbase's own outsourcing-services platform. Submit a project with your pilot customers named, and a person will reply with what discovery would cover.

Custom product engineering for a bounded release outcome Custom product engineering for a bounded release outcome

One defined release of your product, built to named outcomes and handed over with acceptance evidence.

Learn More
line

Tell us what you want to build or automate.

Submit a project