A software company can list forty features and still leave a buyer unsure whether the product is for them. The buyer is not short of information. They are short of a connection between what the product does and the work they do every day: the coverage report pasted into a board pack on a Friday evening, the approval chased across six email threads, the press list that lives in three spreadsheets. Until that connection is made, every feature is just another line to read.
This article sets out how we would make a communications software proposition easier to explain and to evaluate. Our founder’s record names a communications software brand among the brands he worked on, but it does not describe a separate project. So we are not reporting a product launch, an implementation total or a sales result. What follows is the approach, developed from the brand strategy, identity, messaging and customer experience work that the record does document.
Three people, three evaluations
Software of this kind is rarely bought by one person. The person who will use it, the person who will pay for it and the person who has to make it work inside the company’s systems are often different people, and each asks a different question. A message written for one of them tends to lose the other two.
Who evaluates, and what each needs
Practitioner
Needs to see how the product fits a working day: which task becomes easier, what changes in their routine, and how long it takes to become useful.
Manager
Needs a business case: what problem the team stops having, how the work becomes more visible, and what the decision costs in money and attention.
Technical stakeholder
Needs specifics a marketing page cannot fully provide: how the product fits existing systems, how data is handled, and where to find documentation.
They also tend to arrive at different moments. The practitioner often finds the product first, through a search or a colleague’s recommendation. The manager arrives later, usually through a link the practitioner forwarded with a line of explanation. The technical reviewer may only appear once a purchase is likely. Each needs to land on something written for them, because nobody will repeat the first visitor’s path to find it.
The messaging system should connect these needs without forcing every reader through the same dense document. A practitioner who wants to understand daily use should not have to wade through procurement detail, and a technical reviewer should be able to find the right material without filling in a demo form first.
Begin with the buyer’s work, not the product’s inventory
We would map the proposition to tasks the intended customer already recognises. A communications team may be trying to organise information, coordinate activity across people and agencies, or assess whether its work is having an effect. Which of those the product genuinely helps with is a question for the product team, and the exact capabilities would need confirming. The marketing principle is stable regardless: explain the task and the product’s verified contribution to it before introducing a long feature list.
That sequence protects a business from broad promises that sound useful but are hard to assess. “Transform how your team communicates” is easy to write and impossible to evaluate. A buyer should be able to connect each message with a need they have and a claim they could check. Finding that connection, through buyer research and conversations with sales and product colleagues, then expressing it plainly, is the work of positioning a complex software proposition.
In practice we would define three things before any page or deck is drafted: the central proposition, the evidence that supports it and the next action a reader should take. The opening should help a visitor decide quickly whether the product is relevant. Supporting material can then go into detail. The action depends on the actual sales model; it might be reading a technical overview, watching a walkthrough or speaking to the team.
The order a message should follow
Each step depends on the one before. A capability with no task attached reads as a feature list. A task with no verified capability is an unsupported promise. Evidence without a next step leaves an interested buyer with nowhere to go.
Feature-to-message rewrite Example
| Element | Feature-led draft | Task-led rewrite | Confirm before publishing |
|---|---|---|---|
| Opening line | “An all-in-one platform with [feature], [feature] and [feature].” | “For [role] who need to [task they recognise] without [the friction they describe].” | The task and friction come from buyer research, not internal assumption. |
| Supporting point | “[Feature] is powerful and flexible.” | “[Verified capability] lets [role] [specific result within that task].” | A product specialist confirms the capability works as described. |
| Evidence | “Trusted by leading teams.” | “[Approved demonstration, documentation or permitted example].” | Permission and accuracy for every example shown. |
| Next step | “Book a demo.” | “[Step matched to the reader: walkthrough, technical overview or conversation].” | The step exists and someone owns the follow-up. |
Identity that organises information
In software, visual identity has a job beyond being recognisable: it should help the company organise information. Layout rules can create consistent places for the proposition, the evidence and the action, so a reader learns where to look on the second page they visit. Typography and image treatment should improve readability. Interface imagery, where it is used, should be approved and informative; a stylised screen that shows nothing real is decoration, and a sceptical buyer knows it.
Terminology belongs to identity too. If the website calls a feature by one name, the sales deck by another and the product interface by a third, the buyer reasonably wonders whether they are looking at three different things. A short list of approved terms, kept with the guidelines and checked against the product itself, removes a surprising amount of confusion at almost no cost.
The record lists identity guidelines and brand compliance among the skills attached to this branding work. Applied here, those capabilities would help teams produce coherent website, presentation and campaign material from the same principles. We are not claiming a particular set of assets was completed for this account.
The advert and the page must tell the same story
A buyer who clicks on a campaign about one problem and lands on a page that opens with a broad company description has to rebuild the connection themselves. Many do not bother. We would review each destination against the question behind the click: does the page answer it in the first screen, and does it offer a next step that suits someone at that point of evaluation? This is where a website built around the evaluation path matters more than any single campaign.
Sales material should continue the same explanation. A presentation can expand on the business problem, describe verified capabilities and give the prospect something they can use to discuss the product internally, because the person who met the salesperson usually has to persuade colleagues who did not. When marketing provides that material, it becomes useful beyond the first contact, and individual salespeople no longer need to invent their own version of the story. The same multi-audience problem appears in programme marketing; our article on explaining a platform to buyers and users looks at it from that side.
A good test of software positioning is not whether people remember the slogan. It is whether a prospect can explain the product to a colleague after one visit.
Internal agreement comes before external clarity
Most confused software messaging is a symptom of an internal disagreement nobody has resolved. Product, sales and marketing each describe the product slightly differently, and the customer hears all three versions. We would bring product and sales colleagues into the message review from the start. Marketing claims need to reflect the product as it exists today, not the roadmap. Sales teams need language that works in real conversations. Product specialists need a way to flag where a simplified explanation has become inaccurate.
The agreed position then needs a home. A concise messaging guide can preserve it while letting individual teams adapt the depth of detail to their own work. The organisation stays consistent without every document sounding identical. Planning communication for several audiences at once is its own discipline, which we discuss in a programme explained to several audiences.
Shared-message guide checklist
- Intended audience. Who each message is for, and which evaluator role it serves.
- Central proposition. One agreed statement of the task the product helps with.
- Approved claims. Each capability claim, who verified it and when it should be reviewed.
- Supporting information. Where the evidence, documentation and permitted examples live.
- Words to avoid. Claims that overstate the product or describe features not yet available.
- Next steps by stage. What a reader should be offered at each point of evaluation.
Testing whether the explanation works
Useful measures depend on the actual sales process. A large number of page views says little about whether anyone understood the proposition; a prospect who can explain it back in their own words says a great deal. Message comprehension can be tested directly, with a handful of target buyers, before the material goes anywhere near a media budget.
A simple method works well. Show a small group of target buyers the opening screen of the page for a short time, take it away, and ask them what the product does and who it is for. Their answers, compared with the proposition the team agreed, show exactly where the explanation is landing and where it is not.
Sales feedback is the most useful of these over time. It shows where prospective customers misread the proposition, and it lets the team fix that particular explanation rather than adding detail everywhere. The material stays focused, and message development stays tied to the questions people really ask when deciding whether the software suits them. That is the contribution we would make: turning verified product knowledge into material that helps a real person decide what to do next.
