Blue Sky On Mars

I just finished listening to the audiobook of Seth Godin’s Free Prize Inside / Purple Cow. This dual audiobook is abridged. So, if you’re looking for the full deal or you’re not into audiobooks, check out Purple Cow: Transform Your Business by Being Remarkable and Free Prize Inside!: The Next Big Marketing Idea.

I’m going to give away the central point of the book/audio book, but as with any good book, that won’t reduce the value of what you get by reading the whole thing. The main point that Godin drives home in both books is that advertising as a way to grow a business is a dead model. If you want to grow a business, you need a product that is remarkable, so that people will talk about it. A “Purple Cow” is something that stands out, and a “Free Prize” is an aspect to the offering that makes it stand out.

I tend to be a bit ahead of the curve on things. At this point, I watch very little TV and the TV I do watch is on a ReplayTV (mmm… commercial skip). I don’t get a newspaper. I read very few magazines. Almost all of my media input comes from movies, which are largely commercial free, and the Internet. My browser, Firefox, blocks advertising popups, so the most outrageous forms of advertising online don’t hit me. I do listen to radio when I’m in the car, which is probably where the largest quantity of advertising gets to me. I usually change channels when ads come on though. If the profile I just described becomes more typical in a few years, advertising is in for an even bigger problem than it already has.

Regardless of whether you agree with Godin’s basic premise, the fact is that if you’re starting your own software shop you probably can’t afford a big, splashy ad campaign. Starting our own businesses we have to find the free prize to create the purple cow. Otherwise, we’re sunk. When you’ve got a limited budget, you need to be sure to build that free prize in from the very beginning. I have some ideas that I’m hoping will get some attention for my product from the get-go, so I’m definitely taking this to heart.

These books are filled with all kinds of great examples, and a few counter-examples, to really illustrate the point and get you thinking about how your own products can become special. Free Prize Inside has a fairly large chunk on selling your organization on the change, which was interesting but not at all related to my situation. If you are in a large organization, that section will give you a good intro to selling your ideas and getting them done.

Purple Cow and Free Prize Inside are among the most important books you can read as you’re starting a new, bootstrapped business. They’ll get you thinking in terms of building the marketing into your product, which can boost your chances of having a successful product or service.

I’d also like to point out that Seth Godin’s Blog is frequently and generously updated with a continuous stream of thoughts and pointers that can help us geeks keep on eye on marketing.

What do you think about first when thinking about starting a new small software shop? If you’re like me, you think about the product first. You think about the cool idea and some of the nifty bells and whistles. You think about some interesting parts of the implementation. That’s all well and good, because a great software company needs to start with a good product. But, when you’re starting your own small software shop, there are two things that will end up being more important to your success: marketing and support. In this article, I’m going to write a bit about surviving your business’ support needs.

