It’s the most wonderful time of the year. No, not that time. The other one. The time where your startup gets together and starts planning for the upcoming year. Some of you have already finished this process, but with my fiscal year ending in January, I’m currently in the midst of it.
That’s why this article from Sarah Hodges on how to run better management team offsites caught my attention.
In particular, I loved this quote from former colleague and friend Thomas Erickson, the former CEO of Acquia.
Make sure that a focus on execution remains front and center. Have a regular “execution” meeting and less regular “strategy” meetings.
— Tom Erickson, CEO, Acquia & Co-Founding Pillar
I’ve often thought that as leaders, we focus too much on strategy and not enough on execution. Peter Drucker once said culture eats strategy for breakfast, and I agree. I think organizations with a culture of getting shit done win. I’ll take a relentless executor over a “strategic marketer” any day.
I know there is a larger debate around strategy vs. execution. At larger companies, planning, strategy, and execution are seperate disciplines. But my experience comes from working at startups who don’t have the luxury of dedicated teams augmented by management consultants, so finding the right balance is important. Focus too much on strategy, and you’ll end up with a lot of great looking PowerPoints but metrics that look more like 〰 or 📉.
Set the Corporate Strategy Annually
Having worked for Tom for ~3 years, I’ve experienced how he found the right balance between strategy and execution.
Once a year in November, Tom brought the entire extended leadership team together to run a three day activity called the Goal Deployment Process, or GDP as we called it. This process was used to identify the most important issues for Acquia to tackle in the upcoming year, prioritized by their potential impact. It was a team exercise where Tom laid out the three year objectives for the company, and we worked backwards into all the things that would need to happen for us to get there.
The outcome of the GDP was a list of ten or so strategic cross-functional initiatives for the upcoming year, with clear definition of ownership, metrics, and specific actions to take. Here’s a look at what one of them looked like:
The robust planning process drove alignment on the most important items to the company. The GDP actions were often tweaked and metrics were redefined, but very rarely did we decide to abandon any completely during the year. Many of the important milestones in Acquia’s growth came as a result of the GDP process.
Drive Daily Execution
But the most important part of the GDP process wasn’t the annual meeting, it was how it affected daily priorities across the company.
Each owner of the GDP was expected to drive their actions across the company. To make an impact, the GDP leader had to structure their day to make sure they were impacting each of the cross-functional actions they owned. Every month, the extended leadership team would get together to review the metrics. We used a spreadsheet with the plan and actual result, with color coding to highlight areas we were performing under expection.
It was simple and effective. Every month, GDP leaders had to provide an honest assessment of how well (or not) we were able to drive improvements. Too much red? You aren’t executing well. Too much green? You probably set your goals wrong. Note that with Tom, I learned (the hard way) that it was better to have more yellow and red than green.
Tom ran the weekly executive leadership meeting at Acquia the same way. Every Monday morning, he brought the exec team together to review a spreadsheet containing a running list of the most important actions across each department in the company. These were usually less cross functional than the GDP, but still important to the success of the company.
This list forced each executive to provide a weekly assessment of where they were at on important deliverables. This simple format wasn’t appropriate for managing the details of the actions, but it was an easy way for the exec team to track progress, and if something were blocked, it could be addressed directly in this meeting.
Anything that fell in the strategy bucket in the weekly meetings was noted, but not addressed as a part of this meeting. Tom kept the meeting all about execution.
You need a strategy for better execution
Here’s the thing: execution is hard and its a grind. But like anything, being great at execution is daily hard work. There were times that I hated the GDP process, and all of the time it took to drive actions and report on results. But looking back on it, I realize that it was one of the main reasons why Acquia grew as fast as it did under Tom’s leadership.
Chances are at your startup, you’ve already got a good enough strategy in place. You know your customers, and you’ve built business model. You’ve got product market fit and a go-to-market in place. But do you have a strategy for getting better at execution?
If you don’t, that should be a big topic for your 2018 planning process.
A little over a year ago I wrote an article about killing the marketing qualified lead. Here’s a quick refresher: Once upon a time, sales and marketing hated each other. Sales complained about never having enough leads, and marketing complained that sales were terrible at following up and converting them. It was the dark age of marketing.
Enter marketing automation systems, and the birth of the “Marketing Qualified Lead (MQL)”.
The MQL forced the alignment CEOs were looking for, requiring sales and marketing to agree on the traits and actions that described a good lead. It required a good content strategy to guide prospects through the complex B2B buying journey. It drove a consistent set of lead management processes that made it easy to measure conversions at key points. It let marketing prove contribution to revenue.
All of that sounds great, so why kill the MQL?
Marketing automation products made it easy — maybe too easy — to automate processes that would nurture users over time until they became “qualfied” by whatever lead scoring mechanism was put in place, usually by relentlessly emailing users and/or getting them to complete a form(s).
But how qualified is someone just because they filled out a form or opened a few emails? David Cancel of Drift captures the issue:
The MQL and the associated sales and marketing processes around it simply didn’t reflect the modern reality of the empowered buyer. And because marketing teams were goaled on hitting an MQL target, we figured out how to game the system. Most lead scoring models overweight activity, so send enough nurturing emails or run enough webinars and you’ll MQL everyone.
Ultimately the hit the MQL goal at all cost mentallity drove marketers to prioritize hitting short term monthly goals over building the type of sustainable brand magnet that creates demand over years and decades. Hitting the MQL goal became a speadsheet exercize: simply find a low cost acqusition channel and nurture the heck out of leads until they relent errr “qualify”.
Even Account Based Marketing — the darling of everyone’s 2017 marketing budget — doesn’t deviate much from the traditional SaaS 1.0 playbook. It’s certainly a more effective way to reach the people most likely to buy your products, but when you dig into most ABM programs, they are still based on the tried-and-true tactics illustrated by David Cancel in the image above.
RapidMiner Studio is an open source data science platform, with commercial versions that add access to additional data and unlock faster performance. We define a PQL as someone who becomes a user of our flagship RapidMiner Studio product by downloading, confirming their free account, and using it at least once.
Here’s What I Learned About Killing the MQL
In the rest of this post, I’ll share six lessons we’ve learned 12 months into our PQL journey:
Lesson #1: Forget sales and marketing alignment. It starts and ends with product.
“We sold what to whom?”
Remember the telephone game — where you whisper a story to a group of people one person at a time to see how much it changed at the end? A similar phenominon happens in an MQL-dominated pipeline, where the leads you create and opportunities you create from them often look vastly different from the users you build products for. That’s because the “sales and marketing” alignment renaissance triggered by the MQL was actually the wrong goal. We forgot about aligning around product.
The PQL shift at RapidMiner immediately aligned the entire company with product at the core. I get this sounds obvious, but for most companies the sales and marketing tail still wags the product dog. We’re now very clearly product led at RapidMiner, completely aligned around the core personas we serve.
The best part is that it’s now much easier for me to make growth a more important part of the product backlog, and we’ve implemented a series of new product-led initiatives to help increase user acqusition and retention.
Lesson #2: You need a product oriented sales team.
When RapidMiner shifted to PQLs in August 2016, we took a hard line: we only assigned PQLs and “hand raisers” (people who ask us to follow up with them) to our inside sales team. We took almost every form off of our site, and we stopped passing event leads to sales. A year later, we’re still only passing PQLs to sales.
By focusing only on PQLs, the quality of our sales conversations improved. Our target buyer is most often a data scientist — not exactly the easiest persona to qualify. So we put our sales team through extensive product training, supplemented by sales engineers and other internal data science resources. While the PQL model didn’t eliminate the need for technical pre-sales resources, it did change the conversion from selling features (“can RapidMiner do this”) to delivering value (“can you help me create a customer churn model”).
We designed our PQL sales process with the expectation that users would want to engage directly with our inside sales team before buying. While we do a few self service transactions each month, most customers engage directly with our sales team. And that’s because users view us as trusted advisors, not transactional sales people. We’re helpful.
Getting someone to respond to an email or a phone call — even an active product user — is still difficult for all the obvious reasons…(looking at you, spammy nurturing MQL email senders). Here’s the approach that works for us. Our email / phone calls go something like this:
Hey there, thanks for trying out RapidMiner. Please use me as a resource as you learn RapidMiner, and don’t hesitate to reach out if you need help.
The key learning for us was that our inside sales team needed to be able to offer something of significant value the user couldn’t get elsewhere — help, with a personal touch. Which brings me to the next lesson.
Lesson #4: How to scale helpfulness
We’ve made it a company goal to put our users first, even the ones who will never pay us. That’s easy to write on a PowerPoint slide, but it has serious implications when you have the type of scale we have at RapidMiner with tens of thousands of users each month.
One of the ways we’ve scaled a culture of helping with a small team is by using Drift, a live chat platform. We get hundreds of questions a day from data scientists, and we try and answer every single one. Some questions we can answer right away, other times we direct users to the RapidMiner Community, where a user can get questions answered in a few hours. But everyone who comes to our chat and talks to us gets a response, it’s the least we can do.
Through a little bit of automation and and tools, we’ve been able to scale helpfulness to thousands of users with just a couple of dedicated resources (shoutout to RapidMiner Community leader Thomas Ott and Yasmine, our Northeastern co-op who runs Drift).
We know that most of the people we help won’t buy our product — at least not right away — and that’s okay. By helping everyone, we are building a sustainable competitive advantage in the form of brand built on the back of a community. I’d like to think this is one of the reasons why RapidMiner is the most popular general data science platform on KDnuggets and the highest rated product on both G2 Crowd and Gartner Peer Reviews.
Lesson #5: Documentation is the new content marketing
Moving to a PQL model required us to think differently about content. Since our top priority was to create active users, our content strategy needed to be focused on user on-boarding and education. Buzzfeed-y listicles and flashy infographics don’t provide much value to a data scientist looking to tune a gradient boosted tree. So we had to think differently about content.
For example, instead of hiring a content marketer we reallocated budget to the product team to hire a documentation writer. Instead of creating lightweight infographics and eBooks, we create product tutorials and educational content.
To measure the effectiveness of these efforts, we look closely at product survivial cohorts to measure the impact of specific actions to see how they impacted product survival over a period of time. Here’s an idea of what we look at (not our data…)
Lesson #6: Pricing and packaging has to scale with value
Lastly, the key the success in a PQL model is that the user has to be able to clearly see the value in moving from free to paid versions. As anyone who works in open source will tell you, this is really hard to get right.
In August of 2016, we launched new pricing and packaging to support our PQL model. We had previously based our pricing on access to specific features, for example, the ability to access an enterprise database like Oracle. But we heard from users that restricting features made it difficult for users to figure out if RapidMiner was the right tool for them, so we made two changes:
We included all features with the Free edition of RapidMiner Studio.
We simplified pricing to scale along two dimensions: the amount of data you can use, and the ability to speed up RapidMiner Studio by using more logical processors.
This model let everyone use all of the features of RapidMiner Studio for free, and as users progressed from prototyping models to putitng them into production, the pricing step-ups made sense.
Bottom line: the PQL model works
Twelve months into our PQL journey, we’ve seen some really great results. We doubled monthly active users even though we spend almost nothing on user acquisiton. We’ve lowered CAC, and increased LTV.
Why? Because our funnel is full of users who have discovered they like RapidMiner well in advance of signing a deal with us, and often before they engage with us at all.
Build great products, help people use them.
(by the way, I really don’t hate the MQL; I just hate that the definition of qualified became so unscientific and drove bad behavior. More on that here.)
I’ve received 5 emails this week from vendors extolling the virtues of ABM. I’ve been invited to one dinner, two lunches, received a $50 Amazon gift card, and was told by Marketo that “According to 97% of marketers, account-based marketing (ABM) achieved a higher ROI than other marketing initiatives.”
Everyone is “flipping their funnel” using Account Based Marketing and I’m missing out. Or am I?
Ok. Let’s say I buy that number from Marketo (or something close to it). That still doesn’t mean that Account Based Marketing is right for me. Maybe I’m a proud member of the 3% who think ABM is probably great for lots of organizations, but not for mine? Note that none of those BDRs who invited me to dinner tried to make the case why my company (RapidMiner) would benefit from ABM in the first place.You know you are at the top of a hype cycle when its acceptable to market “the thing” — and not what the thing delivers, or why you should care.
The truth is that really great companies almost never follow someone else’s playbook, at least not verbatim. Salesforce, Slack, Atlassian, and HubSpot, didn’t follow trends, they created them. They went right when everyone else was going left. They were the 3%.
The ABM phenomenon got me thinking about what makes marketers so susceptible to trends? Maybe it’s that we like being marketed to? We appreciate masterfully executed campaigns like Flip my Funnel and Account Based Everything. We certainly like belonging to a tribe — being part of a movement. Ever been to the Dreamforce or Inbound? There’s clearly comfort in numbers. There’s nothing inherently wrong with following a trend, but it’s almost never as easy to pull it off as the trend-makers make it seem.
For example, how many “Appropriate person?” emails have you received+deleted this week? I wouldn’t know, because I created a rule to delete them a long time ago.
The book Predictable Revenue by Aaron Ross taught this approach to outbound sales teams and it absolutely worked for many of the most successful tech companies on the planet — until it didn’t. By then, the trend makers had already moved. on while the trend followers continue to blast templated emails to tuned-out audiences like me to this day.
But trends come and go. Ask anyone over 40 how tech marketing worked before AdWords and marketing automation, and it will sound a lot like ABM. Tech marketers in the 90s and early 2000s didn’t have the luxury of the low cost distrubution channels that we have today, so focusing on accounts was the only way to go.
I liked ABM better when it used to be called marketing.
Sure, it was much harder to do ABM then, and the advent of all the new ABM companies make it much easier to do ABM at scale today. Still ABM isn’t new, and it worked then for the same reasons it works now.
Look, I’m not against ABM or any particular marketing tactic. Brandon Redlinger of Engagio lays out some great advice for organizations considering ABM. I’m just against flocking to a trend because everyone else is. There aren’t any growth shortcuts or get rich quick schemes. As I’ve said before, study these trends. Learn from them. Be inspired by them. Implement some of them. But don’t blindly follow them just because you think everyone else is.
Marketing personas are those fictional people with the clever names like Statistical Stephen at RapidMiner or Marketing Mary at HubSpot. Personas are formed through extensive quantative and qualitative research, and who represent the ideal prospects for your product.
Goofy names aside, complete getting alignment across your target personas and more broadly across your entire customer segmentation strategy is perhaps the single most important thing to get right at a growth tech company. But what often happens is that the whimsical personas created by marketing never really leave the PowerPoint slide they were created on, and aren’t truely embraced by the entire organization as they should be.
See if this complete fictitious scenario sounds familiar at your company…
Marketing is asked to update the core company personas, so they go out and do extensive customer research and come up with three primary personas the company should be targeting. They develop differentiated messaging for each that eloquently connects customer need back to the product. Playbooks are created, sales is enabled, and demand is generated. So far, so good.
But sales isn’t totally bought in. They watched the training session from marketing, and while they found some of the material and persona work to be helpful they have a quota to hit this quarter. So, they continue to go after prospects who don’t really fit the personas defined by marketing, perhaps brands they recognize, companies a rep has sold to in the past, or maybe the sales team is organized by verticals that are no longer a good fit. For whatever reason, sales isn’t fully aligned so they continue to chase a different set of targets than were identified by marketing.
Meanwhile, customer success was unfortunately not involved in the marketing persona definitions. Had they been, they would have pointed out a fatal flaw in the persona development: that one of the target personas has a high churn rate. The persona looks like a great fit from an customer acquisition perspective, but when you follow the persona through renewal and expansion, signing them up is just not worth the effort.
Finally, product and engineering continued to build product and shape the roadmap through entirely different conversations with sales, marketing, and customer success. They may even have their own persona definitions outside of marketing.
None of this happens at your company because you are fully aligned, right? Yeah, probably not.
As I mentioned before, I believe that getting alignment across the entire organization on customer segmentation is the single most important thing a tech company can do to scale. And the CMO needs to be the change agent that gets everyone — marketing, sales, product, engineering, customer success — on the same page, and keeps them there.
In the early days of HubSpot, they sold to two primary personas: Owner Ollie, who represented HubSpot’s really small (< 10 employees) market segment and Mary Marketer, who represented someone in the marketing department of a larger SMB company.
For years at HubSpot we debated our target market persona. We had one camp that wanted to build our offering for Owner Ollie, a small business owner with less than 10 employees and no full time marketer. We had another camp that wanted to build our offering for Mary Marketer, a marketing manager who worked in a company between 10 and 1000 employees.
I was a HubSpot customer during the Owner Ollie days. The product was a jumbled mess of SEO and social tools with a touch of email marketing, landing pages, and reporting mixed-in. You could see there was massive potential, and the product was iterating fast. But still it was confusing to me, because as the CMO of a 250 person tech company at the time I had a much different set of needs than the owner of a plumbing supply store somewhere in the Midwest.
For HubSpot to thrive, they had to choose and eliminiate the optionality tax. And they chose Mary. Here’s how Brian Halligan describes the magic that came through focus:
By picking Mary, our marketers could now build content that attracted her and stopped watering our blog (and other assets) down with business owner content.
By this time, HubSpot already had an army of content creators, and now they were entirely focused on the needs of Mary. This let HubSpot distance themselves in the crowded space of content marketing best-practices.
By picking Mary, our sales reps only were rotated leads from companies between 10 and 1000 employees (lead scoring works, btw), honed their value proposition on how to help Mary grow, and largely forgot about Ollie.
Sales immediately got onboard with the Mary decision, simplying their qualification and narrowing their messaging approach.
By picking Mary, our product folks could laser focus on delighting Mary and stop splitting the baby on the UI and feature set they were building for both. If someone suggested an Ollie feature, they’d simply say “no” and move on — no more hand wringing.
The product team could focus on improving the user experience and addressing the feature gaps that prevented HubSpot from selling to more Mary’s.
And lastly because they were so focused on the needs of Mary, it led to a huge decrease in customer churn and got HubSpot over the magical 100% revenue retention number that is so important for high growth SaaS companies.
The Marketing Mary decision at HubSpot fully aligned marketing, sales, customer success and product. The results speak from themselves: every single metric went up through complete alignment and the focus that came with it:
So how do you get a company fully aligned and keep them there? It takes hard work. Personas aren’t a “one and done” activity. The can’t just exist in a PowerPoint slide or a printed picture that hangs on a wall. The CMO must constantly keep them updated and relentlessly focus on making sure the entire organization remains in agreement on the qualitative and quantatative measurements of what makes a good persona for your company.
Tomorrow, as more marketers will be measured on the health of the overall ARR pool, they will be focused on cost-effectively generating not just opportunities-that-close but opportunities that turn into the best long-term customers. (This quadrant helps you do just that.)
And that’s exactly where we need to be.
Here’s some additional reading the topic of segmentation and personas:
Microsoft Teams is set to take on the new breed of collaboration apps like Slack and Hipchat.
Each collaboration area is called a Team — and each Team can have multiple channels. Within a channel you have all the basics like chat (with emojis!) and document sharing, but it really gets interesting when you connect Teams to other applications. Microsoft Teams launched with a bunch of connectors to popular apps like Trello, Jira, Zendesk, and many more — but it’s really easy to integrate almost anything with Teams using Zapier and Webhooks.
Webhooks are a type of event-driven API that lets you push and pull information between different types of apps. Lots of popular applications support Webhooks, including both Slack and Microsoft Teams. My objective was to create a channel for my marketing team at RapidMiner that would let me aggregate customer feedback — the NPS data we capture from SurveyMonkey.
The first step is to add a Webhook to your Microsoft Teams channel. You’ll give the channel a name and a custom logo. Then your Webhook will provide a unique URL to receive the information you push from other apps like Zapier:
Now that you have a URL for your Webhook, you can use Zapier to start pushing information into your Microsoft Teams channel.
Starting with my SurveyMonkey example, you’ll use the built-in SurveyMonkey Zapier trigger to start the Zapier process.
Then you’ll use “Webhooks by Zapier” to publish the chat transcript to Microsoft Teams. I prefer to use the Custom Request type for its flexibility. More on that later.
Now select the POST method and then add the URL of your Webhook. The Data section is where you’ll configure the messaging what you want to send. Since we selected Custom Request, we need to format the JSON using the Microsoft Teams Card format.
I recently came across a lead scoring article on the Mattermark blog that reminded me of a post I’ve been wanting to write for a while: the way nearly everyone is doing lead scoring is totally wrong.
In the modern era of data-driven marketing where marketers boast about being able to connect every penny of marketing spend to revenue, we are using nothing more than gut instinct and anecodotal feedback to figure out the best leads to pass to sales. The main culprit for this data-driven nightmare is the way lead scoring is implemented in marketing automation systems like Marketo and Pardot.
For example, here’s how lead scoring currently works in Pardot: at the system level, you can assign points to specific actions like email opens, page views, form submissions etc.
You can also add points as a completion action to things like form submissions to weigh specific types of actions and content more heavily than others; like maybe an analyst report or a specific webinar.
The idea of course is that now we can pass the highest scored leads to sales, and that there is a correlation between the lead score and likelihood to buy.
But as Mike Volpe points out the way we assign “points” makes absolutely no sense, yet somehow it has become accepted as the gospel of modern lead management best practices.
I have been on a 5 year rampage against the "we give 10 points for VP title" method of lead scoring. Why not 11 or 9 pts?
It turns out that accumulating points is actually a terrible way of predicting an outcome, leading to marketing passing horrible leads to sales; like the serial webinar attenders (you know, those people that come to EVERY SINGLE WEBINAR you run) and habitual email openers— instead of the people most likely to actually buy your product.
It’s likely that much of the benefit of manual lead scoring comes from the placebo effect of telling sales that you are only passing them the best leads. So in turn they work them more exhausitively, and you’ll get better results than the unscored leads of the past that sales would mostly ignore. But that doesn’t mean they are better quality leads. They could actually be worse and you’d never know it.
Don’t believe me? Here’s an A|B experiment you should run immediately:
Take 10–25% of your lower scored leads using your current lead scoring model and start passing them to sales. The leads should appear like the rest of the higher scored leads(MQLs) you are currently passing to sales, and don’t tell anyone so there is no bias on how the leads are worked. Make sure you can identify leads in the experiment group against the control group.
In a few weeks after your sales team finishes following up on the batch of leads, compare the two groups using whatever conversion metric you are using. Now did the higher scored leads convert better than the lower scored leads? When I ran this experiment at my last company they didn’t — and the lower scored leads converted at a slightly better rate than the higher scored leads. Oops.
Building a lead scoring model by assigning random points to actions and attributes of leads is just about as un-data driven as it gets.
The solution is to build a lead scoring model based on a proven mathemetical model that will really tell you the features — or attributes of a lead — that have a statistically significant corrleation with the outcome you are trying to predict e.g. people who buy your product. Unlike the randomness of assigning points to specific behaviors and attributes of a lead, a predictive model will give you a statistical measure of which features actually matter the most.
There are predictive marketing products that will do this for you — like Infer, Mintigo, and Everstring. But they come with a hefty price and are overkill for many companies. You can get started for free using tools like RapidMiner Studio or even good old Microsoft Excel.
The first problem you’ll need to tackle is getting access to clean data. Predictive lead scoring is mostly a “wide data” problem; you want as much data as possible about your users to uncover the specific features that have the most impact on closing deals. This means combining data from your CRM and marketing automation system, hopefully your product, and perhaps even external APIs. But chances are the data from your CRM and marketing automation system is clean enough to get started.
Once you have the data, you’ll model it using a variety of machine learning techniques, and most likely you’ll start with some form of regression. I won’t attempt to explain the math behind regression here, but if you are interested here’s a good overview from RapidMiner founder Dr. Ingo Mierswa.
Here are two resources for getting started with either Excel or RapidMiner Studio for free:
This video from Ilya Mirman, the VP of Marketing at OnShape, shows you how to build a predictive lead scoring model in Excel using linear regression. Okay fine, Ilya is a Stanford-educated engineer and MIT MBA, but the approach he outlines is something even mere mortal Excel power users could figure out with a little bit of effort. If you can do a VLOOKUP, you can try this.
With a bit more effort you could download RapidMiner Studio, which will help you both prepare your data and build your predictive model. RapidMiner Studio provides far more options for modeling than Excel, and will help you get a more accurate predictive model. The current lead scoring model we’re using at RapidMiner was built by my colleague Thomas Ott, and here’s a webinar where he walks through how we built the model complete with a sample of our data and the model we use today.
Regardless of which tool you use, you’ll get a result that looks something like this — a weighted view of the lead attributes that actually result in more deals.
For example, in our RapidMiner lead scoring model. the number of product starts was the most important factor in predicting a purchase, and leads from Netherlands were more likely to close than any other country.
We used RapidMiner Server to automate adding our predictive lead score to Salesforce, but even a simple Excel output of your weighted attributes is enough for you to make those marketing automation point assignments using mathetically-sound principals instead of educated guesses. And that’s a huge step in the right direction, and you didn’t even have to spend a bunch of money on a predictive lead scoring product to make it happen.
TL;DR marketing to developers is hard, and you are probably doing it wrong.
The unstoppable rise of the developer
My former Acquia colleague David Churbuck introduced me to RedMonk’s Steve O’Grady and his 2014 book about how developers are taking over the world, called The New Kingmakers. The idea is that successful companies empower developers to solve problems instead of getting in their way by dictating legacy technology and process.
It sounds obvious now, but it wasn’t so long ago that everyone who sold technology started at the top of an organization, typically the CIO, and worked their way down. Important technology decisions were made on the golf course or at the steakhouse, and companies like Oracle, IBM, and SAP sold billions of dollars of enterprise software this way for decades.
But the explosion of open source and cloud changed everything. Instead of waiting for technology to be handed down by the CIO, developers could now pick whatever best product they wanted, and quick deploy them on AWS, Heroku, DigitalOcean, etc. We even coined the term Shadow IT to describe the stealth adoption of unsanctioned technology. O’Grady captures this disconnect nicely in a Venn diagram:
So while the balance of power has clearly shifted to developers, many enterprise technology marketers continue to chase the CIO with old school enterprise software marketing tactics. Does this sound familiar:
First, we’ll create a whitepaper and put it befind a form. Then we’ll spam errr syndicate it to a bunch of opt-in(ish) email lists. Then our BDRs will call them Schedule a demo. Profit!
Ditch your traditional tech marketing playbook
One of easiest ways to fail at developer marketing is to fall in love with marketing best practices that were formed by companies who don’t sell to developers.
I’ll be honest: I’m jealous of my peers at companies like HubSpot and Marketo who market to marketers. It just seems so much easier. I know how CMOs are measured — how we buy — the language we use. I’m a good proxy for marketing to other CMOs. But I’m a horrible proxy for marketing to developers. I’m reasonably technical; I was a CS major, ran technical sales at a few enterprise software companies, and I’m currently the de-facto WordPress developer at RapidMiner. But I’ve never had to deploy code hundreds of time a day, scale a React.js application, or secure a bunch of Docker containers.
So just running the traditional one sized fits all tech marketing playbook isn’t going to work. The developer audience is particularly wary, and as O’Grady puts it:
Developers have, out of necessity, built up an immunity to traditional marketing tactics. Print ad placement doesn’t work because they spend most of their time online. Online advertising is ineffective because they block ads. Forced registration for white papers fails because they don’t care about your high level whitepapers. Media messaging is ineffective because the developers know more about the technologies than the reporters do. Analyst webinars are ignored for similar reasons. And if you throw a conference featuring your executives talking about their projects, expect your WiFi to crash as developers tune out the talk and hack their way through the sessions.
Respect the community
GitHub has millions of users. Over 100,000 users contribute to Drupal. MongoDB has been downloaded 20,000,000 times. RapidMiner has over 70,000 active users a month. The single most important factor in the growth of companies who sell to developers is the strength of the community. Even Microsoft gets this, open sourcing the hugely popular .NET framework to encourage even more adoption.
But successful developer communities aren’t built by marketing, and sometimes happen in spite of it. They almost always form organically around a product/project that developers love to use, combined with a a shared sense of purpose by the community to do something meaningful.
The danger comes in treating your developer community like a CRM or marketing automation system. Don’t expect that you can convert them with a lead form, “nuture” them with emails, harass them into taking a demo, and close. This approach works to a point, but it won’t the create the kind of sustainable value that comes from having a world-class developer brand.
Go into your developer marketing efforts knowing that many of the positive effects of building a strong developer brand are frustatingly hard to measure. But at the end of the day, developers only really trust other developers. You’ll have to have some patience to get the measurement right, and have conviction in the connection between longer term brand investments and the advocacy and revenue that comes from them.
Great marketing starts with great documentation, and deeply technical content
Your product might be the most important innovation since Sir Tim Berners-Lee’s World Wide Web, but if no one understands how to use it, you’ll quickly become irrelevant. Treat great documentation the same way you treat building a great user experience. It’s that important.
For example, Twilio, Stripe, and Soundcloud all have amazing (and up to date, that’s really important) documentation, complete with thorough tutorials across multiple languages, getting started guides, detailed API overviews, working examples, and more. Their documentation makes it easy (and fun) to use their products and APIs.
And their documentation is easy to find and use. When I ran marketing at Acquia, we had all of our excellent product documentation behind the dreaded lead form, much to the dismay of the engineering team. I argued for it, because this form was one of the best sources of “leads” without consideration for the negative impact it would have on our developer brand.
Every few months or so, Acquia’s head of engineering would ask if we’d consider un-gating the documentation. And each time I refused, armed with the data showing how many leads were sourced via the documentation form.
But I was way wrong; the kind of mistake you make when you overweight short term goals like leads with long term objectives like brand building. Eventually we did the right thing and liberated all of our great documentation and you know what? All the developers who converted via our documentation forms ended up converting somewhere else on our site — webinars, product trials, etc — if they were really interested. None of our metrics went down.
Outside of documentation, creating great developer content requires deep focus and commitment. Developers aren’t going to read your lightweight ebooks and “10 awesome ways to speed your React.js app” listicles. Your content should try to be three things:
Relevant. Is your topic relevant to your developer audience? Bring your own developers / experts / and community into the ideation process. It’s amazing how quickly you can fill a content calendar by just asking your users what they would like to read.
Honest. Marketers love to spin. We love to write about all the game-changing, paradigm-shifting stuff our products do. But developers don’t grade marketing on the strength of our superlatives, they want to know what you really do.
Actionable. Will the reader do something different or try something new as a result of your content?
For example, before the launch of Drupal 8 last year we turned a series of blog posts from Acquia’s Angie webchick Byron into the 40-page Ultimate Guide to Drupal 8. It’s still a popular resource for developers looking to move to Drupal 8, and it checks all three boxes.
Another example comes from Codeship, a continuious integration startup in Boston. With a tiny marketing team, they have built a blog newsletter subscription of over 65,000 users by providing detailed technical content on a wide range of topics. Some content is specific to Codeship, a lot of it isn’t. But all of it has been vetted for technical depth and accuracy, and is highly relevant to their developer audience.
The type of content doesn’t really matter — blogs, webinars, podcasts, etc. all can work. RapidMiner regularly gets over 2,000 people to register for our monthly webinars on data science. Andreessen Horowitz runs a great podcast on a variety of technical topics. Just make sure your content is relevant, honest, and actionable and it will do well.
As a corporate communicator, a so-called “content marketer,” I have a conflicted view of the disease as both a carrier and critic. Without casting stones inside my own house, let me just say that I fight a constant, daily war against the forces of derivative babble-speak, and think, after over a decade within the walls of corporate communications (after two spent in journalism), that I understand the source of the pestilence.
David blames our jargon-laden bullshit addiction on the symbiotic relationship between: 1) the press, and their need to oversimplify complex technology 2) industry-analysts who reward vendors who speak with a common language and 3) Google, and our insatiable need to rank for every possible search keyword.
Our cloud-based platform will enable digital transformation through artificial intelligence <- Says everybody
If you are really marketing to developers, then you need to write for them too. In plain English. Without hyperbole. And buzzwords. Developers want specifics. They want to know what you do, and don’t do, and exactly how you do it differently than whatever approach they are using today.
Take a look at your product page. Does it cover the specific technical details of your product, or does it regurgitate phrases that you are trying to rank for on Google or industry analyst-speak?
My colleague Ingo, the founder and President of RapidMiner, reminds me of this daily: there are over 1500 operators in RapidMiner Studio, but you’d never know it because we’ve buried them on our site. Our goal is to use product pages to narrow someone quickly into detailed technical documentation, tutorials, samples, etc. It shoudn’t take more than two clicks from the homepage to learn about exactly how RapidMiner does logistic regression or deep learning.
Note that the total bullshit filter doesn’t have to apply to your your mission/vision statement. It’s okay to aspire to inspire. For example, Kubernetes is “an open-source system for automating deployment, scaling, and management of containerized applications.” Yeah, that’s exactly what it is. But Nginx provides the more visionary “Flawless Application Delivery for the Modern Web”. But get to an Nginx product page, and you are one click away from the deeply technical content developers expect, like this on the Nginx Content Cache.
Lastly, if you are really the leading platform for something, you don’t really need to say it. And lets all agree to stop using “seamless integration”. There has to be a better way.
Make events a core part of your strategy, but do them differently
Developers love events. They are happy to spend their nights and weekends networking with their peers. Decisions that used to get made on the golf course are now being made over the weekend at camps, cons, and meetups. But your developer event strategy has to be more thoughtful than just sponsoring a tradeshow and staffing it with your sales team.
In some cases, you’ll have to do the traditional big tradeshows. If you sell security software, you’ll need to be at the RSA Conference because all your competitors will be there. If you are in the AWS ecosystem, you’ll probably sponsor re:Invent because of the huge developer audience. But don’t just staff your booth full of eager BDRs looking to scan “leads”. Make sure your booth is staffed with people who can answer technical questions and connect with the audience.
But there are lots of other ways to use events to reach developers without the high cost of big tradeshows.
Hold your own conference. Holding your first user conference is scary. You’ve got to build an audience from scratch. It’s expensive. You’ll struggle to get sponsors. You’re entire marketing team will be all hands on deck for months making it happen. But it’s so worth it, and it gets a little bit easier every year.
Participate in community events and meetups. The easiest way to get started with events is to find and supports the ones that are already happening. Chances are, there are already well established events happening around your product, and they would love to have someone on your technical team participate. Set aside some of your marketing budget to cover travel and arm your expert with plenty of swag.
Be creative, and have fun. You probably don’t have an unlimited marketing budget with and the ability to write a $500,000 check to become the Mega-diamond sponsor of every tradeshow. And thats okay, because brainpower and creativity scale much better than a marketing budget. Here are two good examples of creative developer campaigns:
New Relic has given out well over 100,000 t-shirts, and credits them for a lot of their early traction. Seriously. Never underestimate the impact a brilliant developer wearing your t-shirt can have on a movement.
DigitalOcean, in partnership with GitHub, runs an annual Hacktoberfest event to encourage contribution to open source. Make 4 pull requests from a bunch of open source projects and you’ll be rewarded with a fancy limited-edition Hacktoberfest t-shirt.
Why you should find a developer evangelist
Steve Francia was the Chief Developer Advocate of MongoDB, where he was responsible for the developer experience of MongoDB and led a large team of developer evangelists. He was an early employee and his evangelism team had a huge impact on the early traction of MongoDB.
What does a developer evangelist do? Their job is to lead the grassroots adoption of technology in a quest to win the hearts and minds of developers. There are lots of ways for evangelists reach developers — ranging from speaking at conferences to blogging code samples to participating in developer communities. Evangelists address the the trust gap that developers have with traditional marketing, and they provide unique insights back into the product team as they are often the closest to the users.
Whether or not they live in marketing doesn’t really matter, and they really shouldn’t. I’ve been lucky to work with two great developer evangelists over the past few years. eGandalf aka James Stout was a developer evangelist on my team at EPIServer. James was initially a customer and active participant in the EPIServer developer community forums. We hired James on the marketing team to increase engagement with our developer and partner community, through providing everything from direct mentoring and coaching to code samples and working applications for customers. James led our highly successly Office Hours program, a weekly Google Hangout covering a broad range of topics for EPIServer developers.
Even a single evangelist hire can make a difference. And the best ones aren’t made, they are found. Chances are there is someone already on your technical team who is playing this role, and would love to make the transition. So go find yours.
Marketers like to claim that we’re data driven, but are we… really?
Sure, we track our lead conversion funnel from acquisition through conversion to paid customers. We use campaign attribution to figure out where to invest our budget to generate the highest return. We personalize our emails, A|B test websites and landing pages, and create beautiful reports in Excel or Tableau proving our contribution to growth. Data certainly isn’t the problem. From Salesforce and Google Analytics to DMPs to enterprise-scale data warehouses and data lakes, marketers have more data than ever and plenty of ways to report on it.
The real challenge is still turning data into “oh shit, now what do I do now?” And because that’s hard, I think most of what we end up doing is making data-informed decisions — using data to reinforce our intuition and prior experience. Certainly a positive step forward from Mad Men marketing where an unknown half of marketing spend was wasted. But being informed by data is something very different from being driven by it.
If we’re honest, we’re missing the most important part of the data-driven marketing equation; the part that separates us from our own bias, uncovers the hidden insights not visible in pretty charts and graphs, and most importantly reveals the mathematical truth behind the decisions we’re making.
The data science.
Data science already sits at the center of many innovative organizations. For example, Alphabet created Google Brain, a research team dedicated to solving hard problems around deep learning and artificial intelligence. While mostly a research organization, some of the innovations from the Brain team have already made their way into consumer products like Google Photos. Tesla has analyzed over 100 million miles worth of autonomous driving data, using data science to build self-driving cars. Netflix uses data science to figure out what TV shows to produce.
Building Your Data Science Team
I see the data science team as an evolution of the marketing operations function, who are responsible for marketing technology, processes, and analytics. The head of marketing operations is often thought of as the Chief of Staff for CMOs, and is a natural home for data science efforts in marketing.
While there are lots of different titles for data science, there are two primary sets of skills you’ll to add to the marketing operations team:
1)Data scientists blend machine learning and business acumen to drive marketing teams to actionable learnings. They are responsible for formulating a growth hypothesis and then prototyping, validating, and deploying predictive solutions into the business. Common skills include expertise in machine learning and statistics; proficiency in predictive modeling tools like R, Python, and RapidMiner; data visualization and storytelling; and the ability to translate business requirements into testable hypothesis. Here’s how AirBNB hires data scientists.
2)Data engineers tackle the complexities of access to data, handling the infrastructure and tooling for the data scientist team. Marketers continue to drown in data, and this role helps ensure data scientists have access to the complete picture of a customer by connecting data across hundreds of structured and unstructured sources. Common skills include SQL/NoSQL database systems, data modeling and ETL tools, data warehouses, and Apache Spark.
There’s no doubt that data science roles are hard to find and expensive to hire. And the problem is only going to get worse in the next few years, as organizations scramble to recruit data science talent. McKinsey predicts that by 2018 demand for data scientists is projected to exceed supply by more than 50 percent.
Three Marketing Data Science Projects to Start Right Away
So you’ve decided to invest in building data science team — great decision! Here are the first three projects you should look at:
1. Use machine learning to score leads. Existing approaches to lead scoring are mostly based on gut and instinct, causing too many unqualified leads to pass through to sales and while better qualified leads sit untouched. A data scientist can combine data from all your sources — CRM, marketing automation system, product usage, social media — and then train a model to predict leads that turn into “Closed Won” opportunities with the highest frequency. If you are doing Account-based Marketing, you can score accounts in a similar way. Here’s where you can learn more on how we recently implemented predictive lead scoring at RapidMiner.
2. Prevent customer churn before it happens. Churn applies to every company with a recurring revenue stream. A data scientist can look at all the attributes of a customer (called features) and help identify the specific ones that predict someone is likely to churn. Then we can proactively target specific offers to the customer before they churn. Here’s a great article from David Skok on the financial impact of minimizing churn.
3. Use clustering to segment customers and personalize offers.Dominos Pizza uses over 85,000 structured and unstructured data sources to segment customers, allowing individual stores to tailor coupons.
So Can’t I Just Buy a Predictive Marketing Product?
Absolutely not. Data science is too important to be outsourced to a product. For example, at my previous company we deployed one of the most popular predictive lead scoring products and found that:
The data science was a black box. We knew which leads were better, but not why.
Every time we wanted to tweak the predictive lead scoring model, we had to wait for the vendor. Changes took months.
Each new use case for data science required purchasing a new product. For example, we wanted to look at building a predictive model to identify targets for our Account Based Marketing program, but it required purchasing a separate product.
But most of all, predictive marketing products can’t replace the curiosity and creativity of a skilled data scientist.
They provide the insight behind the action. They know how to formulate and prove a hypothesis. They understand the difference between correlation and causation, and how to prove it. Machines still need to be taught how to learn, and the black-box approach of predictive marketing products removes the humanity that is still required to deliver breakthrough data science.
I’ve been using Sonos since 2005, when I wanted to add whole-house audio to a new home I had just purchased. At the time, multi room audio was a complicated mess — full of legacy companies requiring extensive wiring and proprietary controls I didn’t have. Sonos was exactly what I needed, so I took the plunge. Here’s a screenshot of the Sonos community account I created shortly after becoming a customer:
Sure Sonos was expensive, and buying a bunch of hardware from a tiny startup was risky — the life an early adopter. But it paid off, and 11 years later I’m using my Sonos more than ever. The company has become the model for everything that is right about building a modern consumer electronics brand. Here’s why:
It just works.
When Steve Jobs would talk about Apple products, he would always talk about how they just work. While most would argue that’s no longer the case with Apple, it certainly has been for Sonos. You never have to reboot the devices, or rollback an update, or workaround annoying bugs. They always do what they are supposed to do, and have since the very start.
In a time when we’re expected to replace our phones, TVs, and other gadgets every few years, it’s nice to see hardware that was built-to-last. My Sonos devices are by far the most reliable home electronics gear I own. They. Just. Work.
It gets better. For free!
I’m still running some the same ZonePlayer 100 devices I first bought in 2005, and they continue to get better with fantastic software updates. Sonos has been great about adding support for streaming music services. They were early adopters of Spotify, and moved pretty quickly to support Apple Music. And the iOS + Android apps improve with each update, including the most recent one that lets you control Sonos via the iOS lockscreen.
To the best of my knowledge, Sonos has never released a feature that doesn’t work on their old hardware. They easily could, and would make more money by doing it.
It does one thing amazingly well.
Sonos never lost focus on audio. I’m sure they’ve considered expanding into video and other things, but to date they haven’t. The clarity of focus is what has let Sonos continue to stay well ahead of competitors like Apple, Amazon, and Google, who all offer some form of multi-room(ish) streaming devices.
My only feature request
Sonos, if you are listening, I only need one thing: embrace the Amazon Echo. Your hardware and software combined with the Echo AI would be amazing, and I’d immediately sell my current hardware (+ two Echo’s) if you had it.
In the 80s, IBM dominated tech from the desktop to the datacenter.
Buyers often picked IBM because they were safe choice, not the right choice. It didn’t matter. Buying IBM became the accepted best practice for CIOs. It was an emotional decision, not a rational one. People generally don’t like taking risks, and IBM was the easy, safe choice. Of course this mentality led to high costs and failed IT projects, but at least no one got fired making a decision to buy IBM. Or did they? More on that later.
Study these best practices. Learn from them. Be inspired by them. Implement some of them. But don’t blindly follow them just because you think everyone else is, because that makes them just average practices.
For example, the current BDR tactic du-jour gone wrong — the meme-laden breakup email. I know breakup emails sometimes work; they certainly got my attention when I first started getting them. But they are no longer fun or funny when I get tens of them a week.
Don’t follow the playbook. Be the playbook.
Truly great companies almost always pave their own way. They take best practices and make them even better practices.
The difference between copying a playbook and being inspired by one is understanding. If you really understand the problem you’re trying to solve, and there’s someone else doing it better than you, then by all means copy their idea but do it better. Make it yours. Good artists borrow, great artists steal.
For example, Salesforce re-invented growth for the SaaS era, as explained in great detail (111 plays!) by Marc Benioff in Behind the Cloud. Box later took the Salesforce playbook and adapted it to their land+expand freemium model. Companies like Slack and InVision succeed with a relentless focus on building beautiful, usable products, matched to a sales and marketing model that’s about eliminating friction in the buying process, not creating it.
But if you are implementing a best practice just because it’s the new thing that all of the hot startups and thought leaders are writing about, then take a step back and study the problem more or you’ll probably end up with something much closer to average than best.
In the end, people actually did end up getting fired over buying IBM. The 90s saw the accelerated rise of companies like Microsoft, Oracle, Intel, and eventually open source. Companies who held on to the IBM status quo for too long were exposed to competitors who could do things better/cheaper/faster with superior technology. The safe choice suddenly became the risky choice. The best practice became the average practice.