Brent Sleeper

Former vice president Dick Cheney has died. I was no fan of his actions and influence while in power. And yet his daughter Liz Cheney’s principled stand against Donald Trump suggests his private role as a father left a different kind of mark. It shows he—like all of us—was more than a public persona and official actor. A piece accompanying Cheney’s obituary in the Times about his stubborn (and perhaps intentional) anti-style hints at a bit of both the personal and the official.

Mr. Cheney was about as ostentatious as an I.B.M. accountant and seemed destined to work in Washington from birth. His unremarkable style also played into his critics’ claims that Mr. Cheney was a wolf in a prosaic suit.

I support the principle of independent, non-partisan districting commissions, and I hate that California’s #Prop50 is necessary. But now is the time for realpolitik. Vote!

Maybe San Francisco’s “I Voted!” sticker will help the medicine go down. The cheerful design features parrots, a sea lion, California poppies, Sutro Tower, the Golden Gate Bridge, and of course Karl the Fog.

Post by [@brentsleeper@sfba.social](https://micro.blog/brentsleeper@sfba.social)

View on Mastodon

They don’t design #Strands like Saul Bass and Paul Rand used to.

I share my daily word game results in rapid-fire posts on Mastodon. I’ll include a quick pun, wordplay, or topical reference that hints at the day’s puzzle. Sometimes, I’m too on the nose and spoil it for people. (Sorry.) Mostly, I’m just obtuse and no one understands what I’m going on about. Welcome to my timeline: Come for the trenchant observations, flee with dismay when I flood your timeline with this noise.

So, Strands is The New York Times’ daily riff on classic word-search puzzles. Find several themed words in a letter grid, all connected by a “spangram” that describes the category. It’s a pretty simple game, and I try to marginally up-level the difficulty by finding the spangram (🟡) first.

Usually, a brief social share is all I need to feel I’ve accomplished my day’s duty. But once in a while, I get wildly sidetracked by what the puzzle and my silly, one-line commentary bring to mind. Yesterday’s was one.

A Little Too Iconic. And Yeah, I Really Do Think

The theme (spangram: “ICONICLOGOS”) activated the part of me that loves thinking about brand design. You know I always wanted to pretend to be an architect. “Iconic” is overused to the point of triteness when talking about design, but the puzzle’s answers don’t lie: BULLSEYE, SWOOSH, ARCHES, APPLE, PEACOCK, and SHELL.

After posting my quip on Mastodon about the Strands puzzle, I was kind of shocked to learn that none were designed by the mid-century design legends Paul Rand or Saul Bass. But the influence of Rand, Bass, and a few others among their peers on how we think about branding and corporate identity today is absolute. The designers’ collective work for IBM, ABC, AT&T, United Airlines, and seemingly every other capital-C corporation proved that the right symbol can encompass and convey a company’s entire worldview.

You definitely can see that lineage in today’s puzzle grid. Most of these are descendants of earlier, fussier marks. They’ve been successively simplified to minimum forms that embody clarity, memorability, and assertiveness.

• Target’s bullseye and Nike’s swoosh focus on bold movement and action.
• McDonald’s arches and Apple’s fruit are drawn with curves that simultaneously are idealized and somehow humane.
• NBC’s peacock and Shell’s scallop employ visual rhythm and the strong presence of color to balance geometry with warmth.

Those qualities reflect a shared inheritance from Rand and Bass. They were contemporaries, but their styles were distinct. As far as I know, they never collaborated on a project. I deeply admire Rand’s work, but Bass was perhaps a more flexible designer. His style, originating in film title design, was varied and evolved more obviously as stylistic mores changed over time.

That’s No Moon

I always had thought Rand designed the Bell System logo of 1969—a perfect circle enclosing a simplified bell, embodying mid-century faith in geometry and order. It spoke of authority and technological certainty, as consistent and rational as the monopoly it represented. As a child of the 1970s, that Bell means “telephone” to me in a way nothing else does. But it was Bass’ and team’s work, and the story doesn’t stop there.

In the wake of Ma Bell’s antitrust breakup fourteen years after his original design, Bass was asked back and given a different remit. For the new AT&T, he developed a forward-looking blue globe to signify the change; his old Bell System logo was relegated to the divested, staid regional bell operating companies.

Saul Bass — Bell System (1969) Stable, centralized, communication as institution.

Saul Bass — AT&T Globe (1983) Dynamic, connected, communication as movement.

Bass’ new design used deceptively not-quite-geometric, hand-drawn blue bands that suggested pulses, connection, and communication. It encapsulates a hallmark of how his style evolved over the decades: a sense of movement in a logo that didn’t want to be stamped in concrete or embossed in relief on a product assembly line.

And there’s continuity, too; both perfectly round, both in the same blue. But I’m not sure Bass’ 1983 globe can stand on its own without the “AT&T” lockup. His 1969 bell certainly did.

That former Bell System logo was solid and Platonic: communication as institution. Bass’s blue globe was dynamic and a bit off-center: communication as movement. The swap mirrored their eras. The aesthetic of the 1960s corporation told us to trust in the system. 1980s marketers encouraged us to look forward with expressiveness and change.

40 years on and after a reverse merger in which one of AT&T’s progeny devoured its mother, updates to the AT&T brand have kept Bass’s core idea, but each iteration has been far less durable, employing gimmicks like 3D renders or a coat of faux reflective gloss. The current logo by Interbrand is a digital beach-balling of Bass’s globe. I’m not a fan.

You also could argue that the typography of the AT&T wordmark that accompanies the globe follows the same path: from the assertive Helvetica, to a somewhat more conversational AT&T Gothic, to the assuredly transient ClearviewATT, Omnes, and AT&T Aleck.

The More You Hear, the Better We Sound

Some links to how these marks have been tended and mythologized:

• Apple: For a company that tightly controls branding at every layer of its customer experience, Apple doesn’t make it easy to find much about its official logo, though it’s happy to help you be a better writer. More interesting is Arun Venkatesan’s find of the company’s 1987 brand identity guidelines.
• McDonald’s: The company shares some corporate logo assets, but I don’t see any detail on the company’s design history. This page will have to suffice.
• NBC: Design boutique Chermayeff & Geismar & Haviv have a case study focused on the modern brand iteration from eleven feathers and stylized letterforms to a more idealized fan of color.
• Nike: The Nike Department of Nike Archives Department published a sanitized version of how the company parleyed a $35 freelance design project into $26B in brand equity.
• Shell: The Shell “Pecten” is a direct evolution of a century-old design. The modern logo, upon which I imprinted in late-1970s Lego sets as a kid, was developed by Raymond Loewy in 1971.
• Target: The company’s corporate history timeline features the very mod original 1962 logo. And here is the modern bullseye in every shade of red they’ve ever approved. Which is one.
• AT&T/Bell System: The Bell System Memorial fan site features a succinct summary of the Bell brand history, while the Internet Archive has saved a wealth of Bell System design standard documents, not least of which is the 1970 Bell System Graphic Standards Manual. The company’s own “History of AT&T Brands” and “Evolution of the SBC and AT&T Brands: A Pictorial Timeline” document the party-line history, post-SBC/AT&T re-merger, but seemingly not updated since 2005. And The Atlantic tells the story of “The Film That Changed AT&T’s Logo.”

Step into my time machine, won’t you? I’m setting the dial for November 5, 1955…October 26, 1985…Ah, here we go: April 3, 1995: Amazon.com sold its first book, and the retail experience was about to be transformed forever. Now, truth be told, while the novelty and convenience of ordering online was immediately apparent, the original customer experience on Amazon was pretty rough around the edges. I doubt the booksellers at Barnes & Noble or Borders gave it much notice. Hindsight’s 20/20, but we know how that turned out.

So, no question that e-commerce changed the game. But neither has it been the extinction event for brick-and-mortar retailers that some predicted during the dot-com era. Consider premium shopping neighborhoods, where luxury stores retain undisputed brand status. The cachet of an Hermès Birkin bag is explained by the experience of securing one as much as by its tangible qualities. And on the other end of the price spectrum, stores like Uniqlo are succeeding by combining value with highly appealing design and in-store experience. 

Who’s been left out? A lot of mid-market chains that didn’t develop a distinctive customer experience, but instead grew by dint of being the default choice at shopping malls. But guess what? When it comes to convenience and cost structure, it’s impossible to beat online, and without a compelling customer experience, a number of undistinguishable brands very quickly became also-rans.

The unique ritual of finding a Birkin notwithstanding, another aspect of thriving sellers is that they embrace commerce on their customers' terms. The notion that retailers need to integrate their various online and offline channels is hardly new, but consumers are changing their expectations far faster than many retail businesses realize. For all the industry talk of omni-channel, customers care less about the means—the channel—and more about the end—the experience.

That’s not to say the ability to market and to conduct commerce across channels isn’t critical. Of course it is. But cross-channel coordination is just part of delivering the experience customers expect and reward with their shopping behavior. As Deloitte noted, “winning online is not just about getting e-commerce right. It’s about building a cohesive, consistent, and compelling experience across all touch points in the customer journey, both online and offline.”

I’m going to repeat that last part: the customer experience crosses all the touch points in the customer journey, not just the moments explicitly devoted to shopping. Throughout, there are short-lived opportunities for a business to engage with a customer in just the right place, at just the right time. Maybe it’s in a store, perhaps it’s online, or maybe it’s somewhere well outside the expected retail context.

Those “perishable moments” are fleeting, but they can be a powerful driver of great customer experiences. They’re a chance for a business to deliver a message that’s a nearly pure expression of the classic four Ps of marketing. 

The medium of those messages—email, texts, in-app notifications, or some other mechanism—will vary, though implementation details do matter, so that the message that’s sent is optimized for the user’s context. Effective marketing has got to reflect a deep empathy for the customer’s experience, driven by authentic understanding, true one-to-one personalization, and real-time feedback and analytics.

And that’s where we as an industry still have significant room for innovation (and a lot of work to do). But if we get it right, we can enable an entirely new level of responsiveness to customer engagement and empower businesses to deliver truly great customer experiences.

(I originally published this post on LinkedIn.)

A study released earlier this week (Narrator: It was 2003.) says web services are slower than many native protocols. It doesn’t matter. Simplicity and interoperability almost always trump raw performance.

The study’s sponsors have a horse in the race, of course—selling software built on those high-performing native protocols. They say, “If we’re inside the firewall, why rely on HTTP, which is a relatively slow protocol? Why do we have to parse all these verbose payloads? We know and control what’s at the endpoint—maybe right on the same box.”

And while we’re at it, why not also write these applications in assembly language?

The reason is simple: absolute performance matters in relatively few applications. In those cases, yes, optimize for a particular stack. In the rest, don’t. Barring specific requirements, simplicity and interoperability always trump raw throughput.

Something I learned from a childhood hobby—model trains—illustrates this point. When you think about toy trains, what do you imagine? If you’re like me, I bet you picture old-fashioned steam locomotives circling the track on the floor. And there’s a reason for that.

Steam traction powered railroads for more than a century after their invention. By the 1930s these massive engines could drive trains nearly 100 mph and haul vast quantities of freight. Yet within a decade after WWII, the steam fleet had been replaced by diesel engines that, in absolute terms, didn’t equal the peak performance of their predecessors until the late 1960s.

Why did railroads make such a rapid transition to what was, by all initial measures, a lower-performing technology?

The answer is simple: the gearing and engines that powered top-performing steam locomotives had become so complex that they simply cost too much to maintain. Diesel locomotives required a vastly simpler physical plant. Replacing a steam locomotive with a somewhat lower-performing—but far easier-to-maintain—diesel engine was an easy business decision. Reduced costs for parts, maintenance staff, and downtime created a more productive, flexible foundation that kept railroads competitive with new rivals such as the trucking industry.

Today we see a similar cost-benefit dynamic in software platforms. So, web services are slower than (insert your favorite protocol here). It doesn’t matter. Their performance will improve, but the benefits of simplicity and interoperability deliver far more real business value today than raw speed ever will.

Dealings between sales and marketing are a lot like any long-term relationship. There will be moments of passion when business is booming; at other times, it will seem like the process has become a comfortable routine. And then there are the periods of resentment and shouting matches when it feels like nothing’s working and communication has broken down. But nothing dooms a relationship like building walls, tuning each other out, and accepting stagnant interactions.

While it may be stretch to look to the tech industry for advice about romance, the fastest-growing SaaS (software as a service) businesses today have at least gotten that last part right. They’re shaking up traditional roles in sales and marketing and developing a working relationship that challenges assumptions, is collaborative and, dare I say it, intimate.

You had me at “sales enablement”

In any B2B enterprise, “sales enablement” is a big part of marketing’s job. And it means just what it says: giving sales teams the tools they need to succeed. I think we can all agree that’s a good thing.

Some of that support might take shape as the crafting of buyer personas, giving salespeople profiles of each buyer who’s part of the decision path within a targeted account. Best practice guides are a sales enablement tool, too. As are demo and trial products, product collateral and pitch decks.

But sales enablement is less about the tools than it is about the strategy that guides exactly how you utilize and empower sales teams. That’s changing, as those teams now must function in a B2B technology marketing landscape where many of the old rules don’t apply. Except for one: being a good partner to your sales colleagues.

Sales and marketing’s five love languages

There’s a wide range of variation in how product marketers and product managers work with sales teams. You might think it’s better to be highly directive and controlling, with ironclad guidelines to dictate every move they make, right down to tightly scripting (and recording) sales calls.

Or you may be more comfortable being hands-off, lending positioning and marketing support but deferring to the salesperson’s own experience and native abilities to charm and cajole a prospect.

For most of us, the middle ground is the best place to be. Even then, it’s important to stay flexible and adaptive in that relationship with sales. Market dynamics and the strategies to exploit them are guaranteed to change, and sales enablement has to be one of the places where you stay agile.

Yes, a thousand times yes

What are the key characteristics of a good sales enablement program? We’ve already defined its basic definition — like a good dance partner, marketing should help sales shine. But that doesn’t come without a lot of work and practice. The most successful sales enablement practices have many things in common:

• Buyer-centrism: This is the most important because your sales process must always make the buyer the center of your attention. So you’ll want to always know what resources will be of the greatest value to the prospect at key points in their journey.
• Training: Whether you’re using a dedicated training program or collaborative tools, making sure sales teams know how to leverage the resources you’re giving them is a prerequisite for success.
• Great intel: The more high-quality information and analysis you can equip a sales team with, the better. Give them reports on competitors and rival products, feature and benefit comparisons, links to buyer/influencer communities and sites, updates on sentiment scores and user complaints and more.
• Ease of use: The resources you give them have to be easy to access and deploy, and they must be spot-on in terms of relevance, freshness and quality.
• Accessibility: Everyone in sales should have equal access to enablement resources.
• Clear accountability: The best sales enablement programs mandate that sales teams employ available resources and track whether or not they’re being used, as well as how and when.
• Measurement: Some of the factors that get analytically scoped are sales cycle length, deal size and how resources performed as part of that cycle. Did a specific email drive trial, for instance?

You should always be reviewing and polishing these elements, so your enablement efforts never grow stagnant. Why? Because your marketplace and your position in it are always in flux, in one way or another.

Justify my love and expense account

“Halt and Catch Fire” was a prestige TV series about the early days of the personal computer and internet revolutions. The character of Joe MacMillan was introduced as a relentless ex-IBM sales guy whose gifts of persuasion were only exceeded by his drive to obtain a killer product he could hawk in pursuit of the Next Big Sale.

The old enterprise sales model meant putting all of a tech provider’s eggs in a Joe MacMillan basket. IT architectures and software products were big-ticket investments for buyers, which entailed a long sales cycle. So a salesperson needed to build relationships, work the phone, log a lot of airline miles, and slap more than a few martinis and steak dinners on the expense account.

Swipe right for data

Today, though, the feet-on-the-ground approach doesn’t work as it once did. For nearly all software providers, whether they’re global firms selling global systems or startups pushing mobile apps, it’s not cost-effective to rely strictly on the traditional sales model. There’s an eternity of difference between a mainframe giant selling an IBM System 360 for $3 million in 1966 (that’s $23 million in 2018 money) and a SaaS provider asking for a $50.00 monthly subscription, let alone an app studio charging $4.99 a pop.

Over the last several years, we’ve rolled out an all-new sales toolkit, leveraging automation and predictive analytics, AI and bots to carry much of the weight of modern IT and application sales:

• Big Data personalization is nearly old-hat by now, enabling higher-quality automated engagement with prospects; by using Big Data to personalize emails, for example, businesses see transaction rates that are six times higher, according to a 2014 report by Experian.
• Inbound marketing platforms have taken on the top-of-funnel duties for putting content in front of visitors to websites, with automated follow-ups via email or other channels.
• Salesbots powered by AI, like Drift, promise to qualify true leads among site visitors by applying “conversational marketing” to each encounter. As these systems get smarter, they’ll take on tasks from the top to the very bottom of the proverbial sales funnel. Already, many enterprises are using AI in some form or another,
• Lead identification platforms utilizing machine learning can quickly sort through terabyte-sized shoals of data to pick out the best potential leads for marketing and sales to target.
• Account-based marketing tools leveraging smarter lead gen are replacing the nearly-defunct cold call, reaching prospects with persona-based content and advertising in their social feeds and search results.

Does this mean a human sales team is an anachronism? If the example of the marketing department is any guide, probably not. The transformation sales teams are going through right now mirrors what marketers had to contend with as marketing automation systems and new media took hold.

And long before that, Don Draper was fretting that the advent of doom had arrived, in the shape of his agency’s first computer. But marketer and marketing departments are still here. Evolution didn’t kill them off; it allowed them to evolve, too, and expand what they were capable of doing.

Stand by your man or woman

With a little change management, then, this shift is going to actually benefit sales teams that are willing to adapt and also receive support that moves with the times.

In fact, the very widgets we’ve listed above are already exactly that—sales enablement technologies capable of making massive improvements in the quality and rewards of a flesh-and-blood salesperson’s job.

How? By providing one of the best possible forms of “enablement” in giving people more time to spend on the one area no AI or bot can yet emulate: human interaction with prospects and customers.

The lead-gen platform that builds real-time personas, or the web bot that sorts the wheat from the chaff within site traffic, are performing tasks at which a human being is hopelessly inefficient. The upside of that—and it’s a big upside—is that the sales team gets sprung from the tedium of pushing paper or electrons, and from employing guesswork instead of insight.

Technology will finally free them from the mundane time-sucks every salesperson in history has probably carped about as a distraction from selling.

Meanwhile, the buyer analytics provided by all these data-driven tools will give them more nuanced insights about prospects, improving the quality of those human interactions.

We’d add this, then, to our earlier list of characteristics that define the new and improved version of a great tech sales enablement program:

• Frees salespeople to sell: By leveraging technologies that liberate them from distractive and routine tasks, salespeople are given more opportunity to forge human contacts and productive engagement.

All you need is love

So, this Valentine’s week, I hope sales and marketing teams take a moment to appreciate the contributions of their mates — and then recommit to a culture of growth. That means embracing the best of what marketing technology has to offer while empowering sales teams to make the most of it.

This article originally was published at Marketing Land/MarTech Today.

I recently examined the challenges of B2B developer marketing. One area I touched on was the importance of really understanding stakeholders’ sometimes divergent “hot buttons.” That went hand-in-hand with another lesson: You’re not addressing just one target, but a whole lineup of influencers and decision-makers who have a say in the sale.

That’s because when doing any kind of B2B technology marketing, you’ve got to embrace the hard truth that one size *never *fits all when it comes to needs, value propositions and messaging.

One person’s idea of product value may be another person’s “meh,” to put it bluntly, even if they’re working within the same four walls, even on the same project. You just can’t assume your targets will all interpret your message the same way. That’s especially true when you’re trying to capitalize on marketplace trends. (That is to say, throwing out some buzzwords that sorta fit your product and hoping they stick.)

You think these buzzwords just sell themselves?

Let’s illustrate this with an example ripped from today’s tech headlines. What’s a B2B technology trend that’s on fire, where some providers might think their product practically sells itself? One that’s presumed to be on the Christmas list of every CIO, CTO and Director of Engineering? How about “microservices?”

I see you’re smiling in agreement. (Or are you smirking? It’s hard to tell from here.) “Microservices” isn’t just a bit of marketecture fluff. It’s a bit of codified shorthand that distills many of the architectural trends of the past several years. My own company’s offerings, like many of our customers’ (and maybe yours, too), are designed around a microservices architecture.

So, microservices are a real thing that real technologists do real work with. But that doesn’t mean that namedropping the term is necessarily an effective way to appeal to a B2B tech buyer. (Aha—you were smirking earlier!)

But what about focusing on the implicit functional and architectural qualities instead?

• Does your so-called microservice meet all the right mandates: small, each focused on “doing one thing and doing it well,” modular, elastic, resilient, minimal and complete unto itself?
• Is it a clean and complementary addition to their own enterprise architecture?
• Does it solve a specialized, difficult problem and deliver demonstrable ROI and payback?

That’s a little closer—you’re focusing on qualities and benefits rather than relying on jargon. But even then, going to market with the attitude of, “We’ve built a better mousetrap—isn’t that obvious?” isn’t going to move a lot of business beyond the first few customers who share your vision.

Even in the cloud, tech marketing is a lot like any other B2B relationship

If it sounds like you may be challenged to establish your bona fides on the most basic level, you’re right. Your target buyer isn’t about to make a snap decision. In fact, most aren’t in a position to make a unilateral choice much of the time.

In that way, B2B tech buyers fit the “typical” template of a B2B buyer:

• They don’t make impulse buys, but well-parsed purchases where an entire buying team might be involved, especially at a large enterprise running a sizable architecture. The buying process will have multiple stages, too, including torture-testing your pride and joy to see if it breaks.
• They’re smart and informed, and they’ve seen a zillion or two products in their time, some even pitching the same promises you are. They do copious research and have their ear to the ground at GitHub and other places where they’ll get the real skinny on you and your track record, have no doubt.
• They’re playing for big stakes, because failure can not only lose them their job but can result in their company taking a bullet, too. So they’re virulently protective of the infrastructure they’ve assembled.
• They’re harder to reach, especially the farther up the ladder you go, because real decision-makers studiously avoid taking cold calls or giving advertising the time of day. You reach them with relevance using tools like content marketing, advocacy strategies, participation in industry forums and events, and other more credible touch points.
• They respect relationships and the work you put into developing a sound and steady one with them by getting to understand their challenges and ambitions. It’s a long-haul effort, and it’s entirely about earning trust, often the hard way.

Just because they may share attributes across the board with other B2B prospects, though, you still have to customize your message and approach to suit the individual persona of each role-player who’s part of the buying process.

Another thing to remember: They’ve got the power, more than ever. Vendors, once upon a time, had more control, but the cloud blew up that paradigm. Part of what they expect from the entire buying experience you deliver is ease and convenience, too, just like consumer companies deliver. That’s why vendors with good brand recognition and easy-to-use trials beat out the competition.

All of this circles right back to where we began: Who, exactly, are you trying to convince and convert?

Who is your buyer? I mean, really?

As with terms like “microservices,” marketing and sales personas are a convenient shorthand for describing complex characteristics. But like buzzards, it’s all too easy to jump to the shortcut: “We have an enterprise buyer” or “We market to tech executives.” In reality, those personas are usually quite a bit more nuanced.

You’re obviously aiming to connect with key influencers and decision-makers. Thus, you’re obliged to do a huge amount of research, networking, social media and industry outreach to figure out who it is you need to target within each organization and what their hot buttons/pain points might be.

Remember, though, that the final decision-maker may not be the person doing the assessment and testing, and he or she may only have a momentary presence during the entire buying experience. They may kick off the process and show up at the end, but somebody else is doing the grunt work in between. Even so, you’ve still got to educate and sell them when they eventually show up.

You might be tempted to make the CTO or CIO a primary target, and that might make sense if you were selling an entire enterprise-scale microservices architecture solution to a company that’s migrating away from a monolithic approach or considering it. They’re concerned with big-picture work: How to update enterprise infrastructure without breaking the bank, planning deployment, network and system management, integration testing, risk management practices and so on.

If you’re only selling a widget, especially if it’s a comparatively small widget in the grand scheme of things, the CTO/CIO may not be the person buttering your bread, frankly. But it’s good to make sure that person has heard your name somewhere, in a good way: Attending top-tier conferences, showing up in the trades they read or doing traditional “awareness marketing” via advertising and PR can help with that.

The Software Architect is charged with articulating the vision behind whatever architecture is being deployed. He or she builds models, devises spec documentation for components and apps (like yours!) and validates and re-validates that architecture.

Depending on the company’s structure, the software architect may be a primary target, and certainly, he or she is a purchase influencer/ratifier worth keeping in the loop. But very often, they’re not going to be directly involved with initially assessing your product.

The Director of Engineering comes close to being your sweet spot, though. She or he is on the spot for ensuring proper execution to hit the company’s goals for its technology stack and has a hand in determining the tools that make it happen.

They’ve got the job because they love building things, so showing off the elegance and suitability of your app by talking engineer-to-engineer is the way to go.

The Developers underneath the Director of Engineering may be excellent targets if they’re in the right position to be recommenders or specifiers with enough juice to get your product formally bench-tested. They’re probably avid participants in the developer communities where word-of-mouth and code sharing rule, and proselytizing them can be an open door to real opportunity.

What good can you do them in return? Beyond solving a particular need and helping them build their own knowledge base, you’re giving them the opportunity to look good to their bosses—no small motivation.

Depending on your particular offering, DevOps and Security teams also are in the mix. They might be responsible for assessing your operational requirements and reliability and conducting security audits. And they’ll certainly be responsible for ongoing monitoring of your service when it’s in production.

Even in the age of the cloud, gatekeepers like Procurement or Sourcing Managers still play a role. They’re likely to at least be a formal part of the process for larger deals. They issue RFPs or bid requests, manage the evaluation process and attend to all the nitty-gritty of finalizing a contract or license.

They may (or may not) have a direct role in bringing you to the attention of others in the organization, but you should bend over backward to help them build a business case for your product, especially one that appeals to the multiple stakeholders they’ve got to satisfy.

The closer you get, the better you look

So, are these folks personas? Sure—but more than that, they’re people. And no amount of white-boarding value props can replace the power of genuine empathy and connection. That takes work, and there’s no shortcut.

Certainly, you’re working toward developing a replicable model to scale your efforts. It’s why constructs like personas and leveragable trends such as microservices are critical to B2B marketers.

But your long-term success is going to be built on actual relationships with people: prospects and customers. Forging those ties now and maintaining them throughout the years to come will bring you far more eventual reward than selling a customer a one-off app. Even if it’s a really great app.

This article originally was published at Marketing Land/MarTech Today.

We’ve covered a lot of ground thus far in terms of how to market to developers, from how to deploy content marketing to the importance of not making assumptions about them on the basis of the developers you may happen to know.

I’ve got a pretty vital word of advice to add to all of that: When you’re marketing to developers, never forget the fact you’re not just marketing to developers.

Who are you really selling to? Code or software design isn’t ever standalone. It’s part of something bigger: a product, whether it’s an app or an enterprise platform.

Beyond that, you may have to consider your potential customer’s product as being part of something even larger: the company that’s bringing it to market, or a developer ecosystem or user community built around it.

So developers aren’t your sole audience. There are others who’ll have a voice in the purchase process, and you need to figure out who they are—and how to engage them, too.

A longer journey, with more gatekeepers

Even without the nuances of dealing with developers, B2B selling has gotten tougher. The average number of customer stakeholders involved in a B2B purchasing decision now stands at 6.8.

Back in 2014, you had to convince a mere 5.4 of them. That’s 25 percent more participants in the purchase process in just two years, driven by factors like decentralized decision-making, globalization and aversion to risk.

In approaching a development team, it’s not going to be any different. You’ll just have to contend with the idiosyncrasies of communicating your value proposition to devs, something we’ve delved into in-depth already.

Yet very rarely do two or more developers on a project come cut from the same cloth. The dev working on a product kernel and the one dealing with UI/UX have broadly different jobs and skill sets, but they might both have a say about what you’re trying to sell.

Each individual developer will have a multi-faceted role, too. That’s just the nature of the beast inside fast-paced enterprises. They’ll spend time developing applications, modifying existing ones, testing, researching, purchasing, and somehow carving out time for learning new languages and skills.

So, depending on the nature of what you’re marketing, there’s a good chance you’ll need to develop a targeting and engagement strategy that accounts for a variety of different developers, as well as for non-dev stakeholders (who may be outside of a product team) who’ll have a say in the decision process. That’s nearly guaranteed if you’re trying to make inroads with anything above a small firm or development studio.

Where’s a dev in the org?

Let’s examine a fairly simplified org chart for a development team.

Everyone on this chart may be part of the same product development effort, and may have a voice in the purchase process, but as with any other hierarchy at any other organization, each of them has a different role, agenda, set of responsibilities and accountabilities.

There are “developers” all over this chart, but no two have the same job or demands.

This doesn’t even map in a project controller, CFO or procurement/purchase manager, who have an even more distinct perspective, since they’re holding the purse strings. They’ll definitely be part of what SiriusDecisions calls the “Buying Group” involved, in some organizations, in vetting any purchase bigger than, oh, a router or a new box of paper clips.

Other stakeholders you may want to keep in mind beyond the ones who are directly involved with a purchase? The direct and indirect users of your customer’s product, managers of those users, customer support/help desk members, developers working on other programs that may interact with your customer’s product, even the “gold owner” who puts up money to fund its development. For starters.

Hitting their hot buttons

But let’s bring our focus back to the product team you’re trying to romance. What’s one plain example of how developers may view your product from different perspectives?

Let’s say you’ve identified two members of a potential customer’s development team, a software architect and a development manager, both playing a part in evaluating and (we hope) eventually buying your widget.

The software architect is looking at your widget from a top-down perspective, since he or she is charged with making macro decisions about a software product or platform, including defining its technical standards, coding standards, and the tools and platforms to use and design parameters.

The development manager is closer to the ground, supervising the design of specific modules, functionalities and features, with programmers below him or her to do the actual coding.

The development manager will want your product to simply work within the framework the architect has handed down. The architect wants your product to work within that framework without requiring workarounds or shortcuts that create technical debt, a great term for the trade-off that happens when gaining functionality in the short term creates headaches and a need to rework a product in the long run.

When you can identify product development stakeholders like this going in, and what their hot-button concerns or pain points may be, you’re a lot closer to success than if you’re focusing on just the “developer” you imagine your widget will absolutely, positively sing to. Because within any given organization, that presumed developer archetype may not actually even exist.

Feel their need(s)

Does it sound discouraging? It shouldn’t. When you accept how diverse your target audience is, even within a single prospect organization, you’ve taken a big step toward solving the challenge.

Here are the next steps. Mind you, the path isn’t short or easy, and it demands due diligence. At the end of the day, though, you’ll have a far more targeted marketing program ready for launch.

First: Create a target account profile

• If you know the customers you want to capture, build a profile of each organization so you’ve got a clear understanding of its products, its market stance, its goals, its hierarchies and more.
• If you don’t have specific target accounts in mind, build a profile of your ideal account based on your existing data and key learnings about past successes, or on where you want to drive your business.

Next: Map an account’s buying groups and their demand triggers

• Suss out the personnel and teams who’ll be interested in your product, as well as getting a clear understanding of what the “demand triggers” are that’ll get them interested in the first place. Price? Functionality? What’ll make them sit up and shortlist you?

Then: Personalize your pitch

As a growth hacker and a marketer, I’m always mindful of how important it is to have empathy for my audience, and this is a perfect example of applying that.

• Once you’ve identified the role-players who are part of a purchase decision loop, develop in-depth personas for each of them: the CTO, the development manager, the product planner, right down to the devs who’ll want a hands-on experience with your widget.
• The more detail about individual characteristics, job responsibilities, career situation, hopes and dreams and so on you can bake in, the better. That’s because it’s essential for customizing your marketing messages, even the channels and tactics you employ, for each key contact you’ve got to engage. The CTO may need to hear you speak at a conference; the dev designing a product may need to have heard good things about you from online peers. What you say and where you say it are crucial.
• There are AI-driven software engines available nowadays that can do some of this work for you and keep buyer profiles updated in real time, which can be 90 percent of the work in persona-based marketing—and is often the work that doesn’t get done. Keeping your buyer models current is key, especially in targeting developers.

Last but not least: Help them sell

• If you’ve engaged them, part of the nurturing process is to supply ammunition they can use to sell your widget in with the rest of the buying group or enterprise. The support you give them depends on their role, but it can include the actual product trial, ROI projections the dev manager or CTO can share with the CFO, or whatever else they tell you would come in handy in helping them make your case.

Go all-in on authenticity

I’ve written before about how important authenticity is in marketing to devs. A big part of establishing it is showing how you understand each of them as an individual, not just as a “target” you’ve typecast.

With developers, it may be even more necessary to flush away clichés than it is with other audiences, because they’re acutely sensitive to insincerity and presumption on the part of marketers. Drilling down into who they are and how you can help them succeed within their organizations will only set you up for success.

This article originally was published at Marketing Land/MarTech Today.

If you’ve spent any time researching customer experience best practices for apps and services, you’ve probably read a lot about the ways sites like Facebook, Twitter and Pinterest treat CX as a core differentiator for their brands and platforms. And it’s true — these social apps and other prominent consumer-oriented services ranging from Uber to Eero offer a master lesson about the power of leveraging CX in growth strategies.

But what about B2B products? Long (although perhaps unfairly) pigeonholed as the ungainly sibling of more glamorous consumer brands, business service providers are the real powerhouses behind today’s cloud economy.

Whether it’s a giant like Salesforce or disruptive innovators such as Atlassian and Intercom, the ways successful B2B services convert engaged users into serious, paying customers provide a lesson for other, up-and-coming businesses — B2B and B2C alike.

Grounding CX in B2B

You know the expression, “talk is cheap?” Perhaps it’s a bit glib, but the adage is worth remembering when we talk about the B2B customer experience. When translating CX best practices into a new context, it’s easy to get lost in generalities.

That’s understandable. For all the attempts business school thinkers might make to quantify an effective customer experience, it retains an inherently subjective quality. Indeed, a slide I use as an icebreaker when discussing CX baldly misappropriates US Supreme Court Justice Potter Stewart’s famous statement about a weightier matter.

“I shall not today attempt to further define what is embraced within the shorthand description ‘a great customer experience’ — but I know it when I see it.”

But let’s be honest. Most product leaders are more clear-eyed than that. They judge the effectiveness of their CX work just like any other investment in their product.

So how should B2B teams approach CX efforts? I’m going to go out on a limb — when you distill it down, there’s only one kind of metric that matters: growth (and its antithesis, churn).

CX is measured by conversion and retention

Measuring how user behavior affects growth metrics is a core aspect of how consumer platforms are managed today. Some of the social applications I mentioned earlier are pioneers of using data-driven experiments to tune every aspect of their user experience.

The impact of CX often is more directly understood for consumer products like these. After all, the connection between the in-app user experience and engagement metrics like visits, session lengths or monthly active users (MAUs) can be fairly readily assessed.

But for B2B businesses, which are paid for solving specific business process needs for their customers, metrics of this sort usually aren’t useful. Instead, the paramount measure of how a B2B business produces health is more hard-nosed: customer conversion and retention.

Naturally, B2B products are designed around that core business process need. Innovators are solving challenges from streamlining HR and recruiting to marketing automation to managing aircraft maintenance — among countless other industry needs.

There’s an old expression that if you build a better mousetrap, the world will beat a path to your door. And that may well be true — but even the strongest value proposition won’t ensure customer conversion and retention.

CX is leverage at make-or-break moments

“Build it, and they will come” is never a reliable business strategy — but for services that face the constant risk of customer churn, a disengaged approach to the user experience is downright foolhardy.

That’s why an increasing number of product teams building B2B applications and services today are focusing on CX to reduce friction at key moments where user activation is key to the success of their product.

Consider onboarding. As soon as your users sign up, you need to ensure they hit the ground running. That means helping them discover the most important features and making it easy to take key configuration steps like confirming an email address or setting up two-factor authentication.

And there are many additional times when taking action in the app is essential to their success — and therefore your product’s. Think about the user life cycle in your own application. Perhaps a team member is waiting for notification from a colleague about a maintenance workflow. Or a manager needs to approve a scheduled time-off request. Or a user can’t proceed until she acts upon a security notification or password reset.

Each of these represents a sort of make-or-break moment for your product. If the user successfully navigates the process at hand, the more likely they (and their business) are to realize the value your app is delivering. That’s the crux of ensuring continued use — and renewal of service plans.

Make-or-break moments hide in plain sight

Web apps and other SaaS products are multilayered things, and even the most well-designed have plenty of room for CX investments. That’s just the reality of bringing a product to market — no matter how well product teams anticipate market needs, it’s only when users begin using it in the wild that our assumptions and biases are proven out.

Ironically, one of B2B product teams’ real assets — deep vertical expertise — often can get in the way of the quality of their apps’ user experience. That’s human nature; specialized knowledge can lead to a sort of cognitive blindness. We assume that what’s obvious to us is clear to any user.

In reality, the opposite is usually the case. The very thing you know most about may well be the place your users need the most help — and perversely, the moment in your app’s CX that may be the most broken.

So what’s that one configuration step your users need to take? You know, the one that’s essential to your problem space? The one that everyone, from the product team to engineers to customer support, all can recite backward and forward?

Yeah, that one. That’s a good place to begin looking with a fresh eye on CX. Even an incremental improvement in completion rates at that key step will yield outsized impact on user success — and when repeated over and over again from customer to customer, a meaningful change in retention and growth.

CX’s B2B bottom line

B2B providers that focus on CX do it for a very concrete reason: They know that carefully targeted improvements to their user experience remove barriers that get in the way of customer conversion and that lead to churn.

And when you get right down to it, that focus on growth is how product teams working to build a great experience in any product — B2B or B2C—ultimately are measured.

This article originally was published at Marketing Land/MarTech Today.

I was lucky enough to experience totality during the recent full solar eclipse. Despite my knowledge, I could understand why someone might think it was OK to look right at the eclipse as it approached totality. The risk was deceptive—it seemed as clear as day (or rather, dark as night) that I could trust my senses to look straight up.

Good thing I had external data to contradict my sensory assumptions! But as I was thinking about it on the way home, I realized this experience reminded me in a way of something I’ve often noticed about marketing technology to developers (or to anyone, really). Let me take a step back and explain what I mean about the risk of confusing our own experience with the facts.

For every mythologized outsized success in Silicon Valley, there are many more also-rans and outright failures—even some spectacular bombs. That shouldn’t be a surprise. Risk and reward are central to the culture of innovation to which so many of us aspire.

But when risk-taking is confused with self-delusion, the odds of success go way down. And there’s no clearer form of this dangerous myopia than substituting our own point of view for that of our customers. That’s especially easy to do when our customers seem a lot like ourselves—as when we’re selling to other software developers.

Just consider a few notorious examples of self-sabotage in tech marketing.

It seemed like a good idea at the time…

Do you remember Iridium? In the late 1990s, Motorola pumped $5 billion into launching 66 satellites meant to deliver global wireless service to every corner of the planet. A seemingly elegant, macro-engineered solution to the challenge of global communications.

It quickly turned into one of the biggest tech fails of the last 20 years. Not just because its $3,000 handsets wouldn’t work inside some buildings or moving cars, but because cheaper, more prosaically engineered competitors—cellular phone networks—were busy growing international coverage while Motorola was putting Iridium in place.

By the time it was ready to go, Iridium only had utility for off-the-grid survivalists, oil rig operators, mineral exploration teams and the like. In other words, users who were nowhere near a cellular network, which by definition excluded 99.9 percent of the product’s potential customer base.

Iridium went bankrupt and was sold for pennies on the dollar to new managers who repositioned it to serve those exact types of users: the market Motorola should have been focused on from the beginning.

The lesson? Don’t confuse your own perspective on what the market needs with what the market really wants. Motorola’s very smart engineers thought people wanted mobile telephone service over 100 percent of the planet, and they came up with a brilliant solution.

But 99.9 percent of the consumer market simply wanted affordable mobile service that could reach the majority of the people they needed to talk to—most of whom were within easy sight of a cell tower, not off the grid in the Himalayas or the middle of the ocean.

The risk of universalizing our own experience

It’s a natural assumption for a marketer trying to reach developers that consulting with our own internal developers is a good proof point for ideas about our products and go-to-market messages. And it’s true—it’s a fine starting point for spitballing ideas.

That, though, is only one step in the process. No matter how much of a slam-dunk any product or marketing idea may seem to be, it’s important to remember that our own developers are not our customers. They’re too familiar with the problem space, they’re already emotionally invested in the product you’re building, and they may just be a quirky bunch. In other words, they have biases just like you.

Instead, do hard research with real prospective users to balance all that internal enthusiasm.

An inward focus can ignore a real market need while leading you down a dead-end alley. There are way too many Iridiums in tech history where the allure of an idea didn’t align with the realities of the market.

Always bear in mind that there are plenty of ways we can blinker ourselves to the reality of what’s going to succeed in the real world.

Confusing customer needs with your own white whale

Back during Steve Jobs’ exile from Apple in the 1990s, the company focused on trying to beat the Wintel competition at its own game. Most notoriously, that included trying to mimic the Microsoft business model and licensing Mac clones. But it extended to the developer marketing front as well, as Apple exerted major effort building and advocating its own technologies, like OpenDoc, that sought to answer Microsoft’s dominant OLE (Object Linking and Embedding).

None of these ideas moved the needle for Apple—because it had become fixated on beating Microsoft rather than understanding the company’s core value proposition to its customers.

Jobs’ push to refocus the company on its user experience and to discard an entire portfolio of “interesting” developer technologies—while seeking détente with Microsoft—might well be his key contribution to the company’s ultimate turnaround.

The innovator’s dilemma is a form of narcissism

It’s easy to assume that success with early adopters is scalable in the wider market. And it’s even easier to let our conceptions of what led to that success become a straitjacket. This strategic challenge—“the innovator’s dilemma”—is a classic lesson for business school students. And it’s at least in part rooted in thinking our customers see value in the same way we do.

Case in point? It’s a classic: Sun Microsystems. Sun was a hardware-first company, where its software offerings, like Java and Solaris, were meant to be “wrapped in metal”—Sun Micro hardware. Until the advent of the cloud, they’d had a long and profitable run.

But by failing to see past their entrenched mentality about selling servers and hardware first, Sun lost out on any chance to launch a standalone software business when their own innovations had given them a perfect opening. While Sun became hidebound to its own notions of its value, its core developer customers moved on to new approaches that made them more productive.

Java may live on as a vestigial foundation for the cloud, but Sun itself dropped 80 percent of its value in just one year and was snatched up at fire sale prices by Oracle.

Getting out of a bubble

Even my company, SparkPost, has had to confront this natural tendency to assume our experience is generalizable to our market’s needs. We’re pretty progressive with our own use of technology, and our developers do some pretty amazing stuff building features that leverage state-of-the-art development frameworks.

Along the way, our team developed its own point of view on app development. But when we’re assigning marketing resources to reaching potential customers, we’ve come to understand that the developer community is a pretty diverse place.

Take Microsoft’s .NET stack. It’s enormously popular among a diverse group of developers and IT shops. When an opportunity arose for SparkPost to participate in a .NET conference, we paused for a moment. After all, our own developers didn’t use much .NET; would it be a good fit for us?

But we realized that many of our customers did. And the response we drew from being part of that event validated the notion that our customers’ point of view was the essential one. .NET is a framework used by developers in thousands of mainstream enterprises. Our service works beautifully well for developers in the .NET environment. Why wouldn’t we show our support for them?

Empathy for customer needs is the true north

No surprise: The solution to any of these pitfalls circles back to nurturing empathy for your audience. By having a richer understanding of what drives them, you’ll know how to serve them the right way.

Having a strong vision for your business is important. But don’t confuse vision with meeting customers’ actual needs. As we’ve seen from some of these case studies, internal biases about technology—or anything else—can get in the way of understanding what your customers themselves understand clearly.

This article originally was published at Marketing Land/MarTech Today.

Championing the power of great customer experience (CX) to improve key benchmarks and business results is becoming a core part of how businesses operate today — and a differentiator for those businesses that do it well. That’s no article of faith; real data supports this premise: better experiences lead to better performance.

Like any strategic undertaking, improving how customers experience our products isn’t a single, big-bang event — in fact, it’s quite the opposite. CX is the sum of myriad small interactions, from first-touch onboarding to deceptively powerful notifications, that form a constant, and essential, process.

But the incremental nature of CX improvement also suggests why it’s sometimes easy to put it off for another day, especially when faced with immediate competing goals like speed to market or dealing with technical limitations. That challenge is compounded when CX responsibility falls between the bailiwicks of different teams, as it nearly always does.

The space between

That shared responsibility is why I often think of CX as the “dark matter” of successful products and services. Even though astrophysicists estimate that dark matter makes up something like 85 percent of the total mass of the universe, it can’t be directly observed; it can be detected only through its gravitational effects on the visible matter we do see.

Like dark matter, experience is difficult (if not impossible) to assess directly. CX can feel like an intangible something that exists between all the concrete features and discrete responsibilities that make up a typical product offering.

Maybe that seeming ineffability explains why CX can be so hard to get right — even though it’s as clear as day when it’s missing. I recently experienced an example that illustrates how effective focusing on the space between features can be.

Meshing form and function

WiFi wireless networks are ubiquitous and indispensable to our everyday experience. And in most regards, they simply work — that is, unless you’re the poor soul responsible for setting one up. Whether it’s navigating stone-age UIs or fussing with base station placement to get good coverage, configuring a network hasn’t often been something most of us love.

Coverage is a particular challenge I long faced in the San Francisco Edwardian flat in which I live — a long, skinny space made up of a series of rooms off a single hallway. So when I learned that a new generation of wireless “mesh” networking products from companies like Eero, Google, Netgear and AmpliFi employ multiple small transmitters with the ability to monitor usage and signals to optimize their coverage automatically, I was more than ready to give it a shot.

And so far, the performance of my new Eero network delivers just what I’d hoped: great coverage and speed in the various nooks and crannies of my flat. And even better, it didn’t require a lot of fussing with networking bands or channels or other technical configurations. (But I’m not here to sell you on mesh networking. Go check out any of these various competing products if you’re interested.)

From function to experience

What I am here to tell you is that this product actually was a delight to set up. As a marketing and customer experience champion, that caught my eye in a serious way. What did the company do to spark joy in what should by all rights be a mundane task?

In many ways, I was struck that there were several things along the way that were not part of the core product — but that were essential to my overall experience of it — that actually made the setup and configuration process a delight.

• First impressions. An Eero is a lovely piece of hardware that’s shipped in Apple-like packaging. Does it actually work better because it arrived in a carefully designed box or because the device itself has a pleasing form? No, of course not. But that “unboxing” impression matters when a user is developing her or his first emotional impressions — and it reinforces the notion that this is something different from a run-of-the-mill wireless router.

And there’s even a hidden functional benefit: A better-looking device is less likely to be hidden behind a closet door. Do you think the Eero team considered that a wireless router that’s placed out in the open actually will deliver better performance? You bet they did.

• Core product activation. Setup, or what a pure software business might call onboarding, is very carefully designed to reflect the core Eero brand promise. It’s clear the company put a lot of thought into not just the function, but also the experience of setting up its devices.

In fact, I would not be surprised if the company invested almost as much time and financial resources into designing its software and setup process as it did in solving some the actual rocket science of networking physics.

• Transition from channel to channel. I’m sure you’ve had the experience with some businesses of the right hand not knowing what the left is doing. Classically, the customer support call center won’t know much about your web-based help requests. Or perhaps the web marketing page and the in-app dashboard look like they were designed by competing factions.

Eero’s account confirmation emails, landing pages and in-app screens all feel like they were designed with a cohesive identity — and they don’t force me to engage in the effort of context-switching. It shouldn’t matter to me what channel or platform a particular message or screen represents — it’s all Eero, whatever the platform for the task at hand: marketing, configuration or support.

• Defining its offering as a single experience. Perhaps most telling of all is how Eero refers to its products and offerings. Whether it’s in the box or the app, there’s no Eero XVA5421 or Eero Wireless Router Pro Plus Ethernet and Toaster Oven. There’s just Eeros.

Sure, that’s easier to do when you’re a small company with just one (or perhaps two) offerings, but there’s a core lesson in this approach to branding: Products and plans are just artifacts of an overall brand experience. Either Eero delivers a great experience or it doesn’t.

Note that none of these qualities are actually necessary to how the Eero devices work. It’s very easy to imagine a utilitarian product manager who’s seeking to shave excess cost eliminating them all. So I think it’s telling that these “dark matter” CX qualities are what took my experience with my Eero out of the realm of everyday networking products and into another space altogether.

Feel the force of CX

To be sure, the “killer feature” of mesh networking — great coverage with minimum manual configuration — is key. After all, if the Eero (or any other competing product) didn’t deliver on that core promise, I would have been left disappointed and frustrated. Conversely, even a clunky approach to solving my networking challenge would have left me satisfied, if not euphoric.

But by doing all of these things — 1) addressing my core functional need and 2) focusing on the experience “between” core product features — Eero left me feeling not just satisfied, but delighted. And that’s a powerful emotional asset for any brand to leverage into increased engagement and growth.

