Learning home made copywriting
So you two startuppers have technical skills, a great idea, maybe even a nice logo, and have the means to survive without sales for six months. So you have all you need to create your product and launch your startup?
This is what we believed, and it has been a long journey to realize how wrong we were. In your startup you will need a lot more skills or “hats” to succeed. For example, you need to do SEO on your product presentation site, you need to write license agreements for your software, you need to create and maintain a consistent design, you need to present your plans to potential funders, you need to interview and select workers, you need to have a way to test the application both functionally and on end users, and so on.
A review of the range of activities needed can be found in The Web Startup Success Guide, which I also reviewed here. I have been focusing recently on a skill that underlies many of the needed “hats”: this skill which your startup absolutely needs is
copywriting
usually referred to simply by “copy”. Wikipedia defines copywriting as
Now, there is an apparently simple way for a startup to compensate the lack of internal skills: hire consultants. What is sometimes missed in this “solution” is that most of the needs listed before are not the problems of a day: you have to create copy material almost every day of your startup activity. Also consider that the value of your product may be in details that get added day by day, and there must be a close collaboration between production and copywriting to communicate effectively to the users / visitors / buyers. Considering also that as startuppers you are likely a group of creative people, you may opt for creating contents yourselves! Many – most? – successful startups do that, cultivating a blog, site, tweets and more. And I suspect that spelling out in clear writing the benefits of your product may also help the development of it.
I took notes while studying the literature and introductions to copy, and extracted from there some notes in the form of blog posts. I hope that can be of help to others that are trying to learn copy for their startup.
A note about the “startup” term: I use “startup” more to mean an attitude, or even state of mind, that even software houses which strictly speaking are not startups may assume. In particular in the European Union, creating a new software product and creating new companies may be activities that do not coincide, given the complexity of setting up a company.
These two posts are directly about writing:
Improving the writing style of technical blog posts (part one)
A checklist for improving the writing style of technical blog posts (part two)
and I will talk about this theme at the forthcoming Developers in Florence 01 meeting.
This is about home page composition:
Get visitors to read and remember your home page – the principles
Get visitors to read and remember your home page – applications
and as I will talk about the latest two at the forthcoming Better Software conference, I am expanding the information there with new experiences – will publish an update blog post.
Good luck with your copywriting!
A checklist for improving the writing style of technical blog posts (part two)
This blog post is the second part of a previous post, Improving the writing style of technical blog posts. Read the first part before proceeding.
As you survived reading up to here, now you get a reward: a simple checklist which you can use to verify your posts before publishing them. The checklist does not contain anything about the core quality of your contents: being a technical writer / worker, it is simply assumed that you have something of value to say, but don’t know exactly how.
Checklist
(Get attention)
-
There is an effort to capture reader’s attention in the title and very first sentence
Copy is never too long, just too boring.
-
Benefits for the reader are immediately clear – instead of features
I woke up this morning thinking: I really need …
-
At least in the first paragraph, every sentence somehow leads to the next one.
-
The post contains a (short) story
“For sale: Baby shoes. Never used.” Ernest Hemingway
(Authority)
-
Substitute opinions with descriptions
-
Your assertions are backed up with specific proof
-
You establish authority somewhere, somehow
-
You kept the initial promise through which you got attention
(Style & format)
-
Can you make it shorter? Where in doubt, cut it out
“To be or not to be?”
-
You kept the language simple and clear.
No one will ever complain that your writing is too easy to understand. -
You sum the contents up at the end of the post.
(Review)
-
You’ve printed the draft on paper and re-read it
A way to get a new perspective, a bit like giving it to someone else to read it.
-
You read it loudly
A way to become sensitive to the rhythm of your writing.
-
Immediately before publishing it you did spell check it not just on some online spell checker but on Microsoft Word.
This is it. Shouldn’t be too hard. Download here the checklist in PDF format.
One could add to this list, with a slight change of focus, “Did you insert meaningful SEO words?” in your writings – but this opens up further considerations, maybe I will discuss them in a following blog post.
Using these techniques
Am I using this checklist? Well, I am. Consider for example this recent blog post I published in one of the most boring blogs on the web, the one where we announce Teamwork’s releases:
There were once two brothers and a sister, and they were managers at three companies.
The first brother was called Micro Manager, and he picked the most complex […]. And after a week everybody hated the system, and then they hated Micro Manager, and everybody was unhappy.
The second brother was called Over Simplify, and he didn’t want any kind of management apart from to-do lists […]. And then they hated Over Simplify, and everybody was unhappy.
Their sister was called Reasonable Modesty, and she had minimal goals, had always clear that what matters is how people work and interact, and that software is always secondary, and should be flexible, not do too much, and not get in the way. She started evaluating Teamwork.
Teamwork’s blog usually has posts like “Teamwork 4.3.12323 released”, followed by say a series of bug fixes which make sense only for Teamwork administrators, and can be made more interesting (and popular) using the techniques just described. In fact many people liked this last one.
Another example, this very blog post: this is a bit particular as it is half way between a guide and a blog post, some call it a “blogzine” entry. I did review it (several times) according to its own criteria, and made many changes (improvements, I hope).
A well-written blog post can have several “usages”:
-
It can be used as a base for a talk for a conference – or for proposing one
-
It can become a chapter of an e-book
-
It can be the base for building the contents of a dedicated micro-site
-
It can be transformed in a project – for example as done at the Startuptodo service
Again, all contents of good quality have a positive SEO effect: it is a side effect, but it can be great.
Exercise: review your latest blog post with this checklist. Is there anything that could be improved?
Conclusion
So we started from examining the writing and narrational style of some popular technical blogs, and then isolated a few techniques in a checklist which you can use to refine your own blog posts. This is just a start, you can find references and more material to study in the next section.
Further reading
I would like to thank Mr. Brian Clark for his brilliant site, copyblogger, that I discovered half way through and gave me a host of new ideas. Some advice on how to write blogs is at the end of this podcast:
http://blog.stackoverflow.com/2010/01/podcast-81/
From the notes:
Some tips from Joel and Jeff about why and how (or if) programmers should blog. Set a schedule and stick to it. And don’t be a commodity blogger! It helps to focus on the storytelling aspect of the writing, per Ira Glass. And remember, writing a better article on any topic is usually pretty easy, because so much of the content on the internet is so darn bad.
The Delicious links provide some sources.
This blog’s theme is discussed on Twitter and classified in Delicious under the tag “wellWrittenBlog”. The first part of this blog post, “A checklist for improving the writing style of technical blog posts” can be found here.
Improving the writing style of technical blog posts (part one)
Why few blogs are very popular, and most are practically ignored? You may believe that popularity is simply a question of luck or money. I read many blogs for professional reasons, and some among these are a real pleasure to read. Well, it also happens that the well-written ones are the most popular among the ones I read, and being well written may be what explains their success, at least partially. So in what follows I do some analysis of writing styles and then define a checklist which you may use to analyze your own blog drafts before publishing them, eventually improving your writing.
Most popular blogs are “well written”: by this I don’t (just) mean grammatically correct, I mean well written by looking at them as sort of short stories. Looking at blog posts in this way is a perspective that probably escapes technical writers; it is obvious for anybody who has copywriting experience. A blog can be very well written and not be popular, and there may even be popular blogs that are badly written, but there seems to be enough correlation with “good writing” for blogs that have contents as good as those of many others but stand out in popularity.
Now we will examine three popular blogs, to see some writing techniques in action. Then we will try to define some rules to improve your blog’s writing.
I will not go into why having a popular blog can be important, I just assume that it is so – a discussion would lead us to an entirely different topic. What is here said about writing is contextualized to blogs, but I believe can be a help in any kind of copywriting activity.
Three popular blogs
The blogs I’ve chosen as examples are those of Joel Spolsky, Jeff Atwood and Seth Godin. The first two are about programming, the work of programming and software marketing, the last one about marketing and spreading ideas.
Joel On Software
As an example post from Spolsky’s blog I’ve picked this one: The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!), and here is a short abstract from the blog, the opening paragraphs:
Ever wonder about that mysterious Content-Type tag? You know, the one you’re supposed to put in HTML and you never quite know what it should be?
Did you ever get an email from your friends in Bulgaria with the subject line “???? ?????? ??? ????”?
I’ve been dismayed to discover just how many software developers aren’t really completely up to speed on the mysterious world of character sets, encodings, Unicode, all that stuff. A couple of years ago, a beta tester for FogBUGZ was wondering whether it could handle incoming email in Japanese. Japanese? They have email in Japanese? I had no idea. When I looked closely at the commercial ActiveX control we were using to parse MIME email messages, we discovered it was doing exactly the wrong thing with character sets, so we actually had to write heroic code to undo the wrong conversion it had done and redo it correctly. When I looked into another commercial library, it, too, had a completely broken character code implementation. I corresponded with the developer of that package and he sort of thought they “couldn’t do anything about it.” Like many programmers, he just wished it would all blow over somehow.
Notice how this blog post, which is highly technical, start by asking questions and telling short stories – I’ve underlined the starts. And not only is the beginning like that, it keeps proceeding in such fashion. Why don’t you go now and read it, trying to notice the short stories that pepper this nice post.
Coding Horror
Let’s examine now Atwood’s Coding Horror blog, for example this blog post: The Great Newline Schism. The topic of this post is newline invisible characters, and this post topic is probably on one of the most uninteresting topic ever, but reading it is a pleasure anyway because of the way Atwood evokes old typewriters and nice pictures to lead the reader along; he is not telling a story in a classical sense, but he is indeed engaged in narration:
“The Carriage Return (CR) and Line Feed (LF) terms derive from manual typewriters, and old printers based on typewriter-like mechanisms (typically referred to as “Daisywheel” printers).”
Seth’s blog
Finally, let’s consider the posts from Seth Godin’s blog: these are short (yes, mine aren’t
).
Consider The hidden power of a gift:
“Perhaps we resolve it, as the ancient Native Americans did, by acknowledging the power of the giver … The key is that the gift must be freely and gladly accepted”
and Frightened, clueless or uninformed?
“Comfort the frightened, coach the clueless and teach the uninformed.”
His posts are filled with anthropological observations: he manages to link to the readers’ emotions. He has a talent for finding latent emotional roots in apparently purely commercial / economical interactions. He looks at human beings as emotional chimpanzees – which you may say is exactly what we are – and as shaped by implicit social norms; we are not as logical as we’d like to think we are. Seth explains behavior through micro anthropological narrations, which take little time, and stimulate reflecting on the bases of motivation – hence on marketing.
Design for beauty or readability?
The communication strategy which we are trying to refine here is focused on narration, as this is a way to transmit contents. A different strategy is to use design, but then it will be much harder to communicate a specific content; you will need a different design for every post, and find / invent a graphical metaphor. This is what indeed some talented designers are doing: see
http://line25.com/articles/tips-for-designing-unique-and-attractive-blog-posts
http://www.smashingmagazine.com/the-death-of-the-blog-post/
These are incredible designers that create a different design for each blog post. But as said above, our idea is to excite the reader with narration, not with novel design, as we want the reader to focus on contents. So pick a simple, highly readable, consistent layout for your blog and stick to it. Use very simple typographical tricks to lighten the reading experience, and few pictures. For an example, consider Joel’s clean style. Don’t invent a layout – its non trivial!
The importance of a good start
Blog titles play a crucial role in your posts, similar to that of product / web site’s pitches. What is the purpose of the pitch – in our case, of the title? The purpose of the title is to make the first sentence read. And what is the purpose of the first sentence? The purpose of the first sentence is to make the second sentence read. And so on: if you don’t get the attention of the visitor with the title, your failure is complete.
So make sure you try lists of different titles and starts, and variations on them. Get someone to verify them with you. Do the titles and openings grab attention? Interest?
The words that you are choosing there are important too: these should be inspired by the words used by your potential visitors / customers to describe their wishes, hopes, desires, dissatisfactions, fears, worries in relation to your topic / product.
You should probably dedicate almost half of the total time you dedicate to the post’ writing to experimenting with the title and start. For example, in the case of our Patapage site it took me months to get to a decent pitch. A blog post title is somehow less important than a home page pitch, but still put a significant part of your effort on the opening.
Why telling stories is good idea?
First you should realize that “by default”, nobody is interested in your blog posts, apart from very few people close to you who maybe, maybe, are interested. This is so important to deserve repetition and bold fonts:
nobody is “spontaneously” interested in what you are writing.
This is a “negative” truth. But here comes a “positive” one:
people are hungry for stories.
These two facts can help all along your writing.
As a technician, you are probably the least apt to communicate to the general public, and you also have to communicate the hardest topics. Furthermore, what you are trying to say cannot be trivialized without losing its essence. If you explain your ideas in technical terms, it will be non trivial to keep the attention of the readers. This is why using stories is a good idea: you can begin communicating non trivial ideas building up the readers’ attention.
So tell a story. Now, not a silly story: the point is not telling jokes, the point is to introduce your topic.
The conclusion is: in your post, tell stories, about conflicts, experiences, problems leading to your theme, and you’ll get the reader’s attention.
Hiring a copywriter may not always be the solution
If you are working with a large budget, the simplest way to solve any copywriting problem like writing good blog posts is simply to hire a copy. With the web and social media opening “windows” on companies’ activities, many (most?) companies actually need to create well written, interesting contents every day of work. Now, can you hire a full-time copy? If you can’t, like me, you can do a lot by yourself.
As a startup, there are several occasions where we got perfectly good solutions with a little internal research instead of paying expensive consultants with dubious competencies. The “solution” hire a consultant simply assumes that consultants are competent by default, which is often not the case. Need to write a license? Need a user guide? Need SEO optimization? Hire an expert. We didn’t, and are happy with the results; again, these problems appear continuously, so you need the relative competencies in-house.
In order to write, you need to have some “creative spirit”. It is impossible to learn to be creative: Steve Jobs as quoted in Inside Steve’s Brain says that seeing people trying to become creative is “painful to watch”. Indeed it is. Here I’m just assuming that you are, and that maybe your attention needs to stop a bit on your own writing style.
And now… go to the checklist!
This blog’s theme is discussed on Twitter and classified in Delicious under the tag “wellWrittenBlog”. The second part of this blog post, “A checklist for improving the writing style of technical blog posts” can be found here.
Pricing an online service
This in one of a series of posts that are a sort of “marketing diary” of our (attempt at) launching two new online services. The posts are put into context here.
In this post I articulate the reasoning that led us to define a pricing policy for our new online services. In order not to repeat mistakes made by others, I tried to become familiar with experiences, mistakes and successes from many sources – I give a short selection of references at the end. During this search, I have come to the conclusion that there is a simple and single principle, the “nobody cares about features” one, that every developer/marketer that comes to pricing software should keep clear in mind: this is probably the single original point of this post.
We got to define a pricing policy having already three years of experience and alternate success in selling software online; but this was a downloadable product, not an online service, and things are different. One point I got while thinking and researching about pricing is that “no price is an island”: the price of your online service is one aspect of a more general “pricing policy” that includes demo conditions, free licenses, refunds, segmentation (eventually), and other aspects.
I had got to some principles:
Transparency. Your prices and entire pricing policy should be public, clear and completely defined from the very beginning, from the very first moment your beta goes public. This because you must not keep any of your users and potential customers in a state of uncertainty. This way you may reduced the time it will take to make the first sales, which is a critical factor for your success.
Simplicity. Your price must be simple. Nobody wants to make complex reasonings when trying to understand costs. We’ll get back to this after stating the “nobody cares about features” principle, because its related to that.
Give refunds. Your worst enemy in sales is user’s fear, and anything that can lower that, should be welcome. A clear refund policy reassures evaluators, and do you want to keep unhappy users around? It’s not a good idea for an open, blogged about service.
Have only paid accounts. And then a choice we made is to have only paid accounts; a free online service, say ad-based, is a very complex undertaking, whose difficulty and implications for the users are easily underestimated. The mass audience that you must reach to make such choice profitable is rarely found. Another option that rarely works is the donation model. No, we want to give a refined, quality service, for real money.
Fixed these principles, we are still in the dark about how much we should price an account, say per month. You may start looking for a formula, well, there are two values that can be sort of determined:
Costs: you can determine how much development and maintenance costs, and what is the marginal cost, that is, the cost of activating and maintaning a new account.
Real worth: you can probably determine how much worth your service will be for your average customer, how many days of work and confusion it will save them, etc.
Well, now comes a fundamental realization: these two values are entirely, completely irrelevant for determining your service price; because you are looking at things from the wrong direction and/or with the wrong user model in mind. Consider the theme of my previous post about finding a pitch for your product (Get visitors to read and remember your home page):
The day you realize that nobody is interested in reading your product or service homepage because you love it, may be a bit depressing, but may also be the start of a re-design that will lead to more returning visitors.
Well, something similar holds for your pricing: in a competitive market, you simply can’t base yourself on what you believe your service is worth, or how much is costs, or the features you know it has, because nobody, absolutely nobody cares about that. Sad, but true. You have to set the price for the most direct and simple advantage the user can evidently and quickly see she /he will get.
You should never overestimate the will of an evaluator to carefully review your application: so you should surely put no limitation whatsoever in the service you are providing in the demo or free phase of the service; but then, this also influences your pricing, because if you are attempting what is called “segmentation”, based on limiting the features offered by different levels of pricing, you are sort of preparing a “nasty surprise” for those that want to turn from the full, complete demo to paying accounts: so I think this is a very bad idea. Developers love their products and their features, and (wrongly) assume that visitors to the presentation web site have the same drive; no, visitors drive has to be conquered, with the full power of your service, and also through simple and convenient pricing policies.
If you look at the typical policies of expanding software houses, these are often based on a flat, aggressive pricing policy; look today at how much more appeal has Apple’ OS simple pricing policy compared to the academic segmented prices of Microsoft’s OSs (and when Microsoft wanted to become a leader, it had the same policy as that of today’s Apple).
So the policy I support is to let the evaluators use the service in full, and give a single, simple price if they want to turn to a pay account. This is not what the marketing litterature suggests, but… things change, markets evolve, become more competitive, and also certain costs, like bandwidth, decrease.
Anyway, you may have noticed that we are still in the dark for fixing the price, as simple as it may be! Well, at least we’ve set the background principles, we can now look at similar successful software and services in similar fields; I’m not saying same fields as your service is a new, revolutionary idea, right? This also means that you won’t find many references to compare. At least you can be happy that with online services, all the piracy problems are over.
Another way to get an idea on price is to ask for opinions to your followers, or on The Business of Software, answers.onstartups.com, or Startuptodo. But only those who have a complete and clear picture of the entire pricing policy can take a decision; and I hope that will include you, in the end
For our two new services, we actually fixed the price through a session where the entire software house took part, and voted. So we fixed a price (39$/month) for both our services, with only a limitation for really huge customers.
We’ll see whether it works…
References
Don’t just roll the dice – A usefully short guide to software pricing – by Neil Davidson
Camels and Rubber Duckies – by Joel Spolsky
The Web Startup Success Guide – by Bob Walsh
Subscription based models, how to determine pricing ?
Our new web services: Patapage “More options for your website users” – BugsVoice “Turn bugs into opportunities”



2 comments