Brent Sleeper

Some of my most constant childhood memories are of evenings at my mother’s family’s cabin in Wisconsin’s North Woods. The cabin sits on Cisco Lake, surrounded mostly by birch and other trees suited to the northern climate and poor soil. My great-grandfather built it by hand alongside his two sons-in-law, one of whom was my maternal grandfather. It now belongs to another branch of our family, but it carries for me the accumulated history that places like this do: the smells, the chairs, the rituals.

The rough-finished, high-ceilinged living room was dominated by a large, free-standing stone fireplace and metal chimney hood in its center. Even in the summertime, nights were generally chilly, and there would be a fire every night. Fifty years on, I easily can smell the woodsmoke, picture the low amber light, and hear the quiet sound of cards methodically being shuffled and slapped on the dining table.

It was a ritual. Every night after dinner, two or three of my great-grandparents and grandparents would sit together around the table and in parallel play a very specific solitaire card game. I didn’t have a name for it other than “cabin solitaire”; as far as I know, the game had no other name, at least not one anyone in the family remembers. But I came to know it by heart just from watching, asking my grandfather for rule clarifications when I needed them.

Superficially, the game resembles Klondike solitaire—the game nearly everyone knows from countless digital versions (the classic Mac shareware remains my favorite). It departs from standard Klondike in ways that make it substantially more complex and more interesting. It uses two decks. It has ten tableau columns instead of seven. And crucially, when you draw from the stock, you don’t choose where the card goes: one card is dealt face-up onto every column in turn, regardless of fit, burying your carefully built sequences under whatever the deck decides to send. The resulting tangles are the game’s central puzzle, and unwinding them—engineering chains of moves to free a buried card before it becomes an unsolvable blockage—is where the real skill lives.

I don’t know where my great-grandparents learned the game. From one of their own families? From the close-knit church community in the small town in which they lived? My grandfather said he learned it from them, my grandmother’s family. Whatever its source, that puts its origins in the early twentieth century at the very latest.

I assumed for years that it must have been described in a Hoyles-style compendium, that I simply hadn’t come across our solitaire variant elsewhere. I’ve periodically looked for references to our game’s rules over the past 25 years, but I’ve found nothing. The game appears in none of the major patience collections, not in David Parlett’s definitive histories, not among Pagat’s references, not on Solitaire Central or any of the software libraries I’ve seen that among them document hundreds of games. The specific mechanic that defines my family’s cabin game—the mandatory round-deal, one card to every column, no exceptions—is unusual in the literature.

So I documented the game myself, with some help from Claude to verify the rules’ logical consistency and alignment with standard solitaire nomenclature. I also chose to give the game a name: Cisco, after the lake. That seems to fit the company of the classics—Klondike, Yukon, Canfield, Cisco—and it will mean something specific to anyone in my family who has spent an evening at our cabin’s table.

Cisco Solitaire Rules

A challenging two-pack solitaire game otherwise known only as “cabin solitaire.” It’s a patience game passed down through at least five generations of my family. Origin unknown, dating to the early 20th century or earlier. Rules documented here for posterity.

Overview

Cisco is a single-player patience game played with two standard 52-card decks (104 cards total). It follows the core structure of Klondike—alternating-color descending tableau packing, suit-ascending foundations—but extends to ten tableau columns, uses a double pack with eight foundations, and replaces Klondike’s selective stock draw with a mandatory round-deal mechanic that distributes one card to every column in turn. This deal mechanic is the game’s defining feature: it deposits cards onto tableau columns regardless of their fit, creating tangled, disordered packets that the player must unwind through careful sequencing. The game is substantially more complex and longer than standard Klondike.

Using two packs with contrasting, complementary back designs is recommended—it is aesthetically pleasing during play and simplifies separating the packs after the game.

Glossary

I’ve tried to use the definitions typically used in solitaire rulebooks, in particular Parlett’s terminology.

Pack. A standard 52-card deck (Jokers removed). This game uses two packs shuffled together.

