Lindsay asks: 'who are your customers?' It's an interesting question, and the answers aren't always as obvious as you might think. If you're shipping software, your customers are the people who buy your software - these are often not the ones who use it.
But, as she says:
It all goes back to something I've noticed for a while now - that perceived failure and actual failure are the same thing. If your users don't like the product you build, it's a failure. Even if it helps them solve their problem.
If you always aim to make the users happy, chances are that your ultimate customers will be happy. I think this applies right across the market - from the tiny microISV aimed at the home consumer, to the large enterprise software house selling an abstract product nobody really understands.
As a consequence, I always like to see one feature in your feature set that's solely to make users happy.
As an example, the next version of Context ICE contains a cool new date selection tool. It took about a week to build. We didn't need it - ICE is really good at figuring out dates when they're typed in an input box. But it looks cool, and it makes it just that tiny bit easier to enter dates. And, in our initial random usability tests, it provokes lots of nods and praise.
So sure, consider your customers. Make them happy however you can. Send sexy looking Sales people out to take them to dinner. Put expensive advertisements in targeted periodicals - whatever it takes. All of these tried and true techniques are still worth doing. But if you delight the users, the customers should always be happy. And that might mean adding features and styles that offer no significant benefit to the product, other than to make the users happy.
And once you've got happy users, what then?
Turn them into Salespeople.
Seth Godin explains how.
But, as she says:
The people who pay you, want the people who pay them to be happy.And that means the people who use your software. If you sell your software through partners, or re-sellers the same applies - your deputies want to deploy your software and have it a success. And annoyed users are a great shortcut to unsuccessful projects.
It all goes back to something I've noticed for a while now - that perceived failure and actual failure are the same thing. If your users don't like the product you build, it's a failure. Even if it helps them solve their problem.
If you always aim to make the users happy, chances are that your ultimate customers will be happy. I think this applies right across the market - from the tiny microISV aimed at the home consumer, to the large enterprise software house selling an abstract product nobody really understands.
As a consequence, I always like to see one feature in your feature set that's solely to make users happy.
As an example, the next version of Context ICE contains a cool new date selection tool. It took about a week to build. We didn't need it - ICE is really good at figuring out dates when they're typed in an input box. But it looks cool, and it makes it just that tiny bit easier to enter dates. And, in our initial random usability tests, it provokes lots of nods and praise.
So sure, consider your customers. Make them happy however you can. Send sexy looking Sales people out to take them to dinner. Put expensive advertisements in targeted periodicals - whatever it takes. All of these tried and true techniques are still worth doing. But if you delight the users, the customers should always be happy. And that might mean adding features and styles that offer no significant benefit to the product, other than to make the users happy.
And once you've got happy users, what then?
Turn them into Salespeople.
Seth Godin explains how.
Comments
Post a Comment