Don’t let CX’s often intangible nature lead you to be fatalistic about your ability to shape it, or to abdicate ownership of it to teams with more direct implementation responsibilities. Indeed, paying attention to the space between the features we see makes all the difference between a great customer experience and a lackluster one. And recognizing the impact of that dark matter — and then acting upon it — is the mark of an empathetic and empowered CX leader.

This article originally was published at Marketing Land/MarTech Today.

I don’t need to tell you that the cloud and other enterprise technology is a core part of the modern economy. The work of building the systems that power our businesses is a major driver of employment and other growth. Indeed, there are 3.8 million software developers today in the US and 21 million globally.

Numbers like these are a big reason why the business of supporting developers with infrastructure and tools that help them do their jobs is a significant market in its own right. I’ve written before about the unique challenges of marketing to developers.

Although there’s no one-size-fits-all way to effectively reach developers, some best practices are clear. One of those is finding the right person to be the face of your business in the developer community. But who is that person? And as a marketing leader, what do you need them to do?

Advocacy, not evangelism

It’s not that developers actually hate marketing or need to be handled with kid gloves. It’s more that they’re skeptical and accustomed to marketers doing a pretty poor job of relating to their needs. So let’s begin by positing that at a minimum, an effective developer marketer is someone who understands how developers work and actually listens to what developers say.

