Software is supposed to make our lives easier, not harder. Computers can do the easy work and leave our brains to do more difficult tasks. But without a problem there is no software to solve it.
The alpha development stage in an agile process is a perfect time to solidify the problem statement(s). You can start out solving one problem and discover others -- or realise that your initial problem isn't a problem enough people are having to make developing the software worthwhile.
An early functional alpha prototype that people can actually try out makes these things a lot more evident and reduces the risk of failure down the road. Agile projects can be constructed to the alpha stage without a lot of effort, so they are excellent proof-of-concepts and a relatively inexpensive way to confirm potentional risks in the business plan.
Now is not the time to nitpick. Concentrate on the big picture and respond to feedback quickly. Work on solidifying the big picture -- how the software functions. Detail work could easily be blown away by a reversal of a big decision at this stage, so it's not worth doing a lot of it.
Get it deployed as soon as possible, even if it's simple (or empty). You don't have to tell people about it right away, just get it to the point where you can share it easily...
...and then update it a lot. Deploy changes as you make them. This is the alpha stage and things will break. Don't worry, people will be forgiving because you've given the alpha disclaimer (but only if they understand the implications of it). Explore new ideas and respond to feedback quickly because it'll lead to more feedback.
All of this change is good because you're steering your software closer to what people need to solve their problem(s). But code churn doesn't mean the project turns into an unmanageable mess.
Use a unit testing framework as a safety net: make a change, run the test suite to make sure everything still works and then deploy. Repeat over and over again. Testing is critical to agile development.
"Alpha software" used to mean nearly feature-complete and buggy software that was ready to be let loose on a testing team to find bugs and report back to the development team. With agile development the software can start high quality and continue high during development, giving the term "alpha software" a new definition.
At the alpha stage the most valuable feedback is directed at the big picture. Releasing early and often doesn't produce the best looking software -- but it's important for the developers to make this as low of a distraction as possible.
People experienced with using early releases are able to put aside form and concentrate mostly on function. But there are cases where form at the alpha stage is critical and developers need to address these places to reduce that distraction to big picture feedback.
You don't need a lot of people giving feedback early on. As you can handle increasing levels of feedback, invite more people to use the alpha. If there are too many people giving feedback you'll find that they all say the same thing anyway.
Get quality people instead of quantity. Get people who are experts in the domain or experts with software. You'll get the best feedback from people who are forgiving about the site being ugly and slightly painful to use and can focus on how it solves their problem(s).
Not all ideas people give you at the alpha stage are good ones! Listen to all of the feedback you can and filter out what isn't needed at this stage. Concentrate on the problems you want to solve and how you are solving them. Make it look nice in beta when things settle down.