Programmers like to program - it’s what we do. Just like doctors like to doctor, preachers like to preach, and waiters like to wait. We like it so much, we don’t want to do anything else. We don’t want to worry about all that pesky advertising; we don’t want to spend hours or days choosing just the right words for our web-site; we don’t want to bother with all that marketing stuff - after all, the product is good enough to sell itself. Right?

Wrong.

This is the fatal flaw that destroys many small software companies. Starting out, our knowledge base is limited. We know how to write code and design software, so this is what we do. We release a version 1 of our first product, listen to feedback, and follow it up with a version 2 a couple of months later. It’s good enough to sell, but we don’t know how to sell. It has the potential to sell well if we could just get our message across, but we don’t know how to market.

The next version of PageFour is on the drawing board. After taking feedback from existing users - and scratching my head over a bottle of Merlot - a list of changes and enhancements has been carefully put together. It’s a strong list, and the product will be stronger as a result. The temptation to take this list and start writing code has been overwhelming. Six hard weeks of work, followed by a testing run, and version 3 would have been ready by the end of March.

The road to failure is filled with writing code.

For a small software company to succeed, the two parts of the business must be given equal weighting. Yes, design a great product, and keep making it greater. But we need to work just as long and hard at marketing the product, at getting our message out there.

For most of our careers, we looked down on the guys in marketing and sales, as if their jobs were somehow beneath us. Now, our success depends on learning their skills.

My development plan for PageFour has shifted somewhat. The list remains, but the time frame has changed. Instead of working for two solid months, testing heavily and releasing, I plan to release after each feature is implemented. This means four releases over the next four months - a steady development of the product, progressing side by side with the marketing.

No more mad rush to write code.

My TV remote has twenty nine buttons I’ve never used; the VCR has thirty; the DVD player twenty six. And before you ask - yes I really did count them all.

There’s a name for this kind of excess: it’s called featuritis, and it pops up in all sorts of design failures. I stumbled across an interesting article on The Featuritis Curve the other day that goes a long way to explaining why we have to endure this.

Good designs are obvious. When aesthetic and functional beauty combine, the result is not just pleasing to the eye, but a pleasure to use. This is why the iPod is so popular. Chances are it’s not the best value for money - there are probably other music players that produce a better sound, have a longer battery life, or have a whole raft of additional features - but the iPod looks like a work of art and is simple and straight forward to use

When have you ever heard someone boast that they couldn’t program their iPod?

So who should we be designing for anyway? The 98% who use a small number of features all the time, or the 2% who use advanced features once a week? Wouldn’t it be a whole lot simpler if my TV remote had a single advanced button that opened a menu for all those quirky, unused features?

Make no mistake here - you’ve never used those mysterious buttons either, and you probably don’t know anyone who has.

Software is often designed in the same way, for the same 2% of users. Feature after feature is added, each just as prominent as the one before, with little thought given to the complexity this adds to the product as a whole.

At the nine to five over the past few weeks, we’ve been putting the finishing touches to a new product aimed at the business market. It’s the sum of eighteen months work for four programmers - plenty of time and resources to produce a first class piece of work. But it’s not first class. Dialog after dialog contains features, options, and checkboxes that no one really understands. The poor unfortunate writing the help file has to suffer every time he asks for an explanation of feature X. In some cases, even the person who designed the feature can’t explain it without re-reading his own code, and even then the explanation can be patchy.

This isn’t funny, it’s critical. Complexity like this is nothing to be proud of. But why does it happen?

You can chant ‘keep it simple‘ until you’re blue in the face, and everyone around you will nod their head in agreement. The problem is, we all have a different perception of what simple means. Programmers are geeks; they belong to the 2% who use all those weird buttons on the TV remote, and for many of them these features are absolutely essential. The sales and marketing types want to be able to say that their product is better than the competition because it can also be used to fry an egg, or do your kid’s homework. But that does not make it better.

Features are not important, it’s the product as a whole that matters. Does it do what it was designed to do, and does it do it fantastically well? Does it look good, run smoothly, and behave intuitively? If it doesn’t, then all the features in the world will not save you.

More features does not equal more sales. More features does not make for happier customers. More features will not make your product better than the competition.

PageFour has reached the stage where featuritis first raises its head. Over the past couple of weeks I’ve been putting together a future development plan, and my focus throughout has been on identifying those mysterious buttons that so few of us ever use. Only time will tell if I’ve succeeded.

When I first created the web-site for PageFour, I’d vaguely heard of the term Search Engine Optimization. It was one of those things I assumed I’d get around to eventually, but it would just have to wait until the more important stuff like rolling out the first, and then the second release of PageFour had been dealt with.

I was wrong.

Had I read those few chapters months ago, I would have realised the importance of the URL, and chosen a domain name with more relevance to the product. www.imbt.co.uk has no meaning to anyone but me. I know it’s short for It must be Tuesday; I know IMBT Software is the company name; but does anyone else? And would it make a difference if they did? It’s the product that matters, not the company.

PageFour is software for writers, and the new URL is www.softwareforwriting.com.

It’s been live now for about a week and has already been picked up by MSN’s very industrious robots. The Google team however, seem to be sleeping on the job, and let’s not even talk about Yahoo. Still, it was something that needed to be done, and it really couldn’t have been put off any longer. All the links that I control on other websites have been changed, and the new download sites PageFour has been submitted to each carry the new URL.

Things are finally moving in the right direction.

With the release of version 1.29 of PageFour, complete with one change to a single line of code, the crackers have returned.

My personal opinion of the people downloading my software from these illegal sites is that they’re one candle shy of a decent birthday cake. If I were giving the product away for free, they probably wouldn’t touch it. After all, freeware is just so common! As soon as they realise they can steal something other people pay for, and do so from a shady web-site with Mandarin text, PageFour suddenly becomes hot property.

I can just picture the emails flying to one dank bedroom after another. “Check this out. You can use it for that novel you always wanted to write about life in a twelfth century Cistercian monastery!”

Get a life guys!

Still, some of these sites have a halfway decent pagerank, so the links do perform one useful service.