Let's start off with a simple question:
Why is Dropbox more popular than other programs with similar functionality?
and the answer by Michael Wolfe:
Well, let's take a step back and think about the sync problem and what the ideal solution for it would do:
There would be a folder.
You'd put your stuff in it.
It would sync.They built that.
Why didn't anyone else build that? I have no idea.
"But," you may ask, "so much more you could do! What about task management, calendaring, customized dashboards, virtual white boarding. More than just folders and files!"
No, shut up. People don't use that crap. They just want a folder. A folder that syncs.
"But," you may say, "this is valuable data...certainly users will feel more comfortable tying their data to Windows Live, Apple Mobile Me, or a name they already know."
No, shut up. Not a single person on Earth wakes up in the morning worried about deriving more value from their Windows Live login. People already trust folders. And Dropbox looks just like a folder. One that syncs.
"But," you may say, "folders are so 1995. why not leverage the full power of the web? With HTML 5 you can drag and drop files, you can build intergalactic dashboards of stats showing how much storage you are using, you can publish your files as RSS feeds and tweets, and you can add your company logo!"
No, shut up. Most of the world doesn't sit in front of their browser all day. If they do, it is IE 6 at work that they are not allowed to upgrade. Browsers suck for these kinds of things. Their stuff is already in folders. They just want a folder. That syncs.
That is what it does
Product Identity
The hardest part of early app design is determining what is essential to an application, and what is out of character or a distraction. In nearly all cases as early product designers and implementers we expend resources on features that are defining characteristics, yet we also add and maintain features we aren't 100% passionate about because we believe they might be relevant. In effect our failure to make a hard decision results in watered down effort where it counts, and additional complexity and maintenance. I believe that our duty as early product designers is to relentlessly prune any superfluous features until only an irresistable base form remains.
There's a related question of data capture and what to add to your document store. Here I believe that more is better. Grab every stat you can about how clients interact with your application. You can always decide to dump irrelevant data later, but you can't retroactively add important data. Many modern databases are flexible allowing new values to be added as you go, but having access to information early will impact rapid decision making about resource allocation (ie everyone's going hog wild about the Motherf**king Faces).