How to write pain points that make outbound work

Ask a sales team what problems their product solves and you tend to get one of two answers. Either a list of features with the word problem in front of them, or something so broad it would fit any company in any industry. Both feel like an answer. Neither is much use to whoever has to write the email.

That matters more than it used to, because pain points are not filed away and forgotten. Paraden reads them twice: once when it works out who is worth approaching, and again when it writes to each individual person. Whatever you put in that box is doing real work on your behalf, hundreds of times over.

A pain point written in ten seconds gets read by every prospect you contact.

What a pain point actually is

In Paraden a pain point is four short answers rather than one sentence. You name it, then answer three questions about it.

Name itA short label you would know at a glance in a list. Manual shift handover. Renewals slipping through the cracks. Something you could say out loud in a sales meeting.
The challenge they faceWhat is going wrong in the prospect's world, written from their side of the table and in the words they would use. Not what your product fixes. What is broken.
Why it matters to themThe consequence. What it costs, who it embarrasses, what it holds up. This is the field most people rush, and it is the one that decides whether an email lands.
How your product helpsThe specific thing you do about this one problem. Not your whole value proposition, just the part that answers what you have described above.

The four fields are not a form to get through. They are the argument of a good email, already in order: here is what is happening to you, here is why it hurts, here is what we do about it.

Why vague pain points produce vague emails

Every prospect is researched on their own before anything is written, looking for what that person and their company have actually said and done. Your pain points are the filter applied to all of it. They decide which findings count as relevant and which are ignored.

Say your pain point is inefficiency in operations. Almost anything qualifies as relevant, so nothing stands out, and what comes back is true and forgettable. Now say it is finance teams closing the month late because expense claims arrive as email attachments. The research has something to aim at, and a story about that company acquiring a smaller competitor suddenly means something specific.

Too broad

Companies struggle with inefficient processes and want to save time and money.

Specific enough

Practice managers rebuild the same client report by hand every month, because the time recording system and the billing system were bought years apart and never connected.

The second one is longer, and length is not what makes it better. What makes it better is that a stranger could read it back to you and you would know exactly which of your customers it describes.

The test to apply

Before you save a pain point, read it as though you were the prospect. Two questions decide whether it is ready.

Would they recognise themselves in it, or would they think everyone has that?
Could a competitor of yours have written exactly the same thing? If so, you have described a category rather than a problem.

A worked example

Here is one written properly. Cartwell is invented, and so is everything in the table. Use your own real figures rather than borrowing anyone else's.

Worked example, invented companyCartwell sells scheduling software to logistics operators

Name: Shift handover is done on paper
The challenge they face: Shift supervisors write handover notes by hand at the end of a shift, and the incoming supervisor reads them at the start of the next one. Anything urgent gets a phone call. Anything less than urgent gets lost.
Why it matters to them: The first hour of every shift goes on working out what happened during the last one. When something is missed it usually surfaces as a late delivery, and the depot manager hears about it from the customer rather than from their own team.
How your product helps: Handover notes are logged against the job rather than the shift, so the incoming team sees open items on the jobs they are actually running, and the depot manager sees the ones nobody has picked up.

Put a number on it where you can

The strongest pain points carry a figure a prospect could hold against their own operation. It does not need to be an industry benchmark, and you should not borrow one. Your own customers are the source: what was this costing them before you arrived, and what does it cost them now.

If you do not have a number yet, leave it out and move on. An honest pain point without a figure beats a confident one with an invented figure, and a number a prospect can disprove in a single reply will cost you the conversation.

How many to write

Three or four good ones beat ten thin ones. They should describe genuinely different problems rather than one problem from three angles, because a prospect who matches all three is really only matching one.

If two of yours share the same answer to why it matters, they are one pain point with two symptoms. Merge them, and spend the time you save on the one you have not written yet.

Before you save

The challenge is written from the prospect's side, in their words.
Why it matters names a consequence, not a feeling.
A competitor could not have written the same thing.
Any figure in it is yours, and you could show where it came from.
Each pain point describes a different problem, not the same one twice.

Where this lands in Paraden

Pain points are step four of adding a product, alongside your value proposition, what makes you different, and your proof. You can edit them afterwards at any point, and the next campaign picks up the change.

It is the part of setup worth slowing down for. The targeting, the research and every email that follows are built on what you write there.