Da Art of (Business) Storytellin’

It’s no coincidence that Steve Jobs, the greatest storyteller in business history, was also a critical part of Pixar. After buying Pixar and becoming its CEO in 1986, Jobs immediately brought his talent of combining technology and the liberal arts to the big screen. After trusting his team to pivot from computer graphics to animated films, the company kicked off their 30-year streak of cultural dominance with Toy Story, crediting Jobs as an executive producer.

What Jobs created is now the standard for how tech companies operate. Good companies create stories for their customers, but great companies create stories before a line of code is written. As Tony Fadell, lead designer of the iPod and iPhone, writes in Build:

“[T]he story doesn’t just exist to sell your product. It’s there to help you define it, understand it, and understand your customers. It’s what you say to investors to convince them to give you money, and to new employees to convince them to join your team, and to partners to convince them to work with you, and to the press to convince them to care. And then, eventually, it’s what you tell customers to convince them to want what you’re selling.” - Tony Fadell, Build, pg. 110

Storytelling is not only important for advertising but for internal team alignment. We hear stories about Airbnb’s movie-quality storyboards around its office or Amazon’s Press Release Method. The key takeaway is that the company must align marketing and product. Slogans and one-liners must be brainstormed at the same time patents are being drawn. If the product team builds first, then asks marketing to find the story, it’s a recipe for disaster. It will lead to the customer expecting X but actually receiving Y.

Although I’ve never officially been in product or marketing, I have observed and read a lot. As I pursue my ambitions, I built the following list of tactical methods to bring storytelling into day-to-day development:

1. Name Things

Sara Blakely, the founder of SPANX, is obsessed with naming internal projects. By simply naming a thing, you give it a personality, an identity, that carries on through its development. My advice is to triage work into “projects” and name them. It’s a fun activity! I remember hearing about Xbox’s “Project Natal” leaking to the public, and how it eventually led to Kinect- its controller-less gaming experience. The creators must have named it “Natal” because they felt the device connected with the birth, or new beginning, of a gaming era (see definition). This thoughtful exercise is the first step in critically thinking about your project’s lore and what emotions you wish to convey. If your names are continuously forgotten or misinterpreted, it might be a signal that the fundamentals are off, and you should rethink the purpose of your work.

2. Create Personas. Proper Nouns Only.

As you go about building your project, consider all the stakeholders involved. If it’s software, who’s clicking on your app? What company do they work for? Who are they trying to help? Who is their boss? What are all of their motives and incentives? Many teams just give vague titles and industries (i.e. “salesperson at healthcare company”) and stop there. But, I recommend going a couple steps further. Give that person a name, like Sheila. Give Sheila a fake company, like “D/vision Health”. Give her a boss, a spouse, a list of hobbies, and career aspirations. By giving specificity to your stakeholder, you are reducing the imagination gap for the entire team. Now, the design team has a better understanding of Sheila’s preferred tabs. The marketing team can create content with Sheila’s name on it with some dummy data. And, if anyone has questions, they can ask it in the context of Sheila and her problems, which reduces loss in translation. I recommend building fake personas rather than referencing early customers, as their flexibility allows for edits and additions based on learnings.

Google Cloud uses Cymbal, a fictitious retail company, as its ideal customer throughout demos. Its brand, product lines, and even databases are fabricated as a way for Google to publicize its forward-looking value propositions. Cymbal’s specificity in global retail is used as a tool to communicate to a mass audience, but at the same time, Google makes it known that the story is extensible across multiple sizes and domains. It must be cool to hear Google employees across the entire company talk about Cymbal is actual planning meetings.

3. Stories Should Actually Be Stories

This is more for B2Bs, but I have a serious gripe with “Customer Stories”. Not to throw shade at any specific company, but take a look at this Datadog success story with Toyota. Where’s the story? Who is this Zakir guy, and what challenges was he going through before Datadog? What’s a tangible example of how a Toyota employee or customer’s life improved? What’s the calculation behind every metric? Was there any actual tension in the decisioning, onboarding, and maintenance of Datadog, or was it all just rainbows and sunshine?

I’m bothered by the corporate gloss put into every customer story. I find most of them say a lot of nothing, as their goals are mostly to drive SEO traffic than entrusting the reader with an actual story of motive, conflict, and trade-offs. As I explain further in my article on radical transparency, there’s serious brand value to be captured in not bullshitting your customer. Humans love stories because we find them allegorical to our lives. Companies that trust their audience and deliver a compelling, emotional story will succeed in the long run, as doing so will provide the team genuine feedback which can be used for future iterations. I hope to provide a narrative like that in any customer story I write.