Introduction
Most product pages fail in the same way. They were written from the inside out, listing what the team built rather than what the reader arrived to find out, and every stakeholder who reviewed the draft added the one thing they cared about most. The result is a page that mentions everything and commits to nothing, which is a harder problem to fix than bad prose because the prose is usually fine.
A page that works makes one claim, supports it, and asks for one thing. That sounds obvious and it is genuinely difficult, because deciding on one claim means declining four others in a meeting. The method below is how I get there: understand who is reading and what they already believe, draft long, and then cut until only the claim and its evidence are left.
Research Before the First Sentence
Good copy is mostly listening. Before drafting a page, the useful sources are the ones where people describe the problem in their own words: sales calls, support tickets, onboarding questions, and the reviews competitors have collected. Those are the phrases that belong on the page, because a reader recognizes their own language faster than they parse a category term invented in a positioning workshop.
That listening is also where the keywords come from, and it is why keyword research and audience research are the same task done once. A phrase that shows up in three support tickets and in search results for the same problem is not a keyword to place a fixed number of times, it is the way the reader thinks about the problem, and copy that uses it naturally reads better and ranks better for the same reason. Copy written to hit a keyword density does neither.
The last piece of research is the reader starting position. Someone comparing two tools they already understand needs different copy from someone who has just realized the problem has a name, and one page cannot serve both well. Decide which reader the page is for, write for that person, and give the other one a different page to land on.
Write the headline last. A headline drafted first tends to describe what you hoped the page would say, while one drafted last can describe what the page actually proves.
Cutting a Draft Down to Its Claim
A first draft is for finding out what the page is about, not for publishing. The cut afterwards is where the writing happens, and it usually starts by deleting the opening paragraph, because the warm up sentences that get a writer moving are almost never the sentences a reader needs. The page nearly always improves when it starts at what used to be paragraph two.
After that, the test is specificity. A sentence that would still be true if it appeared on a competitor site is not doing any work, and phrases like industry leading, seamless, and cutting edge are reliable markers of a claim that has not been made yet. Replacing one of them with a number, a named constraint, or a concrete example is usually the single highest value edit on the page. The same applies to structure: a heading should tell a scanning reader what the section says, not label it as Features, because most readers scan the headings and read one section at most.
The last pass is for the ask. A page that has made its claim well and then offers three competing next steps has undone its own work, so pick the one action that matters and make it unambiguous. For a page describing something built, the strongest evidence is usually a link to the work itself rather than another adjective, which is why the Devyst SaaS development pages point at case studies instead of describing capability in the abstract. The interface makes the same argument in a different medium, which is worth reading alongside this: designing AI features that get used.