And that need to listen as much as talk is why businesses like mine have settled on the developer advocate as a major part of our developer marketing strategy.

By the way, that’s in contrast to another common approach, the developer evangelist or technology evangelist. Semantics, perhaps, but advocacy and evangelism aren’t quite the same thing. To my mind, advocacy is about facilitating developers’ work and representing the needs of the developer community back into the organization, while evangelism is more akin to standing on a soapbox and preaching a particular technology and problem-solving approach. Put yourself in a developer’s shoes: Which would you rather experience?

Community at the core

As of this writing, LinkedIn’s Jobs section says there are 1,317 open positions in the US for developer advocates. Developer advocates are as diverse as the company, the product and the type of developers they engage. There’s one plain-as-day commonality, though, shown in these three example snippets cribbed from various advocate job descriptions:

A developer advocate is someone whose primary responsibility is to make it easy for developers to use a platform … I view the role as having a foundation of three pillars: development, advocacy, and community.

We’re seeking a technical content manager/developer advocate to help us grow the developer community.

This is a position for engineers who love connecting with developers and speaking publicly about cutting-edge technologies … your work fosters a community of developers working with Google technologies.

The emphasis on community couldn’t be more obvious. And there’s a good reason for it. Organic communities of interest are how developers share knowledge, hack problems and collaborate on best practices and design patterns. They’re also superb communal mechanisms for testing claims and spotting issues.

