JEM 9 Marketing Consultancy

Most Common B2B Technology Messaging Problems

Messaging often suffers from these specific problems.

1. Using Internal Speak
   • This problem is so common that if you don’t “see” it in your own messaging, be sure to get additional eyes involved. It also manifest in some of the examples below.
2. Using Acronyms / Abbreviations
   • Watch out for acronyms which create a barrier for prospective customers.
   • Example: getting started with CRM – Customer Relationship Management. Actually much of the functionality in this market sector is for not for managing existing customers. Rather its about working with prospective customers!
   • Example: ATS – Applicant Tracking System are a subsection of HR hiring (or is it recruitment) software? ATS software is often categorised within: company software / HR software / recruitment software / ATS software. Those unfamiliar with ATSs need to navigate 4 layers down. This is a standard term so use it but drop the abbreviation.
   • Example: MES – Manufacturing Execution Systems. In practice this is a very niche term. Yes you can google it (although finding a large enough segment in AdWords may be challenging). But it is not (currently) used in even very large established manufacturing sectors. You won’t find it in the food processing sector nor in industrial machinery manufacturing. So in practice this is an invented term so niche that explanation will always be required. Alternatively, ditch it altogether and choose something more familiar to prospects.
3. Generic Descriptions
   • This is terrible => ‘Best software for data collection’. (Not even your mother knows what it means.)
   • This is much better => “The only wart specifically designed for a dog.” (attributed to Neil Rasmussen, APC Corp). This is a silly example but makes the point beautifully.
4. Architecture Moonlighting as Features
   • User Management – every technology product ever has ‘user management’. Only rarely should this kind of functionality make the feature list. Typically it is better suited to user guides. If your approach provides a particular benefit of key interest, such as visibility for the whole team versus financial confidentiality, that fine. Otherwise remove this from messaging.
   • Nearly every piece of software has a database, export capabilities and some form of presentations of information. Typically these kinds of terms/verbiage should not appear in messaging.
5. Me / Us / We
   • Your messaging is not about you. It’s about the problems you solve for customers. Review, remove and rephase sentences that focus on you.
6. Conceptually Disorganized
   • This often manifests as a random list of ‘stuff we do’. That is not how prospects think. Work to group things conceptually based on your understanding of customer needs. As things evolves, you will need to review your conceptual organization.
   • Cart before the horse. Early messaging needs to address opening / early questions. Does this product potentially address my needs? I don’t yet care about how you will help me migrate or how wonderful your post-sales support is. As customers proceed along the journey you need to answer more focused questions.
7. Product Specification Focused
   • Yes you may need a product spec sheet stating, for example how many users are supported or the number of survey exports in this pricing tier. But a random list of features is difficult to navigate.
   • Spec sheets often serve as a detailed comparison checklist later in the decision process.
8. Mixing Levels of Abstraction 
   • Example – ‘Exotic Blue-Shell Fountain Pen with interchangeable nibs’ versus ‘pencils’.
   • Example – ‘Inventory management’ versus ‘product sustainability QR code’.

Product Positioning – Organizing Your Messaging

Once you’ve thought about the considerations above, it’s time to get practical and start populating the framework with messaging that prospects can easily absorb.  Consider a wide-range of data sources to input into your positioning. Expect a lot of iteration.

This approach is designed to get you started by considering existing product functionality, i.e. from the bottom up.

1. List Features

You might decide to do this by assembling a multidisciplinary team or ‘harvesting’ existing documentation (such as past sales quotes or brochures). For working alone or with in-person group, post-It notes work well. For online / remote group work Miro, or another whiteboard sharing applications, work well. It might be as simple as a shared Google Slide.

Start with whatever is available. Simply list what your solution / approach does. Often you’ll discover that something you thought of as a single feature offers multiple benefits.

2. Group Features (by Benefit)

Look for similarities in the benefit each feature provides. Stay focused on your prospective customer by cycling through each customer persona in turn. By definition different customer persona have different needs. They may also have overlapping needs. Expect a lot of rewriting and moving up and down the ladder of abstraction at this point.

The feature group on the left brings together individual features based on the core ‘job to be done’. The feature group on the right focuses in on the different situations of use calling out the functionality for a desktop user as against a mobile app user.

Feature groups may also be more conceptual. For example: ‘These all help our customers to collect customer feedback data reliably’, may results in a feature group called ‘Collect Data Reliably’ or you have have a bunch of features that enable integration with existing technology=> Easy Integrations

In addition these examples consider

• Following a typical workflow, perhaps diagrammatically.
  • For research software this might look like
    • Identify questions to answer -> Identify sample cohort -> Ask this cohort to answer the questions -> Wait for answers to come in -> Send a reminder -> Validate data received -> Export data to analysis -> Report on data.
• Group functionality on the basis of frequency of use by daily, weekly or monthly activities.

4. Name Each Feature Group

Individual features may become the name for a feature group. Each may include a description. Often there is an image or icon associated with each feature bucket.

Examples might include: Data Analytics for Sales Leader or Foot Protection for Long-distance Runners

• Use customer persona language. Ask yourself would prospects understand from this description?
• Articulate naming unambiguously avoiding the common messaging problem.
• Be grammatically consistent (e.g. Start with an action verb or Capitalise Each Word.)
• Be correct and accurate. Avoid vapourware and overselling. (Consider what you will want to say when you release future versions).
• Completeness is completely a judgement call based on market knowledge.

6. Market Place Check / Product Messaging Considers Competitors & Adjacencies

At this point you might try googling those key terms terms, the name of your feature group. Do you get the search results you’d expect???? If not, go back to step 2.

Apart from Google (and other search engines), another important market segment considerations are your peers and other market players. Within your target market segment, compare your features and feature groups to your aspirational and direct competitors. You don’t have to align with the market place. Innovation comes from difference. But if everyone else organizes around a particular concept think carefully about the pros and cons of going a different route.