Platforms need developers to succeed, so you need stories that resonate with developer’s worldview. Stories that you live to make true.
Your stories must be true. Developers can spot lies and it’s easier than ever to spread bad news, such as on Facebook. Not to pick on Facebook, but they serve as an example of conflict between a platform vendor and developers.
Facebook is a platform for third-party applications. And not just for games; you’ll find a range of business and marketing applications as well. After all, with Facebook’s massive user base there’s money to be made.
Success in today’s software industry means building the skills to tell stories that will resonate with your audience’s existing worldview.
Bruce Nussbaum’s article Facebook’s Culture Problem May Be Fatal shows what went wrong when Facebook chose to tell a new story inconsistent with the worldview of their core users.
Watch out if a prospect asks you to prove your story’s true. Instead, seek out an audience inclined to believe your story.
I developed applications for CICS on IBM mainframes in the 1980s. At that time IBM had a project to reimplement CICS using formal methods. Reading about the Verification Grand Challenge reminded me of that project.
An ambitious 15-year international research project, its goal is to create a large repository of useful code, verified to the highest standards of rigour and accuracy. An early case study applied automated verification tools to prove CICS is formally correct. For this they used the CICS Z notation specifications from the 1980s.
There’s no time to think when you’re surrounded by fire. You need to put it out for good by starving it of fuel: customers who don’t fit.
Fire-fighting often becomes a core competency at software companies. The usual cause? Our dread of no revenue forces us to accept customers who are not consistent with our worldview. Unique customers cause trouble.
You’re doing the best you can to deliver great software. You pull all nighters and work weekends to satisfy each hard-won customer. Been there. Done that. But, while it’s great to play the hero fire-fighter occasionally, in the end something’s got to give.
I saw first-hand what happens when your worldview hold’s you hostage: we lost out on a deal worth hundreds of millions of dollars.
Worldviews change; ignore at your peril. At Dynasty Technologies Inc. in the 1990s, I saw first-hand what happens when your worldview holds you hostage.
Dynasty was a 2nd generation client/server application development tool. Our main competitor was Forté Software Inc. Founded in the mid 1990s, both companies had significant venture capital funding with a growing global base of enthusiastic early adopters.
The Dynasty Development Environment generated native C/C++ code with no runtime system. Forté generated proprietary code with a runtime interpreter. For some developers runtimes were OK; for others a pure incarnation of evil. Customer’s runtime worldview was decisive for sales.
The Clang compiler recovers from unknown tokens using a spell-checker. Something small can be remarkable and worth spreading.
Being remarkable doesn’t always mean you have to develop something large. Sometimes remarkable is small, as this Clang example seen today on Hacker News demonstrates very nicely.
Clang is an open-source compiler front-end for C, C++ and Objective C. The project builds on the LLVM compiler back-end with the goal of replacing the GCC tool chain. Their worldview accepts that programmers can and do make mistakes. Amazing feats of Clang Error Recovery shows how they’ve woven this worldview into the compiler.
What caught my eye was how Clang recovers from unknown tokens. Instead of unhelpful error messages (like GCC), the Clang team chose to do something remarkable: they added a spell-checker to guess what you mean:
Apple launches the iPad today, so time to share my Steve Jobs story. It’s about the nearest I’ll ever come to working with him!
The story’s set 20 years ago when I was building cross-platform application development tools. Our customer’s worldview was that their applications would be running for decades. They expected to move from one platform to another as technology changed. They wanted to build platform-independent apps.
Customers liked hearing what others were doing. One story was about a customer in Switzerland using a Unisys mainframe as a server. Nothing unusual there. What made them remarkable, however, was that their clients were NeXT workstations from Steve Jobs’ Next Computer, Inc. Back then this sounded (and was) an exotic combination.
Because millions of users associate WordPress with free, the VaultPress team wove their paid-only story into their beta sign-up form.
A post about VaultPress on Mike Davidson’s blog reminds us that weaving a story into software can be easy. VaultPress is from the great team behind WordPress and is a real-time backup service for self-hosted WordPress blogs.
Most WordPress products are freemium. VaultPress is paid-only: a high-end product for high-end users. Or: VaultPress is for people whose worldview leads them to expect to pay for backups. That covers me, and I don’t consider myself a high-end user!
WordPress is very visible company with millions of users. Many of these will notice VaultPress and take a look. Because most users associate WordPress with free, the VaultPress team wove their story into their beta sign-up:
In a famine of qualified prospects, you’ll try to grab anything that appears edible. Lack of a reliable sales process is corrosive.
When prospects are rare you’ll do everything to win. Development adds features. Marketing invents ROI justifications. Prospects are too precious to waste; you cannot risk letting even one get away. You do whatever it takes.
Lack of a shared worldview is an increasing problem as you grow. Special cases abound; exceptions appear. Everybody is paranoid about saying no.
To see how sticking to a clear understanding of your worldview changes everything, take a look at 37signals. They are a 20 person company selling web-based apps for small groups and individuals. With more than 3 million users, they are very profitable.
As Blaise Pascal (sort of) said: it takes longer to write a long post than a short one; ‘Writing is rewriting’ is so true.
Today I’m looking back on Story Complete’s first month. This is the 17th consecutive day I’ve posted. While at first I found the daily schedule difficult, I’m hoping practice makes perfect.
Written preparation is often the path to success, whereby the writing part is essential. My daily schedule forces me to click that scary WordPress publish button. On the other hand, sharing my thoughts in writing helps me clarify what I’m trying to say.
Identify returning users as VIPs: those most likely to spread your story. Treating everyone the same is easy, but they deserve better.
Existing users are more likely to recommend you than new one, so don’t treat everyone the same. Existing and new users have different expectations, even though they share a common worldview.
A chainsaw cannot change itself depending on whether a newbie or an experienced lumberjack picks it up. Your software is not a physical product. It’s easy to support multiple expectations from a single code base, just as you do with i18n and L10n.
The German tax system is complex (it’s said 80% of the world’s tax laws are in German). As a result, a large vertical niche of tax return software exists.
Forcing our code generation worldview on prospects just lead to heated arguments and late nights cranking out emergency fixes.
For many years I built, sold and supported application generators that generated platform-specific code from abstract problem statements. We generated Java, C++, C, SQL, HTML, COBOL, PL/I and many other languages.
Our worldview: generated code is efficient and works. Our ideal prospects shared our worldview. While they were often experts, they had no expectations about how the generated code should look. Just that it worked and that they were more productive.
Not all prospects shared this worldview. If someone said “I would not have written the (generated) code like that” we knew there would be trouble.
You can’t spread your own story, just create a fertile environment, weave your story, give it its freedom and wish it a world of luck.
Stories are your best chance of getting your message to the people you need to hear it. Even so, the right story told to the right people is no guarantee your story will spread. You need 5 ducks in a row to have a chance of spreading:
The waterfall model for content creation is too slow. You need an agile process to create and ship your storytelling content.
To sell a product you must know what your target audience wants, not just what they need. Wants changes; worldviews are not static. Every message and conversation with peers has an impact, moving the story along.
The software business is quickly picking up qualities of the fashion industry. Both satisfy wants, not needs. Does anyone need designer sneakers? No. Do they want them? Yes!
Worrying about the slippery slope of fashion isn’t new. Windows 3.0 lead business users to want GUIs for their apps. They didn’t need a GUI for their B2B apps, but it was obvious they wanted one. They got what they wanted.
Target people sharing a worldview, already paying attention to your domain. They notice newcomers; are you sure they’ll notice you?
We view the world differently based on our biases, assumptions, values and experience. Our worldview filters what we pay attention to; what we believe.
Our worldview underlies the story we tell ourselves about what’s happening. It drives the guessing machine we use to predict future events.
Your target audience is a cluster of people who share a worldview and who are paying attention to your domain. But, while they notice newcomers, will they notice you?
Selling to developers who hate tools is a quick way to waste lots of money. We targeted the few whose worldview embraced tools.
As application tool vendors we convinced prospects with metrics and ROI. Adopting tools, we thought, was a no-brainer. Even so, selling to developers who didn’t want to use tools was difficult. Time and again developers successfully blocked tool adoption.
Our problem: their worldview didn’t include the idea tools are useful. Our solution: we focused on the 1 or 2 developers whose existing worldview did include a positive attitude towards tools.
Whether or not these developers had formal authority, we got our tool into their hands so they could reach their own conclusions. If they thought our tools worthy, they’d start spreading the word internally. Having someone who developers trust spread our story for us made all the difference.