Stock. The face-down pile of undealt cards set aside after the initial deal. The stock is the source of all subsequent card distributions to the tableau.

Tableau. The ten columns of cards that form the main playing area. Cards in the tableau are available for packing and transfer to the foundations.

Column. One of the ten vertical fans of cards in the tableau. Within each column, cards are spread toward the player so that all face-up cards are visible. The exposed card of a column is the outermost face-up card—the one available for play. Face-down cards in a column are not available for play.

Exposed card. The outermost face-up card of a tableau column. This is the card available for packing onto another column or playing to a foundation.

Packet. A group of two or more contiguous face-up cards moved together as a unit from one tableau column to another. A packet may contain cards that are not in proper packing sequence with one another.

Foundations. Eight piles built up in suit and ascending rank from Ace to King. Two foundations are required per suit (one per pack). Foundations are located above the tableau.

Packing. Placing a card or packet onto a tableau column in descending rank and alternating color.

Components

• 2 standard 52-card packs (104 cards total; Jokers removed)
• A large playing surface—tableau columns grow long during play

Object

To move all 104 cards to the eight foundations, each built up in suit from Ace to King.

Layout

The game has three areas:

Foundations. Eight empty piles above the tableau. Each is started with an Ace of its suit and built up in suit to the King. There are two foundations per suit. Foundations may be started in any order as Aces become available.

Tableau. Ten columns dealt from the combined pack (see Deal below). Columns are fanned toward the player so that all face-up cards are visible. Face-down cards are visible only as to their number and position in the column.

Stock. The remaining face-down pile after the initial deal, set to one side. There is no waste pile.

Deal

Shuffle both packs together thoroughly into a single 104-card pack. Deal the tableau in the staircase pattern of classic Klondike, extended to ten columns. Cards are dealt one at a time, left to right across the columns, repeating from column 1 each time a pass is complete:

• Column 1 receives 1 card (face up).
• Column 2 receives 2 cards (1 face down, with 1 face up on top of it).
• Column 3 receives 3 cards (2 face down, with 1 face up on top).
• … continuing thus …
• Column 10 receives 10 cards (9 face down, with 1 face up on top).

After the deal, 55 cards occupy the tableau and 49 cards remain in the stock. The exposed card of each column is available for play.

Play

Play proceeds continuously; there are no turns per se. The player may make any legal move at any time, in any order, and may deal from the stock at any point (see Dealing from the Stock below).

Packing

An exposed card of any column may be packed onto the exposed card of another column, provided the card being moved is one rank lower and of opposite color to the destination card. Example: the 7♠ may be packed onto the 8♥ or 8♦. Only face-up cards may be moved, and only the exposed card of a column is available as the destination for packing. Face-down cards are never directly available for play.

Moving a Packet

Single exposed cards are not the only cards eligible for movement in the tableau. A packet—any contiguous group of face-up cards taken from the outer end of a column—may be moved as a unit to another column, provided the innermost card of the packet (the card that will make contact with the destination column’s exposed card) is one rank lower and of opposite color to that destination card. This is the same principle as movement in Klondike- and Yukon-style solitaires. As with Yukon games specifically, the remaining cards in the packet need not be in proper packing sequence with one another; they travel with the packet regardless of their internal arrangement. Face-down cards may never be included in a packet.

Foundations

The exposed card of any column may be played to a foundation at any time, provided it is the correct next card in suit and rank for that foundation. An Ace may be played to start a new foundation. Once played to a foundation, a card may not be returned to the tableau.

Vacated Columns

When all face-up cards have been removed from a column and a face-down card is exposed, that card is turned face up and becomes the new exposed card of the column. When an entire column is vacated—all cards removed—only a King, or a packet whose innermost card is a King, may be moved to fill the space.

Dealing from the Stock

The player may choose to deal from the stock at any point during play. Once begun, the deal proceeds as follows without exception:

