I'm not trying to take anything away from you at all, because what you've provided is very good. However, I'd like to say something about marketing vs sales, in that it seems like your material is more geared towards sales than marketing. I'm going to go off on a tangent here somewhat, bear with me...

To explain in my eyes, I see marketing as everything you do to promote your project (i.e. brand/product/etc.), which may not always have a direct financial payout tied to it. For instance, FOSS projects have their own motivations for gaining usage and popularity, and revenue may be tied to that, but they're not explicitly selling anything. But, they do wish to get noticed, to have people try them out, etc. and so they are selling the idea of their project even though they're not actually ringing anything up at the register.

On the other hand, "sales" is much more closely coupled with driving a user to purchase (or maybe even just 'sign-up' for) your service or product. This is what I'm mostly seeing in the slides: pricing, email campaigns, conversion rates, etc. These are all pretty exclusive to making a sale, and while they do embody marketing concepts, there's a lot more to marketing than simply corralling the customer to the register.

Why am I droning on about this? I'll admit that it's for selfish reasons; I was hoping to see some marketing guidance for the page itself. I review lots of projects, and a majority of them that are created by engineers fall into one of the following buckets:

* zero marketing whatsoever, possibly only a github page with a couple sentences in a readme

* poorly-constructed marketing, such as using lots of buzzwords and generic phrases without actually telling me anything at all about what the project actually is or does; for instance, many times the only blurb given is akin to "cures what ails you"

Now there are some that get it right, though I suspect that many of these either have someone with marketing skills on the team, or they've had an actual marketing guru help them out. That, or they're generally really observant and pick-up on it without having to study.

Either way, when I review a project, it's a shame that the basics are so often neglected:

* problem definition: in explicit terms, what problem(s) does your project solve?

* product differentiation: if yours is "the best", "an alternative", "the new way", etc., then why do you think that? Why should I choose yours over X? If you can provide some concrete examples here, all the better.

* product demo: if it can be demo'd, then please at least create a simple working demo. Note: I don't consider projects that include demos as a part of the source code, which must be downloaded, built, and configured as a proper demo. I also don't consider any that require you to register or provide an email address as a proper demo, either. Unless it's a very pressing need that I have, I'm not going to spend 5-15m fiddling with your source or giving away my info. Just host it somewhere so that I -- and possibly my CTO/CEO/purchasing agent -- can see it in action.

* licensing, terms and conditions, etc.: make them prominent enough that I don't need to browse your source files or open a support request to find out if I can even use it.

Sorry, this got longer than I anticipated...