That’s why those 1,317 companies hiring developer advocates—or any other business that’s serious about developer marketing—need to seek out individuals with the knowledge, passion and empathy needed to nurture a community of developers. Without that genuine respect for community, an advocate risks becoming a manure shoveler.

Advocates’ many varied hats

Part of what makes a great developer advocate is understanding how to connect with developers on their terms and work bottom-up, rather than top-down. That means participating and contributing knowledge one-on-one. It also means listening to feedback—the good, the bad and the ugly—and making it actionable for their company.

So developer advocates have to be comfortable straddling two points of view. They need to be passionately, empathetically devoted to building and supporting a developer following, while always advancing the rep and adoption of your product or platform.

That’s easier said than done, and it’s why good developer advocates embody a range of important qualities:

• Empathy. The ability to relate to a customer’s experience lies at the core of all effective marketing. It’s absolutely essential for anyone seeking to play the role of developer advocate.
• Self-starting leadership. Developer advocates need the self-direction and initiative to come up with strategies and tactics to encourage adoption in a competitive marketplace, and drive those to implementation.
• Conviction and passion. Advocates are evangelists who believe in what they’re doing and in the value of the product. If they lack it, there’s no faking it, and developers will see through them instantaneously.
• Practical, technical experience. They’ve got to be able to explain the product thoroughly and answer the tough questions to a developer’s satisfaction, as well as steer product improvements with their own platform team. They may have to generate sample code, libraries, articles, books, training and reference apps used by millions of developers , so it’s imperative that they have the technical skills and baked-in understanding of best practices to do it.
• Communication skills. They’ll need to write code that’s educational and accessible, present engaging and informative content online, on stage or via social media, be comfortable in 1:1 support sessions or huge webinars, meticulously answer questions and interpret bugs, features and issues for internal engineering teams. But they’ve got to speak to the business as well. One of my colleagues described himself a “geek translator,” fluent with tech types on the customer side, but able to translate what they told him so his marketing team could build value propositions that answered their needs (even when the customers didn’t realize they had them).
• Good ears, a subset of communication. Knowing how to listen and really hear what devs are saying, so the advocate can respond in a way that adds value.
• Candor. A good advocate is seen as an honest broker, a facilitator, a real member of their tight-knit community who’s not merely a moderator or curator but a go-to champion on their behalf. Demonstrating transparency and honesty, even about the limitations of advocates’ own products, is invaluable, since it keeps them from being branded as salespeople.
• Appreciation for diversity. The developer community is a lot more than the stereotype of nerds and hackers. A developer advocate who falls back on easy tribalism isn’t going to succeed. That means appreciating and navigating a wide range of languages, cultural backgrounds, places of origin, ethnicities, genders, outside interests, programming language expertise, work styles and time zones.
• Diplomacy. Advocates are sometimes ambassadors, fostering in-house understanding of the dev audience by sales teams, marketing and other stakeholders. Accomplishing that isn’t simple, as it’s about encouraging cultural transformation, not just doing an occasional PowerPoint standup.
• Objectivity. By bringing in an outside perspective, advocates can correct biases or narrow outlooks, internally or externally, but there’s another side to it: They also never lose sight of the fact that everything they’re doing has to ultimately help build business.

Bringing the outside perspective in

These skills are a tough order to fill. Perhaps it’s even enough to make it sound like developer advocates are hard-to-find and hard-to-hire unicorns. And there’s some truth to that—great developer advocates are a scarce commodity.

So it’s easy to see that some might be skeptical that it’s worth the effort. It’s tempting to say, “Don’t we already have developers? Just go down the hall to engineering and ask their opinion.” And by all means—do ask your engineers for their input. It’s a great resource. But don’t confuse it with the kind of input a developer advocate will bring from external developer communities.

That’s because every organization has its own culture and implicit biases (Yes, even the amazing engineers and marketers in your company and mine!). Perhaps we have favored tools and approaches that they believe are more universal than they are. Or we’re so steeped in the difficult challenges of a particular domain space and the intricacies of our products that we forget that outsiders are dealing with more prosaic challenges.

Consider one example. A colleague pushed for us to be part of a conference that some of our team felt was too old-school, and maybe not a fit for our advanced technology. Yet the attendees loved what we put in front of them, because it addressed an unmet need and was presented in a way that spoke to their experience and context. That we were able to do that was thanks to the legwork our advocate had put into understanding and addressing those needs.