1. The deal is mandatory and indiscriminate. One card is dealt face up onto each tableau column in order from column 1 (leftmost) to column 10 (rightmost). The player has no choice about which column receives which card. Each card is placed on the column’s current exposed card, becoming the new exposed card of that column, regardless of whether it constitutes a legal packing move.
2. The deal cannot be interrupted. All stock cards to be distributed in the current deal must be placed before any tableau moves may be made.
3. Final deal. When fewer than 10 cards remain in the stock, the deal proceeds left to right until the stock is exhausted. Columns beyond the last card receive none. The player may not skip any column—cards are dealt strictly left to right until the stock is empty.
4. No redeal. Once the stock is exhausted it is not reshuffled or redealt. All remaining play is from the tableau only.

Stock deal arithmetic (standard game)

With 49 cards in stock after the initial deal:

Winning and Losing

The game is won when all 104 cards have been played to the eight foundations.

The game is lost when the stock is exhausted and no legal moves remain in the tableau.

Strategy Notes

The stock deal mechanic is what distinguishes this game from other documented Klondike variants. Each deal deposits cards indiscriminately onto every column, frequently burying useful sequences beneath out-of-order cards and creating tangled packets that must be methodically unwound.

Key strategic considerations:

• Timing the deal. The player chooses when to deal. Deciding whether to deal now or continue working the tableau first is a meaningful strategic decision at every stage of the game.
• Column order matters. Because the final partial deal is distributed strictly left to right, what sits atop each column—and which column occupies which position—becomes strategically significant as the stock dwindles.
• Blocker awareness. Both copies of every card are required to complete the eight foundations. A low card (particularly a 2 or 3) buried deep in a disordered packet can become a game-ending blocker if it cannot be reached. Identifying and freeing potential blockers is a central late-game skill.
• Vacated columns are precious. An empty column is a powerful resource but can only be filled by a King. Managing when to vacate a column and which King to place there requires foresight.
• Packet movement is the primary tool. The ability to move any group of face-up cards as a unit—requiring only that the innermost card of the packet makes a legal packing move onto the destination—is what makes unwinding possible. Most of the game’s critical decisions involve engineering a sequence of moves that relocates a marooned packet to expose the cards buried beneath it.

Relationship to Known Games

Cisco’s Cousins

Cisco shares structural features with several documented patience games beyond its superficial similarities to Klondike, but it does not appear to match any of them exactly:

• It has some elements in common with Rank and File (a Napoleon at St Helena/Forty Thieves variant) in using two packs, ten tableau columns, eight foundations, alternating-color descending packing, and packet movement.
• It structurally resembles Gargantua (Double Klondike) in its Klondike-style staircase deal, King-only empty column rule, and overall character.
• Its card movement and untangling of unordered sequences is characteristic of Yukon.
• Cisco’s most significant antecedent may be Miss Milligan, a two-pack patience first documented in print in the early 1900s. Miss Milligan shares with Cisco a core mechanic that defines both games: when the player deals from the stock, one card is distributed face-up onto every tableau column in turn, regardless of fit. However, Miss Milligan also differs in meaningful ways, dealing the initial tableau flat rather than in a Klondike staircase and including a post-stock “waiving” (or “weaving”) grace mechanic not present in Cisco.
• A Miss Milligan variant called Milligan Yukon—a rather literal cross between Miss Milligan and Yukon—may be the rules closest to Cisco’s. Milligan Yukon appears only in modern software-era catalogs and not in earlier literature, suggesting either a late formalization or an independent convergence.

Taxonomy and Behavior

Cisco can be understood as a hybrid of three established patience systems, combined in a unique configuration not clearly documented elsewhere:

• From Klondike it takes its structure: the staircase deal, alternating-color tableau packing, suit-built foundations, and King-only empty columns.
• From Yukon it takes its movement model: any face-up packet may be moved as a unit, regardless of internal order.
• From Miss Milligan it takes its stock mechanic: a deal that distributes one card to every column indiscriminately.

