COURSE READING AND WORKSHEETS
How to position your SaaS against real alternatives
Positioning helps a suitable customer understand where your product fits and why they would choose it. Start with the job they need to do, the alternatives they actually consider, and the conditions in which your product offers a meaningful advantage. Support the comparison with evidence.
Choose one buying situation
Define the audience, workflow, and trigger you are positioning for. A product can serve several groups, but trying to explain every possible use at once often produces a statement too general to help anyone choose.
Use the audience definition guide to distinguish product requirements from convenient prospecting filters. A supported integration may determine fit. Company size may simply help you find people to interview.
Write the buying situation in plain language: “A team needs to investigate recurring API test failures before deciding whether a release is safe to continue.” This fictional example identifies work and context. It does not claim that every engineering team buys a monitoring product for that reason.
Your first positioning brief is a hypothesis. Make the uncertainty explicit instead of disguising it with a confident category label.
Map what people do today
Include alternatives beyond competing vendors. People may use an internal script, combine existing tools, hire help, run a manual process, postpone the work, or accept the consequences.
Ask which alternatives customers actually considered and why they kept or rejected them. A vendor that appears next to you in search results is not automatically part of the customer's decision. Conversely, a spreadsheet may be a serious alternative even if it does not resemble your product.
Use customer interviews to understand the decision. Public product information can help verify available capabilities, but it does not explain a particular customer's experience by itself.
Record source dates for factual comparisons. Recheck time-sensitive details such as competitor capabilities or pricing before publishing a specific comparison. This guide supplies a method, not current claims about named vendors.
Compare the workflow under consistent conditions
Choose criteria that matter to the buying situation: setup requirements, supported inputs, investigation steps, output quality, collaboration, constraints, ongoing effort, and purchasing requirements. Do not begin with a giant feature grid simply because it is easy to fill.
For each alternative, state what you know, how you know it, and what remains unverified. If you test products, use comparable tasks and record the environment. A demo under ideal conditions and a complex customer deployment are not equivalent evidence.
The comparison should allow an alternative to be a better choice in some situations. An internal script might be sufficient for a stable, narrow workflow. A service might suit a team that wants someone else to perform the work. A product requiring an unsupported integration may be unsuitable despite other strengths.
Useful positioning explains fit. A table designed to make your product win every row tends to hide the conditions the buyer actually needs to assess.
Use the comparison to identify where you should lose
For a fictional investigation product, a practical alternatives map could look like this:
| Situation | Plausible choice | Reason to investigate |
|---|---|---|
| Rare task; existing logs already answer the question | Current manual workflow | Switching may add more work than it removes |
| Stable, narrow process maintained by the team | Internal script | Existing control and low ongoing effort may be sufficient |
| Recurring investigation across supported sources | Proposed product | A shared context view may address repeated collection work |
| Required source is unsupported | Another compatible approach | The current product cannot deliver the needed workflow |
These are hypotheses, not verified comparative results. Ask customers about the relevant conditions and test the product claims. A useful positioning brief explains why one situation fits better than another instead of declaring your product superior everywhere.
These are the guide’s fictional fit hypotheses. A fair comparison permits another choice to fit better and does not declare the product a universal winner.
Find differences that change the result
A difference matters when it affects the customer's job or decision. A feature name alone does not explain that effect. Follow the chain from capability to workflow change to useful result.
In a fictional product, grouping relevant test context in one investigation view could reduce the need to collect it manually. That is a plausible workflow difference. Claiming it halves investigation time would require measurements that support the statement under defined conditions.
Ask whether the customer values the difference enough to change behavior. A capability can be distinctive without being important. Conversely, a familiar capability can matter when its implementation fits the customer's constraints unusually well.
Separate inherent product differences from promises that depend on service or future work. If hands-on setup is part of the current offer, say so. If a capability is planned, do not position it as available.
The chain distinguishes a product behavior from a proposed benefit. Product verification supports the capability; an improvement claim needs evidence appropriate to that result.
Connect each claim to proof and a limit
Create a claim ledger containing the statement, supporting evidence, scope, and any necessary qualifier. Evidence might include a reproducible product demonstration, a documented test, or an approved customer account of a specific result.
Match the strength of the wording to the strength of the evidence. “Collects these records in one view” can be demonstrated directly. “Makes every team more productive” requires a much broader foundation. Avoid upgrading a narrow observation into a universal outcome.
Record what would weaken the claim. If the result depends on a supported environment, setup assistance, or a particular workflow, that condition belongs in the explanation. A useful limit helps buyers assess fit and helps your team avoid making inconsistent promises.
Choose a category that helps people understand
A category gives the customer an initial frame of reference. Use a familiar term when it accurately describes the product and the buying situation. Explain a new category only when the existing terms cause a material misunderstanding.
Test whether the label creates appropriate expectations about the workflow, outputs, and alternatives. If calling a product a monitoring platform makes people expect capabilities it lacks, either clarify the scope or choose a more accurate description.
You do not need a novel category name to have useful positioning. Precise context and a meaningful difference may explain the offer better than an invented term that needs a second paragraph of translation.
Write an internal positioning brief
Include the audience, situation, alternatives, relevant differences, resulting value, proof, requirements, and situations in which another choice is better. This gives product, marketing, and sales a shared basis for decisions.
A fictional brief might state: “For engineering teams investigating recurring API test failures in supported environments, this product brings relevant test context into one investigation view. It is an alternative to manually gathering that context across tools. The current offer includes assisted setup; it does not replace the team's release decision.”
That statement is an illustrative hypothesis. It would need product verification and customer evidence before being used as a real offer. Its purpose is to show how fit, difference, and limits belong together.
The internal brief is not necessarily your homepage headline. Translate it into reader-facing language through the messaging document.
Test understanding and choice
Show a suitable person the explanation and ask what they think the product does, whom it is for, and when they would choose it. Ask which alternatives they would compare and what information they still need.
Do not judge positioning only by whether someone likes the wording. Accurate understanding and relevance matter more. If they misinterpret the scope, revise the explanation. If they understand it but do not value the difference, investigate the audience, product, or offer before polishing the headline again.
Download the alternatives map and positioning brief. Review it when product capabilities, customer evidence, or the competitive situation changes enough to affect a buying decision.
Explore the SaaS growth guides and templates to choose another problem to work on.