That’s exactly the perspective a great developer advocate will bring to the table. And it’s why developer advocacy is a fundamental part of an effective developer marketing strategy.

This article originally was published at Marketing Land/MarTech Today.

Philosophy abounds with variations on the notion that pretty good is actually pretty great. Aristotle found virtue in the middle ground between aesthetic and ethical extremes. Ralph Waldo Emerson advised “moderation in all things.” And we know how Goldilocks felt about finding something that was just right.

But, still, it’s human nature to hold ourselves to a higher standard. Lots of folks are loath to finish a job when it’s just good enough. One upscale automobile manufacturer staked its reputation on “a relentless pursuit of perfection.”

I daresay many of us who are devoted to improving the customer experience (CX) of our products and services fall into that camp of perfectionists. It makes sense—we advocate because we’re highly attuned to the needs of our customers, and we notice all too clearly when we see something that’s not quite right in the design and flow of our apps.

That empathy is a major strength of companies that create value from long-lasting customer relationships. But if the goal of a great experience turns into perfectionism, it gets in the way of solving real problems, right now. As Voltaire wrote, “The perfect is the enemy of the good.”

What’s wrong with being perfect?

But wait a minute, why shouldn’t we strive for a perfect customer experience? Isn’t that a laudable goal? Well, in purely aspirational terms, I don’t know. I’ll leave that to an Aristotelian to argue.

But I do know that perfectionism has costs in the real world. If CX advocates define their roles as fixers of every flaw, then the sheer size of the problem quickly becomes overwhelming, and we lose perspective on where to get leverage. Instead of resulting in great customer experiences, the quest for perfection usually leads to dithering, paralysis by analysis and defining conditions of success in a way that can only set ourselves up for failure.

In other words, aiming for a perfect customer experience is the antithesis of what we’ve learned works when building a successful app or cloud service: experimentation, fast iteration and nurturing multiple avenues for improvement and growth.

80/20: More peas, please

In the late 1800s, Italian economist Vilfredo Pareto observed that about 20 percent of the pea pods in his garden yielded 80 percent of the peas. That insight led him to describe similar dynamics in human and marketplace behaviors. This Pareto principle is more commonly known as the “80/20 rule,” and it’s become a trope of countless PowerPoint decks. I’m sure you’ve seen variations like:

• 80 percent of a software application’s users need just 20 percent of its features.
• 80 percent of a company’s profits come from 20 percent of its customers.
• 80 percent of software crashes can be solved by fixing the top 20 percent of bugs.
• 80 percent of complaints a company receives come from 20 percent of its customers.

You get the drift. And while reality isn’t always so tidy, it’s an appealing idea because of its intuitive simplicity.

But nifty aphorisms aside, its real value is in providing a pragmatic way to break problems like CX down into addressable chunks. The notion that complete perfection isn’t worth the effort is especially apt when thinking about the customer experience, because it encourages focusing on incremental improvements that can have an outsized impact on the total experience.

Pick the right CX leverage points for maximum impact

So which 20 percent of your pea pods are likely to yield rich customer experience wins? Certainly, many will be specific to your particular app and problem domain, but most services share a few common friction points that are ripe for the picking. Here are five places CX teams can have a powerful impact with even small improvements:

1. Pricing options and plan selection. Because they have an explicit connection to revenue and business success, pricing pages, plan selection choices, upsell prompts and the like are an obvious choice for focusing CX efforts. And making these all-important faces of your business succeed certainly helps to demonstrate the ROI of CX investments.

But in order to succeed, a CX champion must be empowered and ready to assert her or his mission in the face of multiple stakeholders and a process that typically spans a marketing website and app. In many ways, pricing pages and the sign-up flow to which they lead represent the challenge and opportunity of CX in a nutshell.

2. ‘Unboxing’ and the first touch point. In the physical world, product packaging used to be considered a forgettable, disposable need. As long as the box adequately protected the product and made mundane needs like shipping efficient, it deserved little other thought. But masters like Apple have transformed the experience of opening the box into a powerful, delightful component of their brand (and created a new genre of YouTube videos along with it).

What happens when a new customer lands in your app? It’s hard to overstate how significant an impression that very first moment will leave in their overall sense of your service and value. It’s just part of being human, for we’re hardwired to retain the emotional connections made the first time we experience something. So be sure to make that moment an intentional one, or you’re quite likely to leave an inadvertently lackluster experience deeply embedded in your customers’ brains—if they even stick around at all.

3. Setup and configuration. Unless you’re actually a single-serving website, even the simplest services require some amount of preference-setting and configuration by the user. Whether it’s as straightforward as choosing a username or as complex as validating the DKIM settings for your domain, these tasks are essential to delivering the functional value your service promised.

So why do we often make it so hard? Too many setup screens embody a disjointed, confusing experience. I’ve written before about how crucial good onboarding cues and flows are to the success of apps and cloud services—every incremental improvement to the setup process will meaningfully increase the likelihood of successful user activation.

4. Advanced features learning curve. Simple setup and an elegant first touch point don’t need to come at the cost of powerful functionality to meet complex needs. In fact, quite the opposite: In a sort of twist on the supposed trick to successfully boiling a frog, great apps introduce complex functionality at a measured pace that makes it easy for new customers to get started without limiting the value for more experienced users.

Directed onboarding is part of that, for sure. But another effective style of new user experiences is the gradual surfacing of advanced features only when the user has met certain preconditions: taken a particular action, configured a relevant setting, accrued a certain amount of “experience points” and so on.

Of course, you’ll want to be sure to allow someone who already knows their way around to have a direct way to fast-forward to the good stuff.

5. Account-related communications. Think about the different messages your customer receives from you. It might include billing notices, customer support tickets, triggered onboarding messages and marketing communications. Too often, these come from deeply siloed systems and business processes, with the corresponding negative affects on everything from visual branding to messaging voice to how to we expect the customer to respond and take action.

It’s a classic challenge at most companies, but treating notifications as an afterthought has a pernicious effect on the customer experience. Fortunately, it’s also a great place for relatively simple CX efforts to make a major impact. For many cloud services, email or other notifications are the primary vehicle for both administrative and engagement needs. So put the effort in to get them right and to get them consistent.

I won’t suggest that addressing any (or even all) of these five CX needs will solve every challenge your customers face. But each will have an outsized impact on the overall experience your customers have with your business.

Forget perfection. Even a small improvement to one of these areas will go a long way towards delivering a better customer experience. And getting even one of them mostly right will pay off in a big way for your customers and make a meaningful difference in crucial metrics like user activation, engagement and more. That sounds like a perfect win-win to me.

This article originally was published at Marketing Land/MarTech Today.

The challenges (and myths) of marketing to developers can feel boundless at times. Indeed, the apparent chasm between marketers and our technical customers can be daunting—and the stereotypes sometimes run both ways. But the remedy is a deceptively simple one: empathy.

We’re hearing a lot about empathy (or the lack of it) in popular and political culture today. At heart, it’s about listening to another person tell you their experience. It’s about listening to someone else’s point of view—without interjecting your own.

So rather than blathering on with my opinion about what developers should want from marketers, I thought it might be better to let some of the developers with whom I work tell me in their own words about their marketing experiences: the good, the bad and the ugly.

When I asked in our internal and developer community Slack channels, I wasn’t disappointed. Here’s some of what I heard.

I am not your nerd

The first response I received when I asked what marketers should know about developers was very personal:

“I’m not a stereotype. I’m social, pretty well-adjusted, and don’t respond only to Star Wars memes.”

Just like software user personas, buyer personas have their place. They can help focus efforts and messages and remind us that we’re marketing to humans, not rows in a leads database. But to be honest, I’m not a huge fan. For a practice that’s intended to create empathy for our customers, it often doesn’t work that way.

The reason is pretty simple: Most of us rush through that empathy-building exercise. We reduce personas to stereotypes. We use mental shorthand to project what we think our customer looks like, rather than… I dunno… asking and getting to know them.

So—“developer.” If you’re marketing software and services infrastructure, develops systems or development tools, you probably have defined a developer buyer persona somewhere in your marketing plans. Be honest: Is that guy (yes, guy) named Sheldon, a kinda geeky comic book fan, a gamer and a cola-guzzling introvert who doesn’t really enjoy the fresh air of outdoors?

Yeah. It’s time to retire the tired tropes of what a developer looks like.

These are not the memes you’re looking for

If you’re marketing to developers, I bet your Twitter feed has included its share of puns about the Force. And references to Azeroth. And perhaps a bit about Bash. Sure, fine, but what’s the thing developers wish marketers would stop doing?

“Pretending to ‘get’ certain ‘lingo’ and trying a little too hard with humor.”

We’ve all experienced the awkward feelings (or eye rolls) that come with not being quite in on the joke. Or when an outsider appropriates a subculture’s language. It doesn’t work, because it’s not authentic. And authenticity is a key part of empathetic communication—with developers, or anyone else.

So if you (yes, you) can authentically crack wise about Emacs and natural 20s, great. Own it. But don’t pretend to be something you’re not. Authenticity—marketing in your natural voice—beats faking it every time.

Gotta get it right the first time; that’s the main thing

I hope it’s self-apparent that if you’re a marketer, you need to understand your own product. Like authenticity of voice, technical accuracy is crucial if you’re marketing to developers. Don’t try to get away with faking it:

“Sloppiness — trying to talk about tech but doing it wrong, anything that communicates ‘this was not written by your fellow engineers’—it’s going to tank a pitch pretty fast for me.”

Take the time to learn what you’re selling. If your business is making a technical sale, you’ve got to hire marketers who have the technical knowledge (and even working development experience) to communicate with precision.

After all, what’s the alternative? Websites and product pitches that betray a fundamental lack of knowledge about your developer customers’ needs and how your solution works. That’s a deal-breaker.

Get out of your own way

Creative marketers love visually powerful ads; a benefit statement that also works as a subtle dig at a competitor; or expertly rendered feature pitches. But what do developers actually want when they’re in buying mode?

“Tell me a clear price. Give me direct access to trying something as quickly as possible without getting in my way. Show me what the app looks like and what people do with it. Be straight with me, and I’ll be straight with you.”

Could this developer’s request possibly be more clear? I can’t tell you the number of conversations I’ve had in different organizations where the question of whether to publish a transparent price list was the right thing to do. (Answer: yes.)

And certainly, every step we can take as marketers to help reduce both the procedural barriers and the conceptual “mental taxes” that get in the way of getting up and running in our apps will better serve the needs of our developer customers.

If marketers’ product content and the sales pitches that follow come at the price of speaking to developers’ actual decision-making process, then it’s not effective marketing—it’s solipsism.

And that brings us back, full-circle, to the notion of empathy. It’s understandable that a lot of marketing to developers falls flat. Not because it’s not thoughtfully conceived or well-executed, but because it’s speaking to and functioning for a different audience than we claim it to be.

Think about the clear advice these developers shared with me. How well does your marketing fare when examined in that light? I’ll be candid—my own is a work in progress, but I strive to achieve the straightforward tone and clarity these developers describe.

So, honestly, who is our marketing serving, our customers or ourselves? One of those is the opposite of empathy. Until we get that right, developer marketing will remain a frustrating exercise for us and our customers alike.

This article originally was published at Marketing Land/MarTech Today.

Marketers sometimes get a bad rap for not understanding the basics of the products we sell. You know, the idea that marketing is the easy A of Silicon Valley. If you’re a tech marketer, I’m sure you’ve encountered it at least once over the course of your career. While I won’t get into the stereotypes that let that notion linger, I think it’s safe to say there’s a bit of a “marketers are from Venus, engineers are from Mars” thing going on.

That’s a shame. Not just because it relies on a caricature of what marketing is all about, but also because of the consequences it can have on the actual products we sell—and our customers’ experiences using them. Any disconnect between the people who build products and the people who market them inevitably results in less successful products with less satisfied users. And that’s not a place any of us want to be.

But don’t misread me. I’m not here to mope that marketers are misunderstood and underappreciated. Like any relationship, successful product/marketing collaboration is a two-way street. And there’s a critical, high-leverage area that we marketers need to step up and do a much better job at: connecting our marketing efforts to the actual experience our customers have using our products and services.

That customer experience (or CX, to use the buzzy shorthand) isn’t just an abstract notion that lives in business school articles and consultants’ strategy documents. It’s the real, down-to-earth thing our customers do with our software every day. But too many of us, whether product marketers or product builders, forget (or perhaps have never experienced) what using our own offerings feels like.

I’m not much of one for brogrammer-speak, but if there’s one expression I want you to think about right now, it’s this: As a marketer, it’s high time you ate your own dog food. To make that menu palatable, I’ll offer you three concrete ways you can start doing that—and keeping your CX grounded in your customers’ reality.

Experience your product as a customer would

All right, marketers: It’s high time you found out what happens when people stop being polite – and start getting real. Because if anything warrants the reputation we seem to have among our more technical colleagues, it’s that shockingly few of us actually have taken the time to use the products we’re trying to sell. That’s got to change.

I’m telling you right now—go sign up for your own service. From scratch. Delete your cookies and bookmarks. Create a new account. Walk through every onboarding step thrown in front of you. Try to accomplish the tasks you’re asking your customers to do. I bet it’s not as easy as you thought.

There’s a good reason for that. As marketers, we suffer from a large amount of cognitive blindness when it comes to our own products. Our minds fill in what we expect to be there, rather than seeing what a customer actually experiences.

It reminds me of something I experienced several years ago, when I spent a lot of time writing taglines, product collateral and so on. In all those pieces, I used a common call to action—and guess what? For months, the documents I produced featured the wrong phone number. Not because I didn’t know better, but because I literally stopped comprehending the text that I was using over and over.

In fact, I only noticed the typo when I happened to read my material in reverse order; that forced me to see each word for what it was, rather than glancing at the whole thing as a unit and seeing what I expected.

It’s easy to get inured to something that we take for granted. So stop assuming you understand your product, just because you market it every day.

The only way to get an honest glimpse of the customer experience is to do it without the crutch of bookmarks, saved form values or previously established accounts. To really see what your customers see, you’ve got to experience it with fresh eyes—to read it backward, as it were.

