January 23, 2018
Ep. #24, Server-Side Rendering with Trey Huffine of Postmates
Brian is joined by Trey Huffine, software engineer at Postmates, to discusses the pros and cons of server-side rendering and the joys of Rea...
Good afternoon, everyone. Thank you for having me. Messaging as the source of truth. This is something near and dear to my heart, because I have spent decades writing lots and lots of words. Why this topic?
Because we fundamentally as marketers, with messaging, want to solve this problem. How many of you have seen this episode where Richard comes out from the focus group and says, "They don't get it." Literally whiteboarding regular people off the street for three hours, and then they're all like "I finally get it ." What we want to do with messaging is solve this problem.
As a founder there is a way that you can tell the story, the origin story of the company, how you personally evolved to get to that point to create this product and this company. It's totally unauthentic said by anybody else. As you hire more people, as you have a marketing person join, as you start to do sales enablement, they can't tell the story in the way you can because that's very personal. The purpose of messaging is to take some parts of your origin story and turn that into something that's consistent and scalable across the company.
Because at its best, what messaging does do is informs what everybody at the company does. The messaging framework becomes an organizing principle for how all the different teams organize. One of the best experiences I had with messaging was in the end-user computing business unit at VMware. It was the first time we were doing anything on top of the core vSphere platform. We were selling to a different audience and everything, so it was very exciting.
We'd gotten to a place where we found we were entering a highly saturated market. There was already a company that had been winning in there for two decades, and we were coming in with something new. We needed to find a way to define our product and h ave pillars that were differentiated.
The best example of how that brought the entire business unit together is my product management partner and I, when it came to looking at the next release, and we were possibly going to run out of time and maybe we needed to cut a feature or two, we would look at our messaging. The messaging framework that we had, and make the decisions together. Because would it be something that we had to do because it's foundational to compete, or do we choose this other feature because it actually propels us ahead in another value area that the company competition doesn't have?
When you have a great framework it should organize everyone together.
When everyone inside the company is saying the same words and is using the same framework to organize. You could be a five person company or a 10 person company or a 100 person company but you'll look so much bigger from the outside. Because everyone's like, "It's always the same story."
So, the rest of this I'm going to go into how to do it. Who needs to be part of messaging? Literally everybody and nobody, all at the same time. Everyone has a role to play, it's about managing what that contribution and scope is, and it's really important as a marketer or whoever is the first person that's running this exercise to keep the process moving. It's not a one and done, but it is something that needs to have an end point.
Then from there the teams need to consume and execute. Then you have to build in a cycle for review and iteration. Marketing and product should be the primary core drivers of the process, if you have a marketing person they should own the process and do the translation layer.
When you look at the messaging framework itself, it just looks like a few boxes. Doesn't this look so simple? It actually can be very challenging, arguments can ensue. This could take a couple of weeks or it could take months. I've seen this at large companies take many months, lots of approvals. I've been able to do this as fast as two weeks. It's really how you engage the people in the process, let them know who needs to be involved when, what the expectation is, and how you move this along. This is the core that you need for the framework. It is not a framework unless you have these things.
I will go into the different steps and how you extract those nuggets, but it's also important that you're concise. You want to get this to be something that's about two pages as the core, because if you cannot dumb it down then the people outside your company are never going to understand what you're selling. What you want to do is for people who are not intimately involved with your product every day, how do you explain this so that anyone off the street can understand it?
As you grow I have seen people add onto this. If this is your great framework, every time you might do another big launch or a big announcement, more use cases are added. This can be the framework in which you add those because it should be about, as you add feature sets or expand your portfolio, how does it enrich the core value that you're bringing from your company to your customers?
Let's start from the top. Market and customer context, this is the place where you want to involve your founders. Founder or founders, and some key executives. The key questions to ask here is "Why should anyone care? What is the purpose of this company?" When you're a smaller organization and just getting started the company purpose is very much the product purpose. Because you're probably a single product.
So when you look at this, it should be about two paragraphs. First thing is the market industry. You want to have a bigger vision, like "We're attaching to some mega trend. But as part of that mega trend I've identified a specific user persona, that has a problem that I want to solve." That's the red and the blue.
We just talked about market and customer context, now we're going to go down to the bottom where it was the pillars. The pillars are really important here because this is the meat. This is the bulk of the work the product or engineering and the marketing team will go through. What you want to do here is your pillar, your pillar is your category of value. This is how you group the capabilities that you have together.
The benefit statement, when you look at your category of value like "Easy to use, security, choice, agility, whatever." When you look at those, what is the statement, "the benefit, from the point of view of the customer? Not the marketing lingo we may want to use, but what our customers or your target customer is actually saying? Use their language.
Supporting points, is all the how. This is all the features that you have, and then with the features you then want to give some proof points. Are there statistics you can point to? Download rates, usage rates, industry stats? Are there users that have given you quotes as to why this is awesome, why that feature is awesome? When you go through this exercise what you want to do is look at all the features you have and then from there compare against other competitors out there.
You want to strip away the things that everybody else does, because that's not necessarily differentiating. Say you had 50, a list of 50. You look at what everyone else is doing and then it takes away about 25. Then you look at your remaining 25 and start to group them, and then you can play with the words and what should the names of those groups be. Those are your pillars, and then everything cascades down from there. I show three here, rule of three.
Two never seems like enough, no one can remember the fourth one. I highly recommend just stick with three.
It's like all our brains can consume at one point. So you've done the very top of the market context, the high level, you've done all the groundwork on actually how that gets done.
Now it's time to do the positioning statement. The reason I like to do this in this order is that once you've outlined the big problem, the customer problem you're trying to solve, and then you've spent the time like marinating in all the features and the capabilities and how you actually do this, the position statement becomes the answer to that customer challenge. That's answered by how you've identified your core categories of value, and you've already thought through like how you're differentiated.
I recommend starting with the 50 word, it seems to be the best length in which you have enough room to play around with words and sentences. You'll end up with about three-ish sentences there, and then once you get to a good place you should iterate and vet with a marketing executive, product executive or founder.
Vet with them, go through a cycle and then once people feel good about the 50, then you spend the time to decrease and increase. Don't try to write all of these at once. Also, the tagline is the hardest thing to start with because it's like literally no words. 50 is a great place to start, and then you can build up and build down.
That's it. I didn't put the persona thing on here because everyone talked about it in the panel earlier, but you can keep building with this context. One interesting thing to note, this is your core. This is all you need.
Now people are going to start cutting and pasting, someone's going to send an email for an event. They can cut and paste. When you start thinking about websites, cut and paste. "I want to build some demos, I can build a bunch of demos around ease of use. Wow, you've given me three supporting points? I can do demos on each point." It gives really good guidance for the rest of the teams for what they could do.
So, you've done a draft. You've done some iterations. Who needs to buy in, how should people review, how should people approve? The product and marketing teams, they're iterating. Founders and execs, you all have a voice but you don't steer the whole thing, you're one voice. Cross-functional teams, it's important to loop them in, I'll talk about them a little bit later, but you also want them to be involved in the later stages to see if they may have a little bit of input, but they're also your primary customer of this content. I have customers, media analysts, basically all these people outside of your company.
Super important to test, but it doesn't need to be a big long process. If you already have some customers, build relationships with one or two so that you can just run these things by them.
Reporters and analysts, a lot of times they will totally take your call to run something by them. They actually like having that kind of relationship with you, and you say under confidence "We're running some messaging changes. How does this jive with what you're doing?"What you want to do in the testing is be very structured. Do not send them the whole messaging Doc, because t hey're going to be like "I can't read all of this.
" What you should do is with the framework that you've built, try to put together three slides of a pitch deck and then run it by them. With that be very clear on the questions you want to ask for the feedback you want. Because just saying, "How was it? Did you like it?" They're like, "It was alright." What part was alright? You want feedback.
So you could say, "I have these three pillars and we're waffling on, does ease of use sound good or should it be simple or fast or agile? What are the terms that you are using most?" If you're very clear about that you will get very clear feedback. As an example, I've done this with a few different things over when we were at Docker. Because it was an emerging space we had to ask people "How are you thinking about this?" Things like "Security," we changed it to "Governance." Things like "Do we call these legacy apps?" They're like, "No. Call it traditional. You don't want to offend your user." Very quick 15, 20 minute calls got us very meaningful feedback to iterate and get messaging that was tighter.
It's great, people love it, you got buy in, it's written, oh my gosh. You can lock, no more changes. Then what do you do? You need to roll it out, depending on the size of the company maybe you're the person that it's going to roll out to and then you're going to do all the marketing.
But in the chance that there's other teams there that will be consuming this, it's really important to have enablement. Enablement is not just something that you do for sales enablement or to teach your customer, you need your internal customers, all the teams listed on the left there, they need to be involved. Because they need to be involved to understand all the context behind that.
Putting together enablement around "Here are the pillars, here is why. Let me explain the supporting points and the features and how they're being grouped." If there's a customer statement in there or a user statement saying "This was super easy to use, I got to do XYZ in a few minutes," use that time to train your customer, your internal customer, on that customer story. Who is that customer? What was a problem they had, how did they try this, how did they come to our product? How did they impact what they're doing? You have that luxury to enable them, and by enabling them they can internalize that story and then be able to execute better.
The next point is really important because I've seen so many ways that this plays out in different companies as to who actually builds all this content. There's a lot of teams out there that need to build content that's going to be executed and consumed in different ways out there. The person who authors the messaging doc should actually create at minimum two pieces.
One that's presentation, or a presentation form. It has the story of "How would you pitch this?" Using the message framework to pitch a customer. The second is something written. It could be a blog post, an article or a white paper style. You want to know how it's going to read in a long form story, that gives much more context for someone else to write more blogs or do whatever, because you get some things around tone, examples, etc.
It's also important to say who's going to write what as your organizations grow, not everyone is comfortable writing and some people may want to write different things. We talked earlier, when they say "How do you define product marketing?" It's very different at every company, and so in that sense the role of the authoring is very different at every company.
So as new companies are formed, it's important to say "OK. What do you want to write? How do we do this? What's the review cycle we should have?" Because if they're going off on a tangent with one of the key pillars or one of the points, you want to have the opportunity to do feedback and review. Then feedback loop, build in a feedback loop so as someone's doing an event or they're doing blog posts or they're doing some other community evangelist material, build in a cycle for feedback because they're out there talking to end users. You want that feedback back so that if you need to iterate on your messaging you have it.
How do you know if this is working? We're currently living in a highly data-driven everything. "Everything is data, you plug it into my BI dashboard, I'm going to know. I wrote this messaging doc, now I can see how many people have reviewed it." Unfortunately this is one thing that doesn't quite work like that.
You can't plug it into your Looker dashboard or Domo or whatever fancy tool you're using, it's a little more subjective. But here's a great example in that my own experience, I spent four and a half years at Docker. We went from under 100 to 450 people when I left, and for the longest time it was just me. It was really easy to just not have a messaging doc, because I wrote the bulk of this stuff.
We got to a point of hiring more product marketing people, and then we started hiring field marketing and campaigns and programs, and some of those people lived in other countries. It was like "Oh my God I cannot be this human source of truth anymore. I can neither write everything and I cannot review everything." About in the last year we put together the first messaging framework and it was part of a launch, and the biggest impact I felt was all this stuff was getting done, and in many cases without my ever having to see it. It was amazing. But we were still on message and we're still consistent.
The best impact of messaging is seeing that you empower other people inside your company, as well as agencies or vendors that you pay to do the work that they do best, within the guidelines that you're setting.
Recap, messaging is the source of truth. This is the most fundamental basics. You have to have that. It brings everyone together. Develop the framework with those core sections. You can continue to riff on it if you need to, but at the minimum you need those sections. Engage and enable the cross-functional teams so that they are involved, they feel they're brought in, as well as they're enable to go off and do the things they need to do. Monitor and measure the impact, see where it's working and see where it's not working, and then test, rinse and repeat. If you get those together, you can be so awesome . I could not find a picture where they're actually like excited, so this is the best I could do. Thank you.