In most patience taxonomies, movement rules and stock behavior are the dominant modes of classification. That places my game closest to the Milligan-Yukon family of variants that combine Miss Milligan’s row-deal with Yukon-style packet movement.

Cisco, however, differs structurally in three significant ways from a pure Milligan Yukon game: it uses a ten-column Klondike-style tableau and structural constraints, it omits the reserve and relief mechanisms found in most Milligan variants, and it produces deeper, more entangled positions. It feels very familiar, but plays significantly harder.

Thus, a shorthand description of Cisco might be:

Cisco = Klondike framework + Yukon movement + Miss Milligan deal mechanic

Provenance

The game has been played in my family for at least five generations: my great-grandparents, grandparents, mother and uncle, myself and my siblings, and now my own children. It originated in the early 20th century or perhaps the late 19th. Its canonical name, if it ever had one, is not known.

These rules were documented April 2026 with the assistance of Claude AI observing my gameplay as I narrated with photographs and then clarified ambiguities through a series of interactive Q&A prompts.

As I said earlier, I believe Cisco is a heretofore-undocumented solitaire. But if I’m wrong, and you know the game, please let me know!

Note: I list some offensive words in this post.

I’ve been playing a lot of the new Crossplay Scrabble-style word game from The New York Times, mostly against my sister (and mostly unsuccessfully).

Unlike Scrabble, Crossplay automatically checks word validity on plays, so the game doesn’t feature bluffing or challenges. That got the word nerd in me wondering about its dictionary and playable word list. I did some sleuthing.

These Are Not the Dictionaries You’re Looking For

Before diving into the words allowed in the Crossplay game, understand that the most serious Scrabble players do not use ordinary dictionaries as the authority for playable words.

Tournament-level Scrabble has a lexicon that is large, obscure, sometimes profane, and the product of occasionally awkward negotiation among the game’s manufacturer, dictionary publishers, and the competitive Scrabble community.

On the other hand, casual players turn to standard references such as Merriam-Webster or maybe The Official Scrabble Players Dictionary for the especially dedicated. These dictionaries designed for general use don’t specifically list every game-legal word form, and the common abridged editions omit a large number of obscure or controversial, but playable, words.

Tournament play uses something different: comprehensive, curated word lists derived from dictionaries but authoritative for competitive gameplay. These lists enumerate every legal word form individually, including pluralizations and inflections that ordinary dictionaries treat as grammatical variants rather than separate headwords.

In the U.S., the primary tournament standard is the NASPA Word List, maintained by the North American Scrabble Players Association (NASPA). The current 2023 edition is commonly referred to as NWL2023.

In most English-speaking regions other than North America, competitive Scrabble uses a different lexicon known as Collins Scrabble Words (CSW), derived primarily from Collins dictionaries. The Collins lists are larger and somewhat more permissive than the NASPA lists.

As a result, a word that is legal in one tournament may not be playable in another. Like so many norms, “dictionary authority” in Scrabble is a negotiated concept rather than a simple appeal to Webster or Oxford.

196,419 Words and Counting

Casual word games often sanitize their allowable vocabulary. Many ship with word lists that are thousands of words smaller than standard tournament lexicons.

When it comes to word choices, NYT Games has another very particular layer of consideration. The paper’s games editors express a distinctive voice across its platform: crosswords, Spelling Bee, Wordle, etc. I’d assumed the Crossplay dictionary similarly would show evidence of an opinionated editorial hand: an emphasis on general knowledge, maybe the addition of some NYT jargon or tics, and almost certainly an aversion to working blue.

So, where to start? The Crossplay app explicitly credits NASPA as a source of its word list. I did some forensics (fancy word, but worth only 14 points in the game) on the Crossplay dictionary and compared it against NWL2023.

I was surprised to discover that the two lists turn out to be nearly identical. Specifically, the Crossplay word list contains 196,419 entries. NWL2023 contains 196,601. That means the Times removed precisely 182 words from NASPA’s list.

