You're mixing up a couple of questions here. One is "should I build just a minimum set of features and then add features slowly, or should I first draw up a design that includes every single feature I think we might eventually want?" The other is "should I build a site that works well for only one user -- probably myself -- or should I design with the assumption that there will be a lot of future users?"
These are important and controversial questions with answers that depend on the circumstances. The general approach advocated around here tends to be "start small; don't build things you aren't sure you're going to need; launch your site as fast as you can with the minimum number of features and don't build more until you're sure that users are interested and that they want more." But that approach is tuned for certain problems -- specifically, it's tuned for bootstrapped startups that are exploring new classes of application that might or might not have a market. One might argue (I would) that the majority of problems are well suited to that strategy, but no doubt there are some problems where other strategies are more appropriate. (e.g. you're designing a site for the Olympic Games, which will have relatively few users for months, then have thousands of hits per second for two killer weeks, then have a much smaller number of users going forward. You're not going to get to iterate the design over and over after the Olympic opening ceremonies; you have to plan ahead and build all the features you want, in a scalable fashion, in advance.)
Your question is related to the problem of categorizing software development processes. You might want to check out these two links for a start:
http://en.wikipedia.org/wiki/Waterfall_model
http://en.wikipedia.org/wiki/Scrum_(development)
Or, if you have an idea for a website, you might be better off skipping all this management-class stuff, learning some HTML and/or PHP or Ruby, and putting a site up! Design it just for yourself! Don't put in more than one button at a time!