Feedback and collaboration are wonderful, important topics and they have passionate advocates. If you develop your offer with your customers you get better, more satisfying and more profitable products and services.

But.

There’s always a but, isn’t there? It’s not fair. Yesterday I was writing about how you should collaborate and work with your readers, now I’m saying there are times you should ignore them. I wish there was a hard-and-fast, do-this-and-you’ll-always-be-right rule, but there never seem to be any.

Feedback won’t help you build something radically different

User feedback would never have created the Aeron chair. (Malcolm Gladwell wrote a whole chapter about this in his excellent book Blink.) It wasn’t an incremental improvement, it was a completely novel design. It didn’t look like any chair that had come before it.

There were survey groups: they had nothing to compare it with, and no frame of reference on how to think about it. All of them hated it.

If the designers had listened to their users, they would never have produced the chair. Fortunately, they decided to ignore the user feedback and sell it anyway. It’s won some seriously impressive awards, started a new design aesthetic for chairs (more and more designs that look like Aeron knock-offs), and sold a lot of chairs.

So user feedback will help you design a new product or service if it’s similar to something they already know. They can tell you if they would like dark chocolate instead of milk, half-hour sessions instead of hour-long, extra-large or medium.

But if you are making something totally new, something they don’t have a frame of reference for? Your users will say “It’s ugly” or “It’s too complicated”, but what they really mean is “I don’t get it.”

(Quoth Henry Ford: “If I had asked my customers what they wanted, they would have said a faster horse.”)

You have to know your customers intimately, understand their needs, and then ignore their first reaction when you bring out a really new product or service. You can’t test revolutionary ideas beforehand. You have to put them out there, patiently wait for your customers to get used to the idea and try it out, and then ask them what they think about it. That’s scary and frustrating. But it’s really the only way to build remarkable, awesome, game-changing stuff.

Your five-minute mission, should you choose to accept it…

Spend a couple of minutes writing down totally off-the-wall ideas that your customers would vigorously reject. Repeat every month. If you come up with a revolutionary idea? Fly that flag of revolution, comrade!

Ever had an idea that you thought was great but was rejecting as being too different? Tell me in the comments!

It’s time to shake things up here in BeAwesomeOnlineLand. (Did you hear someone start playing Eye of the Tiger? Weird.) We’ve just completed two months of how-tos and daily 5-minute missions, and gotten to know a lot about you and where you’re at and you’ve let us know how we’ve helped you, and these are all awesome things and I want to keep doing them.

But.

Remember that colourful manifesto I wrote? It came from a serious and passionate part of myself that wants to burn down and jump on the ashes of every boring, useless, un-awesome website on the internet. So for the next month I am going to write about all the common wisdom of websites, and why much of it sucks a giant pile of ass.

(Also, I will probably using the phrase “giant pile of ass” more often. I’m being heretical and confrontational, whee!)

So here’s the first high treason, for which I may be ejected from Geektopia:

Technology is the least important part of your website.

I’ve given myself a small loophole here. For some websites, technology is very important: Amazon’s website would be much less popular without features that are heavily tech-reliant.

But you’re not Amazon, and neither am I. For my website, and for most websites, you could use 500 different tools for content management, design, integration etc etc etc and your visitors would neither notice nor care. Most website technology is Good Enough.

So that means that the hours upon hours you spend debating tools are wasted time. Worse than that, for a lot of people they’re an avoidance mechanism. I understand! This is scary stuff, but you’re approaching it wrong.

How most websites are started

1. Sarah decides to start a website for her dog-walking business.

2. She spends eighty-seven hours researching tools and technology.

3. She spends another thirty-six hours getting the tools and technology to work, floundering in a sea of PHP versions and database permissions and header margins.

4. Sarah finally has a website! Seventy-three hours later it looks sorta kinda the way she wants.

5. Completely worn out by the process, Sarah takes three hours to throw together a few sentences of content and calls it done.

Result? Sarah’s website sucks. The stuff people care about (information about dog walking and how to hire Sarah) is slapdash and thrown together, and because she was completely drained when she wrote it, it reads like a corporate manual. People leave after 15 seconds, but it doesn’t really matter because no-one finds the website anyway. Sarah has spent one hundred and ninety-nine hours on this website… and only 3 of them were on the unique value only she can provide. The most important task got left to the end when she was tired and burned out.

There’s a better way.

A better method to start a website

1. Sarah decides to start a website for her dog-walking business.

2. Sarah spends sixty hours writing articles for her website. She gathers testimonials and photos of excited dogs and a page of tips on how to keep your dog healthy in winter.

3. Sarah decides she doesn’t want to fuss around with technology for ages, so she hires Johnny B. Truant to create a totally decent website for $175. (Of course, if Sarah was a do-it-yourself kind of woman she’d buy the Website in a Weekend course and do it herself, but she doesn’t really want to know how it’s done. She just wants it to work.)

4. Three days later she has a website.

Result? Sarah’s website is awesome. It’s useful, it’s got lots of pictures, and loads of natural search engine optimisation. Because Sarah wrote the content at the beginning when she was at her most enthusiastic, the content is passionate and interesting and worth reading. She loves the website, and not in that I’ve-suffered-so-much-I-might-as-well-enjoy-it way. And as she writes more content and gradually adds new features, the website starts getting traffic. Sarah gets more dogs to walk. And the world is just a little better for it.

Your 5-minute mission, should you choose to accept it…

(You didn’t think the missions would go away, did you? Never!)