What do those removed words have in common, and what does the Crossplay database suggest about the game’s design? It’s more interesting than the number of entries alone suggests. Or, at least interesting to a nerd like me.

Examining the Crossplay Dictionary

The Crossplay word list is stored internally in a SQLite database inside the app’s software. To look at it, I extracted the file from a copy of the game‘s iOS .ipa bundle saved from my iPhone.

The table is structured such that each row represents a single playable word and includes a number of associated metadata fields. Exporting the table’s entries produces a dataset with 196,419 rows and 9 columns.

An excerpt of about a dozen words in the A alpha-sort range illustrates the format:

(Note: I trimmed content in the definition field for the sake of space.)

The first word field is the essential one. It defines the playable vocabulary. Matching this column with the NWL2023 headword list allows a direct comparison of the two lexicons. It’s just math:

• NWL2023 entries: 196,601
• Crossplay entries: 196,419
• Difference: 182

Given the number of words we’re talking about, a difference of 182 entries is remarkably small—less than one tenth of one percent. Crossplay’s word list is almost exactly the same as the one used in North American tournament Scrabble.

What the Crossplay-Brand Word Game Removed

A list of 182 words is pretty easy to scan, and a cursory glance showed that nearly every one of the removed words is derived from a trademark, brand, or proprietary product name.

Examples include:

• BENADRYL
• CINEPLEX
• CUISINART
• FORMICA
• JACUZZI
• KLEENEX
• ROLLERBLADE
• TASER
• VELCRO

Entire inflectional families disappear together. For instance:

• BREATHALYZER
• BREATHALYZE
• BREATHALYZED
• BREATHALYZES
• BREATHALYZING

Some of the removed words are widely regarded as genericized trademarks, meaning the original brand name has long since entered common usage. Examples include:

• FRISBEE
• KLEENEX
• LAUNDROMAT

The decision to remove brand names in general makes sense in the context of a commercial software product. Tournament Scrabble lists include these words because they appear in published dictionaries, but a game developer might reasonably prefer to avoid trademark complications entirely.

However, if the issue were potential legal liability for trademark misuse, expired and other legacy brand terms should not have been a cause for concern. Their removal suggests an automated filtering rule applied to the source dataset, rather than a specific deliberate judgment by NYT Games editors. If the underlying lexical database flagged an entry as trademark-derived, an automated filter would remove it regardless of whether the word has become generic in practice.

Three Black Sheep

A very small handful of (and by small, I mean exactly three) removed words do not obviously derive from trademarks. The words are:

• ADRENALIN
• ADRENALINS
• ASBESTINE

These are simple spelling variants (ADRENALIN for ADRENALINE) and the adjectival form of ASBESTOS. I have no explanation for why these and no other brand-neutral obscurities were removed from the NWL2023 source.

Talk Dirty to Me

The more surprising thing to me was what the Times did not change.

Aside from the trademark filter, the Crossplay lexicon tracks NWL2023 almost perfectly. That includes vocabulary many players might expect the Gray Lady to avoid.

For example:

• ASSHOLE
• COCKBLOCK
• FUCK
• MILF
• TITTIES

All remain valid words in Crossplay.

Before examining the data I had assumed that the dictionary might be somewhat bowdlerized to better suit a family newspaper. Instead, Crossplay adopted the tournament lexicon almost wholesale.

For competitive Scrabble players (along with snickering middle-schoolers and just plain grown-ups who use grown-up words) this is good news. It means the game’s vocabulary basically matches the one used in sanctioned play.

Slurs Not Welcome

You might notice that certain offensive words are absent entirely. Those removals did not originate with Crossplay.

In 2020, NASPA removed about 200 slurs targeting specific categories of personal identity from the allowed tournament list. This decision was somewhat controversial in the community (with the predictable sort of opposition), but it was the right one. NASPA eventually codified the criteria for removal in an official policy. Those changes were incorporated into subsequent lexicon releases, including NWL2023.

