How to write an about page for a product: six blocks, one evidence table

How to write an about page for a product: answer the four questions a stranger asks — who this is for, what it does, why you can be believed, and what to do next — in six blocks, and put every claim in an evidence table before you write a sentence. The page is not a founding story. It is the shortest proof that the product is real.

Why an about page is a product page, not a biography

A reader who lands on your about page is deciding whether to spend ten more minutes on you. They are not there for your timeline. They want to know whether the product was built for someone like them, and whether the claims around it survive a second look. A biography answers a question the reader did not ask.

The same page is also a source that answer engines quote when someone asks what your product is. That makes consistency matter: the company name, the category, the audience, and the thing the product refuses to do should match the product profile and the homepage. An about page that tells a different story from the rest of the site gives both readers and machines two versions of you.

A founder story explains why you started. An about page explains why the reader should stay.

Before you start: write the one-sentence positioning first

You need one sentence that names the audience, the job, and the difference before the page can be outlined. If that sentence does not exist yet, write it first with the four checks in the product positioning statement. The about page expands that sentence into evidence; it cannot replace it.

You also need a short list of claims you can actually support: a dated customer result, a public number from your own product, a named integration, or a real limitation you publish on purpose. Collect those before drafting. Writing first and hunting for proof afterwards is how pages end up with "trusted by thousands".

How to write an about page in six blocks

Six blocks, in this order, answer the reader's questions before their attention runs out. Each block has one job, and each one fails in a predictable way. Write the evidence column first; the sentences are easier once the proof is on the page.

1. Write the identity line last. Draft the other five blocks, then compress what the page actually proves into one sentence. The line is a conclusion, not an opening move.
2. Name the reader, then name the exclusion. "For solo founders shipping a paid product" is stronger with "not for agencies managing twenty clients". The exclusion is what makes the first half believable.
3. Use one scene from the reader's week. A specific Tuesday beats a market description. Keep it short enough that it does not become a second homepage.
4. Describe the workflow, not the feature list. Three steps with a visible input and output are easier to trust than ten capability badges.
5. Attach proof to the claim it supports. A customer quote belongs next to the result it describes, not in a carousel at the bottom.
6. Close with one action. If the reader can start free, say so. If the product is not open yet, say that and offer the waitlist instead of inventing urgency.

The deliverable: an evidence table and a copyable skeleton

Fill the evidence table before you write the page. Every row is a claim you intend to make, the proof behind it, and where that proof lives. A claim with no row does not go on the page. This is the part that keeps the page honest six months later, when the person who wrote it has moved on.

The skeleton below is deliberately plain. Replace the bracketed parts, delete any block you cannot support, and keep the order. A short page with five honest blocks is better than a long one with six and a gap where the evidence should be.

<h1>[Product] helps [specific audience] [do a specific job]</h1>
<p>[One sentence: the task, and what changes after it.]</p>

<h2>Who it is for</h2>
<p>[Audience.] [Exclusion: who should not buy this.]</p>

<h2>The problem we kept seeing</h2>
<p>[One concrete scene from the reader's week, in their words.]</p>

<h2>How it works</h2>
<ol>
  <li>[Input] → [step] → [output]</li>
  <li>[Input] → [step] → [output]</li>
  <li>[Input] → [step] → [output]</li>
</ol>
<p>[What it does not do, in one sentence.]</p>

<h2>Evidence</h2>
<p>[Dated result or quote, with permission and a link to the case study.]</p>

<h2>Start here</h2>
<p>[One action, one link, and what happens next.]</p>

How to audit the claims before publishing

Read the page as a stranger who does not know the product name, then read it as a competitor looking for a sentence to mock. The first pass finds missing context; the second finds unsupported adjectives. Both passes take less time than rewriting the page after launch.

• Every number has a date and a source, even if the source is "our own dashboard, 2026-10".
• Every customer quote has permission and a named person or a stated reason for anonymity.
• Every "we do not do X" matches what the product actually refuses today.
• "Trusted by thousands" with no number, no date, and no way to check it.
• A founding story that takes three paragraphs to reach the product.
• A promise the checkout, onboarding, or support flow cannot keep.

Google's people-first content guidance, read on 2026-10-21 at developers.google.com/search/docs/fundamentals/creating-helpful-content, asks whether a page demonstrates first-hand knowledge and leaves the reader feeling they have learned enough to act. That is a better brief for an about page than "tell our story".

What this page cannot do

An about page cannot fix a product that is hard to understand, and it cannot manufacture trust that the rest of the site contradicts. If the pricing page, the onboarding flow, and the about page describe different products, the reader will believe the least flattering version.

We also have not measured how much an about page lifts conversion, and we cannot separate that effect from price, traffic source, or the product itself. Anyone quoting a precise percentage for "about page conversion" is guessing. The defensible claim is smaller: a page that answers the four questions removes one reason to leave.

Common questions

What should an about page say?

It should say who the product is for, what job it does, how it works, what proof exists, and what the reader should do next. The founder's motivation can appear, but only after those five things are clear.

How long should an about page be?

Long enough to carry the evidence, and no longer. A small product with one customer result often needs 300 to 500 words. A product with a regulated category or a complex workflow needs more. We have not found a length that reliably performs better, so treat the evidence as the constraint rather than a word count.

Should the about page be about me or the product?

It should be about the reader's decision, with you as the person accountable for it. Write the product first, then add the part of your story that explains a choice the reader can verify — why you built the workflow this way, or why you refuse a certain category of customer.

Does an about page help with search or AI answers?

It can help a reader and an answer engine confirm what the product is, but it is not a ranking trick. The page earns its place by being consistent with the product profile, the homepage, and the pages it links to. Keep the company name, category, and audience identical across them, and link to the evidence instead of repeating it.

Should I link to case studies from the about page?

Yes, when the case study carries the proof for a claim on the page. Link from the claim, not from a generic "read more" block, and use the result as the anchor text. The guide to writing a customer case study covers the evidence side; the about page only needs the shortest version of it.

If the page is ready to publish, put it in the same product profile you reuse across channels, then check the whole asset set in the content creation workspace before you push it live.