(And by the way, reading documents backward is a great way to proofread.)

Get on the front lines to learn the truth about your CX

You just walked a mile in your customer’s shoes. Guess who else sees the down-and-dirty of how your product actually works? The fine folks who staff your front line customer support. Whether it’s by phone, email, or novel channels like Slack, no one—and I mean no one—knows what’s working and what’s not in the customer experience like the support team.

Consider this: Product managers and engineers built it. We marketers and our friends over in sales sold it. But who actually interacts with all its tics and warts (and occasional delights) every day? You know who. I often write that my support and services colleagues are “the hardest-working team in the email business.” It’s a slogan I see proven every time I look out to their desks the next row over.

That’s why one of the most powerful things a company can do to nurture an understanding of the customer experience is to encourage every employee to hear it firsthand, on the front lines. That’s something my company does, and it’s been a real boon for building awareness of the overall customer experience. Seeing the specifics of how our product actually works is an object lesson in how CX decisions play out in real-world use.

Or consider another approach: One company I admire that serves a technical market asks every employee to spend a week learning to code an app. That’s a tangible way of building empathy for their developer customers’ needs and to foster understanding of the product they offer.

If you’re a marketer serious who’s about CX, you’ve got to get out of the ivory tower. Spending time on the help line, solving problems for your customers, is the surest way to develop an understanding of the real challenges your customers face.

Remember that CX is a natural role for marketers

Think about why you chose this career. Perhaps you were great at persuading people to take a particular course of action. Maybe you had a talent for the creative, expressive side of the business. Or it could be the natural empathy you have for your customers’ challenges. I know a dash of each of those qualities played a role in why I eventually came to be a marketer.

Well, guess what? All three of those attributes also are key to being successful with CX. Persuasion? A great customer experience makes desired outcomes feel effortless. Creativity? Words, visual design and UX (user experience) work together to add up to a customer experience greater than the sum of its parts. Empathy? That’s CX boiled down to its essential core.

There’s no question that marketers are well-positioned to champion a better customer experience. CX remains an aspiration as much as it’s a discipline in many organizations, so now’s the time for marketers to advocate for the responsibility and make it a reality.

Just to be clear, this isn’t just some kumbaya fantasy. A better customer experience also means better results on the kinds of metrics your CMO is being charged to drive today: conversions, customer engagement and growth. That’ll help even the most numbers-driven among us understand that improving CX has a direct impact on results.

Economists like to talk about “aligning incentives” in organizational and marketplace behavior. Let’s be a little more direct. Making a bottom-line connection between CX and dollars is crucial for our success—and a hard-nosed way of keeping CX real.

This article originally was published at Marketing Land/MarTech Today.

Developers have a reputation among marketers as a tough audience, as we’ve mentioned a time or two before. It’s very true that reaching them through marketing entails unique approaches. In past columns, I’ve gone into the ways a marketer should use content to engage developers, and how important the right attitude and empathy are to creating that connection.

One dream scenario for a marketer is to create a developer platform with a life of its own — to lay the groundwork that transforms customers into a community of followers or, better still, into passionate evangelists for your platform, product or company.

Here are six best practices to keep in mind if you’re trying to build a developer community. They’ll help you build the kind of unforced, authentic participation and advocacy that’s more invaluable than ever.

Don’t assume you know who you’re looking for

Let’s take a quick snapshot of a “developer”:

I’m a figure skater. Coming from a background in collegiate sports, I’m highly driven, with an inner voice that replies to a challenge by saying, “Suck it up, buttercup.” I have a contagious amount of energy and an intense amount of grit.

If you’re used to stereotypical representations, this reads more like someone in sales or marketing, right? Not like a developer, or the buyer persona a marketer might draw up for a developer. Yet…

I also happen to be a passionate software engineer.

Her name is Aimee Knight, and she’s a great example of how, in the real world of developers, we find a colorful spectrum of personalities. Resorting to clichés and assumptions about devs is a mistake, and so is trying to paint every developer community with the same brush.

So, it’s important not to fall back on stale assumptions about what a “developer community” is all about. Before attempting to attract a dev community, research exactly who it is you’re trying to attract.

Don’t just rely on job titles and development roles or profiling data; interview them, immerse yourself in how developer-customers use social media and other established dev communities, and ask your own friends and co-workers who are developers for their insights. That’s the best way to learn their motivations and needs and how your community can leverage those. For example, here’s Knight again:

When a developer for my (former) employer’s website handed off a CMS to me and said, “Don’t touch the code outside of this,” my competitive spirit took the bait — and my fate was sealed… I started to stay up late… really, really late… working on the site (while hopefully no one was looking!).

Like many other developers, she’s a self-starter who’s willing to dig in really, really deep to resolve a challenge. That’s a potent insight for a marketer or community-builder.

Make it a planned community

Community is an organic thing, and it can’t be forced. But you can create structure that encourages the patterns that best fit your users’ needs — and your business goals. Beyond researching your target membership, you’ve got to plan out other aspects of your community well before launch:

Know why you’re building a developer community, and how it’ll be useful and unique. There are different types of developer communities, serving different needs; what’s your focus? What value do you offer to any dev who joins up? As you’re answering questions like these, make sure to stress-test your answers; honestly ask yourself and your developers if there’s a value proposition there.

Decide where it lives. A “community” can take shape across a range of different channels, including social media, blogs and websites, collaboration tools like Slack, and even (still!) conferences and live events. Figure out what the best channels and formats are for your purposes, and what’s most sensible for the kind of user engagement you want to create.

Define the relationship you want to have with members. You can have a model in mind, but you’ll need to be transparent and authentic with your audience about what you’re out to achieve and how it’ll involve them. Commit to being flexible and accountable about this, or you’ll quickly lose traction.

Work out roles for community members. It’s a great way of actually pushing ownership of the community out to its membership. After all, they’re the ones that will make the community happen, not you. Make sure you identify the best people to take on leadership, curation, member assistance or ombudsman roles. Let’s revisit Aimee Knight for a moment:

Outside of work, I’m a panelist on the JavaScript Jabber and Angular Air podcasts, a co-organizer for Charm City JS, and an avid runner.

People like Knight are your best bet for conversion into effective evangelists, since they’re actively looking for ways to help others or to network. So give them a useful role within your dev community. Even the fact that she’s a runner gives you options: Ask her to take charge of putting on 5K meetups for other members who run, for instance.

Curate, but don’t control

Developers are about the last audience on Earth willing to consume a drip-feed of promotional messages in community channels. They’re there to debate, gossip, share and learn, inspire and be inspired. They own the community, and they’ll abandon it if marketers begin clumsily infringing on their space.

Still, a functioning community coalesces around curators/leaders. Especially at first, you’ll need to nurture members to fill those roles.

It’s up to your team to avoid overt marketing while cultivating participation and interaction by acting as social guides, newsagents, emcees and conversation prompters. They’ll honor and reward top contributors and reach out on a personal level to all types of members.

If your developer community feels they’re getting value, recognition and honest engagement, they’ll keep looping back into the conversation, encouraging others to join in.

There’s still a real world outside

Building a community 20 or more years ago would have meant hoofing it from trade show to trade show, holding conferences and conventions and shaking a lot of hands. The web and social media have mercifully spared us all of that, right?

Wrong. You wouldn’t be going out on a limb to think that attending conferences, meetings and otherwise engaging people in person is now more important than ever. After all, somebody’s booking all those halls and hotels, right?

Developers are just like the rest of us in desiring eye-to-eye contact and authentic, unmediated interaction. So as part of your community outreach, schedule events where they can engage in exactly that way.

Be sure to include presentations designed to remind audiences of the human experiences behind your products. For instance, whenever Knight attends an event and tells her story of transitioning from triple axels to Angular coding, audiences love it.

Embrace buzz, good or bad

Never expect devs to flinch from calling out faults or failures and sharing their findings with other users. Don’t make the mistake of trying to steer that dialogue, either (unless they’re out-and-out wrong or used dubious methodology): If you thought bad buzz spreads quickly around topics like the Zika virus and Billy Bush’s interview technique, you haven’t seen anything.

Developers who think you’re being dodgy will happily flame you within your own feeds and boards and put a pox upon your name at Quora, Stack Overflow or Reddit, among other places where you’ll face a reputation flogging.

Instead, make sure you’re constantly aware of what the community is saying about you in real time. But if you get bad buzz that’s irrefutable, accept it as good data about the product. Be honest and responsive; your openness will shine, and you can use it as a springboard into deeper engagement, as you’ll see next.

Nurture collaborators and “devangelists”

No matter what marketers may think, developers aren’t naysayers. But they possess a keenly honed skepticism. It’s why they’ll trust word-of-mouth from peers over the most lavish marketing campaign you could ever afford.

That’s because a developer’s focus, from the first line of code they ever wrote, is on getting stuff done: Whatever they develop or integrate has got to simply work. So they’re always applying an empirical lens, since they’ve seen plenty of marketing and advertising bloviating over the years behind half-baked products.

That quality makes them a priceless resource as members of your developer community. As outsiders with an interest in your product, they’ll provide the purest kind of research and field testing — organic, objective and brutally honest.

At SparkPost, my employer, we’ve learned how to partner with our own dev community in refining our products. There’s a quid quo pro that makes it succeed:

1. We make our expertise constantly accessible. Our core engineering team manages community code contributions and readily accepts feedback, while regularly sharing their own best practices and problem-solving skills.
2. That collaboration has encouraged a cadre of developer evangelists who promote positive buzz and help sell our products, but they’re always willing to push back on us as they see fit, driving the cycle of improvement.

It’s important to represent the company within the community, but also to represent the community within the company. It’s a partnership that pays off.

6 keys to building your dev community

Stick by these six tenets in building a developer-oriented community and you’ll find success. Good luck! It’s hard work and a long road, but it’s worth the effort.

1. Research what kind of members you want to attract, so you’re able to draw them in with authentic interactions and relevance.
2. Put a plan in place before you launch, making sure you’ve got perfect alignment on goals, audiences and execution.
3. Serve and curate, but remember your dev community is really the property of its members, so never intrude on it with overt marketing.
4. Execute live community activities, going beyond just online channels.
5. Always embrace member feedback, good or bad, provided it’s valid.
6. Nurture community collaboration to foster deeper engagement and collaborative improvement of your products.

This article originally was published at Marketing Land/MarTech Today.

It’s nearly the end of 2016, and I see you’re a time traveler, just joining us from 2006. First, welcome! Second, here’s a cheat sheet for what you need to know about the past decade in the business of building and marketing tech.

• The iPhone not only transformed our experience with mobile devices, but it also reshaped how we experience nearly all of our digital interactions.
• The cloud and API-driven web services have become the dominant technology architecture, regardless of whether users interact via the web, mobile apps or otherwise.
• And the way we consume all manner of software has inexorably shifted from up-front purchases to various flavors of recurring revenue, be they subscriptions, consumable in-app purchases or advertising-driven models.

By itself, each of these patterns is a leap from the status quo of a decade ago. Taken together, they add up to a sea change in our customers’ expectations for technology. And that means the way we marketers interact with our customers has changed as well—or, that is to say, it should change if we hope to be successful.

In the beginning, there was customer experience

When I see how marketing’s changed in our industry, I’m not speaking of the hegemony of Google AdWords or the emergence of social media as a marketing powerhouse, though those are indeed consequential shifts in advertising.

What’s changed for marketers of cloud services, both B2C and B2B, is the two-part recognition that customer experience (CX) is essential to a service’s success, and that it’s a fundamental responsibility of marketers to work with our product management colleagues to shape CX.

This lesson can and should be applied to other software-based interactions as well—such as websites, ecommerce experiences and brands’ mobile apps—but I’ll focus here on SaaS offerings.

When I think about apps and services that have become an ingrained part of my own life at work and at play, I, of course, consider the functional value that they deliver. They help me accomplish something I need to do!

But I also know that the emotional and subjective qualities we call “experience” are equally important factors in determining whether or not I stick to a particular service—and share it with friends and colleagues. That’s why the teams behind successful apps and services spend a lot of time building something that feels great to use.

Now boarding on Platform A

But it’s not just fuzzy, happy accidents that lead to this success. In fact, a key realization among growth marketers at pioneers like social media platforms is that very specific aspects of the experience during a user’s first interactions with a platform represent key “make or break” moments that can determine whether a service thrives or withers on the vine. Some teams call this process “user activation”; many others describe it as “onboarding.” (There may be fine distinctions between the two, but for our purposes, let’s use them interchangeably.)

Onboarding is a multi-faceted occurrence that encompasses a range of functional and qualitative experiences. It spans the very first welcome screen, account creation, introduction of features and alerts that prompt specific tasks in a workflow.

When done right, each of the steps represents an opportunity for increasing user engagement—but, if poorly implemented or introduced with little forethought, they become hurdles that risk turning a customer away for good.

Missing the boat

If you’re anything like me, you’ve been tempted to sign up for many more services than you actually can use. Maybe I’ll log in once, then get back to whatever I was working on, thinking to myself that I’ll check out this great tool a little later.

Or perhaps I’ll get intimidated by a complex setup process for which I just don’t have time at the moment. Or, worst of all, the basic workflow for a site will be lost on me, and the payoff for figuring it out seems unequal to the effort.

Unfortunately for the teams behind these apps, each of these scenarios is a potential death-knell for my engagement with their products. Every time I delay taking a step with an app or service, it becomes decreasingly likely that I’ll become an active, paying and profitable customer.

That’s why getting onboarding right is so crucial—the first few moments with an app can make or break an entire customer relationship.

Key moments in the onboarding experience

The most successful apps find a balance that makes it easy—seductive, even!—for users to incrementally increase their engagement in a way that feels natural and self-paced, all the while capturing data and other indicators that feed behavioral models that identify profitable audience segments.

While there’s no magic bullet to solving the onboarding challenge, there are best practices that have emerged over the past decade.

First and foremost, make it easy to get started, and that means less is more when it comes to onboarding.

Forget the idea that onboarding looks like a linear wizard from the days of Windows 95. With each step a user must take to begin realizing the value of a service, the harder it is to get her or him to stay. Do you really need a user to verify an email address or pick a profile nickname before she or he can do a thing? Or what about the radical idea of not requiring him or her to create a password until they’ve already had a taste of the experience?