In a weird coincidence, the number of slurs removed from NWL (182) exactly matches the number of additional words removed from the Crossplay dictionary. Counterintuitively, this is pure coincidence; the Times’ list is unrelated to word offensiveness, and the two lists of struck words have nothing in common other than count.

NASPA did not completely ban offensive words. As I noted earlier, words inappropriate for polite company but not directed at identity groups largely remain in the lexicon. Moreover, words that have established, non-slur meanings in standard dictionaries also were retained.

Examples of the latter include uncomfortable words like:

• BITCH
• CRACKER
• DYKE
• FAGGOT

The NWL list continues to include these because dictionaries document the neutral sense (dog, snack, levee, bundle of sticks, etc.).

By contrast, the Collins lexicon used in Commonwealth countries has not adopted the same broad removal of slurs, meaning that many offensive words absent from NWL still appear in CSW.

Crossplay’s NWL and Oxford Languages Sources

Unlike most Scrabble word lists, the Crossplay dictionary is more than a list of playable words. Each entry includes substantial linguistic metadata.

Fields include:

• Part of speech
• Pronunciation in IPA
• Usage labels
• Corpus frequency values
• Flags controlling AI behavior

These fields show how the dictionary was assembled from more than one source. We’ve established that every playable word originates from NWL2023, but acknowledgements in the Crossplay app indicate that most of the definitions and linguistic annotations in the data come from Oxford Languages, the dictionary data division of Oxford University Press.

Deducing meaning from the source field in the database:

• source = 1 → Definition and metadata are Oxford-sourced
• source = 0 → Definition is NASPA-sourced

Out of the 196,419 entries in the database:

• Oxford definitions: 195,371
• NASPA definitions: 1,048

Oxford and other standard dictionaries typically list only a base lemma and describe inflected forms grammatically rather than creating separate entries for each spelling. Scrabble lists, by contrast, enumerate every playable word individually.

The 1,048 NASPA entries contain only a brief definition and no other metadata — and for many examples, that definition is simply, “An offensive word.” These 1,048 correspond largely to forms that Oxford does not treat as independent headwords. They are Scrabble-style variants that include technical words, offensive language, non-standard inflections, alternative spellings, or verbalisms.

How the Dictionary Data Appears in the Game

These source-and-register distinctions are visible in the Crossplay interface itself.

When a word’s entry comes from Oxford, the in-game dictionary shows a full lexical entry: definition, part of speech, pronunciation, and usage labels.

When the entry is sourced from NWL instead, the interface explicitly indicates that the definition, if even present, derives from the NASPA word list.

Labels such as vulgar or derogatory also are visible in the app’s dictionary UI and correspond directly to the register column in the database.

Scrabbling for 15 Letters

Another column in the database contains a numeric frequency score that appears to be derived from the Oxford English Corpus, a large database of published English texts. Analyzing this column emphasizes the stark difference between everyday vocabulary and the Scrabble lexicon.

In the real world, the average corpus frequency declines sharply as words grow longer. That’s not the case with the contents of Crossplay’s dictionary.

Scrabble words are a specialized vocabulary optimized for combinatorial play, not a natural language. The disproportionate number of 10- or 15-letter words in the game dictionary reflects the peculiar composition of these word lists, which include thousands of rare technical terms from fields such as botany, chemistry, and taxonomy that maximize utilization of the game’s 15×15 grid. Words like PSITTACINE (relating to parrots) or ZYZZYVA (a genus of weevils) are perfectly legal Scrabble plays but appear almost never in ordinary English writing.

Words Available to Crossplay’s Computer Opponent

The database includes two flags we can conclude govern in-game behavior:

• isOffensive
• isPlayableByComputer

1,049 words are marked isOffensive = 1 (true), and 1,413 words are labeled isPlayableByComputer = 0 (false). Examining the two lists shows that every word marked offensive is unplayable by the computer, but not every word marked unplayable is also considered offensive. To be precise, the offensive words are a strict subset that is 364 entries smaller than the total unplayable words. In mathy terms:

{isOffensive = 1} ⊊ {isPlayableByComputer = 0}