1. Choose one feature you haven’t added to your website yet. (If you haven’t started one, your list will be quite long. If you do have a website, I bet you still have a feature or five you haven’t implemented.)

2. Stop looking at the technology and spend some time planning what the tools are for.

• What questions will you ask in your survey?
• What fields do you need in your contact form, and how will you ask for them?
• What will your welcome email say?
• How will you describe yourself in your new profile?

This is a bigger post, and a new format. Please help with your feedback:

• Do you like the new longer posts?
• Do you want me to stop using the phrase “giant pile of ass”?
• Agree with the heresy?
• Have some other ideas to destroy?
• And most importantly, have you completed the 5-minute mission?

photo credit: donakeannadoanek3n4an

The following is the fruits of seven years or so of having been involved in interviewing and hiring techies, and over ten years of working amongst my own kind and observing. And to clarify, by techies I mean people with specialised computer skills, whether it’s administering servers, developing code for your website, or possibly even doing the visual design and layout for your site. Now, you might find that the majority of jobs you need a techie for are short, clearly defined pieces of work that are well-specified. In which case, the personality and peccadilloes of the techie is less important than their resume or previous work.

All the same, the info here might be useful in determining whether to use someone again and again. So here’s some traits to keep an eye out for, and some possible ways to check for them.

Also, I’ve thrown in some quotes from Hagakure, my favourite book. It’s relevant in a way, given that the book is primarily about the relationship between a retainer and their lord (albeit in feudal Japan) Because fundamentally techies are retainers – well-trained retainers, but retainers all the same. We’re here to serve some fundamental need that is larger than just our work. At any rate, here’s hoping you find the quotes interesting.

Once there was a certain man who was very clever, but it was his character
to always see the negative points of his jobs. In such a way, one will be useless.
If one does not get it into his head from the very beginning that the world is full
of unseemly situations, for the most part his demeanor will be poor and he will not
be believed by others. And if one is not believed by others, no matter how good a
person he may be, he will not have the essence of a good person. This can also
be considered as a blemish.
Yamamoto Tsunetomo

Arrogance: What’s Their Attitude to Mere Mortals?

If I had a nickel for every time someone I’d worked with on a contract had said “They just don’t get it, man” then… I’d have a very heavy pile of nickels that wouldn’t do me much good in Australia. But it would still be a potent visual reminder that this sure happens a LOT.

A common byproduct of such specialised knowledge, and a genuine love for the field that they work in, which are both laudable traits on their own, is the unfortunate tendency to look down their nose at people who don’t understand and appreciate the inner workings of their field themselves. Which is a shame when it happens.

What To Do: When talking with your potential techie, pick a particular term or technology you’re unfamiliar with, and profess your ignorance. Ask the techie to explain further, and see what happens. Hopefully, they’ll accommodate your request happily, rather than sighing in exasperation. The key thing you’re looking for here is how they react to a lack of understanding from you – what happens to how they interact with you.
When something is said to you by the master, whether it is for your good or bad
fortune, to withdraw in silence shows perplexity. You should have some appropriate
response. It is important to have resolution beforehand.
Moreover, if at the time that you are asked to perform some function you have deep
happiness or great pride, it will show exactly as that on your face. This has been
seen in many people and is rather unbecoming. But another type of person knows his
own defects and thinks, “I’m a clumsy person but I’ve been asked to do this thing
anyway. Now how am I going to go about it? I can see that this is going to be much
trouble and cause for concern.” Though these words are never said, they will appear
on the surface. This shows modesty.
Yamamoto Tsunetomo

Over-promising: Do They Know How To Say No?

On the other side of the fence, one character trait that a lot of techies seem to have is an almost pathological need to please. We like to solve difficult problems for people, and make them happy.

One of the problems that can come with this is a tendency to over-promise – to be rather optimistic about underlying challenges and deadlines, and not want to say no. To be fair as well, deadlines for technical tasks can also end up being unrealistic because of unexpected complexity – kind of like that follow-up phone call from the mechanic where they explain that things are actually going to cost a LOT more, and you really should think about canceling that trip around Europe by the way. Or paying for food for the next month.

Ideally, you want your techie to have the battle scars that give them the instincts to push back on unrealistic deadlines and say no. Because you can’t plan with deadlines that won’t be met. Whatever crucial part of your site they’re putting together for you won’t be ready in time for key tasks, and everything will fall apart.

What To Do: When discussing estimates for a particular task, see what happens if you suggest compressing the time taken by 30%. This is a guesstimate figure because it’s small enough to seem reasonable, but still a big enough chunk of time that it’s unlikely to not have an effect on the work. Ideally, your techie should gently but firmly explain that the task will take a fixed amount of time. Or, they might be willing to compress timelines a little in exchange for other considerations (eg. more money for more stress, or extending other deadlines)

What you don’t want to see is them nodding and saying ‘sure’ with a daredevil adrenaline-junkie glint in their eye, or sighing, slumping in resignation and agreeing to the new timeframe. If you’re given timeframes that match with reality, you can plan around that even if they’re longer than you’d really like.

What you can’t plan around is a constant state of “Just a few more days”.

(Note: tread lightly with this one, as pushing too hard on timelines will give the impression that you either don’t understand the reality of the situation, or you’re unreasonable)

I’ll be back Monday with Part Two. In the meantime, let me know what you think.

Tips on managing troublesome techies, or books/articles you’ve read that have given you great advice? Hit us up in the comments!