I think you're on the right path with the mindset of narrowing down your feature set making sure that you have a few features working well rather than a wide set of features that are wonky. If the ones you listed are the correct ones however is far too complex to give an objective point on.
–
AndroidHustleJan 7 '13 at 9:30

Why do you want to leave any of these features out? I assume it's because of time restrictions so you need to trim the feature-list initially?
–
JonW♦Jan 7 '13 at 9:32

@JonW I want to launch it as an MVP(minimum viable product). I don't want to add a bunch of features and then realize that people is not using the site at all.
–
janoChenJan 7 '13 at 9:48

2

@janoChen OK, I've edited the question title to make it clearer what you're asking. Feel free to amend if it's not correct, but the title wasn't clear enough when viewing on the front-page.
–
JonW♦Jan 7 '13 at 10:01

2 Answers
2

alexeypegov's answer is excellent and I would strongly recommend interviewing your potential user base about what the features they would anticipate in a product like yours. However since users might not always be aware of what features they might find useful, it will also be really useful if you perform some basic usability and feature analysis tests with some low fidelity prototypes to see how your users use the system . Also since you are looking at this product as a Minimum viable product, be careful that you dont miss out on small but related things which might not seem significant in the short run but can ruin the user experience in the long run if they are missed or left (e.g. a password reset or a way to update their email address) .

Does the minimum-viable approach lead to gaps in the user experience?
It doesn’t have to. There’s a distinction to make: The set of features
you choose to build is one thing. The level you choose to execute at
is another. You can decide whether or not to include a feature like
‘reset password’. But if you decide to do it, you should live up to a
basic standard of execution on the experience side.

Features can be
different sizes with more or less complexity, but quality of
experience should be constant across all features. That constant
quality of experience is what gives your customers trust. It
demonstrates to them that whatever you build, you build well.

37 Signals writes a lot about MVP and releasing something the second you have something to show for it. Their books Rework and Getting Real (especially Getting Real) are pretty much about this thing exactly.
–
SimonJan 7 '13 at 18:58

The best way for you to find out which features should be included in MVP is to interview your target audience (and show them mockups, sketches, prototypes, etc) about the features they want to get at the first place.

Interviews are really powerful tool to get more knowledge about your users so don't ignore them.

We're not your target audience so things we'll assume useful or useless may not represent the real situation so you should treat these recommendations (if any) very careful.