When you enter an organization as a product marketer, among the first things you want to do is working on positioning and messaging, shaking things up, moving the needle, and proving the value you can bring.
The key to nailing product positioning is storytelling - you can’t win without a good story and there are some great frameworks out there to help you create it. Coming up with the right story isn’t easy, but it’s achievable, aided by the use of the right resources, as can be seen in the evolution of MarkLogic and how we changed our story.
My name's Matt Allen, and I'm VP, Corporate & Product Marketing at MarkLogic. What I want to talk about in this article is how you refresh messaging and positioning. I wonder how many of you reading this were the first product marketer to join your company?
Usually, when you're going into a company, you have product marketers that have come before you, they've already done a lot of the messaging and positioning work, and your role is to come and change it, to update it, and to refresh it.
MarkLogic: a turnaround story
The story I'm gonna tell today is about MarkLogic's turnaround that really started about five years ago, the company itself is about 20 years old. We are a database software company based out in San Carlos about 600 people or so - kind of mid-stage, and the company was facing some significant challenges between the period of about 2010 and 2013.
It was interesting because, on paper, the company actually looked like it was very successful. We had a patented technology, the founder was still with the company. We had a continuing investment from Sequoia Capital, we had about 30 million in the bank and we had a great list of customers.
JP Morgan Chase is already running major trading systems on our platform. We were already the number one modern database company for the public sector, and so we looked really good. But we were also facing some significant challenges.
Challenges
Within the period of about three years, they had some significant turnover at the leadership level, where there were two CEOs that were let go. There was also a significant employee exodus, people going to work for our direct competitor. What was going on?
There were also some challenges that MarkLogic was facing in particular, we had a very engineering-driven culture, a very complex product and sales cycle, it was pretty long, we're talking 12 months or so. Brownfield market, the number one database company is Oracle, if anybody knows the market, they know how Larry Ellison treats competitors.
We were also facing this new movement called Open Source, and the leadership of MarkLogic decided that they were not going to use that as their business model, so that did create some adoption challenges.
There were also the challenges that I think everybody faces, even outside of this particular market. It was a very crowded marketplace, there were about 35 different competitors, this was right when the whole big data movement was taking off around 2010. AWS started in 2009 and Azure and Google Cloud Platform followed right behind them.
Then there was the challenge of gaining buy-in among stakeholders. So you have your board, you have your leadership, you have your sales team, you have your engineering founder, and they all have different ideas about how to position the product and that's really challenging when you have a platform product that can do so many different things - identifying what it's best at is really challenging.
But I think at the heart of it all is this problem of storytelling. MarkLogic didn't really have a story that employees could believe in or customers could believe in.
I joined the company in February 2014. My first day of the company was actually our sales kickoff event in DC. This was right when the company had just gotten some additional funding so they were starting to hire some new sales guys that didn't necessarily have any database background. We all started along with some other product folks from strategy consulting firms.
We walk into the auditorium and we're super excited to join this company, we sit down in a row next to each other and the CEO gets up on stage. One thing we do at sales kickoff every year is layout the new corporate presentation, the new way that we're going to go out to the market for the next year to pitch our product. Anyway, the CEO gets up on stage and this was one of the first slides that he put up on the screen.
I looked at this, 'we're the only enterprise NoSQL database', and I looked nervously down the row and I'm getting out my phone and hoping nobody sees me as I google, 'what's an ACID transaction?'. I literally had no idea. I had some experience in technology but this was going to like a whole other depth.
After the first set of talks, I went out and grabbed a coffee and one of the engineers came up to me and said, "Man, it's great to have you join the company. You sure were taking a lot of notes at the meeting". I was very interested in learning a lot about the technology but when I looked at this I thought we can do better than this, we need to be able to tell a better story.
The importance of storytelling: Slack
Some of you may have heard of this little company called Slack. I was listening to a podcast recently and the founder Stewart Butterfield said…
How many of you reading this used HipChat? My company used HipChat before we switched over to Slack, and what's interesting is HipChat had a lot of the same features as Slack did, feature to feature it was relatively the same. But I think at the end of the day, Slack was able to tell a better story, and that's why I think it was about a year ago that they bought HipChat and promptly shut it down.
You cannot win without a great story
My point is this - when it comes to strategy, when it comes to positioning, when it comes to messaging, you really have to have a good story, you cannot win unless you have a really good story. So I'm going to go through quickly some of the evolution of our story at MarkLogic and how we've changed the positioning and messaging of that story.
The evolution of MarkLogic
2001-2013: XML content server
Don't worry, I'm not going to get too technical, but in the first 10 years of the company's history, we were positioned as an XML content server and that was essentially just calling the product exactly what it was.
Our founder had patented some technology for storing and searching XML and serving it to users, therefore, ‘XML content server’, pretty simple. I think that had some value in terms of getting some initial user adoption, among a more technical audience that was looking very closely at different technology products.
The problem with that was that there was no market for XML content servers, we were a market of one and it was really difficult for anybody to come in and explain to an enterprise what an XML content server was.
2014-2015: enterprise NoSQL database
The next iteration was when we had a new CEO who's still the CEO today, he came and positioned us as the ‘enterprise NoSQL database’. While there were some concerns, it was a very technical approach to thinking about the product, it had a lot of value right off the bat. He was coming from running Oracle's database division and so he immediately saw that our product was a database.
As a result, we immediately had this bucket that you could fit our product into, and our sales team didn't have to go out and explain what our product was anymore. Not only that, but we were part of this new category called NoSQL which was basically these set of modern databases that were particularly good at scaling. Not only that, but we were an enterprise player, so we were further differentiated from all these other new database companies that were getting funding because we had been around for 10 years.
Again, that was a very technical way of looking at the product and it could do so many different things, so we made a pretty surprising choice around 2016.
2016-2017: the world’s best database for integrating data from silos
This was when the market was getting increasingly crowded, and we needed a way to further differentiate our product. What we did is we looked at all the case studies that were bringing in the most revenue, and looking at the things that our customers really valued our product for, and we found out that it was really this use case for data integration, our product can be used for a whole lot of different things, namely search, but we took this direction of just focusing on the one thing that our customers really valued us for.
It was the one thing that we could beat Oracle hands down and so that was when we came out with this messaging of being the world's best database for integrating data from silos.
That was important, we talk about Clay Christensen and 'the innovators dilemma', and being able to find the job for that milkshake, and this was essentially doing that, finding a pain point and solving it for customers.
2018-present: data integration simplified
In the next iteration, we built even more on that, and the unique thing about this was that we didn't even mention the name of our product in the tagline. We're talking about just the business solution that our goal is to make data integration simple for our customers.
That tied in very closely with our product strategy, because we just launched our first cloud service last year and if you know cloud services, you know it means that we're managing the infrastructure, it's like a SaaS application. What it means is that you can target the business more, you're not just talking to IT folks and a lot is to really get outside of this IT firewall and start communicating directly with the business.
So this whole progression over the past five years has really been moving it from what it is to why you should use it. So I'm going to quickly run through our story, just to give you some more detail on the story arc for how we communicate the story today.
Our story today
We first start with laying out the future vision, for us, that's building a unified view of data.
Then we talked about the customer pain, the reality is that data is in silos. Sometimes it's called a reframe, where you're providing some insights, some new information that your audience may not know.
Next, we present some personas and talk about the pain that they're in. That's also called rational drowning, where you're actually showing what the world would be like if you don't change.
Next, we lay out what the future world will look like if they adopt your solution.
Then we give a lot of validation talking about customer examples.
We end by giving a summary of the business results you’d expect by using our product, again, using a lot more validation from customer examples.
Focus on business results
The business result is really important. There was a survey that Gartner had just recently that made this exact point, which is that focusing on the business results is going to be the most compelling thing to get somebody interested in buying your product.
MarkLogic results
I'll briefly go over some of the MarkLogic results, especially for those of you who might not be as familiar with the company.
Big vision for PR and AR
So, this change in messaging immediately gave us some interest with PR, because now they can start talking about the business, we could get past those technology discussions.
The other big thing is with analyst relations. Gartner for the first time when we started talking about ourselves as a database, we actually, for the first time showed up in these reports.
When we came out with the messaging about data integration it was interesting, we got a kind of backhanded compliment where they said, "You're innovative, but you're way too early, we're not sure if your customers are going to be able to understand what you're working on when you're not talking about yourself just as a database".
The very next year, they said, "All of your competitors are starting to talk about data integration, and we're scared that you're not going to be differentiated enough". Lesson learned, you're never really going to win with the analysts, but we'll do our best.
Clarity for customers
Your next big thing is clarity for customers, you're able to have a very clear message and for a fairly complex enterprise software product, like us, that was really important is being able to speed up the cycle, when you're working within a large company, you often work with champions, and it's really important for them to be able to communicate the message across their own enterprise, and when you have a message as simple as "we make data integration", that is something you can leverage.
What it means is that when you're presenting your first call back, your first meetings is that you only have to spend the first 10 or 15 minutes talking about what you do. You don't have to spend time talking about what an XML content server is, you can get right to, "let's talk about your business problem. And let's talk about your architecture".
We sell product...
The last thing is, of course, we're selling a lot of product. So as we're speeding up our demand Gen and deal cycles and having the messaging and positioning support that, we're doing some really significantly large deals in our industry, that means seven or eight-figure deals, and we're getting the valuation and the revenue that we want.
Over the past few years, we've generated - and I can't share the exact details - but well north of 100 million a year.
How we changed our story
Start by developing your framework
Let me talk tactics, and how we went about changing our story. Some of the frameworks that we've used, I think it's been helpful to see how these frameworks are used when you're selling one single product and going through and comparing and contrasting these different frameworks.
Framework 1: CEB (now Gartner)
The first one is Corporate Executive Board, they were bought by Gartner. They're all about the A to B reframe. The basic story is you start with your current state, use what they call a commercial insight, highlight what's missing, take them to your B state, stay where your emerged transform.
That's very similar to how another consulting company talks about telling your story…
Framework 2: Duarte
Nancy Duarte founded this, it's a consulting firm down in Palo Alto, they consult a lot for some major tech firms for their conferences, they help with Ted Talks.
I found them a very useful resource when you're talking about telling your stories. It's a little bit more about presenting but you can see that they have a similar storyline where you're taking your hero and they encounter a problem and they emerge transformed.
What they say is, when you're telling your story, it's about going back and forth between this A and B state so that you're building tension and contrast in your story, so you make it interesting. And just so you don't think it's too simple of an approach, they have a lot of resources that we find valuable that you can use when you're putting together your story.
Framework 3: Storybrand
Another consulting firm is Storybrand, they have a New York Times bestseller called Building a StoryBrand, they have something very similar to what Duarte has, and the only element they add that's a little bit different is adding this idea of a guide, who's taking the hero through this journey, and then emerging transformed at the end.
Framework 4: SiriusDeicisons
SiriusDecisions, they're, again, a very popular framework, and I'm not going to go into detail and I'm probably not going to do it justice. But this is one that we've used and what's helpful is that they focus a little bit more on process.
So you walk through these different arcs of what they call their Messaging Nautilus. They have frameworks and a very analytical approach to understanding messaging, and it starts by understanding your audience, going deep into what their buying intent, whether you're building consensus or trying to convince them of a paradigm shift, and then looking at the actual narrative elements of your story and then actually what steps do you want to take to activate that messaging, and then put it together in a blueprint that you can actually roll out.
For SiriusDecisions, for us, it was in many ways too much. I think if we tried to use it, for every single one of our product launches and solutions campaigns, it was just a whole lot. What we've done instead is take the things that were useful from it, and incorporate them into our approach.
One of the tips I'll share that I think has been really helpful for us is finding the value prop.
Formula for finding your value prop
This is a simple formula you can use when you're trying to find your value prop and something that's important because people often argue about what's your value prop and then you get into writing in and then you argue for a while.
It's just simple when you can have a formula like this to layout your need, say why your customers want it, what the outcome is, what makes you distinct, string it together and there it is.
Our general approach where you're thinking about frameworks is to keep it simple. Keep it manageable, keep with something that's easy to communicate across your team and is appropriate. For us, as a mid-stage company, it hasn't really changed too much.
Deliverables and process
As you grow, you can continue to adopt it and add additional things and do additional research. But this is essentially the different tiers of messaging that we think about, for our company and our product.
- Company deliverables, those are ones that are often already developed before you get to a company.
- The core product is where I've been talking mostly about MarkLogic's messaging and positioning, that's the A state the B state, laying out your differentiators, what results you expect, those basic things, and that's where we've done the most change within MarkLogic.
- When we think about product and campaign launches, those are gonna be very similar, they may have a few more elements that you build in, but we expect that you usually are able to write those a lot faster, because you're pulling a lot of the same messaging from your core product messaging, just as you're pulling a lot of your core product messaging from your company messaging.
So just a few notes on the process that we use, it's pretty much the same for us when we're talking about the process for coming up with messaging.
For us, it starts with a lot of research, we again, have a fairly complex product, and a pretty broad competitive market so it involves doing a lot of research and talking to a lot of customers, figuring out what they're using your product for, and I don't want to overlook the writing stage.
We put this in here because it's so important to sit down and actually, as product marketers, be spending the amount of time we need to write. My advice if you're hiring, is hire writers, it's very easy within our space to find somebody that has a computer science degree, it's very hard to find somebody who knows enough about the technology, but can also write.
The next step is the buy-in and testing phase, for us when it comes to core product messaging the thing that I've found most important is getting leadership buy-in. Surveys show one of the challenges that product marketers face is not being able to feel like they're getting heard. For us the most important thing has been getting in front of the CEO, getting in front of the head of products, having the discussions that you need to have.
Once you have something written down getting their buy-in and putting a stamp and saying this is final and now let's use it for all of our collateral, and then having them actually go out and test it.
So when we come up with new messaging that's affecting core product, they'll actually take the new pitch and they'll actually go test it in the wild with customers. If they're happy with it, then we'll give it to our top sales guys and they'll take it out and start testing it.
Then we'll launch it at our sales kickoff, and on a quarterly basis iterate on it.
For product campaigns, it's a little bit different, for a product launch we'll launch the product, and then we have a beta testing period where we're testing the product messaging at the same time, and then again, making changes to it and iterating along the way.
What about features?
We talked a little bit about the features, and those do come into play at some point and my advice is to avoid the feature paralysis of giving somebody too many features to think about. I love the story of VMware.
An example: VMware
VMware has been described by one of their co-founders, Diane Greene, as a little bit like a Swiss Army knife and it was appropriate because people have described MarkLogic this way as well.
It's a product that can do so many things so it's tough because you have to figure out what to focus on, otherwise, you end up paralyzed. For them, VM was a complicated product to understand and even though right from the outset, Diane Greene and the team had this huge vision, they knew that a virtual machine would become the foundation for modern cloud infrastructure, but they couldn't just go out and start selling it that way.
When they put together the go-to-market strategy, they were throwing everything up against the wall, and nothing really stuck. What eventually ended up working was that they found that university professors really valued being able to set up a virtual machine because what it meant was that they could get their Linux machine, and they needed to also run Microsoft Outlook email, which would usually mean they would have to go buy a Microsoft box, having a VM meant they could run both on the same box and saved them money.
That was such a simple use case, but that was where they started getting initial adoption and I think everybody knows where VMware is today. But in an interview with Reid Hoffman, what they said was, "Rather than sell the whole Swiss Army Knife let's just sell the tweezers" and when we think about features of MarkLogic, we think about that very similarly.
Framework 5: the Kano model
The Kano model, I think, is a really helpful framework for thinking about features, and focusing just mostly on the features that are going to be the delighter features, the ones that are really going to impress users and really move the needle in terms of their interest in buying your product.
Other features fall in the category of what they call performance features. An example would be a nice UI. You have a UI that's maybe slightly better than the competitors and users like that, they like a prettier UI, but it's not really going to make them be more interested in your product in any significant way.
Then you have your must-have features which are ones that are checkbox features where you have to have them and if you don't have them, then users will be upset, and they will completely dismiss your product.
Winning requires more than great features and a great story
I've been talking a lot about the importance of telling a great story and having a way to talk about features. But I want to also provide a counterpoint here, in that the story is not everything.
When we look at Steve Jobs, one of the greatest storytellers of all time, I love this example of when he launched the MacBook Air and how it could fit into the manila envelope.
For all of Apple's products, they all met the same criteria for having an awesome marketing launch, having awesome messaging, being able to tell a great story, the products had amazing design, and yet when you look at the market share for Apple's products, they're all over the map.
Apple computers today still only has about 7% market share. PCs running Microsoft have over 90% market share. But then you look at other Apple products, like the Apple iOS, that has about 48% market share, if you combine it with Android, it's close to 100%.
Same approach, awesome marketing plan, awesome design, two completely different outcomes.
So, there's clearly something else going on here. The idea is that the difference between these two products is the difference in which ones have the best connections.
Connections are important
Apple computers - relatively weak connections, it's a relatively small community of developers, especially in the earlier days and they could only run on Apple hardware.
If you look at Microsoft, they really took advantage of the fact that a lot of people already had PCs and Microsoft could run on any hardware, and in the early days, that meant easier file sharing between PC users, and that helped them gain that market share.
Apple iOS made the decision to launch an app store. App Store is all about having developers build apps, put them in your app store. Obviously, Android has the same thing. Nokia and Blackberry didn't have that.
There are lots of other examples you can look at the importance of connections. The Amazon Kindle is one example, the Sony e-Reader actually came out before the Kindle did and was actually a superior product and yet obviously we know how that ended.
Encyclopedia Britannica doesn't exist, Wikipedia is obviously where we go to for information.
And if you look at our market, it's very similar examples, I just put six in the image below but I could easily find more.
These are similar stories, these are all just complex architecture diagrams, and they all look relatively the same. They're all about getting data into your platform, doing something with it, and then sending it out downstream for whatever you want to use it for.
The interesting thing is that despite having very similar products and messaging, there's very different outcomes. Two of these companies don't exist anymore. Three of them have very low revenue numbers, and one of them has a $7 billion market cap.
You've got to look at the importance of connections.
I would recommend this book...
I think this book is just as important as the Innovators Dilemma in terms of figuring out your positioning and your strategy. It's the Content Trap by Bharat Anand, and he goes into a whole lot more detail on this topic about the importance of network connections, or what Bill Gates calls network externalities, and how to build that into your strategy.
I want to leave you with the thought that to position for growth, you need to tell a great story, but you also need to build connections into your strategy.
For MarkLogic that means you want to focus on the developer community and building connections there, but for us, it also as an enterprise software company means building connections among your buyers, which is more on the business side and among your architects.
That means going out and building stronger partnerships, both on the technology side, working with systems integrators, obviously, we're doing things to work on our cloud service for our adoption strategy among users there.
There's other things that we get very involved in with specific enterprises, for example, we have our head of engineering who actually sits on Boeing's board for guiding IT, and we also hold workshops at these large enterprises and those are all strategies that are focused on building connections for our users and our buyers.
And that's it. Thank you.
