Building a SaaS Landing Page That Sells the Job, Not the Tool

The page opens with a headline about being the platform for modern teams, then twelve cards in a grid: dashboards, integrations, automation, permissions, reporting, an API. Every card is true. The product genuinely does all of it. And a visitor who arrived with one specific problem reads the lot, learns nothing about whether their problem is solved, and leaves for a competitor whose page is worse but clearer.

A SaaS landing page has one job, and it is not to describe the software. It is to answer what changes for me, and what do I do next. A feature grid answers neither. It lists capabilities and quietly delegates the hardest work in the funnel, translating a capability into an outcome, to the person least equipped to do it: someone who has known your product for eleven seconds.

What follows is the structure we would use instead. A contract above the fold, proof that does not depend on numbers you do not have, an objection section carrying most of the persuasive load, and exactly one primary action. All of it assumes you already know who the page is for. If you do not, that is a positioning problem, and no amount of copywriting papers over one of those.

Why the feature grid fails

The grid is not a bad component. It is a bad opening argument. It fails for two reasons that are easy to name and awkward to fix, because both of them are organisational rather than visual.

The translation tax

Every feature card asks the reader to perform a conversion: from "the product has role-based permissions" to "I would stop being the person who manually checks who can see the payroll folder". Buyers can do that translation. They will do it for one feature, maybe two, and only once they already believe the page is about them. Twelve cards is twelve requests for unpaid work.

Worse, the translation is guesswork and the guesses are yours to lose. When a reader turns a feature into an outcome, they use their own situation and their own assumptions, and they routinely conclude that a product does less than it does. Nobody writes in to check.

What the grid is actually for

Feature grids usually exist for internal reasons. They are the roadmap made public, or a settlement between three people who each wanted their part of the product represented on the homepage. That is why cutting one feels like demoting a team. The way out is to agree what the page is selling before arguing about what it shows, which is the same distinction our parent company draws between a product, a service and a feature.

A feature list tells a visitor what you built. A landing page has to tell them what is different about their Tuesday.

The above-the-fold contract

Treat the first screen as a contract with four clauses. Not four sections: four clauses, and they can be satisfied in three lines and a button. If one is missing, the visitor has to scroll to learn whether the page concerns them, and scrolling is a favour you have not earned yet.

1. Who this is for. Named specifically enough that some readers exclude themselves. "For finance teams closing the books in spreadsheets" beats "for modern teams" precisely because it turns people away.
2. What job it completes. A verb with an object: reconcile the ledger, brief the freelancer, ship the release notes. Not a category name, and not a description of the interface.
3. What changes as a result. The state the buyer ends up in. This is the clause most pages skip, and the only one the reader is actually shopping for.
4. What to do next. One action, described in the words for what happens when they take it rather than in the words your marketing stack uses internally.

The visual half of the same contract is whatever sits beside those lines. Show the product doing the job, with real content in it rather than a device frame full of grey boxes. That image is usually the largest element to paint, so it decides both what the page says and how quickly it says anything at all. A hero video that plays for four seconds before the headline resolves has spent the entire opening on a transition.

Proof when you have no numbers to show

Early products have a proof problem: no logos worth showing, no case studies, no metrics that would survive a follow-up question. The standard response is to manufacture adjacent credibility, and it is always visible. "Trusted by teams everywhere" reads as "trusted by nobody yet", which is worse than silence, because it also establishes that this page will stretch the truth when convenient.

What counts as proof

Proof is anything a sceptic can verify without taking your word for it. That definition is more generous than it first sounds.

• The artefact itself. A real screenshot of real output, an exported report, a short recording of the job being finished. Showing the thing beats describing it and costs less than either.
• Documentation a stranger can read. Public docs prove the product exists and that somebody thought about its edges. Serious buyers read them before they contact anybody.
• A public changelog. Dated entries are evidence of a team that ships, which is the real question behind "will this still be here next year".
• Stated limits. Naming what the product does not do reads as confidence, and it disqualifies poor fits before they become churn.
• Operational facts. Where data is stored, how it comes out, what happens on cancellation. Boring, checkable, and disproportionately reassuring.
• The pricing itself. A published price is a claim you have committed to. A hidden one requests a conversation the visitor has not agreed to have.

What does not count

Stock photography of people laughing at a laptop. Testimonials with no name and no company. Awards nobody has heard of. Counters that animate upward on scroll. Each was persuasive once, and each now signals that the page ran out of real material. The rule we hold to, on our own site and on client work, is that nothing goes on a page until it is true and checkable. It is slower, and it removes the whole category of claims you later have to defend in a sales call.

