A short guide to product descriptions

Most teams know this matters. Fewer have decided who owns it. Everything we would tell a client about product descriptions in the time it takes to drink a coffee.

Content is the part of a project most likely to be underestimated and most likely to delay a launch. Write the reasoning down alongside the decision, because the reasoning is what changes first.

What is actually at stake

Lead with the benefit, support with the specification. There is a version of this that is over-engineered, and it is worth avoiding. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

The practical version

Manufacturer copy is duplicate content. That sounds obvious written down. It is still the thing most often skipped. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

Common failure modes

Answer the question that stops the purchase. In practice this is a scheduling problem more than a technical one. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

What this looks like day to day

Writing for the web is largely an editing job: the first draft is always longer than it needs to be. Three things worth confirming about product descriptions before you move on:

• Someone can say what the current setup is without going to look
• Answer the question that stops the purchase — and you know whether that is true here
• There is a way to tell whether the last change to this helped

The point is not perfection, it is knowing which of these you have consciously chosen to skip.