Message validation as part of the product development playbook

How a new product feature is marketed & positioned, is crucial for the success of its initial launch as well as the ultimate feature adoption.

In many organisations, the marketing/communication activities often only start once the product feature is build and tested and often only goes through an internal review and refinement process.

In my opinion this is too late and in itself a very risky approach. Modern software teams pride themselves on building features/products very close to the user and iterate based on feedback. The same should happen for the marketing messaging itself that accompanies the feature launch.

Let’s call this process: Message validation

What can be done to effectively include message validation within product development playbook?

As a first rule of thumb: The creation of the messaging and the marketing assets should start already a lot earlier, namely in parallel to the feature development process.

Once the process is initiated, the marketing team should go through a set of steps/exercises to refine the messaging. This will ensure that there are no unwanted surprises during launch day and the feature is set up for maximum impact.

1. Decide on the audience & core message(s)

Similar to the product team that thinks about the user archetypes and the fundamental jobs to be done of the feature, Marketing needs to think about the personas that they are addressing, as well as to how the job to be done is communicated in a language that the user understands.

Helpful questions to refine the persona(s):

  • Who is my target audience?
  • Do they speak different languages?
  • Do they work in different functions and thereby derive different value from the feature?

Who is usually responsible for creating the core messaging?

Usually it is a mix of the two functions and depends on the org. structure. The product manager or product marketing manager should create a draft of the USPs and use cases that the new feature is fulfilling (As they likely needed to write this up anyway to justify the creation of the feature). If the company works with a job to be done methodology, usually the content already exists.

If not, in a Q&A session, jointly derive:

  • What problem/job to be done that the the feature solving?
  • In 5 sentences: How is the user using the new feature in the day to day activities?

2. Decide on the communication channels

Note: I am writing very much from a B2B software business perspective, so this list is not exhaustive:

  • In-App communication
  • Email
  • Press release
  • Launch page or company blog
  • FAQ page
  • Sales team
    • Yes, the sales team also communicated about the new feature with customers and can be an effective channel to bring the message across
  • Hard coded infrastructure messaging (like info boxes for the feature)
    • this is often forgotten or not fully utilised

3. Create the marketing assets

With the core messaging at hand, the marketing team can refine the content for the different mediums. I keep this light as that is theme for another post.

Of course there is an internal QA phase until marketing and product approve the messaging.

4. Message validation

This phase is often skipped, but crucial, as you decrease the risk of the feature being wrongly perceived when launching to the whole user base.

When is a good time to carry out this phase?

One approach could be to test the messaging, while the feature is being tested with real users during the beta phase.

How can I validate the messaging?

User interviews

Send/Show the user the messaging and test the perception. Usually, one really wants to understand: Is the problem-solution well explained / does the user understand the use case?

Use case: This method is rather explorative. Has a los sample size and is rather to minimize the downside that the messaging is completely off.

Full simulated launch to a small group of users

Again, if the product team is already testing the feature functionality and the feature is reasonably stable, team up and test in a real life scenario. Make the feature available to a selected group of users and send them the real messaging via the desired channel(s).

Use case: This works really well for refining the messaging, get a first feel for opening rates etc. Based on your product & audience, you could even get to numbers where you can A/B test different messaging.

Repeat this process until you are happy with the messaging.

5. Launch with a validated messaging

If all goes well, come launch day, you have properly tested the messaging and there are no surprises when you are sending/activating the communication via the different channels.

As a last exercise differentiate between:

External launch:

  • Launching the feature to the desired user group.

Internal launch:

  • Brief sales/customer support and other stakeholders about the feature so that they can use it in their workflow/can advertise it and know how to answer questions from customers.
  • Ideally happens a couple of days before the full launch 😉