How to lead a successful messaging workshop for developer products

Today, we're going to talk about messaging and positioning and the methodology for how you do that.

A lot of developer marketers get asked to drive the creation of messaging and positioning. It may go under a different name if you're in DevRel, but it's essentially the same thing.

This is going to be all about how you run a workshop to get a bunch of people in the room. Messaging and positioning is a group activity, and it definitely requires a little bit of thought to make sure that everyone's time is spent effectively, especially your time as a marketer.

Facilitating messaging workshops that drive clear decisions

What happens a lot with a workshop is you have some big, hairy problem that you need to solve. And somebody says, “Hey, let's get everyone in a room, we'll order some lunch, put some stickies on the wall, and we're going to solve this problem.

That sounds really good, but what happens more often than not is that everyone gets in a room and talks in circles, and it doesn't feel like you're coming to any kind of resolution.

Then the next day, you're looking at all the pictures that somebody took of the stickies on the wall and you're thinking, Huh? Did we even solve this? What is this? What does this even mean?

This is going to be a very tactical piece about workshops. It’s very focused on internal work and working cross-functionally to help you not have this feeling where the stickies didn't really get you any closer.

The three foundations of messaging

There are generally two different paths that people take to becoming a developer marketer. There are people who have a traditional PMM background. They have a marketing background, but maybe they're new to working with a developer audience. And then there's the other direction, which is people who started out as developers or developer adjacent, and then all of a sudden, they're a marketer.

The second one was me. I started out as developer relations, and then I moved into marketing. All of a sudden, I realized that there was this art and science of being a product marketer that I needed to learn.

If you’re in that boat, hopefully, some of these techniques will be helpful to you.

But first, a little bit of a level set. Marketers and product teams use the word messaging a lot. Sometimes when product teams use the word messaging, they're actually saying some really fancy words that marketing is going to make up that fix the problems that we're having with our product.

Messaging is definitely not that. It's not magic.

Messaging is the talking point and how you communicate your product. It's like the icing on the cake. But you can put icing on a really terrible cake. No amount of icing is going to fix it if your cake is broken, so your messaging needs to rest on a firm foundation of three things:

A very clear value prop for your product. You need to understand the benefit that you're bringing to your audience.
An understanding of your audience.
Positioning, which is understanding where your product sits relative to other options that are available to your user in the market.

Once you have an idea of those things, then you can begin to talk about messaging.

The three foundations of messaging: value prop, audience, and positioning

Signs that you should run a messaging workshop

So, what are you trying to do during a workshop? You're not going to solve that big hairy problem. Even if you shut everyone in a room for two days and lock away the key, you're probably not going to solve it.

So, the goal during the workshop itself is to get quality inputs so that you as a marketer have what you need to go off and create a durable and authentic message.

Let's talk a little bit about when you should run a messaging workshop.

The first one is the textbook thing for a marketer; you have a brand new baby product and it's fresh out in the world, and you get to decide from the ground up what that value is and how you're going to talk about it. That's a fun place to be as a marketer, it's like this green field.

Number two is when you have a product that's been in the market for a while, but maybe you're going after a new type of customer. You might be adding a new feature or a new release that substantially changes what that product represents.

Number three is probably the least fun one. You have a product and you have a message, but something about it is troubled. It’s like the check engine light has come on in the car. You're getting signals from your audience that that message isn’t resonating.

Run a messaging workshop when you're launching a new product, going after a new market/category, or your current message doesn't resonate

Case study: Establishing purpose and goals

A lot of people get workshop fatigue. Somebody says that they're going to put a workshop on the calendar, and everyone is like, “I’m so busy. Please don't do this to me.”

Virtual workshops are one thing, but, especially if you're asking people to travel and you're trying to justify that budget spend to get a bunch of people in the room, you need to do the legwork to show that you have a very clear idea of the problem that you're solving, and you have a solid plan in place to fix that problem.

So, the ‘why now’ is the circumstances that make this necessary, and what's happening that shows us that there’s a problem that needs a messaging workshop to resolve it.

The ‘why now’ is the problem statement.

The objectives are the high-level solution that you think is going to solve that problem. It's not necessarily what you’re going to achieve during the workshop itself. That’s actually the deliverables.

The deliverables are the artifacts, the actual things that you’re going to produce during the workshop. And later, in a second phase of work, those things are going to help you get to the objectives.

What does this actually look like on paper?

I thought it’d be helpful to do a little composite case study made up of different things from over the years doing these messaging workshops.