Time and money are both hugely constrained in your typical, home-grown business. (If you’re working with venture capital, go ahead and hire that team of support staff When you’ve got only a small handful of people working with you, you need to optimize on time and money outlay. Each email or phone support request is going to take time, so you need to do what you can to avoid as many as possible.

Work on usability

I can’t afford a full-blown usability study of my application. What I can do, and I’m sure you can to, is find someone who fits a reasonable user profile for your application and just observe them using the software. Start them out from the very beginning (your website), and see how they do with downloading and installing the software. Then, watch how they actually use the software.

Are there things they did frequently that required more clicks than they should have? Was there something that they wanted to do, but got lost while doing it? For each time they turn to you either for reassurance or to ask a question, that could be a sign of support requests to come. Except those support requests could come from hundreds of customers all over the world, rather than just one person sitting in front of you.

Anything you can do to watch real people using your software (without assistance) will give you insight into making your software better. Usability Testing in Practice by Andrew Starling gives a quick overview of how the pros do it. Observing the User Experience: A Practitioner’s Guide to User Research (Morgan Kaufmann Series in Interactive Technologies) by Mike Kuniavsky may provide some good tips (I haven’t read it, but it appears to be one of Amazon’s higher sellers and has four 5-star reviews).

Do sufficient testing

In the days of yesteryear (say 5 years back), it used to be the case the a QA group was responsible for all of the testing. A developer would write some code, fire up the program, test that one thing and proclaim it “done”. Well, it’s no longer yesteryear, and my tiny company doesn’t have a QA department.

From time to time, I see people write that “unit testing is not a silver bullet”. That’s true, but that doesn’t mean you shouldn’t do it. Test driven development can improve your designs and improve your ability to fix bugs quickly. If you want to have a low bug count on release, do your automated tests.

Since I don’t have a QA department, I need to have a good beta test program. In fact, I need a good alpha test program. The earlier in the process that you have more people involved, the fewer gotchas you’ll have later. Try to get people with different experience levels and computer setups so that you’ll catch more problems before release. All of the really weird stuff is going to come out of the woodwork after release, so you might as well get the easy ones out of the way earlier.

Public betas can be a double-edged sword. While they do allow you to get the broadest possible exposure and shake out more bugs, you may also attract some people who have release-software expectations for your beta and others who would just give up rather than reporting bugs. For a beta test to be useful, the testers need to know that the software is almost, but not quite, done and that you’re counting on them to provide bug reports.

One option to consider is to do private beta testing, but take your first “release candidate” and put it out there as a public beta. A release candidate is not like a traditional beta. With an RC, you believe that the software is ready to ship. By putting it out there as a public beta, that gives you a chance to broaden your testing exposure while still giving some of the impression that it’s not fully done. Once you’ve seen the response from the RC, then you know you’re safe to release.

Make sure the answers are there and accessible

Your website needs a search engine. It doesn’t matter how you do it (you can even use Google, if you wish), but just make sure that people can search. And people really need to be able to search the whole site in one go. If your site is a patchwork of HTML files, PHP forums and a Movable Type blog, you have an interesting integration problem (go with Google and save yourself the headache).

My plan for that, by the way, is to use Drupal for my site. Something like Plone is also a good choice. Both of these let you incorporate a variety of content with discussions and more, all of it under one always-up-to-date search engine. They’re also both free.

With a bit of clever packaging, you should be able to provide a lot of the same content in multiple forms: a manual, context-sensitive help, and a frequently asked questions list. Especially in this age of hyperlinks, many FAQs can be answered with a short response and a link to the appropriate part of the documentation. All of this content should be on your website.

If you write all of your docs in some kind of structured text format (HTML, XML, ReStructured Text) and you’re handy with a language like Perl, Python or Ruby, you should be able to put your content to work in many ways.

If you can afford one (which I can’t right now), hiring a professional documentation writer can be a very valuable thing. I can write reasonably well, but I know that a pro would be able to do the job more efficiently and will avoid common pitfalls.

Only answer a question once

While I’m writing about trying to save support costs, the idea is not to save the costs at the expense of providing good support. Word of mouth can be crucial to a small business, and there’s no better way to spoil it than bad support. So, the goal is to help the customers help themselves as much as possible, and then to respond quickly to anything that wasn’t caught by those efforts.

A web-based forum can be a powerful tool. Any questions that get asked there automatically become searchable. When you post an answer, you’ve automatically increased the chance that the next person who has that same question may find the answer in a search. If a question pops up more than once, or seems like something important, it definitely pays to get that into your main documentation right away.

The thing to keep in mind about a forum is that it’s public. If you try to squelch criticisms of your product, they will come back to bite you. It certainly pays to remove outright offensive forum postings. But, genuine criticisms, even if you disagree with them, should be taken seriously and responded to. As long as you handle things reasonably, your other customers will still see you as being responsive.

Some parting thoughts…

I’ve provided support in a variety of capacities for different kinds of products over the course of my career. The capabilities of modern computers and the internet have potentially greatly reduced the support burden of creating a software product. To get the benefit, though, you need to plan ahead and take advantage of the tools and techniques available today. The tools are free, you just need to put in the time. The more customers you end up with, the better leverage you get out of that time spent up front.

Warning: I got a bit of a ramble going on this one.

I’m in the process of listening to the audiobooks of Seth Godin’s great Purple Cow and Free Prize Inside. So, out of curiousity, I stopped by his blog today and took a look. The writing is excellent, as you’d expect, and the topics look very interesting. One caught my eye, because this is a meme that’s been traveling around lately: The end of candor talks about how blogs are no longer authentic media.

While there has been an increase in “fake” blogs, I’m not sure that it really matters. There are plenty of real blogs. Like Seth’s blog, for example. Here’s a guy with a reputation. Sure, he could have ghost writers and it could all be some big ploy to sell books and speaking engagements. But, at the end of the day, Seth Godin’s blog is gonig to present the public face that Seth wants to wear.

Readers will then decide whether or not they want to listen.

So, that’s the deal for well-known people. What about people like me? (A brown cow for now, but I’m fashioning a much more purple suit for myself). Though I don’t attract the same level of attention as Seth, the fact is that when I’m looking for a job or possibly having any number of other interactions with people, there’s a distinct possibility that I may get googled. When I do, I want this blog to represent me.

This blog is not a commercial endeavor. I was just asked if I was interested in reading a press release for a product and maybe put an ad up for it. I’m more than happy to talk about a product that I like or dislike (I’m a sneezer in Seth’s Ideavirus parlance), but I have no desire to talk about something that is outside of what interests me now.

For people like me, the longevity of the blog helps. The fact that I’ve been doing this for three-and-a-half years and have collected random links pointing in over time is a good sign to folks that I am what i say I am. I’ve been reading Dave Winer’s blog for more than five years. I didn’t know who he was before then, but at this point I’m quite certain that he’s not a fake.

I think that there are plenty of folks like me who blog because it helps them to organize and remember their thoughts. And, sometimes, putting those thoughts out in public will help other people.

For those who have some kind of “fake” agenda, the blogs will ultimately fail because:

1) they’re not interesting because they are too focused on that agenda, or
2) they’ll get caught in a lie. If there’s any significant readership, some alert reader will spot problems. This has happened over and over already.

