The more I think about it, the more I think it is almost as simple as saying this: your product team should have its own CMS.

1. Building a CMS is trivial. For us, we found that we could take our designer's deliverable site and just serve the pages up in Sinatra verbatim as Erb instead of HTML. Done!

2. Once your static site is nominally dynamic, you can easily improve it. Trivial things, like integrating analytics, are truly trivial, but even "significant" things are easier in your own code. For instance, screenshots are just a template substitution for us; a tiny piece of markup in any static page, and fwoosh a fully functional lightboxed captioned screenshot.

3. A "real" CMS comes with many hundreds of developer hours put into making admin and workflow "pretty". Wow is our admin/workflow not pretty. Who cares? Your CMS is more agile than a general-purpose CMS because you don't have to put a penny into stuff that doesn't matter.

4. Once you have a dynamic site, you are now in a position to come up with "marketing features", which you won't really think about until you are in that position. Customer lifecycle + Mailchimp? User-generated content? Live-chat based beta product support? Web versions of downloadable products? These are things that are quarterly objectives when you don't have your own CMS, and are weekly objectives when you do.

One thing I forgot to mention in my sprawling parent comment:

You do not know how to do any of this stuff until you start doing it.

Content generation and SEO are a perfect example. You have no idea what you need to do until you get something out there, so you can start monitoring how it gets used. For us, we wrote a page template we thought was nominally effective, and bugged it with Google Analytics. Within days of it getting spidered, the keyword logs had 10+ obvious, trivial changes to make the pages more effective; we literally just had to include a couple more words ("permit" instead of "allow", for instance).

But given that we know this is true (intellectually, if not viscerally) about product development, and we can plainly see that it's true for content generation, it seems fair to suggest that it's axiomatic. You don't know how to "engineer" "marketing" until you start trying to engineer marketing. Which implies: you shouldn't wait to figure out exactly what to do.

I agree with all of the above. It is almost the shadow case for Rails or your web framework of choice: the last 2+ years of development of my website has been starting with a 300 line core and then just bolting stuff on. (And when I say "stuff", I mean everything from my own automated bookkeeping system to A/B testing to the web version of my product.)

Thomas has teams of smart people he can deploy to have quarterly objectives, but I don't, so I generally look to Things I Can Get Done In A Weekend, which typically means little 300 to 500 line featurelets. Somewhat surprisingly, that actually works.

(Incidentally, while adding new features to the product often takes significant amount of time to test, little marketing featurelettes are often self-contained and more or less consequence-free. The Q/A cycle on them is pretty much "Re-run existing tests and observe they don't break." followed by "Deploy to production.")

Like Thomas says, most of this stuff will not obviously be on the roadmap when you start out. Often, you'll discover in the course of reviewing usage of Featurelette 17 that there is an opportunity for improvement or (cringes) synergy, so you just schedule Featurelette 18 to bolt on a little more.

I could tell you a dozen stories that fit that pattern. "Hey, I bet it would help to have a web app. Hey, why doesn't my web app have dedicated landing pages? Hey, I could reuse content from the CMS to populate those landing pages."

It turned out the content we were generating for search marketing: very valuable in the product as well. Wouldn't have thought about it, except that we had the content staring us in the face. You have to start doing stuff to get the better ideas.