Monthly Archives: September 2012

Because some idiot in Redmond thought it was a good idea…

I have been known to get a little frustrated with certain Microsoft products. Only really Office. And Windows. So just 75% of the stuff I use.

I know I am not alone. This is particularly apparent when they ‘upgrade’ the products. Functions that were once easy to find and use are buried beneath lots of new ‘features’ and work completely differently. Sometimes, they have disappeared completely. (or maybe they are just so deeply buried that I can’t find them, which is effectively the same thing).

The obvious question is “Why did they do that”, to which my response is “Because some idiot in Redmond thought it was a good idea”. I have in mind a particularly geeky programmer with glasses and bad complexion (I know, cheap stereotyping) who has never used the product in anger and has no understanding of how most business people and office workers think. In fact, I think of someone who has very little contact with normal people. How else can you explain the changes they have made?

Now, I know that’s ridiculous and there are probably hordes of people who have to sign off the changes to the user interface. Well, perhaps none of them understand how real people work. Or perhaps they don’t care. Either way, I am mystified, annoyed, upset and outraged. And I don’t think that’s what they were aiming for.

It’s really, really important that you understand your customers. Not just understand them, get inside their heads, think like they do, see the world like they do. The Empathy Map is a good tool to help you with this but you have to keep working at it. Of course, you should be talking to them and enlisting their help to design the product, but you need to have your own reference point as well. (They need to go home, eat, do their stuff, after all).

Remember, it’s them you need to please, not you. Don’t be like that idiot in Redmond…

Effort. Less.

My wife and I went snorkelling on our recent holiday and marvelled at how the instructors seemed to move so easily through the water.  We splashed around like fury and they seemed to make hardly any movement at all but zoomed around all over the place. Less effort and more effect.

That’s true for many sports. As I have become a more proficient skier I use much less energy because I know when to apply the pressure to get maximum effect, so I can ski much more for the same effort.

It’s also true in golf (although I have yet to master it!). Ernie Els is know as ‘The Big Easy’ because he appears to put hardly any effort into his shots but he hits them further than most. He is able to apply his power at exactly the right moment and place to get the maximum distance.

When we begin something we thrash around in an inefficient and ineffective way. Gradually, we realise what works and what doesn’t and refine our actions. We might get some advice, some coaching to help us. Maybe, eventually, we achieve mastery.

Sometimes, though, we just keep thrashing around. It may be we’re just no good at it (and should get someone else to do it), or we get obsessed with the money or the glory, and get distracted. We stop looking at the results, we forget to learn and refine our actions. The problem is that just thrashing won’t get us where we want, , no matter how much we want it.

Instead of trying harder and harder, we should looking to put in less effort. Because that shows we’re learning, developing and growing. So we’re more likely to achieve our goal.

Effortless doesn’t mean easy. Quite  the opposite, you need to apply yourself and work at it. It just means what it says.

Effort. Less.

Can’t code, Won’t code.

image by – creator

I do product. I don’t do code.

Some people are surprised by this. I work with tech businesses, after all. In the eyes of some, it reduces my credibility. For a few, it rules me out completely.

There are several reasons why I don’t code, including the fact that there a tons of people out there who have far more passion for it and proficiency at it that I could ever have. But there are three that are key.

Firstly, my strengths lie elsewhere. I’m interested in all the other stuff that goes to make up a great product or service. I’m good at spotting what’s missing and filling the gap as quickly and easily as possible. Getting involved in the code would be a major distraction.

Secondly, I am the customer champion. As far as I’m concerned, if it doesn’t deliver a recognisable benefit to the customer, it gets chucked out. I am above being seduced by the neatness of the feature, the elegance of solution or the brilliance of the code. I am immune to the conceits of ‘pet’ features. If it doesn’t rock the customer’s boat, it’s out. My detachment from the code is crucial to maintain that clarity.

And thirdly, I don’t need to know. I don’t have to do it to appreciate and value it. I know how hard developers work, how difficult it can be to do apparently simple things.( I also know what padding and filler looks like and how to ask difficult questions, btw). I can’t cook a gourmet meal, make a vintage wine or sing like Sinatra but I can appreciate the skill and talent involved. And I can tell if it’s good or not.

Instead, I spend my time creating an environment where the coders can do their very best stuff. And then we all get to do the things we excel at.


How much process do you need?

There seems to be two approaches to process. None, as expounded by the JFDI, action-focused, now-is-too-long entrepreneur. Or loads, as implemented by the risk-averse, detail-obsessed control-freak. I’d like to say I am exaggerating here but people really do seem to fall into these two camps. So which is right?

Neither, obviously. Without process, a business will reach a point where the entrepreneur becomes a bottleneck and just can’t do it all, and will ultimately crash and burn. (That’s the business. Or the entrepreneur. Or both.) Too much process and the business is unable to respond quickly, gets locked into doing the wrong things, takes too much time and money to do things and comes to a complete halt.

In both cases, by the way, the staff feel completely powerless and demotivated and contribute far less than they are capable of.

Process is a means to an end, and you need just enough of it to reach that end, i.e. a profitable and successful business. To me, process is what you use to make sure you don’t have to solve the same problem twice. You solve a problem, put it into a process so that others can deal with it in future, and move on to the next problem.

So when do you need process? When you’ve solved a problem that you think you’ll encounter again (or you anticipate a problem that will keep arising, such as dealing with customer complaints). How much process do you need? Enough to allow others to deal with it without your supervision, but sufficient for you to be able to manage the activity.

In a growing business, your resources are constrained, so you have to use them carefully. Don’t waste them on process you don’t need (i.e. writing a big thick manual to deal with a one-off or occasional problem), or on solving problems more than once (i.e. being surprised everytime a customer asks for a refund).

It’s a delicate balance, a matter of judgement. Asking yourself if you need a process, and if so, how much process, is something you should do continually. Getting it right will make a big difference to your business.