Lessons learned from helping over 150 startups with marketing (from my Offer HN)

http://www.plurty.com

Previously, I had this giant "Sign up" button on the home page, but what I had forgotten was that most of the value of the site came from the ability to not have to sign up in order to buy our products. We built anonymity into it so much that you don't even have to enter your email address. This was crucial for us because nobody wants to sign up for a website that is unknown.

Also, Ilya pointed out that the most distinguishing feature of our site were the extended exposure images and that we should use it as a marketing tool. We are currently planning on replacing our text-only adwords campaign and using the images to get more clicks.

Anyway...just thought I'd add my $0.02 and thank Ilya again. It was useful advice that we really needed.

This should be repeated again and again, and I think this is a point missed by many enginers. (Disclaimer: I'm an engineer.)

I've seen people spend months (or years) building that perfect website, wait anxiously for the proverbial "launch day," and then be highly discouraged when customers don't magically come. Figuring out who your customers are (and how you are going to get them!) is as important (or even more important) as picking the best framework, optimizing your code, or whatever else we spend time on.

From my experience, the user needs to first know what your product is. After that, you can sell the benefits. Benefits are not easily understood without knowing what the product is.

You should get better results with "Hosted payroll for your business" on the frontpage than "Cut payroll management costs by 37% instantly" (Unless of course all your visitors are already aware of you and what you do - this is never the case). The "Cut payroll management costs by 37% instantly" should be used on the "take a tour" page to describe the benefit and drive conversions.

I'd be curious to know if you have any stats related to this that you can share? It seems a bit counter-intuitive that a "flat" descriptive headline is better than flashy benefit, but the data I've seen shows that.

Great advice. Linking the value prop of any B2B service with a crystal clear ROI makes for a great sales pitch.

The fastest way to make $1 is to make (or save) your client $10.

If your actual features are so far removed from your listed benefits that people who ask "how?" don't also have an answer within 5 seconds (or at least a clear obvious path to that answer), you haven't solved the problem.

[Marketing is] everything- product, price, placement, and promotion. Start thinking about these things before you launch, learn from them, and iterate quickly before wasting a lot of time and money.

Since "product" is part of "marketing", it would be nice to include it in the iterative cycle. Instead of working it out before launch, launch prematurely, and work out the product simultaneously with the rest of the marketing. That is, "release early, release often", and iterate the whole thing. This helps for those products that you didn't know you needed until you saw it. It worked for me for a software library; I haven't tried it with an application.

Reflection: the idea of "assessing the market first" is waterfall-style, even though it is agile-style within that stage. The idea of "pivoting" attempts to incorporate an iteration, but at a much longer time-scale. It would seem better to be even more agile, by assessing the market with the product within each iteration, and pivoting within each iteration. This would need instant prototyping; and rapid feature changes (for pivots). One obstacle is that software takes too long to build, and too long to adapt. Consider: if you could make a prototype as easily and as quickly as a webpage to gather email addresses, wouldn't it be better to do that? If you could create different feature sets that would appeal to different markets as quickly and easily as making different landing pages, wouldn't that be better? Like "A/B testing for products".

Sounds like a hacker-philosopher's stone? While we can't eliminate essential complexity, only accidental complexity (by Brooks) and so it's hard to make much progress in this for general programming, for the subset of programming which is SaaS websites, we have already made great progress, with frameworks, RoR, AppEngine etc. It could be made much easier, if we focussed on the goal of an initial prototype, where bugs and lack of features don't matter, provided you get feedback on them (eg: have a "search for help" facility, and store the searches). Then, you can iterate and change direction quickly. The task is to seek traction. You don't need to hit it perfectly (like the iPhone), but just to get a nibble, and then you adjust. At first, you just want to know where the fish are.

Of course, product features are only part of marketing, and you also need to iterate quickly on graphic design, copywriting, adwords and so on. And pivoting may be intrinsically slow, because it takes time for your message to diffuse, be trialled, be adopted, word of mouth etc - though twitter, facebook etc may also speed this up too.