In the simplest case you can simply append an & (ampersand) to the command. This is the same as running it, typing [Ctrl]-[z], then the bg (shell job control: "background") command.
This will run the command in the background. However, it may stop on its own (from a signal that it gets regarding the terminal focus SIGTTOU I believe). For instance vi has nothing useful to do in the background and thus will immediately restop if you try run it in the background. A program that's designed to run in the background will not suffer from this problem; of course.
You can invoke a program with stdin, stdout, and stderr all redirected to /dev/null to isolate a program from your terminal.
Another issue you might run into with some programs will occur if or when you exit the shell from which you started the program. In this case the backgrounded program will still get the "hangup" signal from the shell exiting (or the xterm or other terminal connection to that shell being closed). In other words, it's more signal handling stuff. The default signal handler for SIGHUP is to die. Obviously a program that installs a handler for that can continue to run in the background even after its parent program has died.
You can run the nohup utility to force a program to run even through a hangup signal. Read the nohup man page for details on that. In general you can also run the disown built-in (shell command) to remove a program from the job control and signal dispatches by the shell.
It's even possible to run a program under screen and force that screen session to start up detached. This connects the program to a psuedo-terminal in such a way that you can always re-attached to it later (to see its output and any error messages, and to provide it with terminal inputs).
That's an advanced technique I won't go into here.
Of course programs that are designed to run as daemons can (and should) do their down work, setting themselves up their own "session/process group" --- detaching themselves from the signal propagation of their parent; closing their "standard" file descriptors, etc. In other words, check the documentation for the program in question to see if it as a command line switch to do the job for you.