I just don’t see a fake having any lasting impact or readership. Seth says, “One of the reasons blogs worked so well for so long is that we could believe them.” I think there will continue to be more than enough to believe in across the blogosphere that blogs will continue to work just fine.

Another good one from Slashdot. XML.com: Printing XML: Why CSS Is Better than XSL. Of course, it would be nice web browsers supported all of the CSS printing goodness that they outline. On the positive side, in the comments someone mentions css2xslfo. Ironically, this converts your nice, concise CSS to the very format that the authors are blasting. However, XSL-FO can produce nice output, and it can do it today. So, having a free tool to produce good PDFs out of your HTML/CSS is a bonus.

Don Shelkey, the author of Enforceability of EULA’s [1] is a lawyer (not providing legal advice, of course). This article provides a quick review of how the courts have viewed End User License Agreements. It appears that in many cases, a click-through license agreement is enforceable as a contract. Good to know if you’re either clicking through, or creating/choosing a EULA for your software.

This still leaves the GPL untested. Given that there’s no “consideration” for GPLed software, and that you generally don’t even clickthrough and many GPLed packages, the GPL will probably still have its day in court.

[1] [link goes to MirrorDot because the original seems to have gone off the air]

I’m not a graphics person. There, I’ve said it. I can admit it to the whole world (of course, you already knew that, judging by Blue Sky On Mars :). I’m looking for someone to work with (on a contract basis) on the product I’m building and its associated website. I’m not particular about finding someone who has a lot of fancy resume experience. I’m looking for someone who has a good style and knowledge of putting together nice looking web pages.

Someone in Ann Arbor would be fabulous. Someone halfway around the world would be fine as well, though.

Please send me email if you or someone you know might be interested. Thanks!

Update: Please use the subject “graphics design” if you do send me a message about this. I just want to be sure that no one falls into my Spam folder.

If you ever wondered why they don’t have more geeks in Teen Beat, though I never wondered such a thing, look no further than these photos: Bill Gates Strikes a Pose for Teen Beat Photospread, 1983. It is, of course, unlikely that these photos were actually for Teen Beat, but they’re still funny.

It is apparently not an urban legend that a 100 pound, 19-year-old woman ate a 6 pound burger with 5 pounds of trimmings. Gadzooks. And she did in in under 3 hours. Makes me quesy just thinking about it.

Like many others, I read Mike Spille’s How Groovy Lost Its Groove Thang which eloquently detailed how Groovy was a lost cause unless someone stood up and started forcing the choices to be made. He is absolutely correct: for Groovy to become a fully realized and standardized language, someone has to sit down and document the rules. I guess one could document it in a TCK, but many people would probably like to see it in English.

So, Mike got this off his chest and could move on with his life, right? Apparently not. Instead of moving on to other topics, he started hammering out the details of Groovy Closures and Related Syntax Issues. He’s either trying to directly show people the kind of detail they need to go into in order to properly specify Groovy’s behavior, or he’s trying to demonstrate that he’s the guy to take the bull by the horns and get it done.

In terms of JVM languages, I think Groovy has some good things going for it. BeanShell is too close to Java to be truly productive. Jython is too far from Java for many people’s tastes. Nice has some really great features, but seems more positioned as a better-than-Java language, rather than a scripting language. Groovy tries harder than Nice to make it quick and easy to do things (which, arguably, is what you want in a scripting language).

Though I haven’t agreed with all of Mike’s suggestions for Groovy along the way, I will say that no one has put the effort into documenting the details like Mike, and those details are what will inform the difficult tradeoffs. I hope that those who are into Groovy are paying attention, because what Mike is on about is exactly what will move Groovy into acceptance are big companies.

With that said, I’m going to go back to writing my Python now

Bob Ippolito came to my rescue today. I started using Cheetah for some template work, and it turns out that doing:

from Cheetah.Template import Template

from within your action is bad. (Bus Error bad, not simple exception bad.) So, if you’re using PyObjC, make sure you do your imports at the module level, not in a given block of code.
Update: Bob tracked it down. Don’t import Cheetah inside of an action, because it will import PyObjC’s WebKit (thinking that it’s getting WebWare’s WebKit) and importing PyObjC’s WebKit inside of an action has some issue at present. So, go ahead and do imports wherever you want again, as long as it doesn’t involve WebKit