Patrick offered to come by and grab a drink with me; instead, me and 'cscott bought him a cheap cup of coffee, led him into our cramped meeting room, shut the door, and interrogated him for three hours. It our cheapest, highest-ROI consulting session ever.
I want to get a couple refinements from that conversation onto the thread here:
* At Matasano, the revelation we had in the last couple weeks has been: we have a surplus of engineering cycles and a deficit of marketing effectiveness; it's time to find ways to reallocate. This doesn't mean hiring/contracting marketing. It means finding ways for engineers to improve marketing outcomes.
* Too many software people have an overly narrow definition of what "marketing" is. To them, marketing is promotion, search marketing, conversion tracking, requirements documents. This leads you down a path of bucketing marketing objectives: "ok, so we'll have an engineer set up adwords", or "ok, so we'll have an engineer improve analytics", or "ok, so we'll have an engineer staff a trade show booth".
Marketing is product definition, awareness, lead gen, conversion, and then the measurement and improvement of same. If we're smart enough to define and execute features in products to make our customers lives better, we're smart enough to come up with clever ways to improve awareness and lead gen.
I don't know what Patrick's doing, but we're trying to come up with better ways to engage with our target customers using software engineering cycles; this may include open source, it may include some interesting free web apps, it may include some targeted content generation. Almost none of it fits into a preexisting shrink-wrap "marketing" packet.
* I cannot possibly vouch more strongly for Patrick's thoughts about content generation and long-tail search marketing.
Patrick has a reasonable case to make for being a world expert on computer bingo card topics. We have an even stronger case for being the right people to write pages about how to firewall different applications; we're domain experts first and developers second. And we are the wrong people to write this content.
Some facts about content generation: (1) even at a high level of quality, it's cheaper than a half-hour of your time; (2) 1-2 people cannot maintain a high level of quality for weeks at a time without burning out; (3) however strong your domain knowledge is, there's a huge benefit in diversifying your sources, since they'll have different strengths; and (4) if your processes and tech are good, you can distill excellent content out of adequate raw material.
We have done a decidedly half-hearted job of content-based search marketing, and it has already crushed anything we've gotten with search ads.
* A specific example of "force-multiplying" marketing-engineering, in case you haven't read Patrick's other posts: if you're doing it right, a single piece of content should be many many different pages in your site; the new unit of content is just one parameter among many that makes up a page. For us, the parameters so far are "firewall vendor", "network application", which gets us a 4-5x multiplier on any piece of content. But there are other parameters we can add to improve that down the road.
* I am, for the fleeting time being, sold on the idea that everyone should just write their own CMS (just start with Rails or Django hello-world with a static site and go from there). There are a bunch of things that we were/are able to execute quickly on our custom CMS that we'd have a much harder time doing in a pre-built CMS:
--* Editorial workflow on parameterized user-generated content
--* Fire-and-forget captioned screencast pages
--* Screenshots! I mean, W-T-F: our static site has product screenshots with captions done in Photoshop, meaning we had to actually fire up Photoshop to make new screenshots. The current site we just upload a PNG and click spots on the image and type in a caption, and a tiny amount of JS and CSS makes it look identical.
* Which I guess leads me to the one point from our conversation that Patrick didn't capture, which is: a lot of execution stuff is about friction. For instance: editing a screenshot requires opening up Photoshop, so we're disinclined to change our screenshots or add new ones. Engineering is a great way to take an isolated piece of friction and eliminate it. When you get rid of friction, you execute better. Writing a solid page about firewalling Citrix on a Cisco PIX ASA firewall was a multi-hour task. We were disinclined to write a lot of them. Writing a content management system to outsource elements that could make 1000 strong pages was a 2-3 day task, and now a new page takes minutes to build. We know we're going to execute on that now.
Just a bunch of random overcaffeinated points on Patrick's post.