A great way to keep the onboarding experience simple is the onboarding email. Once relegated to a simple transactional message that essentially said, “Hey, you joined, here’s a confirmation of your username,” onboarding email has since matured into a fundamental piece of the customer experience.

Email’s asynchronous nature allows a user’s first interactions to remain focused on the emotional cues that drive engagement, while still nurturing completion of key onboarding stages. The most successful onboarding emails are designed as a series of carefully timed and triggered messages that help to accomplish key activation goals.

Finally, the most successful services realize that onboarding can go beyond the individual user and actually start to drive growth. That requires identifying the key metrics of new user activation that make a service go viral.

For example, Facebook realized that the point of no return is when a user makes seven friends in 10 days. At Slack, it’s after a team sends 2,000 messages. At Dropbox, it’s when a user has shared a file with someone else. Nurturing users to reach these critical thresholds should be a major priority for marketing teams.

It’s never as good as the first time

As marketers and product managers, we never have a better chance to influence our customers’ relationship with our product than the very first time they use it. We invest time and effort in building a great product. We spend planning and money on customer acquisition.

But that’s all for naught if we don’t make the onboarding experience a genuinely great one. I don’t know about you, but as a product marketer, I sure don’t want to throw away my shot to make a difference for my customer experience and conversion. Do you?

This article originally was published at Marketing Land/MarTech Today.

Look at the website of any business selling enterprise services or technology, and I’m certain you’ll find libraries of e-books, white papers and other content for download. Fill out a form that asks for your name and email address to get access to all the PDFs and infographics you’d like.

Ideally, you’ve found information that helps you get new insight into a strategic challenge or that provides really practical solutions to an ongoing business need.

When done right, that’s content marketing in a nutshell. You’ve traded something valuable (your contact info) for something else valuable (great content). It’s a win-win for you and for the business that published it.

Too many times, the outcome isn’t as ideal

In fact, I’ll bet you (like me) have had the unfortunate experience of feeling like you just made a Faustian bargain—trading your soul for something that wasn’t quite as worthwhile as you’d imagined. And now you’re hounded relentlessly by Mephistophelean sales reps who don’t seem to understand your needs.

This frustrating situation is one we’ve all experienced, and it’s something that developers, in particular, say they encounter more often than not. In fact, more than one dev friend has told me they simply ignore that stuff when they see it on websites. And it’s why tech marketers who put up gated white papers or similar content, hoping for developer leads, usually wind up disappointed with the results.

So, is content marketing a hopeless exercise for businesses like mine that sell primarily to developers and other technical users? In my experience, if you use a cookie-cutter approach to content marketing, the answer may well be yes.

But when done the way content marketing really should be done, I think you’ll find connecting with developers through content can be a very effective way to nurture the growth of your technology platform.

Content marketing is essential in B2B

Let’s take a step back to remember why content marketing has become the de facto strategy for connecting with B2B prospects.

When the business world migrated online, there was a power shift from the marketer to the prospect. Advertising and other push strategies lost ground, because the “self-directed buyer” is interested in useful, relevant and valuable content, not in selling messages—especially so in B2B. Marketers are naturally obliged to feed that need.

Today, 93 percent of B2B firms use content marketing (PDF), largely because it just plain works in an environment where prospects rule the purchase decision process. There’s debate about the exact figure, but it’s been estimated that around two-thirds of the buyer’s journey is complete before they think of calling a sales rep.

That’s because they’re checking out content before assembling their short list. According to a CMO Council study, 90 percent of B2B buyers say online content has a moderate to major effect on their vendor selection.

But. As important as content marketing is to reaching prospects, it’s even more important to use the right kind of content, properly targeted against your specific audience. Especially if you’re trying to engage developers.

It’s a mistake to try to engage devs by defaulting to content strategies that may have worked with other audiences, even if those were also within the tech/IT space.

With devs, value trumps vision

If you’ve ever got the time or the patience, you should browse through a random cross-section of the content that’s published for B2B. You’ll find a lot of it is repetitive, almost just “copyscraped” filler, designed to simply capture eyeballs.

Even when it’s got originality and value, it’s very often devised to express “thought leadership,” written as though aimed at the CTO or CIO level, revolving around big-picture strategic concerns or industry trends. How will XYZ transform the industry in the next 10 years? How can you lead the charge in upending your company’s digital paradigms? That kind of thing.

It’s where a lot of content marketing falls into a trap. It’s guilty of offering too much vision, not enough value.

That’s a problem for anyone. But developers are less likely to tolerate it than other professionals. I suppose some of that is temperamental, but it’s also because the nature of their work means fuzzy content offers them very little value. In other words, you’re not holding up your end of the content marketing bargain.

What’s the right content to deliver value to developers?

Great developer marketing (like any effective marketing) is full of empathy for the needs of your audience. So, instead of trying to shoehorn the content we marketers like to read into a developer space, instead think about the kinds of content developers actually use.

There are specific types of content that’ll resonate with developers because they first and foremost help them do a better job, grow their skills and move ahead in their career path. (And when you think about why content marketing works, well, those criteria are no different from those any of us have when we judge its quality.)

The kinds of content that I’ve found effective when working with developer customers of companies like mine include:

• Development or migration guides that help developers understand the characteristics of your platform and APIs, how to move existing code or systems onto your platform or how to integrate it with what their existing stack.
• Best practice guides for security, accessibility and other “hard” issues that a developer shouldn’t be left to figure out on his/her own.
• Code samples, in-depth walkthroughs, projects and any hands-on examples that give them a demonstrable idea of what you’ve got to offer—and how your platform or service actually works.
• Third-party examples and community contributions that drill down into real detail on how other developers have benefited from your product.
• Tools and scripts that help them be more efficient, or simplify time-consuming and repetitive tasks.
• Internal sell-in support material to help a developer pitch your product to his/her boss or other decision-makers inside the organization, turning that dev into the kind of “mobilizer” you want on your side as they get the organization aligned behind adoption.

The dos and don’ts of developer-targeted content:

• DON’T rely on “vision piece” or topline white papers and e-books: If you skew toward the thought leadership approach, or become too thesis-like, or focus on just delivering an overview, you’re not being useful to a developer.
• DO be careful what you call it: However useful content may be, labeling it a “white paper” or “e-book” can be a mistake for the very reason above, so be careful—terms like “guide” or “handbook” will resonate more.
• DON’T be too generic: They’ll happily accept highly technical, detailed content that’s specific to their job and challenges. But if you’re being too broad in focus in order to broaden your reach, you’ll lose their interest very quickly.
• DO geek out: Create content that shows you’re looking at things from their perspective. Write a blog post that digs really deep into the latest release of a developer tool, or post a podcast interview with a programming legend, or even recruit existing customers to submit posts, case studies and more.
• DO be transparent: Engineers are skeptical by nature, and they need to understand how things work, so if you’re showing any sign of holding back or trying to apply spin, they’ll spot it and tune you out.
• DON’T go textbook-y on them: Yes, they like technical information and thorough guidance, but don’t think that means they’ll accept “wall-o’ text” dissertations or hard-to-scan content. They want it sharp, short and to-the-point.
• DON’T overcook content design: They also don’t need clever design flourishes to spice up the material. Again, they’re looking for simplicity, clarity and easy absorption, not distraction.
• DO keep it all current: Developers seriously hate documentation of any kind that’s out-of-date, for obvious reasons. So any content you target them with has to be timely, and older content you assume is “evergreen” had better be updated, too.
• DO use humor: Judiciously going off-the-wall with the right kind of humor makes you relatable—and authentic, even—to developers, because they’re inherently skeptical, even cynical. So (good) nerd humor or skewering sacred cows is right on their wavelength.

This article originally was published at Marketing Land/MarTech Today.

It’s self-evident that designing and delivering a product or service that your customers want to use is the best route to business success. But the way marketers help companies get there has changed dramatically in recent years, as products and services increasingly live in the cloud of web and mobile apps.

There was a time—not so long ago, really—when marketers and product managers operated in very different spheres. Product managers built stuff. Marketers sold it.

Of course, that’s a simplification of an interrelated relationship between marketers and product managers. Even if we had clear boundaries, to be effective, we’d work together to understand market needs, and we’d periodically touch base to get aligned with product road maps and strategic priorities. But we each lived our own side of the house, and our responsibilities were pretty well separated. Almost sounds quaint, doesn’t it?

If you’re a marketer or product manager, think about where you are today. I bet a lot of us find the boundaries between these job responsibilities to have grown quite a bit more ambiguous.

Depending on our organizations, we might not even have roles or titles that fit that classic paradigm. Perhaps we’re growth hackers. Or maybe we’re customer champions. And I’m sure there are other novel roles I’m omitting. But even those of us with tried-and-true labels like “product manager” and “product marketer” recognize that our goals, day-to-day work and teams have evolved in some dramatic ways.

Things change. Like most social constructs, businesses and management theory are susceptible to fashion and novelty.

But I’m not here to mock business school jargon or the eccentricities of a tech bubble. In fact, far from it. Something fundamental is going on with this shift in how marketers and product professionals work to create value for our customers.

X marks the spot

If you’ve marketed software or web apps over the past decade, you’ve likely encountered (and incorporated) a steady progression of conceptual approaches to understanding and shaping how customers interact with your product. User experience. Customer experience. Digital experience.

So ingrained are these terms that the catchy initialisms used to name them—UX, CX, DX—have become shorthand for an entire style of product strategy and design thinking. I wouldn’t be surprised if I’m soon reading about the discipline of “XX” on thought-leader blogs.

The similarity in these terms makes clear that the underlying ideas are interconnected. But their euphony also makes it easy to conflate the concepts. Don’t make that mistake—they’re not the same thing! Here’s one way to think about these interrelated concepts:

• The discipline of user experience (UX) design in software is focused on usability, affective and emotional aspects of a product, making certain desired user activities intuitive and so on. It’s about designing for how a software product is used.
• Customer experience (CX) is concerned with the overall interaction between a business and a customer over the span of their relationship. It is a high-level, strategic view of the quality of a customer’s encounters with all touch points: products, services and brand.
• Finally, digital experience (DX) could be said to represent the intersection of UX and CX. Its focus is understanding, measuring and optimizing how customers interact with a company on the web, in apps and in communications channels like email and text messaging.

A quick search on Google for any of these terms will show a booming cottage industry of articles, conferences and experts all dedicated to helping marketers put the X in their go-to-market strategies and marketing programs—not to mention martech platforms that enable CX execution.

In the cloud, we’re selling the experience of being a customer

It’s easy to see how the customer experience at a retailer like Target or a coffee shop like Starbucks is shaped by very tangible factors in their store environment, merchandising, ubiquitous branding and so on.

These particular companies also have deservedly good reputations for bridging their online and offline experiences with strong mobile app offerings and cross-channel integration. You can be sure these companies consider CX to be a core aspect of their mission.

But what about businesses that exist entirely online? How does CX play out when there’s no real-world analogue to carry into the digital realm?

For users of a cloud service, the digital experience is the customer experience. That’s why marketers at cloud service providers need to remember our businesses are not just delivering a functional value—whether it’s music streaming, CRM, or in the case of my company, email delivery.

What service providers are in fact selling is the experience of being a customer. That understanding, as much as any technical or functional advantage, is what differentiates cloud leaders from also-rans.

Good marketing is part of a great customer experience

Because the online experience is so malleable, digital marketers can have an outsized impact on our customers’ experience.

Think of your own interactions with web apps and cloud services. While I hope the majority are delightful, I’m sure you also can recall too many that are marred by intrusive ad technology or other poorly conceived marketing efforts that compromise your experience as a customer for the sake of the marketers’ convenience or short-term needs.

So, what should we do as marketers to help our companies deliver a great customer experience? I’d like to leave you with three ideas to consider.

First, because customers don’t draw a bright line between their pre- and post-signup experiences, neither should we. In other words, marketing itself is part of the customer experience we sell. In fact, when done right, marketing is the epitome of making the customer journey feel effortless—an experience so good the customer wants to invest time and money.

Second, marketing can’t stop at the sign-up form. Dumping a customer off at the front door leaves a jarring disconnect between the promise and the fulfillment. Truthfully, that doesn’t work for any business, but it’s especially problematic for one that’s selling an experience.

Marketing must cross the marketing/product divide attitudinally and functionally to support and optimize things like onboarding and customer engagement that used to be considered “a product problem.”

Finally, generating leads “at any cost” hurts the customer experience. Sometimes, we’ll have to give more and get less—to get more in the long run. We have more ways of targeting customers and measuring the impact of our efforts than ever before.

That insight and accountability is a good thing. But don’t be fooled that martech by itself will drive results; exclusively focusing on the technology and data can make it easy to chase the needle and to privilege short-term gains over long-term value.

Martech tools and the data they generate are fundamental to today’s digital world. Like any tool, martech is only as good as the way it’s applied. It’s key to making a great customer experience a reality—as long as we don’t lose sight of what the “X” in CX signifies. With a nod and an apology to James Carville’s ebullient misanthropy, “it’s the experience, stupid.”

As digital marketers, let’s make sure our true north is our customer experience.

This article originally was published at Marketing Land/MarTech Today.

It’s easy to caricature the relationship between marketers and developers as something like, “marketers are from Mars, developers are from Venus,” where they even don’t speak the same language. Or the (non-)relationship is painted as being downright antagonistic, with oblivious marketers trying to crowd their unwanted messages into the attention space of contemptuous devs.

How often have you been told, “Developers hate marketing?” More than once, I’ll bet.

So it’s not surprising that marketing to developers can feel like you’re trying to navigate a dangerous mountain path, where the signs that can lead to safety—or danger—are written in inscrutable hieroglyphs. “If I only knew their language,” you might think, adjusting your pith helmet. Like there was a Rosetta Stone of some kind that would let you translate your pitch into DevSpeak.

But seriously, it’s time to get over this mythology. We’re in the age of the Cloud, when all kinds of businesses, not just traditional technology vendors, need to win the buy-in of developers.

And that means developer marketing is part of the new marketing mainstream; we’re not journeying to an isolated Galapagos (or even a “Land of the Lost“) where the normal rules don’t apply.

