Most all development projects start with a hunch at a problem. Seldom do you have the opportunity of enough resources prior beginning building to fully vet all assumptions and define all requirements. Or at the very least if you do, you’re not in startup mode. For this reason the very first thing you build is often not the perfect solution. If you’re lucky its a start at a solution, and even if its not, if you’re close users will tell you what they want.

What this leaves you with is a couple of key items. First is get to the minimum product you can to vet your idea. Most commonly known as Minimally Viable Product. This should be the minimum product you need to vet your idea, and add some form of value for users. Once you’ve created this, don’t refine, don’t keep iterating, launch. More time won’t let you perfectly solve the problem, getting it in front of users will help you solve things perfect.

Second is make feedback simple. Often times support can be difficult, if its a form that requires 5 fields on your website forget it. If at all possible, provide multiple ways for users to give feedback. ALL ways should be simple for users. Email is great, because every user already has it. If it can be built on your website, great, but you should make registering as light as possible. Personally, I’m a big fan of Get Satisfaction. They give a great embeddable widget and provide a service that just simply works.

Third, and perhaps most important: Listen to your users! When users start to give you feedback, that’s the best requirements you can receive. There’s a couple of pieces to this step. When users give you feedback, you want to acknowledge them. Give some recognition for giving feedback; respond as positively and supportively as possible. If at all possible to act on requests do it, it will set you apart from the typical services they use of never getting a response and never seeing a change.

In short three key steps make for requirements gathering that trumps all else: