Loading insights
Loading insight article
Insights / Production Engineering
Understand buyer needs, alternatives, purchasing barriers and adoption before deciding how to build, price and sell your SaaS product.
A founder has a working product, a launch date and a list of marketing channels. In a customer conversation, a basic question remains unresolved: whose budget would pay for it?
The person who likes the demonstration may never control that budget. The team with the budget may already have an acceptable workaround. Another team may want the product but be unable to connect it to the systems its work depends on.
A SaaS go-to-market strategy defines who will buy, what makes the product worth changing for, how the customer will reach a purchase decision and how they will get value afterward. Those answers should shape the first release, the price and the sales approach together.
The useful test is whether the plan explains a specific customer's next decision. A list of channels cannot explain why someone would make room in their budget.
Start with a recent instance of the problem. Ask someone to walk through what triggered the work, who became involved, which tools they used, and what happened when the process became difficult.
Listen for concrete consequences. An inconvenient step, a recurring backlog and a missed contractual commitment may all produce complaints, but they create different reasons to buy.
Useful questions include:
Customer discovery has an established role in assessing commercial potential; NSF's I-Corps program uses it to help research teams investigate the market for their inventions. For a SaaS founder, the practical lesson is to test assumptions through conversations and observed behavior. NSF's explanation of I-Corps
Market size matters, but an industry total does not reveal how many customers you can reach or serve. Examine the conditions around the work: budget ownership, changes in staffing, procurement rules, existing software contracts, integration access and customers' willingness to change a familiar process.
A useful first segment shares a problem, a reason to act and a plausible buying path. “Law firms” is a starting category. A more testable hypothesis might concern firms with a particular intake process, a named operational owner and a repeated handoff problem.
Keep that hypothesis provisional. Discovery may reveal that the problem is frequent but inexpensive, that the buyer is different from the expected user, or that a neighboring segment has a clearer route to purchase.
Write down the evidence for each candidate segment. Use these questions to compare them:
Scroll horizontally to view all columns.
| Question | Evidence worth seeking | Reason to reconsider the segment |
|---|---|---|
| Is the problem recurring? | Recent examples and the current workaround | Interest appears only during the demonstration |
| Is there a reason to act? | A funded initiative, capacity constraint or dated business need | Everyone agrees it would be useful someday |
| Can the buyer be reached? | Introductions or a channel producing relevant conversations | A large market estimate with no practical access |
| Can the customer adopt? | An owner, usable data and a feasible approval route | Essential permissions or integrations are unavailable |
| Can delivery repeat? | Similar work across independent customers | Every sale requires a substantially different product |
A bottom-up market estimate can then start with the number of organizations that meet the definition and a plausible annual contract value. Treat the price as an assumption until buyers test it. Reachable demand is smaller again: it depends on access, sales capacity, procurement and the number of customers the team can onboard. Label those assumptions instead of presenting the total as a revenue forecast.
Your competitive analysis should include the spreadsheet, the assistant who coordinates the work, an existing system's unused feature and the decision to leave things as they are.
Those alternatives have advantages. They may be familiar, already paid for and accepted by the team. Understanding why they remain in place gives you a more useful positioning argument than a list of features competitors lack.
Ask what would justify the effort of switching. The answer may involve reliability, coordination, visibility or a new operating requirement. Treat each answer as something to verify.
For B2B software, identify the person doing the task, the person accountable for the result, the budget holder and the reviewers responsible for technology, security or procurement. One person may hold several roles; in another customer, each may sit in a different team.
Each role needs different evidence. A user may need to complete a real task. A budget holder may need a credible cost comparison. An IT reviewer may need a clear account of access, integration and support responsibilities.
Use this map to shape the product and evaluation materials. If connecting customer data requires an approved integration, a frictionless signup page will only take the customer to the next barrier.
For sensitive-data products, compliance readiness from day one belongs in this buying map. Ask which evidence a customer needs for a pilot, a purchase and broader deployment; those may be three different decisions.
Consider a hypothetical SaaS product that prepares client-status updates for legal teams. Discovery might find that users value faster drafting, while the operational buyer cares most about identifying matters that have no confirmed update.
That difference changes the first release. Alongside a draft, the product may need source dates, missing-information flags, assigned reviewers and a queue of unfinished updates. Those capabilities help the buyer evaluate the actual problem.
This example is a product hypothesis, not evidence that the market wants a particular solution. Its purpose is to show how research can change scope before the team commits to a larger build.
Turn the hypothesis into a positioning sentence: “For [specific team] dealing with [recurring problem], this product helps complete [valuable task], with [credible reason to choose it].” Replace vague benefits with work the customer recognizes. Test whether the customer repeats the value in their own words and will take a concrete next step, such as introducing the decision-maker or agreeing to a scoped evaluation.
An in-house buyer may have a different need from a law firm even when both review contracts. The in-house legal operations article follows requests across business departments and shows why that distinction changes a product's workflow.
Pricing should reflect how value is received and how costs arise. Seats may fit a product used regularly by named people. Workspaces, matters or usage may fit other patterns. Test whether customers understand the unit, can predict the bill and have a budget that matches it.
Include onboarding, support, integrations, infrastructure and any AI processing in the delivery model. A price that looks attractive in a demonstration may be difficult to sustain when each customer needs extensive manual help.
Then choose a route to the customer that fits the buying process. Self-service needs a credible path to value without extensive intervention. A sale involving several reviewers needs a way to answer their questions. A partner route needs clarity about who sells, delivers and supports the product.
Begin with a reachable segment and a small number of channels. Learn which message leads to serious evaluation before expanding spend.
Make the route to market an explicit hypothesis:
Scroll horizontally to view all columns.
| Route | Condition to test | First useful experiment |
|---|---|---|
| Product-led | A user can reach meaningful value with permitted data and limited assistance | Observe a new user completing the core task without a guided demo |
| Sales-led | Purchase requires several people to agree on value, risk or implementation | Run an evaluation involving both the user and the decision-makers |
| Partner-led | A trusted adviser or platform partner already reaches the buyer | Agree a small joint opportunity with clear delivery and support ownership |
These routes can coexist. A self-service evaluation may lead to a negotiated company purchase. What matters is whether the handoff works.
Stripe's guide to SaaS pricing and packaging describes trade-offs among seat, tiered, usage and hybrid models. Use those categories to frame customer discussions, then test the economics of the actual workflow. For an AI product, record processing and support costs per completed customer task, including failed attempts and retries. A low cost per model call says little about the cost of delivering a usable result.
An evaluation should have an owner, an agreed workflow, an appropriate baseline and a date for deciding what happens next.
Measure successful work after review, including corrections and manual intervention. For an AI feature, generating an answer is only one event; the important question is whether an authorized user can use that answer to complete the intended task.
Track the path from qualified conversation to evaluation, from evaluation to paid use, and from first value to repeated use. Early measurements will be incomplete. Record their definitions and limitations rather than treating a few enthusiastic demonstrations as a repeatable business.
For example, define activation as a customer completing the agreed task with their own permitted information. Define repeat use over a period that matches how often that task occurs. Calculate evaluation conversion using evaluations that have actually reached a decision; include losses and record why they happened. Keep unresolved evaluations visible rather than quietly excluding them from reporting.
If people enter the product but never complete the task, investigate onboarding and value. If they complete it but will not pay, revisit the buyer, budget and alternatives. If they pay and then leave, investigate ongoing usefulness, reliability and the cost of operating the workflow. Each pattern suggests a different next experiment.
The output of this work can fit in a short decision document: target segment, recurring problem, alternatives, buyer roles, promise, first useful workflow, price hypothesis, distribution route and evidence needed to continue.
Revisit it as customers use the product. A stronger understanding of the market should change decisions. It should help the team choose a smaller, more useful scope and explain clearly why a particular customer would make room for it.
Once the problem and buying path are clear, AI product development covers the engineering work of turning that scope into software.
Tell me about the system or workflow you are working on.
30-minute intro call on Calendly