The overlap of the two sets reveals several categories of words the computer player can’t use.

First, the AI won’t play words flagged as offensive or derogatory.

Second, it skips certain socially sensitive topics. For example, the Crossplay dictionary includes several abortion-related terms that are legally playable but flagged as unavailable to the computer player.

Finally, the obscurity of the remaining unplayable words suggests the AI avoids vocabulary that would feel implausible to casual players.

In short, the computer player seems to filter for:

• No offensive language
• No social hot-button topics
• No obtusely uncommon words

There may be additional rules coded in the software, but the in-game behavior I observed generally matches the signals contained in the word database.

None of these constraints apply to human players. You and I are free to use the full lexicon represented in the Crossplay dictionary.

Crossplay Uses a Faithful Scrabble Dictionary

Taken together, the evidence shows that Crossplay’s vocabulary is essentially NWL2023 minus 179 trademark-derived words and three additional randos. Everything else—from obscure botanical Latin to crude profanity—remains intact.

Having said that, the Crossplay dictionary itself turns out to be an interesting window into how the game works.

• The NASPA Word List provides the authoritative list of playable words.
• Oxford Languages supplies definitions, pronunciations, and corpus statistics.
• The Times removed trademark-derived vocabulary.
• Additional metadata guides the behavior of the computer opponent.

For a casual word game published by The New York Times, that is a surprisingly faithful implementation of the competitive Scrabble lexicon. The result is a dictionary that preserves the full eccentricity of the tournament Scrabble vocabulary while still allowing the game’s AI to behave in a way that feels reasonable to ordinary players.

P.S. I made a list of all 182 words removed from NWL2023 for Crossplay for easy download.

I have a hot crush on the Love Factually podcast by Eli Finkel and Paul Eastwick. It’s a two-man show that uses rom-com movies as a framework to discuss the social science and psychology of romantic and other close relationships.

It’s terrific. I like that the hosts mix genuine critical appreciation with a pedagogical frame. They are affectionate, humane, and thoughtful about relationship dynamics.

The podcast launched with the ur-example of the genre, When Harry Met Sally. Though the hosts don’t explicitly discuss it, one of this movie’s best-characterized details is its music. In fact, listening to the podcast prompted me to do something I’d been intending for a long time: make a playlist of the actual music heard in the movie, in the order it appears in the story.

It Had to Be You

I did my best to recreate the film’s exuberant on-screen musical arc, and you can listen here: When I Met Harry and Sally (Full Film Order).

A couple of songs from the film are unavailable on Apple Music. Each might be best described as a brief musical cameo.

The first is heard second-hand in the indelible scene at the end of Casablanca. Harry and Sally are in their individual beds talking on the phone, watching Humphrey Bogart say to Claude Rains, “Louis, I think this is the beginning of a beautiful friendship,” before “La Marseillaise” plays in the background of the film’s end credits. I substituted a straight-ahead recording of the French national anthem that somehow works almost perfectly as a break between Acts I and II in my cinematic playlist.

The second missing song is from a brief moment when Harry and Sally perform a goofy karaoke-style version of “Surrey with a Fringe on Top.” That’s not something that was ever going to be released as a single, so I added a fantastically moody recording of Wes Montgomery performing at the Blue Note club in New York. Tonally, it’s a faithful fit for the songs that surround it.

The final missing song is something you easily could overlook because it’s almost subconscious, ambient place-setting to the intensely foregrounded dialog in the movie’s climactic New Year’s Eve scene. It’s Louis Armstrong performing “Auld Lang Syne.” While there is a live 1954 recording he made for CBS Radio in San Francisco that’s a just-perfect fit, it unfortunately is not available to stream. I decided to leave that song out for now rather than substitute an imitation.

I Could Write a Book

Columbia Records’ commercially-released soundtrack album exclusively features Harry Connick, Jr. It is fantastic, and it turned me onto jazz singers as a whole class of performance when I was a baby listener. Today, I imagine most people (myself included) remember the film’s music as “the Harry Connick, Jr. soundtrack.” That’s not wrong. His songs are prominent in the film’s atmosphere.

