The Law of Remarkability

Reflecting on Giles’s story, I kept coming back to the same adjective: “remarkable.” What Giles discovered, I decided, is that a good mission-driven project must be remarkable in two different ways. First, it should be remarkable in the literal sense of compelling people to remark about it. To understand this trait, let’s first look at something that lacks it. Before releasing Archaeopteryx, Giles had worked on another open-source project. He collected popular command-line tools for Ruby and combined them into one package with consistent documentation. If you asked a Ruby programmer about this project, he would tell you that this is solid, quality, useful work. But it’s not the type of achievement that would compel this same Ruby programmer to write his friends and tell them, “You have to see this!”

In the words of Seth Godin, this early project was a “brown cow.” By contrast, teaching your computer to write its own complex music is a purple cow; it inspires people to take notice and spread the word.

What’s nice about this first notion of remarkability is that it can be applied to any field. Take book writing: If I published a book of solid advice for helping recent graduates transition to the job market, you might find this a useful contribution, but probably wouldn’t find yourself whipping out your iPhone and Tweeting its praises. On the other hand, if I publish a book that says “follow your passion” is bad advice, (hopefully) this would compel you to spread the word. That is, the book you’re holding was conceived from the very early stages with the hope of being seen as “remarkable.”

There’s also, however, a second type of remarkability at play. Giles didn’t just find a project that compels remarks, but he also spread the word about the project in a venue that supports these remarks. In his case, this venue was the open-source software community. As he learned from Chad Fowler, there’s an established infrastructure in this community for noticing and spreading the word about interesting projects. Without this conduciveness to chatter, a purple cow, though striking, may never be seen. To be more concrete, if Giles had instead released Archaeopteryx as a closed-source piece of commercial software, perhaps trying to sell it from a slick website or at music conventions, it probably wouldn’t have caught fire as it did.

Once again, this notion of remarkability applies beyond just Giles’s world of Ruby programming. If we return to my example of writing career-advice books, I realized early on in my process that blogging was a remarkable venue for introducing my ideas. Blogs are visible and the infrastructure is in place for good ideas to quickly spread, through, for example, linking, Tweets, and Facebook. Because of this conduciveness to remarking, by the time I pitched this book to publishers, I not only had a large audience who appreciated my views on passion and skill, but the meme had spread: Newspapers and major websites around the world had begun to quote my thoughts on the topic, while the articles had been cited online and Tweeted thousands of times. If I had instead decided to confine my ideas to paid speaking gigs, for example, my mission to change the way we think about careers would have likely stagnated—the venue would not have been sufficiently remarkable.

To help organize our thinking, I’ll summarize these ideas in a succinct law:

The Law of Remarkability

For a mission-driven project to succeed, it should be remarkable in two different ways. First, it must compel people who encounter it to remark about it to others. Second, it must be launched in a venue that supports such remarking.

Once I had articulated this law, I began to notice it at play in the examples I had previously found of mission leading to a compelling career. To help cement this marketing-centric approach to mission, it’s worth taking a moment to return to these examples and highlight the law in action.