The natural temptation on planning a product's roadmap is to plan far into the future.  That temptation arises for reasons such as wanting to please clients by telling them you'll give them what they say they want, wanting to relay the internal technical teams' plans to deliver something far in the future, feeling that you already know the list of features that users want, and not wanting to feel like you're planning all the time.  In my experience, that is less successful than trying to only plan and publicize a short time horizon out (and not even promising anything outside that time horizon).  Here are some of the reasons:

• You're always delivering something.  In other words, the user regularly sees progress.
• Related to the above bullet, it forces you to think of creative ways of solving your users' problems.  If you know you have to deliver something in the next month, then you have to carefully explore the requirements, prioritize, and come up with some unexpected solutions.
• Quick responses to what you release:
  • When something needs to be tweaked that you just released, you can quickly move to the next iteration.
  • If your idea turns out to be a real stinker, you can drop it before you spend a lot of time on it.
  • If you have an unexpected hit of an idea, you can quickly continue to refine it.
• Inevitable slips don't end up cascading tons of other deliverables (if all you promise is delivering 10 features in the next three months, then if three slip it only affects those three -- if you had promised 10 each quarter for the next year, then if three items slip in the first quarter then probably 37 items slip for the year).
• Combats somewhat against almost everyone's natural propensity to procrastinate.  If there are always items that need to be publicly delivered, then it's harder to procrastinate than if you have some huge delivable a year out. 
• A regular period that people expect a progress report.  Some advantages: a) the potential "embarassment" factor makes you pay close attention on a regular basis, and, moreover, b) your clients know they will be engaged in the discussion of your progress.
• The further out you plan, the less accurate you are about the schedule.
• You can respond more quickly to changes in your industry or competition.  If you've already publicly planned a year out, then if, for example Web 4.0 hits the scene quickly, you've either got to upset a lot of people that are already expecting a bunch of features that year (by slipping those to make room for Web 4.0 now) or not even consider adding the Web 4.0 features until after the year has passed!

I partially read the following a while ago that helped convince me to push toward short delivery schedules: Agile and Iterative Development: A Manager's Guide by Craig Larman and Getting Real by 37signals.