The SCons design emphasizes an implementable feature set that lets users get practical, useful work done. SCons is helped in this regard by its roots in Cons, which has had its feature set honed by several years of input from a dedicated band of users.

SCons is intended as a portable build tool, able to handle software construction tasks on a variety of operating systems. It should be possible (although not mandatory) to use SCons so that the same configuration file builds the same software correctly on, for example, both Linux and Windows NT. Consequently, SCons should hide from users operating-system-dependent details such as filename extensions (for example, .o vs. .obj).

Novice users should be able to grasp quickly the rudiments of using SCons to build their software. This extends to installing SCons, too. Installation should be painless, and the installed SCons should work "out of the box" to build most software.

This goal should be kept in mind during implementation, when there is always a tendency to try to optimize too early. Speed is nice, but not as important as clarity and ease of use.

SCons should also provide a rich enough set of features to accommodate building more complicated software projects. However, the features required for building complicated software projects should not get in the way of novice users. (See the previous goal.) In other words, complexity should be available when it's needed but not required to get work done. Practically, this implies that SCons shouldn't be dumbed down to the point it excludes complicated software builds.

As a key element in balancing the conflicting needs of Usability and Utility, SCons should provide mechanisms to allow SCons users to share build rules, dependency scanners, and other objects and recipes for constructing software. A good sharing mechanism should support the model wherein most developers on a project use rules and templates that are created and maintained by a local integrator or build-master,

SCons should provide mechanisms for easily extending its capabilities, including building new types of files, adding new types of dependency scanning, being able to accomodate dependencies between objects other than files, etc.

In addition to providing a useful command-line interface, SCons should provide the right architectural framework for embedding its dependency management in other interfaces. SCons would help strengthen other GUIs or IDEs and the additional requirements of the other interfaces would help broaden and solidify the core SCons dependency management.