But the movie has a fuller musical palette that mirrors Harry and Sally’s story arc:

• FM radio from the late 70s (opening road-trip scenes)
• Big-band swing and Songbook recordings (exuberant and joyful New York friendship)
• Jazz trio arrangements (emotional intimacy and connection)
• Holiday standards (bookending their split and reunion)

Even with the handful of 70s pop songs (and the interjection of “La Marseillaise”) the whole has great flow The soundtrack echoes the movie’s seasons—autumn in New York, winter holidays, New Year’s Eve—and how Harry and Sally’s relationship develops.

Where or When

Putting together the playlist was fun to do. Listening to the movie’s songs again made it obvious how tightly bound music is to emotional memory. That’s probably the point. A theme of the movie is the way couples develop their shared stories, how people remember falling in love. That’s exactly how the soundtrack works.

For me, it recalled two particular moments. The first is seeing the movie for the first time at a theater in 1989. I was a 19-year-old on winter break during college. I was enthusiastically head-over-heels for the person I was dating. She’d taken me to see the movie over the week between Christmas and New Year’s, before we returned to school for our winter term. It’s a nice but very ordinary young-college romantic memory. I was (and remain) a sentimental fool.

I have more vivid recall of a different moment. It was a few weeks before I’d seen the film with my girlfriend, so I knew nothing about the movie.

I was working in a chain record store in a shopping mall in northern New Jersey over my six-week holiday break. The soundtrack album had come out earlier in the year and was doing a decent amount of business in our store leading up to Christmas.

I was standing at the cash register when a customer stormed up, holding the CD, furious. In a textbook Jersey accent, he demanded, “Who the fuck is this guy? These are Sinatra’s songs!”

He meant Connick. Though I didn’t have a clue (I was feeling serious “Sir, this is a Wendy’s” vibes), the complaint made sense later when my appreciation of the Songbook era of pop music history developed.

I realized Jersey Guy wasn’t entirely wrong. For a lot of Sinatra fans—especially there and then—those standards weren’t just members of the American songbook. They were Frank Sinatra songs, period.

But Connick deserved more credit than that. Sinatra and his contemporaries built their careers doing exactly what Connick was doing: reinterpreting standards. It’s how the music business worked when Tin Pan Alley still reigned. The idea of a singer-songwriter as the norm came much later.

Still, as great as the Connick recordings are, the music as actually played in the movie is fuller and more varied than the commercial soundtrack album. Hence, this playlist.

I’ve been carrying around an unformed thought for more than three months after I posted about Dick Cheney’s death. My brain works like that sometimes.

On an episode of the Slate Political Gabfest a few days after Cheney died, hosts David Plotz, John Dickerson, and Emily Bazelon were discussing Cheney’s legacy and whether his advocacy for extraordinarily strong executive power as George W. Bush’s vice president had set the table for Donald Trump’s autocratic (and despotic) behavior today.

Bazelon:

Cheney [had the] idea that he knew better and that the office of the president should be very strong because a wise, national-security-minded person like him was in charge.

There’s a real irony to how he wound up opposing Trump later in his life, I think a lot because of his daughter. Liz Cheney was being such a strong rule-of-law, stand-up-to-Trump figure in the Republican Party, for which she obviously paid a huge political and personal price. It was like the scales fell from Dick Cheney’s eyes—that if you gave all this power to the presidency and then it turned out the person who occupied the office was not someone you liked or trusted or thought well of, well, maybe that wasn’t such a good idea.

Dickerson:

Yeah, I don’t think he reflected on that. I think he thought the presidency could still be as muscular as he wanted. You just shouldn’t have, as he said, Trump—the most dangerous person in the history of the republic. Two hundred forty-eight years, he said.

I think what’s maybe the most striking thing is that he didn’t reflect on the fact [of what] his theory [had become].

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.