Sometimes, marketing efforts go awfully, terribly wrong. Sometimes, it’s nobody’s fault - it’s just the way things turned out.

However, sometimes, it’s absolutely and clearly someone’s fault. Some ad campaigns are really badly designed. They don’t necessarily come out of an obscure, inept company. The ad campaign I’m going to talk about today is from Forbes.

I can never leave well enough alone. After my article blasting perfectionism, I guess it was inevitable that I should engage in a bout of it myself :-)

Not that the blog is perfect now, by any means.

Anyway, so I’ve moved over to a new blog engine, from Wordpress to Typo. Typo is written in Rails, and supports all the key features I want on my blog (e.g. Trackbacks). This means I can extend and reprogram it as I want, something I could not do with Wordpress and its mountains of spaghetti code. I’m planning to add a few cool features now that I’ve got full control over the code. Keep your eyes peeled for funky things like hit counts on posts, and other things you probably don’t care much about but which will make me feel happier :-)

As you can see, there’s also been a redesign! I have my friend Kelvin Koh to thank for the lovely new header, which not only looks 20 times cooler, but also only takes 19 kilobytes (as opposed to the humongous 75k of the previous one!). Here’s the old one one last time so we can all say good bye to it.

Looking forward to posting many more interesting articles for your reading pleasure.

Ciao,

Daniel

PS: If you love or hate the new design (or if you find anything broken anywhere), please don’t hesitate to let me know in the comments below!

1. The idealistic path to ‘perfection’

You’re sitting at your desk, alone with your idea. Or perhaps you’re with some friends or colleagues or both. This is a great idea. You’re excited! Now all you need is to implement that perfect vision, and you will become rich and famous.

You’ve heard that ideas are nothing without implementation. You’ve heard that ideas are a dime a dozen, you know that what will make or break your idea (and your business along with it) is how well this idea is implemented. The devil is in the detail, and you’re going to make damn sure that every detail is right. All you need is to make something people want, to make it the best damn implementation out there, and you’ll be laughing all the way to the bank!

Unfortunately, there’s a fatal flaw in your plan: you and your brilliant idea. You, I’m sorry to say, don’t have the first clue what your users really want. Oh, you have some vague idea — and at this stage, a vague idea is a pretty good start — you know roughly where you want to go, but the truth of the matter is, if you took your vague idea, concretised it, and implemented it perfectly as it is currently in your head, it would be a very, very bad product, a monumental flop. This is true whether you have detailed knowledge of the business domain, are a technical expert, or both.

There is much talk these days about building a product for a niche and making a lifestyle business out of it. Much of the online literature about starting up is focused on how to create some fantastic product which will gather millions of visitors and make you a billionaire, and the “new wave”, so to speak, proposes that rather than taking a 1 in 10’000 bet that you can make billions, it is better to take a 1 in 10 bet that you can make millions.

Since I have started two such businesses already, here are thirteen tips from my own experience.

Once or twice a year, the same thing happens to me. Suddenly, unexpectedly, I feel overwhelmed with simply too many different things to do. It’s hard to juggle a lot of unrelated balls, and I inevitably let a couple fall at the beginning, before I finally re-learn what I learnt the last time this happened, and juggle the balls effectively again. Once that’s done, I feel efficient, happy, on top of things.

Why do I have to re-learn it all over again each time? Each set of balls is different, but I think in this case it’s simply a failure of paying attention to my own failures and learnings. I’ve already successfully juggled “too many balls” a number of times, and each time I applied pretty much the same method.

Part of the problem when you get overwhelmed is that you feel stressed, and you don’t think clearly anymore. That may explain why I don’t automatically recall what I did last time, when this happens. So, in the hopes of helping the many future stressed me’s, and the many stressed you’s out there, here’s my way to keep on juggling when life and work (they always seem to do it in concert) throw you another half-dozen balls.

In this article, Adrian Hon, picks up on the idea (originally from Gregory Bateson, I believe) that time pressure creates what Bateson calls false endpoints, that reduce the quality of the final solution. He also proposes that the development process in creative fields should be altered to encourage “play” as a way of generating solutions, even as part of a business.

I believe this is misleading, because it’s partially correct. Time pressure does cause us to make compromises, but those are not necessarily to the detriment of the overall solution, particularly if one takes a long-term view, or if one considers just how unknowable a concept the “best” solution is.

You’re a business guy, a manager, or you’re a developer. You work on a startup, or within a large corporation. You’re about to start on your company’s flagship product, or you’ve been asked to take project X forward. Or you could be anywhere in between those extremes. One question should be worrying you as you take on the noble task of delivering something viable: how tough is your project, and why?

This matters a lot, because if your project is tough, you’re going to need to figure that out quickly and address the things that can go wrong with it. And if your project is really tough, you’ll need to find great developers to work on it.

So how do you figure out how tough your project is? There’s a number of ways. You can ask people, for a start. In aggregate, qualified people who understand the project will have a pretty decent idea of how tough it is. But sometimes you can’t ask, either because there’s no one to ask, or because the politics of the place dictate the wrong answer. What you can use in those cases is a list of criteria, of checkboxes that mean your project is tougher if you tick more of them.

While looking for reviews of productivity tools (task tracking tools, specifically), I stumbled on a great new blog called Put Things Off. I liked the articles - they’re all well written, interesting, and exquisitely illustrated (seriously, I’m not kidding), and since their topic is somewhat related to some of my posts, and they only launched in mid-January this year, I thought I might as well share this discovery.

From their own description: ”PTO helps freelancers, entrepreneurs and busy people work smarter, play harder, and live the lives they love.”

Enjoy!

Over at Business Of Software, there’s an article trying to present some approaches to hiring managers. This struck a chord with me, since I’ve been thinking of whether there was a way to translate my how to recognise a great programmer article into something similar for managers.

The difficulty I’ve hit, and which is not mentioned in the linked article, is that where “great programmer” was a moderately controversial idea (if you read the comments you’ll see what I mean), “good manager” is very subjective and hard to define. This makes it very hard to come up with any clear list of criteria that define what a good manager is.

When building something new, mistakes are unavoidable. To paraphrase the common saying, “if you’re not making any mistakes, you’re not trying hard enough”. There’s another saying which says that the difference between a good carpenter and a bad carpenter is not that the good carpenter doesn’t make any mistakes, but that he’s better at turning them into masterstrokes. You can, and should, try to prevent mistakes from happening, but it’s a fact of project life that things go wrong.

Many books can be filled on the subject of how to deal with the huge variety of project mishaps. In this article, I’ll focus on one specific type of mistake: the big, fundamental mistake.