Engineering Your Way To Marketing Success
kalzumeus.com
kalzumeus.com
The thesis is, essentially, that you'd get much higher ROI if you redirected engineering assets from building marginal features to supporting your marketing endeavors. For concrete suggestions as to how to do that, see the article.
I think this may be one reason us engineers have trouble getting out of the feature mindset when trying to market our products as we tend to be these people as customers so, logically of course, we figure other people must do the same thing when they go looking for products.
You have a marketing and SEO platform that's clearly optimized to heck at this point, yet it's returning $30k/yr on $45k. There are content businesses I have personal contact with turning over $45k/day based on SEO.
So, why stick with bingo cards? Are you just comfortable with it? Is the software not easy to expand outwards to other niches? Do you not know of any other niches to hit? Do you think you haven't reached diminishing returns in the bingo card market?
/devils-advocate
Give me another couple of months, though, and I'll hopefully have another iron in the fire as well.
It is unlikely that I'm going to do something adjacent to bingo cards for my next thing. It is also unlikely that I'd go into the richest affiliate markets, which is where I'm assuming your buddies are if they're doing $45k a day. (The richest markets are high competition, high stress, and also tend to be highly concentrated in fields where I would not like to make a living. For example, as a consequence of running a squeaky clean website in bingo, I rank fairly well and have been offered impressive sums of money to be less than squeaky clean. I don't want to promote gambling -- ever. That isn't even a moral thing with me, since I'm fine with gambling in moderation -- I'd just much prefer to be the software guy at $45k a year than the gambling tycoon at $4.5 million a year.)
How do you get any statistically significant sampling with this many landing pages. Doesn't this put your required traffic to get a statistically significant result at somewhere around a few hundred thousand page views?
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.
I wanted to mention a lot of it but figured "client confidentiality" (although in the future I will hopefully have more stringent and expensive definitions for "client" than "bought me a cup of coffee").
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.
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."
Some good material here, whether it mentions you or not ;)
Which, apparently, is still preferable to a visit to the dentist.
>"Write your own CMS. I would have totally disagreed with this advice up until last week or so, but Thomas convinced me: writing a single-purpose CMS is pretty much the new Hello World for modern web frameworks (heck, it is the official Rails demo), and with a man-week or two you can make something much more productive for your purposes than using, e.g., Wordpress. (Though if you can do whatever functionality you need as a Wordpress plugin, I’d still be inclined to suggest that. No need to reinvent the wheel for basic CRUD operations on textual content, or HTML parsing.)"
My argument is that within the existing CMS options it's almost always easier to just create a module to add the functionality rather than trying to create your own CMS. I work with Drupal as you stated and it's pretty open to what can be done with it and quite easy to add almost any functionality I want. So the quoted piece from the text is a bit confusing from the article.