As you're describing the problem statement, maybe we have the current messaging that our audience is resisting. Maybe we released a bunch of new capabilities that totally changed the mental model of this product and we need the messaging to catch up.

Maybe your messaging in the past was slightly misleading and you have customers that are saying that your product does something that it doesn't. That's definitely a messaging problem and something that might require some myth-busting.

So, how are we going to fix those problems? We’re going to construct a product story using a structure that describes what the situation is, and what the big ‘why’ is that this product has to exist. And then we also need to map out a delivery plan to get that product story out to our customers.

We're not necessarily going to do those things in the workshop. Instead, we're going to create some things that will help us get to those.

We're going to create a storyboard, we're going to map out a timeline view that lines up our product milestones at our marketing moments, and those are going to be the raw materials that actually help us solve this thing.

We're going to use some formulas here. Your version is definitely going to look different.

If you're asked to run a messaging workshop and you're Googling how to run a messaging workshop, that's actually not that bad because as a marketer, your biggest skill is being able to define your objectives and then go out and find an existing framework that does 80-90% of what you need it to do, and Frankenstein all those things together into something that helps you.

So, think about your objective, take what helps, and leave the rest.

Who should you include in your workshop?

Now, let’s look at your invite list. I'm a product marketer, so I work extremely closely with our product team. It's really important that you work closely with product on this for two reasons.

Number one, you're going to have a much better end result if you’re getting the brainpower of your product team and everyone in the room to help with this thing, but you're also getting buy-in.

So, your product team needs to be part of the solution. Otherwise, if you just go off on a mountaintop and write out a really nice product narrative, and you come back and say, “Hey, guys, check it out,” it's not going to fly. You need to bring people in on the ground floor.

Number two is DevRel, partnerships, and research. This is an umbrella group of people who are very close to your end user.

As a product marketer, you also own being an expert on the customer. They're not playing the role of coming in and being the only one to speak for developers. But it is important to get a 360-degree view, especially if you have access to research. Not just stories, but actual data that your research team has collected.

I also wanted to mention marketing. Obviously, you're going to be there, but I wanted to underline what your role is in this whole thing. You’re the orchestrator. You’re guiding the group and designing activities so that you get what you need to do your job. You're putting yourself at the center of this and everyone is here to give you what you need.

Pre-workshop essentials

Before you get everyone in a room, there are some baseline things that you need to have:

Visibility into the six-month roadmap.
A list of current capabilities for the product.
Some analysis of your target audience
You need to be aware of any gaps or blockers like missing features that sit farther out on the roadmap that customers are asking for.

If you don't have any one of these things, it's probably not worth doing a messaging workshop at this point in time because you'll just find yourself doing it again really soon.

Example workshop agenda

Voice of the developer

I always like to start a messaging workshop with a voice of the developer session. It gets everyone warmed up while they're still drinking their coffee, but it's also really important for setting the context.

You want to make sure that everyone is in that headspace and thinking about what the developer is experiencing and what they're doing, saying, and feeling. I usually ask the developer experience team or the research team to present this. Sometimes it's nice to have product marketers sprinkle in a little competitive research.

One of my favorite formats for these is quizzes. I was at a messaging workshop with my team last year in Sydney and our developer experience team put together this awesome quiz. They had a whole ‘Who Wants to Be a Millionaire’ theme and put somebody from the workshop in the hot seat to answer questions as though they were the end user.

It was funny, but it also made everyone realize what they were trying to communicate, which is that there was a little bit of a logical disconnect between what we were asking our users to do and what would seem like the right choice for them.

Everyone loves a quiz, especially if you're competitive.

Sliding scale

The next exercise is a sliding scale. A sliding scale is helpful if you think that there might be varying opinions within your workshop group about what your product fundamentally represents. That might sound surprising, but as products grow and become more mature, different people have different ideas about what that product is and what it means, especially if your org is a little bit siloed.

The purpose of a sliding scale is to align on where your product is opinionated and what it wants to be.

Step one for this is if you have a larger group, break everyone into smaller groups of two and four. Of course, you’ve got to have a pack of stickies; this is a workshop. So, give everyone a bunch of sticky notes and a marker.

Then you want them to brainstorm two opposite pairs of product descriptors, totally opposite opinions about what your product is.

On one end, you might have out-of-the-box, beginner-friendly, super-accessible Heroku. On the other end, you might have a complex, super configurable professional developer-grade platform like AWS.

Brainstorm as many of these as you can, and then have the group vote for the top three to bubble those up. You want to arrange each descriptor at opposite ends of the sliding scale, draw yourself a little line in between, and then the line in the middle is your slider.

