The integration of features into a sensible (even if not ideal) work flow is far more important, IMHO, than the number of features. Start by finding out what data would be transformed in what way in what order in a typical manual arrangement. You can start with those most common features and make sure they actually make sense together. You might even be able to model the interface itself around the work flow instead of around the document object. Then, as optional or less frequently used methods become needed, they can be fit into the best place relative to what currently exists.

Once the most basic features are incorporated in the project, it may become more apparent how to best integrate what I like to call the "smaller checkbox" items. Those are the things you'd like to have on your checklist, but which are less important than your "big checkbox" items -- the features you'd advertise in bold. This is a good time to consider a plug-in architecture, a scripting engine, a transformation rules engine that's accessible between other steps, or coding the lesser features in directly. By knowing the common steps and having them already implemented, adding optional behavior to the major steps or minor tweaks between them becomes, IMHO, more clear than trying to plan for every feature up front. Since you already have the code for the major features in place (and hopefully debugged before starting on minor features), design and implementation details for the inputs and outputs of a pluggable module or the hooks needed for a scripting engine become clearer.

Have a clear relationship among the features which makes using the software make sense. Your end users will be far happier with that. By focusing on 20% or 80% more features and throwing them in, you often end up with a confusing maze of menus. The options on those menus are often grouped by some artificial categories based on what they generically do. This might be to make the software more flexible or just because the features are the central concern. However, if you're writing an application to solve a process problem rather than a wide range of unguided data manipulation issues then the process should take the lead in design and implementation. A word processor or spreadsheet is about flexibility, and a categorized menu system makes sense when the document is the end result. However, when the main point of your application is to follow a more defined process, minimizing interaction with the interface will make the program seem more powerful.

One reason I think web-based applications are becoming so popular is because of this process-based modeling. Part of this is a happy accident. The HTTP protocol being stateless and transactional lends well to small changes being made one after another. While JavaScript, XMLHTTPRequest, and the browser DOM make some fairly heavy state maintenance on the client possible, it's still often being based around a process that makes the applications so friendly. This is the same idea as wizard-based applications. While many programmers and power users prefer a menu or even a textual interface, there are times when a guided approach makes more sense for the majority of tasks. Chained web forms, even with fancy controls, model this pretty well.

Many web-based applications are modeled after the old screen-based input of the mainframe and minicomputer business applications of twenty to forty years ago. Many of those applications for banks, airlines, hotels, POS systems, government agencies, and similarly process-bound businesses have changed little over that span of time.

If you're working on a creative work like a graphic or presentation, a wide array of options at every point is helpful and being railroaded into a single track is frustrating. However, I think too many applications are modeled after Photoshop or Word when they ought to be modeled more after a reservation system, a government questionnaire, or even a semi-custom manufacturing process.

How about a nice, tidy example? Engine size, trim package, stereo head unit, transmission, wheel and tire size, type of seats, and more can be specified for a particular model of car rolling off the same assembly line. That line can start by making every car the same, and as each option is designated by the designers and engineers it is added to the line. At each step, two or more options might replace the single unit that was involved before, which narrows the point of changes to a local portion of the line. The particular model of car doesn't change, and the overall process of assembling the car doesn't change. Every once in a while, there's a hook in the process where a box can be checked to specify an option instead of the default.

In software terms let's say you're periodically putting together the same report (we'll use a monthly fiscal report as an example). You'll be pulling data from multiple places and transforming it to make a presentation. You'll probably be pulling the same data from the same places most of the time. You'll probably also be presenting it in a somewhat standard format. However, some department might need a more detailed accounting of expenditures on, say, office supplies one month and perhaps expense reimbursements the next. This is often accomplished as a second, separate report because messing with a general fiscal report in a word processor or spreadsheet for one customized report means major changes to the document model. However, if you're just summarizing each set of data as it comes in and placing it in a template of the final report, you can easily change how a certain section is summarized. That's a document-centric vs. process-centric difference.

It's similar to the difference between mingling your presentation and code and using a template system in a web project. Mingling them ties you to the presentation, while using a template frees you to work on process. Process, after all, is what most general-purpose programming languages model really well. Presentation is what markup languages model really well. There's much already written about the division of presentation and process, MVC, templating systems, and similar topics. I'll skip over anything deeper on those topics here.

One of the most important questions to ask yourself during software design is often overlooked. It should be considered before how many features you need. It's possibly more important than visual polish on a publicly released product, and definitely more important for internal projects. It's even more important than asking which features you need. That question, though, is really simple. Ask yourself, for every project, "Are we dealing with a document or a process?"

If you're working on a general document type without a set process, you'll want your features to be more widely and readily accessible. You'll also be working on a rare type of requirement which is usually already well represented by other software. However, if you're working on implementing a process, having the basic process flow correctly is your first concern. Fitting options and less frequently used features into the process should come after a default output can be created.

In the process-centric scenario, "good enough" becomes "which outputs can we produce from a given set of inputs?" rather than "do we have X of Y requested arbitrary features?". People don't pay for software fully customized to their needs in order to have a shiny checklist like on a shrink-wrapped box. They pay for it to get their information from specific input formats they can already access to specific output formats they want or need to use in their business. That can be as simple as a web form that asks the right questions instead of a generic comments form. It can be as complex as typesetting a book from a manuscript, or building a home from blueprints and materials specifications.

The point is, when you're filling a business need in software your customer is often better off having a business process they already perform automated. Often what they get is general, flexible software that can be used to manually perform the same tasks in a digital medium instead of on paper. Using a digital medium is good, but automating parts or all of the actual process is a much bigger deal. The interface often matches the flexibility of the tools involved, which can slow or even overwhelm less savvy users. If the interface is modeled on the process, and option check boxes and optional interim transformations of the data appear as steps within that process, it will feel more natural and be less error-prone for the user. It also helps minimize the interaction of the features to well-defined steps (and perhaps some features are only available once or twice in the whole process). That minimizes not only searching through menus and the conceptual overhead of the features, but also the places in the code you'll find features creeping into the data representation.