Feature pages

What a feature page is

A feature page explains one capability of one product in full: what it does, how it works, what it will not do, who it is for, and what it takes to set up. It is written for a narrow, valuable reader — somebody who typed the name of that capability, knows they need it, and is checking whether your version is the one.

Four page types on this site sit close together. A service page covers one thing you sell as work. A product page covers one product whole. A solution page is built around a problem and usually spans several of your services. A feature page is the narrowest of the four: one capability, one page, for a reader who already knows the vocabulary.

It is not a help article. A knowledge base article is written for someone who has already paid and wants to make the thing work. A feature page is written for someone deciding whether to pay at all, and the two need different material even when they describe the same screen.

Who this is for

Software companies, equipment makers and anyone whose product has a handful of capabilities that buyers name individually. The signal is that people arrive asking for a part rather than the whole: not “scheduling software” but “offline mode”, not “a mixer” but “a variable-speed drive”.

The second signal is a features page that is really a list. Twenty capabilities, an icon each, one sentence each, and a reader who wanted to know about one of them leaves no better informed than they arrived.

You do not need this if your product has five features and one audience. Those belong on the product page, done properly, and splitting them into five thin pages makes the site worse rather than better. You do not need it either if nobody searches for the capability by name; write only the pages somebody is actually looking for, and let the rest stay on the product page.

What goes in it

A feature page is judged by whether a knowledgeable reader can decide from it alone. That means covering the awkward parts, not only the good ones.

• What it does, in the reader’s words. The capability named the way buyers name it, then one sentence on the outcome it produces. The internal product name goes second, if at all.
• How it works. Enough mechanism that a technical reader believes you, including what happens in the awkward cases: no signal, bad data, a user who does it in the wrong order.
• The limits. What it will not do, what it needs in place first, which plan or model it is on, and where a bigger tool would genuinely be the better answer. This section is why the page is believed.
• Who uses it and for what. One or two real situations, at the size of business that actually uses it, rather than a generic promise of efficiency.
• How to get it working. Setup time, what you need from them, whether it is included or extra, and the next step.

Each page ends by pointing back at the product page, so a reader who came in through a side door still sees the whole thing before they decide.

What you get

The pages. Each feature page as a separate document of 600 to 900 words, with headings, body, image and screenshot notes, button labels, title tag and meta description. Four to ten pages is a usual set.

The feature list, with the pages that did not get written. A short document saying which capabilities earned a page, which stay on the product page, and why. Owners tend to want a page for everything, and this is the argument against it, written down.

A linking plan. How the feature pages connect to the product page, to each other, and to the help material, so the set does not become a pile of loose pages.

A walkthrough call. Forty-five minutes with whoever demonstrates the product, so the page and the demonstration describe the same thing.

A worked example

An illustration, not a client. A small Saskatoon company sells scheduling software to plumbing and heating firms. Its features page lists eighteen capabilities with an icon each. Sales calls keep opening with the same question, asked by people who have already been told by a competitor that it cannot be done: does it work on a phone with no signal, in a basement, and what happens to the job sheet afterwards.

One feature page is written on offline working. It says what is stored on the device, which parts of the app keep working and which do not, what happens when two engineers edit the same job while both are offline, and how long the reconnection takes on a bad connection. It states plainly that photographs upload only on a real connection and that a firm running fifty vans a day should talk to them first. It names the plan the capability sits on. Three more pages follow on the same pattern for text reminders, payroll export and parts stock. The other fourteen capabilities stay on the product page as a list, because nobody has ever phoned about them.

How it runs

1. A half-hour call. The product, the capabilities buyers name, and the questions that come up in demonstrations. No charge.
2. A fixed price in writing. The number of pages, the price and the dates, agreed before anything starts.
3. Access to the product. A demonstration account, a recorded walkthrough, or an hour with the person who built it. I would rather use the thing than read about it.
4. The page list. Which capabilities get a page and which do not, agreed with you before drafting.
5. Drafts and delivery. Pages in batches of two or three, one round of changes each, then the full set with the linking plan and the walkthrough call.

Three to five weeks for a set of four to ten pages is typical.

What it costs

Feature pages are quoted as a fixed price in CAD after the half-hour call. The size depends on how technical the capability is, how much of it I can see working rather than take on trust, and how many of your people have to be interviewed to get the limits right. Pages are priced per page with the list included. The number is fixed in writing before anything starts. The pricing page shows the four ways of working and how quotes are built.

What happens next

Feature pages attract readers who are comparing. The usual follow-ons are a page that sets you against a named alternative, written fairly enough to be believed, and the short questions answered before the sale for the parts that do not deserve a page each. If the product itself is still described as a datasheet, the product page is the better next job. All of those are separate decisions. The feature pages are complete work on their own and nothing further is assumed.