How do you find out what users really want?

Contrary to popular belief, you don't ask them. Well, you don't listen to them when they tell you what they want. You watch them while they use what they have right now. If they don't have anything, you listen to them enough to give them a prototype, then you watch them use that. How a person actually uses software tells you a lot more than what they actually say they want. Watch what they do to find out what they really need.

Use Cases.

What will they do with that feature?

It works like this.

• People take actions. We build software to help them take actions

• In order to take an action a person must make a decision. We build software to help them make decisions.

• In order to make a decision to take an action, a person needs information. We build software to collect and present information.

Every feature must be an Action, a Decision or Information. And the connection had better be direct. Information that does not lead to a decision or an action isn't even "nice to have" -- it's junk.

Users say a lot of things. What do they do? What decisions do they make? What information do they need?

Edit

Note that not everyone is good at describing use cases. Some people have no vision and will simply tell you what they do today without understanding how they are creating business (or personal) value. They may not really know what decisions they're supposed to be making, and are vague on the information they need.

Other users know what value they create, and why, and can discuss use cases well. They can envision alternative ways to create value; they can articulate options for their actions. Decisions don't have a lot of alternative implementations (people make decisions, not software) and the information required doesn't change much, either.

I'm assuming based on your wording that you are building a product to sell, and not building something to order for a specific client.

In that context, I'd say that you should start by becoming a user yourself and building the features you need in the way that you want it. As you evolve the product, you'll need feedback from other users, but this at least this gets you started and breaks the chicken-egg cycle.

As for measuring actual usage of features, you can set up a discussion forum to get feedback on the features you added... you don't need anything too complicated if you are time-strapped.

1. Watch them.
2. Identify bottlenecks in their work
3. Create something that solves that bottleneck in an elegant way
4. Let them use it
5. Repeat until everyone is happy

Based on the principles:

1. Users know what they want, but they don't know what they really need.
2. You ARE NEVER going to get it right the first time.

It seems like a chicken-and-egg problem. Much like computing PageRank. A page's page rank is dependent on the PageRank of other pages linking to that page. One way of computing PageRank is by iteration.

Iteration is the key!

A. Voting

1. Gather a biiiig list of features all users want (make them enumerate each feature they want).

2. Then have them review the list and allow them to vote on features. Say, give em 100 points to distribute on features. They can give more than 1 point to a feature.

B. Analysis

Analyze the business model, List the features that you think is needed. This is needed because:

• users sometimes don't get the big picture
• you have this REALLY great idea that users won't think of in a bajillion years.

C. Implement

Analyze list from A and B, merge, remove a few, improve some. Implement.

D. Test

Test it on users. Hear their complaints. Look at - features they use often - stuff they get stuck on - etc etc etc

E. Iterate

It's called Market Research.

No, this wasn't a dig at the guy, that's really what it is about. Sure, there's a bunch of techniques that UCD people use in the field to get user requirements, but they are exactly the same tools used by market researchers. Card Sorting, Priority lists and so on are all market research terms.