Sure, the developer community has a distinctive argot and its own cultural norms, but you know what? The basic lessons we know about effective marketing still hold up.

The challenge isn’t language, but empathy

Consider inbound marketing. Now, I’m a natural skeptic about jargony bandwagons, but there’s a good reason this label took hold: It’s shorthand for how to market in the age of the internet; it’s a codification of the basic principles of how we should support our customers’ natural goals as they seek out useful information to help them make smart decisions.

Done right, it’s empowering for them, not just a way of enabling a commercial transaction.

Content is fundamental to inbound marketing. But the notion that it’s a Faustian bargain (“Let me tempt you with this white paper, but at the price of your personal data so I can spam you into submission!”)—just (click)bait for the (sales)hook—is assumed to be one of the reasons “developers hate marketing.”

But great content—for instance, relevant and informative e-books, guides and white papers—works as marketing tools because it truly helps a prospective customer be more successful.

Consider the content you’ve probably searched out yourself. If you’re a tech product marketer, it might have been a competitive landscape overview, like a Gartner report; if you’re an email marketer, maybe it was a how-to or best practices guide for optimizing across email clients.

I just read a thorough review of a new crop of analytics tools, some of which may help me understand how my customers use our website. I read it because it was written with my point of view in mind. It had empathy for the prospect’s wants and needs.

And empathy is the foundation upon which you build an effective marketing program. Even—especially—if you’re out to reach developers.

Listen before you speak

Guess what? Developers only want the same thing as any other customer: resources that help them do a great job. “What are the options out there for handling this part of my application’s data?” “Has anybody else worked around this bug I’m running into?” “What cool ways are other developers improving their toolchain?”

What’s developer-focused content? It’s code samples. It’s how-tos. It’s personal blog entries by other developers, walking through their approach. It’s talking with peers in social environments like Slack or Stack Overflow.

But first of all, to understand what they want, you’ve got to stop putting the cart before the horse: Stop talking and start listening.

Even if developers really were from Mars, speaking a whole different language, isn’t listening intently the only way you’d figure out what they were saying?

Eight tips for marketing to developers

• Learn to listen. Practice an attitude where you’re listening to what they’ve got to say, asking questions, while never breathing a word about A/B testing your tag lines or value propositions.

• Buy a developer a beer. You probably know one, right? Just sit down with a dev who’s in your target audience and have a real conversation about what kind of content would help him/her do a better job. Then even follow this up with focus groups or meetings with existing customer devs.

Hear what their challenges, hopes and dreams are, how they hope to impress their CTO—anything that gives you insight into how you can help them.

• Meet them where they chat, share and learn. That’ll mean online, at Quora, Stack Overflow, Stackshare, Dzone, even Reddit and other sites. And look for specialized sub-communities that might be focused on your segment or product type.

If you can handle conversations that get deep into the weeds about coding, try GitHub or one of the many platform-specific IRC channels out there.

• Avoid creating noise. Don’t waste their time, whether it’s by blathering in chat, spamming their inbox or using clickbait content that doesn’t offer anything original or useful. Anything you say should demonstrate constructive value and relevance.

• Know thy product. One of the biggest irks for developers? Getting waylaid by marketers who don’t even know their own product (or category) well enough to do a decent job of explaining how they can help the developer.

• Ban the b.s. Developers have a unique penchant for calling out any hyperbole or blue-sky claim: “You’re telling me your widget is the fastest? Let me just sit down and bench test that …”

They’ll test it, compare it and—just as importantly—talk to their colleagues and share their observations in chat or blog. If you’re speaking truth, they’ll spread the word; if you’re blowing smoke… well, I think we all know the meaning of the word “eviscerate.”

• Give them a worthwhile trial. Without asking for any commitment, let developers give your product an extensive trial. That’s not just good marketing; it’s good product refinement, too.

Many devs will happily diagnose bugs, suggest upgrades or let you know why you’re not a good solution for their needs. Plus, many aren’t in a position to be the buyer, but it’s their post-trial recommendation that will carry weight with their IT purchasing manager.

• Gather testimonials. If we haven’t made the point, it’s this: Developers listen to other developers. So get solid testimonials from satisfied developers who can clue in other devs on just how good your product really is.

But as with anything else, the “no-b.s.” rule applies here, too: Any testimonial has to be authentic and in-depth.

This article originally was published at Marketing Land/MarTech Today.

I want to be up-front about something: I’m a CMO who hates marketing.

Sure, I’m exaggerating. But only to a point: as the marketing lead of a company that sells primarily to developers and other technical practitioners, I’ve learned to be really and truly skeptical of some of the “conventional wisdom” about B2B marketing.

Some of that wisdom still holds in my situation. But a lot of it doesn’t; not because it was never valid, but because conditions have shifted profoundly when it comes to marketing to developers.

Don’t get me wrong: when companies like mine are selling enterprise solutions, we’ll certainly leverage aspects of the B2B model that get results. But there’s no denying that something’s changed in the business of selling technology over the past decade. And it has everything to do with developers—and how they discover, evaluate and deploy solutions to their technical and business challenges.

Not coincidentally, that change has coincided with the rise of the cloud and APIs (that’s “application programming interfaces,” though we hardly need to spell it out anymore) as the primary means companies, big and small alike, utilize software and technology.

An explosion of API options

Several years ago, Internet development pioneer Marc Andreessen claimed “software is eating the world.” The cloud gave every kind of enterprise the ability to employ a lot of the same platform solutions as the biggest competitors. The access to and scalability of cloud-based systems has caused a real sea change, in just a few years, in how businesses leverage software. As business pundit Steve Denning has pointed out, it’s caused every company to act like a software company nowadays: how they adopt, adapt and manage software is central to their ability to compete.

But if the cloud is a conceptual architecture, then APIs are the tools developers are able to use to bring software-as-a-service (SaaS) capabilities down to concrete reality. APIs are nothing new; they’ve always been a fundamental part of developing for a specific platform, like Microsoft Windows or POSIX.

And latter-day APIs offered by pioneering cloud providers, from Salesforce to Google, extended that concept by leveraging the ubiquity of the Internet itself as the common integration platform. It made all manner of business processes accessible to developers without requiring a heavy-weight, on-premises implementation. And, for this next generation of platform providers, Internet-accessible APIs were a great way of creating developer reliance on those platforms.

But developers have been through this sort of platform dependency before and understandably chafe at the notion of being boxed into one provider’s approach. So it’s no surprise how they’ve driven the explosive recent growth of third-party APIs. They’ve embraced the latitude to shop from among thousands of specialized APIs enabling everything from site search (Algolia) to home automation and monitoring (Z-Wave) to email delivery (why my company does business).

Here’s a growth profile to keep in mind: In 2010, there were slightly over 2,000 APIs publicly available in the cloud. Today, some analysts estimate that number has skyrocketed at an amazing rate; API development platform Apiary says it alone has over 130,000 APIs registered.

Imagine what that landscape will look like as wearables and the Internet of Things (IoT) really take hold.

So, if you’re trying to market your product to developers, what’s the current lay of the land? Developers refuse to be limited to single platform solutions, understand the inefficiencies of home-grown development and know there are third-party APIs galore to choose from to meet their needs. That’s a pretty good picture of a buyer’s market.

How do you survive the shift?

From the standpoint of somebody selling technology, developer empowerment presents both key opportunities and serious challenges, thanks to all these very rapid changes. Developers spread throughout an entire enterprise often have the leeway to be choosy about the solutions they need to get their work done, and they might do so on a practically individual or unit-by-unit basis.

That’s in stark contrast to older models of technology sales, where IT sales were typically top-down endeavors with clear gatekeepers, and developers often were given very little choice about which technology they could use.

What does this power shift mean from a practical perspective? It obviously represents more competition for the marketer, and it changes the dynamic of whom you’re addressing and how you’re engaging with them.

If you’re marketing to developers in this new context, what are the keys to surviving or, better yet, thriving? In my experience, there are several strategies for success to keep in mind:

• Your API is your key marketing tool. It goes without saying that your API has to perform and deliver compelling functional value. But it also must be easy to understand, easy to use and appealing in its own right: well-formed, or even beautiful. Remember to make sure its documentation provides just as much clarity and convenience, too. No matter how amazing your overall solution, if the API is just an afterthought, you’re not going to get past square one with developers.
• Don’t fake it. Developers say they hate “marketing,” but what they really mean is that they’re not interested in marketing that shows how a marketer doesn’t understand them and their needs. Some of those sins? Clumsy messaging that shows an ignorance of how to apply the technology you’re selling, especially in their particular situation, that puts them through hoops that waste their time and drag on their productivity, or that shows a disconnect with reality by relying on hackneyed stereotypes of developers and developer mindsets. Any of these missteps just go to prove, in their eyes, that you don’t understand what they want.
• Don’t stereotype developers. This works in tandem with the point above: never assume that developers’ negative reactions to your marketing mean they’re automatons who don’t “get” marketing. They’re just having the same absolutely natural reaction to bad marketing that you would if you were in their shoes. In other words, if your marketing is falling flat, it’s not them—it’s you.
• Help developers help themselves. Developers are inherent tinkerers and experts in making things work. Help them get to success faster by providing them with great documentation, blogs, how-tos, code samples and more, and make it easy for them to find the resources they need via Google as well. Create tools that help their development work flow better (Slack is a great example of finding success by making developers’ work life better). And don’t just cling to selling your core product. The more resources you can supply to solve “adjacent” problems, the more important and authoritative a collaborator you become, in their eyes, as they grapple with different or bigger challenges.
• Nurture a collaborative community with developers. Whether that takes the form of peer-to-peer advice and testimonials, walkthroughs and how-tos, conversations on Twitter, developer-specific sites like Stack Overflow or collaboration platforms like Slack, successful developer marketers scale one-off conversations into a collective sense that “all of us are part of making this thing work.”
• Listen. There’s nothing more valuable than the specific feedback developers can offer up about how your product works, what they wish it would do, and where your product assumptions don’t match their pragmatic reality. Be sure to listen on Twitter and other channels. Better yet, don’t simply wait for that input, but solicit their ideas on “how can we make this better?” You’ll get an earful, I’m sure, but a great thing about selling to developers is that they often proactively want to tell you what works and what doesn’t. Product managers in other industries would kill for the precise, actionable feedback developers are often more than willing to share. Developer feedback is gold and a key part of the collaborative process that wins buy-in.

This article originally was published at Marketing Land/MarTech Today.

Jay Henderson, general manager of IBM’s Marketing Cloud business, was a featured speaker at SparkPost’s annual Insight user conference. In his talk, he delivered a great overview of how marketing is adapting to new technology and business models.

I’ve embedded Jay’s presentation below, but here are few key ideas:

• Noisy marketing chatter is cheap. And ineffective. The number of campaigns and emails and messages we encounter has soared. The right content is critical to breaking though the clutter.
• Mobile technology is ubiquitous. Mobile marketing isn’t a niche—in fact, it’s the most mainstream medium possible. Email and other marketing tools need to be mobile-first, not mobile-maybe.
• Cross-channel experiences are not optional. See above—customers use mobile all the time. But then, they walk into a store. Or switch to a web site at their desk. Does the experience you offer follow effortlessly, or at all?
• Marketers must manage their portfolio of marketing technologies—the martech stack—strategically. In a period of innovation, it’s easy to wind up with a jumble of technologies that barely hold together. The balance between streamlining technology investments while still pursuing competitive advantage and differentiation is a perennial challenge for all of us.
• Successful marketers cultivate a culture that bridges technology and creativity. Better-performing marketing teams collaborate with their technology providers and have the operational resources to make the most of martech. But marketing isn’t just numbers—if it were, we’s just turn on the computer and walk away. Customers aren’t clickstreams. The emotional talents that marketers apply like creativity, empathy, and intuition all remain utterly essential to our craft. Don’t let the data or an algorithm blind you to the human being you’re striving to reach.

Jay’s presentation stuck with me in the subsequent weeks, and I kept thinking about the implications of these changes for my profession. What does it mean to be a marketer today?

In most regards, there’s never been a better time to be a marketer. The technology’s awesome and has made all kinds of things possible that we couldn’t do before. The business models of growing businesses, be they cloud-based services or real-world retail, are increasingly dependent upon marketing expertise to understand customer behavior and engagement. The portion of marketing budgets that are considered strategic rather than discretionary is increasing. The amount of “marketing” that we all experience is going up, up, and up.

Yep. Good times.

But why, then, do I sometimes sense some unspoken anxiety from my peers at professional conferences and meetups? Why does it seem that a lot of us are “faking it ‘til we make it?” Hey, no shame. I have those feelings from time to time, too. I think a lot of it is just human nature in the midst of change. Some of us welcome it, and some of us fear it, but there’s no denying that the marketing worldview has changed in lots of meaningful ways.

Maybe you’ve heard the comment author William Gibson made at the dawn of the modern Internet era: “The future is already here—it’s just not very evenly distributed.” And perhaps, at first, the different facets of digital and data-driven marketing seemed like specialized skills. But this change has been underway for a long time, and it’s now become so obvious that it’s impossible to miss.

Over the two-plus decades since Gibson made his quip about the future and the web ushered in commercial use of the Internet, several technology stacks have arisen (and sometimes fallen) to enable an ever more intimate (read: data-driven) customer marketing relationship.

So, for marketers, the future indeed already is here. It’s all about the long-term shift in how businesses think about connecting with customers. Conceptually, one of the biggest changes has been an explicit reorientation away from a relatively static notion of marketing—for example, that a customer’s decision to buy is based on a lightning strike of the right combination of the four P’s of product, price, promotion, and place. Instead, most of us today understand that a customer’s experience with a brand or a company really occurs in many steps over time. That experience over time is the “customer journey” that we strive to perfectly fulfill.

But one thing that sometimes gets lost in this acknowledgement of the primacy of the customer journey is that we marketers have been on a journey of our own. Sometimes that journey requires a fresh perspective on our craft. Other times, it means becoming facile with new technologies. And throughout, it depends upon bringing more “science” and empirical decision-making to our creative “art” of communication. But above all, it means not standing still.

(This post originally was published on the SparkPost blog.)