Objection handling is most of the page

Once someone accepts that the product might do the job, everything after that is doubt management. Most pages treat this as an FAQ bolted to the bottom. It works far better as the spine of the page, each section answering the objection that arrives at that point in the reading.

The fourth row is the one teams underestimate. A page that sells the job has to show the beginning of the job, because the visitor is silently pricing their own effort while they read. Describing what happens in the first ten minutes after signup does more than another benefit statement, and it has the useful side effect of forcing the product team to look at what those ten minutes currently contain. Often the page cannot honestly describe the first run because the first run is not good, at which point the fix belongs in product design rather than in the copy deck.

Objections are also where the page earns the right to be specific. A limits section that names three situations the product handles badly will be read more carefully than anything else on the page, and it makes every other claim more believable. Buyers are not looking for a product with no weaknesses. They are looking for one whose weaknesses they can live with, and they would rather find them now than in month four.

One primary action

Book a demo, start a trial, join the waitlist, read the docs, watch the video, talk to sales, take the newsletter. Pages accumulate actions the way drawers accumulate cables, and every extra one costs a decision. Pick the single action a well-qualified visitor should take, repeat it, and demote the rest to text links.

Which action depends on price and on how much of the value is visible before purchase. Self-serve products with a published price should send people into the product. Products that need configuration, data migration or procurement should send people to a conversation, because a trial that fails without help produces something worse than no trial: a person who has decided, from evidence, that it does not work.

Secondary routes still matter, they just do not deserve buttons. Documentation, pricing and a security or data page should be reachable from the page in one click, because those are the links a serious evaluator hunts for and cannot find. Put them in plain text, in the place a person would look, and let the single button carry the visual weight. A page with one obvious action and four findable links reads as confident. A page with five buttons reads as undecided.

Make the action operable by everyone. Real button semantics, a visible focus state, adequate target size, and contrast that survives the brand palette, as set out in the WCAG 2.2 quick reference. Then watch what gets bolted on top of the page: a floating chat widget that traps focus or covers the button on a phone is a conversion problem before it is an accessibility problem, and it is comfortably both.

Writing it in the order people read

Readers do not move down a page evenly. They take the first screen, skim headings until one matches their situation, stop there, and read that section properly. So every heading has to work as a standalone sentence, and the section under it has to reward the stop. That is the same discipline behind writing pages for people rather than for a query, and it survives every change in how pages get found.

One practical consequence: the page has to be editable by the people who learn what visitors are confused about, and those people are rarely the engineering team. A page that needs a deployment to change a heading is a page that will not be changed. A structured content workspace such as Acrosite takes one approach to that: it generates the files, commits them and triggers the configured deployment, so editing stays ordinary while the page stays in version control.

Then measure the change honestly. A landing page rewrite is a bundle of a dozen edits, so crediting a movement to any one of them is usually wishful thinking, and a low-traffic page will not settle the argument quickly either. We have written separately about proving that a design change worked, which matters most exactly when the page is new and the traffic is thin.

Where traffic is genuinely too low to test, the useful substitute is qualitative and cheap: five people from the target situation, reading the page aloud, saying what they think the product does and who it is for. Two of them will misread the same line. That line is the work. Most of what passes for conversion optimisation on a small site is this, done regularly, rather than a test that will not reach significance before the quarter ends.

What we would change first

If you have an underperforming page and one afternoon: replace the headline with the job statement, move the strongest piece of real proof directly beneath it, delete every action except one, and cut the feature grid down to the three features that carry the job. Leave everything else alone. Four changes, and they are the four that alter what the page is about rather than how it looks.

The concession, and it is a real one: this advice weakens as a market matures. When buyers already know the category and are comparing three products they can name, the feature comparison is the decision, and burying it under narrative copy irritates the person who came to check one specific capability. In that situation, sell the job above the fold and put the detailed comparison one click away, built for the reader doing diligence. Two readers, two pages, and neither pretending to be the other. The reverse holds when nobody is waiting for your launch: with no category to lean on, the job statement is all you have.

And if the page still will not convert after all of it, stop editing the page. The problem has moved upstream into what the product is for and who it is against, which is positioning work rather than page work. Copy cannot rescue a claim nobody wants. If you would like a second read on which of the two you are holding, send us the page and the sentence you wish it said.