And then the fun part is to open up the discussion and have your group discuss where your product would sit on the sliding scale. I've seen some really surprising things come out of this.

If you're in a workshop group and half of your group thinks that you're building a low-code tool, and the other half thinks that you're building pro-code, that's something that you want to be aware of because it could potentially trip you up with putting together a cohesive messaging strategy down the line.

So, hopefully, your group is all on the same page and you have three principles that come out of this.

First principles thinking

The next example of a workshop agenda item we're going to talk about is first principles thinking. First principles thinking goes all the way back to Aristotle, so this has been around for a while.

A lot of times, especially when you’re working on a product that's been around for some time, there are assumptions that are made about what you're building that are so old; they were made by people who aren't with the company anymore, no one even remembers exactly why we think about these things a certain way.

So, it's a way of starting from scratch to break down your assumptions into their most basic parts so you can try to suss out what those underlying truths are.

There are a lot of ways of doing first principles thinking. For a messaging workshop, the simplest way is to start by describing what the thing is.

If you were describing a developer platform to somebody who had no idea what a developer platform was, you’d say it was this thing that lets you access APIs and execute code. It's this thing that’s secure. It’s all of the characteristics, capabilities, and qualities that make up your product.

Then the next thing is to apply an interrogation technique called ‘the 5 Whys.’ This originated from Taiichi Ohno from Toyota in the 1970s. A lot of times it's used for root cause analysis, but it's also really useful for breaking down an assumption until you get to something that’s a deeper level of truth.

You just ask why five times until you get to something that something pops out and you're like, “Oh, yeah, that's the last why.”

Divide everyone into groups, give everyone a few different product principles to break down, give them some time to do this interrogation technique, and then have everyone come back and talk about what was surprising and what came out of it.

Storyboarding

The last piece of our workshop is going to be storyboarding. Storyboarding is a little bit like a customer journey in that you’re tracking what the user is doing every step of the way.

It's also a very logical structure when you think about it, and a really nice way of thinking about the environment that your product’s in, who your user is, and how you’re helping them. If the logic falls apart at any stage, then the story doesn't make sense.

So, here are the parts. You first have the situation. I like to frame the situation around something that has changed or a transformation that's happening. Maybe it's technology in your industry, something legacy is going away and something new is rising.

Then you have your hero, which is your user. The conflict is the thing that drives the hero to seek out your solution.

The plan is a very important piece. You need to be able to describe step by step how your product is resolving the conflict.

And then the positive outcome is painting a picture of what success could potentially look like.

Example of each narrative element in storyboarding: situation, hero, conflict, plan, and positive outcome

It starts with a quick definition of the hero persona. If you have personas that are fairly fresh, you can borrow some of that. But it's also really nice to get your group back on the same page of what the role is and what their responsibilities are, and then jot down a product idea napkin. This is just the bare minimum description of what's innovative, what the value of your product is, etc. That's the baseline.

The next thing you want to have everyone do is follow the traditional story arc. You have your exposition, the inciting incident, the rising action, the climax, and then the falling action.

We’re going to use that framework to describe all of the things that happen to the hero along the journey.

Each team creates its own version of this storyboard, and then after everyone does that, you're going to do a vote to make this composite story that's made up of everyone's best ideas, and then discuss as a group what's working and what's interesting.

Putting it all together

Those are a few ideas of things that you can do during your messaging workshop to create some useful artifacts and hopefully come to a deeper level of understanding and alignment with your group.

But this is where a lot of workshops drop off. Everyone's like, “Cool, we did it. We're going to go back to our regular work.”

How do you make sure that you don't lose that momentum and put together something useful?

Immediately after the workshop, you want to document everything that happened, summarize the takeaways, collect all of the artifacts that were produced, note any open questions that you still have, and your plan for getting those resolved. You also want to communicate when the group can expect the next phase of work.

The last thing you want to do is craft the message. You want to document it and socialize it with all of your stakeholders.

At Atlassian, we love a message house. Every team at Atlassian uses this structure to create a record of truth for their messaging.

The message roof is your umbrella. Under that, you typically have three value pillars. Each one of those is a benefit that your product provides.

And then at the very bottom, you have your proof points. The whole thing is supported by evidence. These aren't just nice benefits that we’re saying because it sounds good. They’re supported by actual features that the product has.

That’s a simplified version of a message house. There are a billion templates that you can go find. But this is a marketer’s biggest secret skill.