Book design guru Chip Kidd discusses how designing books is all about using visual design to convey the story contained within. He also makes some great observations about eBooks.
"Much is to be gained by eBooks: ease, convenience, portability. But something is definitely lost: tradition, a sensual experience, the comfort of thingy-ness — a little bit of humanity.” (Chip Kidd)
Showing posts with label story telling. Show all posts
Showing posts with label story telling. Show all posts
Wednesday, April 4, 2012
Tuesday, June 29, 2010
Technical Communication As Story Telling
Over on his "I'd Rather Be Writing" blog, Tom Johnson, has taken my idea of Tech Comm as storytelling, and expanded on it an excellent post, that I highly recommend.
In particular I like these two ideas on the practicalities of applying story telling techniques to technical documentation:
And..
In many ways the examples and ideas that Tom cites, also feedback to my earlier post on Applying the 10 Commandments of Storytelling to Technical Documentation.
In particular I like these two ideas on the practicalities of applying story telling techniques to technical documentation:
THE ELEMENT OF CHANGE
In a good story, the resolution always brings about some type of change, or comes about because of change. If you listen to stories on The Moth podcast (a storytelling podcast), you’ll constantly hear this element of change near the end of each story. For a story to feel meaningful, the protagonist always changes as a result of the conflict. Without this element of change, the story feels flat.
In technical documentation, achieving that element of change is difficult. In almost all technical documentation, the reader is the protagonist, since our point of view is second person (“you”). You (the reader) have a problem. ..... Through the help topic’s steps and information, you find a solution that solves your problem. Hooray, you’re much happier and complete now. That’s the basic transformation.
And..
FOCUSING ON THE PROBLEM
A problem of some kind usually drives and gives rise to the story. But isn’t every help topic by default the answer to some problem? And aren’t users coming to the help content with a problem already in mind? Do we need to explicitly supply the problem, since it’s already apparent in the user’s mind?
Yes, your protagonist already has a problem. That problem is what is fueling his or her path through the help. But it can still be helpful to state the problem explicitly so that users can connect their problem to the solution you describe.
It's great to see these ideas being picked up and expanded upon.
Tuesday, February 9, 2010
How a Great Story Can Help Your Brand
Yesterday evening I spent a couple of hours interacting with other local business people and entrepreneurs at this month's Network In Austin event. As usual it was an excellent opportunity to meet and learn about a whole new bunch of local businesses.
In the space of two hours I must have heard about at least a dozen new businesses, what they did, and what they were called. That's a lot of information to take in in a short time.
As I drove home I did a quick mental review to see if I could recall the salient points from each conversation. I managed to recall something about everyone, but what struck me was that the first two businesses that came to mind were the two that had stories attached, and one in particular that had a story attached to the brand name.
The lady who ran the company had told a fun short story of how the company name came from an expression her father used to use a lot.
Several years ago I used to write a regular marketing newsletter that included the stories and histories behind some of the most well known brand names. That section was always the most popular part of the newsletter. It gave me the idea of maybe writing a book on the subject - but then I found out that someone had already done it...
And Evan Morris' fun book "From Altoids to Zima" is now one of the most thumbed books on my marketing bookshelf.
There is a story behind most company and brand names. I've worked for companies named after bags of chips, science fiction villains, a historical event, and even one that got it's name from a typo.
Discover your story - work it in to your pitch, put it on the website, and people will remember it, and they will remember you.
In the space of two hours I must have heard about at least a dozen new businesses, what they did, and what they were called. That's a lot of information to take in in a short time.
As I drove home I did a quick mental review to see if I could recall the salient points from each conversation. I managed to recall something about everyone, but what struck me was that the first two businesses that came to mind were the two that had stories attached, and one in particular that had a story attached to the brand name.
The lady who ran the company had told a fun short story of how the company name came from an expression her father used to use a lot.
Brand names with a story behind them stick.
Several years ago I used to write a regular marketing newsletter that included the stories and histories behind some of the most well known brand names. That section was always the most popular part of the newsletter. It gave me the idea of maybe writing a book on the subject - but then I found out that someone had already done it...
And Evan Morris' fun book "From Altoids to Zima" is now one of the most thumbed books on my marketing bookshelf.
There is a story behind most company and brand names. I've worked for companies named after bags of chips, science fiction villains, a historical event, and even one that got it's name from a typo.
Discover your story - work it in to your pitch, put it on the website, and people will remember it, and they will remember you.
Saturday, January 9, 2010
Comics in Corporate Communications
Is there a place for comics in corporate communications? I certainly think so, and have long been a vocal proponent of using comics graphic and story telling techniques in the business world.
Recently Scott Abel, industry leading consultant and blogger, offered me the opportunity to write about the subject on his CONTENT WRANGLER blog.
My two page article Comics Can Make You A Better Communicator is now up, and you can check it out simply by clicking HERE.
Thursday, March 26, 2009
Why Technical Writers Shouldn't Be "Writers" - Slides
Technical writers love the written word. Perhaps, we love it a little too much? We need to ask ourselves is the written word the best thing for documentation? Is it the best thing for us as an industry, and is it the best thing for you as a content developer.
Over the last several months I've delivered a talk entitled Why Technical Writers Shouldn't Be "Writers" at several STC regional meetings and conferences (such as last week at DocTrain West)
The presentation was inspired by an earlier post on this blog, and takes a look at why we are so focused on the written word, and presents a few ideas about better ways for us to deliver our message to the end user in a way that increases customer satisfaction.
What can we as documentation professionals learn from just observing the world around us, and how people communicate? What is the impact of new Web2.0 technology and social networks, and how they will change the way we need to view documentation design, distribution and usage?
Several people have asked for copies of the slides I used, so here they are.
However the slides are not full of text and bulleted lists, in line with the central theme of the presentation, they are mainly graphics used to illustrate an idea or to serve as talking points. This is a "performance best seen live."
If anyone is interested in me delivering this presentation to their STC group, the writing team at their company, or a conference - then just send me an email, and let's chat.
Over the last several months I've delivered a talk entitled Why Technical Writers Shouldn't Be "Writers" at several STC regional meetings and conferences (such as last week at DocTrain West)
The presentation was inspired by an earlier post on this blog, and takes a look at why we are so focused on the written word, and presents a few ideas about better ways for us to deliver our message to the end user in a way that increases customer satisfaction.
What can we as documentation professionals learn from just observing the world around us, and how people communicate? What is the impact of new Web2.0 technology and social networks, and how they will change the way we need to view documentation design, distribution and usage?
Several people have asked for copies of the slides I used, so here they are.
However the slides are not full of text and bulleted lists, in line with the central theme of the presentation, they are mainly graphics used to illustrate an idea or to serve as talking points. This is a "performance best seen live."
If anyone is interested in me delivering this presentation to their STC group, the writing team at their company, or a conference - then just send me an email, and let's chat.
Why Technical Writers Shouldn't be "Writers"
View more presentations from 4JsGroup.
Tuesday, January 13, 2009
10 Commandments of Storytelling as applied to Tech Doc?
One of the topics I am slated to deliver at various conferences in 2009 is my presentation on why I think “Technical Writers Shouldn’t Be Writers.”
Towards the end of that presentation I have a slide that mentions four recommended books as “must reads.” One of those four is Robert McKee’s “STORY: Substance, Structure, Style and the Principles of Screenwriting.”
Anyone who reads this blog will know that I’m a strong advocate of storytelling in all forms of communications. I believe that it applies as much to technical or marketing communication as it does to your favorite novel or movie.
It seems I’m not alone in that thinking. Over at the excellent slide:ology blog a recent post applies McKee’s “10 Commandments of Storytelling” to PowerPoint Presentations.
Picking up on that thought I decided to see if I could apply McKee’s 10 Commandments to Technical Documentation.
1. Thou shalt not take the crisis or climax out of the protagonists hands.
So who is the “protagonist” of your documentation? It could be your product, but the most likely candidate is that your “protagonist” is the person using your documentation. Your documentation should be written in such a way that your protagonist can use the information so that they feel that they have solved the crisis (or put more prosaically, overcome the problem they have) themselves based on the knowledge you have presented. Another story telling trick, often cited by screen-writer Todd Alcot, that is worth remembering – ask yourself “What does the protagonist want?”
2. Thou shalt not make life easy for the protagonist.
This seems contrary to the very purpose of Technical Documentation. Isn’t it our job to make life easier? Yes it is. But in certain types of documentation, such as training materials, you may want to include challenges, and then guide the reader through them. This way you can build a sense of accomplishment as the reader progresses through the material.
3. Thou shalt not use false mystery or surprise.
Don’t hold back anything that is integral to full understanding of the product or service you are writing about. But also make sure to reveal information in a logical manner that is considerate of the reader’s needs. Make sure they have the information they need to know, at the time they need it.
4. Thou shalt respect thine audience.
The first rule of any sort of writing is “know your audience.” Know them, and respect their level of knowledge. If you are writing something for experts, then you may not need to include the basic information that you might use for a more general consumer market. The use of conditional text is a great way to handle different topics and statements designed for different audiences within a common documentation set.
5. Thou shalt have a god-like knowledge of your universe.
A joke I often use is “What’s the definition of an ‘expert’?” – The answer is “it’s a person who has read two more pages in the manual than you have.” So what does that make the person who wrote the manual in the first place? We may not know everything about what we are documenting, but we should give the reader the confidence that we do.
6. Thou shall use complexity rather than complication.
Most of what we write about in Tech Doc, is by its very nature, complex. We should take that complexity and break it down into logical steps and topics that can guide the reader. We should never use complexity as an excuse for making the documentation complicated.
7. Thou shalt take your character to the end of the line.
We learn in grade school that every story should have a beginning, a middle, and an end. The same applies to documentation too. The narrative should guide the reader through the process, or information, in such a way that it flows logically, and that at the end they know more, or have achieved more, than when they started.
8. Thou shalt not write on the nose dialog.
Wait, I hear you asking, there’s no dialog in Tech Doc – so how does this apply? Well the definition of “on the nose dialog” relates to the scene when a character says aloud, exactly what he is thinking or describes what is happening around him. So how does this apply to Tech Doc? Do you have sections of doc that are restating the obvious? Try reading your docs out aloud? Is it boring and repetitious? Try altering sentence lengths. Don’t think anyone ever listens to docs as if it was dialog? As a teenager I spent hours working under cars while a buddy nearby would read the steps from the manual for me to follow. How about a visually impaired customer using a reading device?
9. Thou shalt dramatize thine exposition.
Put simply “show don’t tell.” In prose this means have your characters reacting to an event, not talking about it. But isn’t our job to tell people how to do something? Yes it is, but the key word is “how.” Replace long descriptive texts on operational theory with a few active steps the user can take themselves, that demonstrates the product, and they will gain a quicker understanding. People learn more by doing than they do by being told.
10. Thou shalt rewrite.
Do I need to explain this one? Plan your schedule with time to write, have someone else review, and rewrite. Best of all scenarios is to write, have someone actually use your draft to accomplish the tasks you have written about, get feedback. Better yet, watch them try to use your docs. Then go back and rewrite based on your observations. They say that any good piece of art is never finished. Writing is art, even Tech Writing. You can always improve on what you’ve done.
Towards the end of that presentation I have a slide that mentions four recommended books as “must reads.” One of those four is Robert McKee’s “STORY: Substance, Structure, Style and the Principles of Screenwriting.”
Anyone who reads this blog will know that I’m a strong advocate of storytelling in all forms of communications. I believe that it applies as much to technical or marketing communication as it does to your favorite novel or movie.
It seems I’m not alone in that thinking. Over at the excellent slide:ology blog a recent post applies McKee’s “10 Commandments of Storytelling” to PowerPoint Presentations.
Picking up on that thought I decided to see if I could apply McKee’s 10 Commandments to Technical Documentation.
1. Thou shalt not take the crisis or climax out of the protagonists hands.
So who is the “protagonist” of your documentation? It could be your product, but the most likely candidate is that your “protagonist” is the person using your documentation. Your documentation should be written in such a way that your protagonist can use the information so that they feel that they have solved the crisis (or put more prosaically, overcome the problem they have) themselves based on the knowledge you have presented. Another story telling trick, often cited by screen-writer Todd Alcot, that is worth remembering – ask yourself “What does the protagonist want?”
2. Thou shalt not make life easy for the protagonist.
This seems contrary to the very purpose of Technical Documentation. Isn’t it our job to make life easier? Yes it is. But in certain types of documentation, such as training materials, you may want to include challenges, and then guide the reader through them. This way you can build a sense of accomplishment as the reader progresses through the material.
3. Thou shalt not use false mystery or surprise.
Don’t hold back anything that is integral to full understanding of the product or service you are writing about. But also make sure to reveal information in a logical manner that is considerate of the reader’s needs. Make sure they have the information they need to know, at the time they need it.
4. Thou shalt respect thine audience.
The first rule of any sort of writing is “know your audience.” Know them, and respect their level of knowledge. If you are writing something for experts, then you may not need to include the basic information that you might use for a more general consumer market. The use of conditional text is a great way to handle different topics and statements designed for different audiences within a common documentation set.
5. Thou shalt have a god-like knowledge of your universe.
A joke I often use is “What’s the definition of an ‘expert’?” – The answer is “it’s a person who has read two more pages in the manual than you have.” So what does that make the person who wrote the manual in the first place? We may not know everything about what we are documenting, but we should give the reader the confidence that we do.
6. Thou shall use complexity rather than complication.
Most of what we write about in Tech Doc, is by its very nature, complex. We should take that complexity and break it down into logical steps and topics that can guide the reader. We should never use complexity as an excuse for making the documentation complicated.
7. Thou shalt take your character to the end of the line.
We learn in grade school that every story should have a beginning, a middle, and an end. The same applies to documentation too. The narrative should guide the reader through the process, or information, in such a way that it flows logically, and that at the end they know more, or have achieved more, than when they started.
8. Thou shalt not write on the nose dialog.
Wait, I hear you asking, there’s no dialog in Tech Doc – so how does this apply? Well the definition of “on the nose dialog” relates to the scene when a character says aloud, exactly what he is thinking or describes what is happening around him. So how does this apply to Tech Doc? Do you have sections of doc that are restating the obvious? Try reading your docs out aloud? Is it boring and repetitious? Try altering sentence lengths. Don’t think anyone ever listens to docs as if it was dialog? As a teenager I spent hours working under cars while a buddy nearby would read the steps from the manual for me to follow. How about a visually impaired customer using a reading device?
9. Thou shalt dramatize thine exposition.
Put simply “show don’t tell.” In prose this means have your characters reacting to an event, not talking about it. But isn’t our job to tell people how to do something? Yes it is, but the key word is “how.” Replace long descriptive texts on operational theory with a few active steps the user can take themselves, that demonstrates the product, and they will gain a quicker understanding. People learn more by doing than they do by being told.
10. Thou shalt rewrite.
Do I need to explain this one? Plan your schedule with time to write, have someone else review, and rewrite. Best of all scenarios is to write, have someone actually use your draft to accomplish the tasks you have written about, get feedback. Better yet, watch them try to use your docs. Then go back and rewrite based on your observations. They say that any good piece of art is never finished. Writing is art, even Tech Writing. You can always improve on what you’ve done.
Friday, December 12, 2008
Banging The Drum Again...
In his excellent blog post about the current state of the book publishing industry Mark Tavani, a Senior Editor at Random House, makes the following observation.
Substitute the word "book" for "documentation," and the word "story" for "content" and I think the observation applies equally to the world of corporate publishing as it does to traditional book publishing.
=========
I need to add a couple of points of clarification here.
- Anyone who knows me and has heard me speak will know I love books (the traditional kind). I have a house full of them, and spend my evenings and weekends writing them. BUT while I'm a passionate bibliophile, I am also aware (as I mentioned in my last post) that the "book model" is perhaps no longer the best model to be using to ensure that content reaches the end user of a product or service.
- While I suggested swapping the word "story" for "content" in the quote above, that was more to illustrate a point. For me everything we write or produce that is designed to pass on knowledge or information is, and should be treated as, a story. The ability to tell stories is the most powerful communications tool we have at our disposal. As Tavani points out, we've being doing it for millennium, and will continue to do it irrespective of any technology or medium.
... books are a mere format. Yes, they can be beautiful and wonderful to hold in your hands, and yes, there are some books I plan to keep in my home until the day I die simply for their sentimental value. So I understand what is magical about books. But the most magical thing about them is the information they convey: the story they contain. The word “book” and the word “story” are not synonymous, just as eight tracks and music are not the same thing. Stories pre-date books by milleniums; and though books might someday go away, story will last as long as our civilization does.
Substitute the word "book" for "documentation," and the word "story" for "content" and I think the observation applies equally to the world of corporate publishing as it does to traditional book publishing.
=========
I need to add a couple of points of clarification here.
- Anyone who knows me and has heard me speak will know I love books (the traditional kind). I have a house full of them, and spend my evenings and weekends writing them. BUT while I'm a passionate bibliophile, I am also aware (as I mentioned in my last post) that the "book model" is perhaps no longer the best model to be using to ensure that content reaches the end user of a product or service.
- While I suggested swapping the word "story" for "content" in the quote above, that was more to illustrate a point. For me everything we write or produce that is designed to pass on knowledge or information is, and should be treated as, a story. The ability to tell stories is the most powerful communications tool we have at our disposal. As Tavani points out, we've being doing it for millennium, and will continue to do it irrespective of any technology or medium.
Tuesday, November 25, 2008
Remember the (STC) Alamo
Just over a week ago I attended what was simply the most open and stimulating regional STC event I have ever been to.
The Central Texas STC Fall Seminar, was organized jointly between the Austin and San Antonio chapters of the industry group and held at the excellent Hotel Valencia on San Antonio’s famed Riverwalk. (Home to many fine restaurants - including the one where we had lunch.)
But it wasn’t the setting that made it memorable – it was the participation.
In my experience a lot of these regional get-togethers end up in features and functions comparisons of tools, minutiae of the job, or arcane technical discussions about standards that only a minority of people use. Not so in this case.
The discussions ranged from using emerging new technologies, Web2.0 tools,, wikis, social networks, to how to develop and recognize metrics, to how to make sure that the documentation process is heard and accounted for in a Agile Development driven world.
But underscoring all the talk of technology was the realization that technologies will come and go, and the most important skill to develop was the ability to learn about new things, and communicate that in an empathic way.
There were several people who were attending their first STC event and they, along with everyone else, left with the impression that this is an exciting time to be in the corporate publishing world.
The Central Texas STC Fall Seminar, was organized jointly between the Austin and San Antonio chapters of the industry group and held at the excellent Hotel Valencia on San Antonio’s famed Riverwalk. (Home to many fine restaurants - including the one where we had lunch.)
But it wasn’t the setting that made it memorable – it was the participation.
In my experience a lot of these regional get-togethers end up in features and functions comparisons of tools, minutiae of the job, or arcane technical discussions about standards that only a minority of people use. Not so in this case.
The discussions ranged from using emerging new technologies, Web2.0 tools,, wikis, social networks, to how to develop and recognize metrics, to how to make sure that the documentation process is heard and accounted for in a Agile Development driven world.
But underscoring all the talk of technology was the realization that technologies will come and go, and the most important skill to develop was the ability to learn about new things, and communicate that in an empathic way.
There were several people who were attending their first STC event and they, along with everyone else, left with the impression that this is an exciting time to be in the corporate publishing world.
Thursday, September 4, 2008
The Google Chrome comic - why it didn't work.
Yesterday I spent a fair amount of time talking with a prospective client about a project involving the use of sequential art to convey some very technical information.
In short, he wants to use the medium of comics to tell prospective engineers why it would be cool to work on the projects his organization is responsible for. (And having heard what projects they are – I can confirm it would be VERY COOL to be involved in almost any capacity).
I walked him through the process I use to develop and produce promotional comics and various options for delivery etc. based on budgets, audience and so on.
During the conversation the “technical comic” produced by comics guru Scott McCloud in support of the launch of the new Google Chrome browser was discussed.
My client had loved the idea, checked out the links, started out to read the McCloud comic and after about six pages he had glazed over, skim read a few more pages and not actually finished it.
His concern was that he was not alone in this reaction, and because of this was wary of citing the Google comic to his budget holders as a way to justify his own project.
Even with the added incentive of professional interest, I must also admit that I found the Google Chrome comic difficult to finish. No one else I have spoken to since has actually read it the whole way through.
Why? Because despite the “novelty” of the method of presentation, they didn’t stay engaged in the subject matter.
Today I came across the following quote from Scott McCloud in an FAQ.
And perhaps there lies the problem.
There is no single voice and no narrative.
Let me say that I greatly admire McCloud. He knows more about comics storytelling and structure than I ever will. I constantly reference his classic work “Understanding Comics” in producing my own work, and in various papers I write, or presentations I give, on communicating.
But I’m amazed with the Google project, because the lack of narrative seems like a basic omission from such a high profile project.
Whenever I produce a promotional comic I always try and include a central character that the reader can empathize with, along with a story (more often than not something light and fun to off set the heavy technical jargon) to guide the reader through the points being made.
As I’ve often said before, all communication is a story and technical communication needs it just as much as fiction.
I’m not sure what audience the Google Chrome comic was aimed at. While it was great to see comics used in such a high profile way, did anyone consider the implications and impact of the fact that the very use of the comics medium would expose it to a wider audience than first intended?
In short, he wants to use the medium of comics to tell prospective engineers why it would be cool to work on the projects his organization is responsible for. (And having heard what projects they are – I can confirm it would be VERY COOL to be involved in almost any capacity).
I walked him through the process I use to develop and produce promotional comics and various options for delivery etc. based on budgets, audience and so on.
During the conversation the “technical comic” produced by comics guru Scott McCloud in support of the launch of the new Google Chrome browser was discussed.
My client had loved the idea, checked out the links, started out to read the McCloud comic and after about six pages he had glazed over, skim read a few more pages and not actually finished it.
His concern was that he was not alone in this reaction, and because of this was wary of citing the Google comic to his budget holders as a way to justify his own project.
Even with the added incentive of professional interest, I must also admit that I found the Google Chrome comic difficult to finish. No one else I have spoken to since has actually read it the whole way through.
Why? Because despite the “novelty” of the method of presentation, they didn’t stay engaged in the subject matter.
Today I came across the following quote from Scott McCloud in an FAQ.
Who wrote the script?
The engineers, for the most part! I helped conduct interviews with about 20 engineers who worked on the project, then adapted what they said into comics form. Some paraphrasing, lots of condensation, and one or two late drop ins, but basically it was a very organic adaptation and I had a lot of latitude.
And perhaps there lies the problem.
There is no single voice and no narrative.
Let me say that I greatly admire McCloud. He knows more about comics storytelling and structure than I ever will. I constantly reference his classic work “Understanding Comics” in producing my own work, and in various papers I write, or presentations I give, on communicating.
But I’m amazed with the Google project, because the lack of narrative seems like a basic omission from such a high profile project.
Whenever I produce a promotional comic I always try and include a central character that the reader can empathize with, along with a story (more often than not something light and fun to off set the heavy technical jargon) to guide the reader through the points being made.
As I’ve often said before, all communication is a story and technical communication needs it just as much as fiction.
I’m not sure what audience the Google Chrome comic was aimed at. While it was great to see comics used in such a high profile way, did anyone consider the implications and impact of the fact that the very use of the comics medium would expose it to a wider audience than first intended?
Thursday, June 26, 2008
Story Quotes
A couple of great quotes about the power of stories in business that I came across today.
"Good leaders are good authors of stories that include everyone else."
- Gerhard Gschwandtner - SellingPower.com
"Stories give us context, and context helps everyone understand."
"Stories wield special power because they can be translated into something visual. When we hear a story we see it too, and the visual image becomes something that sticks in our memories long after the words have fled."
- Harry Beckwith & Christine Clifford - You Inc.: The Art Of Selling Yourself.
"Good leaders are good authors of stories that include everyone else."
- Gerhard Gschwandtner - SellingPower.com
"Stories give us context, and context helps everyone understand."
"Stories wield special power because they can be translated into something visual. When we hear a story we see it too, and the visual image becomes something that sticks in our memories long after the words have fled."
- Harry Beckwith & Christine Clifford - You Inc.: The Art Of Selling Yourself.
Thursday, June 12, 2008
Business and Storytelling
Anyone whose spoken to me for more than a few minutes will quickly find out that my passion is story telling. In fact I believe that ALL business communication, be it in sales, marketing, technical publications, white papers, reports, even simple emails, is simply different forms of telling stories.
Sitting on my desk next to me is a book with the great title Whoever Tells The Best Story Wins. I'll be honest I wasn't too impressed by the actual content - but I keep it on my desk so that every day I see that title.
Today doing some business plan research I was looking for examples of the ultimate in business story telling - The Elevator Speech.
What's an Elevator Speech - the idea is that if you are riding in an elevator and someone asks "What does your company do?" - you can answer before the elevator ride is over. In other words you can tell your business story in less than thirty seconds.
That research lead me to the video below.
The video has some good pointers on composing a good Elevator Speech - but what really caught my attention was the idea of a CEO using the job title "Chief Storyteller." - That's a job title I think we should all adopt, at least in spirit if not in practice.
Sitting on my desk next to me is a book with the great title Whoever Tells The Best Story Wins. I'll be honest I wasn't too impressed by the actual content - but I keep it on my desk so that every day I see that title.
Today doing some business plan research I was looking for examples of the ultimate in business story telling - The Elevator Speech.
What's an Elevator Speech - the idea is that if you are riding in an elevator and someone asks "What does your company do?" - you can answer before the elevator ride is over. In other words you can tell your business story in less than thirty seconds.
That research lead me to the video below.
The video has some good pointers on composing a good Elevator Speech - but what really caught my attention was the idea of a CEO using the job title "Chief Storyteller." - That's a job title I think we should all adopt, at least in spirit if not in practice.
Subscribe to:
Posts (Atom)
