Marketing Playbook

The Marketing Playbook is a forthcoming book [the blog]. A brief description from the authors John Zagula and Rich Tong:

Most of the time marketing -is way too complicated. One way to keep it simple is to think of it like a game. A game where you need strategy – the Marketing Play, you need intelligence about what you are up against – the Marketing Playing Field, and you need some guidelines for when you actually run down the field – the Campaign.

The Marketing Playbook idea is really just a concept or system for keeping these three elements organized and at hand. It is also the lense through which we make sense out of a lot of what we see in business out there.

It enumerates the Marketing 5 Marketing Plays:

  • Drag Race: “you pick one competitor to compare yourself to and then you put all you have into beating them across the finish line.”

  • Platform: “you generally choose to ignore the competition, or even coopt them. Instead you win by becoming a Platform from which a whole industry can win too. You win by making it easy and profitable for others to ally with you and painful for them to let you loose.”

  • Stealth: “this is almost the opposite of the Drag Race. When you run stealth you are trying to avoid getting squished by the competition. Generally you focus on a specific niche where you can build your strength unnoticed, or you peacefully coexist and even draft behind a would-be competitor. Until you have what it takes to move onto another more open and larger play.”

  • Best of Both: “Many product and services categories have both high and low end offerings – and never the twain shall meet. In Best of Both you aim to gain dominance the whole category by collapsing both high and low ends into a new more compelling offer. You winning by offering ‘your cake and eat it too.'”

  • High-Low: “this is basically the opposite of the Best of Both Play. Here, instead of offering a combination that collapses the extremes of a category, you emphasize the importance of choice. You offer both extremes, no compromises and a migration path between them.”

  • Gmail and Hailstorm

    Steve Gillmor offers a comparison:

    [Microsoft’s] HailStorm’s notion of a massive in-memory cloud of XML data and metadata was doomed, not by the daunting mechanics of schematizing a broad set of generic business processes or assembling a mesh network of server clusters, but by the fears of many that Microsoft would commandeer personal information to achieve network domination, as it once seized the desktop.

    Basic to Google’s rise is its Tom Sawyer-like success in harnessing others’ work to its benefitcorralling their requests for information to create an authority map based on page rank. The resulting rank becomes the coin of the realm, leveraged for intelligent search responses, targeted advertising and services designed by Google and its users through Web services API calls.

    At the core of Google’s dynamic is implicit metadata, made on the fly by users as they reveal their interests by browsing, messaging, filling out Web forms and creating documents. Separating the metadata from the underlying data it describes has let Google initiate a conversation in which users effectively trade general personal data for access to services derived from the aggregated requests. This scoped contract between users and the cloud sidesteps most privacy and political concerns. Where HailStorm required a Passport account to enter the network, Google merely requires a willingness to view additional informationadvertisingthat has been dynamically generated based on user metadata inputs to the system.

    The implicit metadata contract between users and services is creating what open-source journalist Doc Searls calls “mutant” companies, where startups’ services mutate to exploit users’ wishes and desires.

    In his eWorld keynote, BEA’s chief architect, Adam Bosworth, cited the similar transformation around the GUI, which gave procedural control to users. Now RSS is creating another shift, away from the Web request model to user-controlled aggregation. TiVo-like user metadata can be harvested to offer services in return for access to group and trend data. And as RSS containers become more intelligent about applying authority filtering to feeds, the signal to noise improves. Bosworth showed eWEEK Senior Writer Darryl K. Taft and me an intelligent RSS router, built atop his Alchemy extended browser project, a framework that uses declarative metadata dynamic caching to create a rich conversation between a thin client and the server cloud. Sounds like HailStorm, I told Bosworth, who didn’t disagree. But a HailStorm based on a framework BEA will open-source.

    How Microsoft Lost the API War

    Joel Spolsky writes: “Microsoft’s crown strategic jewel, the Windows API, is lost. The cornerstone of Microsoft’s monopoly power and incredibly profitable Windows and Office franchises, which account for virtually all of Microsoft’s income and covers up a huge array of unprofitable or marginally profitable product lines, the Windows API is no longer of much interest to developers. The goose that lays the golden eggs is not quite dead, but it does have a terminal disease, one that nobody noticed yet.”

    One of the points made by Joel:

    Every developer has a choice to make when they plan a new software application: they can build it for the web or they can build a “rich client” application that runs on PCs. The basic pros and cons are simple: Web applications are easier to deploy, while rich clients offer faster response time enabling much more interesting user interfaces.

    Web Applications are easier to deploy because there’s no installation involved. Installing a web application means typing a URL in the address bar. Today I installed Google’s new email application by typing Alt+D, gmail, Ctrl+Enter. There are far fewer compatibility problems and problems coexisting with other software. Every user of your product is using the same version so you never have to support a mix of old versions. You can use any programming environment you want because you only have to get it up and running on your own server. Your application is automatically available at virtually every reasonable computer on the planet. Your customers’ data, too, is automatically available at virtually every reasonable computer on the planet.

    But there’s a price to pay in the smoothness of the user interface. Here are a few examples of things you can’t really do well in a web application:

    1. Create a fast drawing program
    2. Build a real-time spell checker with wavy red underlines
    3. Warn users that they are going to lose their work if they hit the close box of the browser
    4. Update a small part of the display based on a change that the user makes without a full roundtrip to the server
    5. Create a fast keyboard-driven interface that doesn’t require the mouse
    6. Let people continue working when they are not connected to the Internet

    These are not all big issues. Some of them will be solved very soon by witty Javascript developers. Two new web applications, Gmail and Oddpost, both email apps, do a really decent job of working around or completely solving some of these issues. And users don’t seem to care about the little UI glitches and slowness of web interfaces. Almost all the normal people I know are perfectly happy with web-based email, for some reason, no matter how much I try to convince them that the rich client is, uh, richer.

    So the Web user interface is about 80% there, and even without new web browsers we can probably get 95% there. This is Good Enough for most people and it’s certainly good enough for developers, who have voted to develop almost every significant new application as a web application.

    Which means, suddenly, Microsoft’s API doesn’t matter so much. Web applications don’t require Windows.

    It’s not that Microsoft didn’t notice this was happening. Of course they did, and when the implications became clear, they slammed on the brakes. Promising new technologies like HTAs and DHTML were stopped in their tracks. The Internet Explorer team seems to have disappeared; they have been completely missing in action for several years. There’s no way Microsoft is going to allow DHTML to get any better than it already is: it’s just too dangerous to their core business, the rich client. The big meme at Microsoft these days is: “Microsoft is betting the company on the rich client.” You’ll see that somewhere in every slide presentation about Longhorn. Joe Beda, from the Avalon team, says that “Avalon, and Longhorn in general, is Microsoft’s stake in the ground, saying that we believe power on your desktop, locally sitting there doing cool stuff, is here to stay. We’re investing on the desktop, we think it’s a good place to be, and we hope we’re going to start a wave of excitement…”

    The trouble is: it’s too late.

    The new API is HTML, and the new winners in the application development marketplace will be the people who can make HTML sing.

    Slashdot has a discussion.