Engineering Your Way To Marketing Success

http://www.kalzumeus.com/2009/12/31/engineering-your-way-to-marketing-success/

by patio11 • 17 years ago

109 20 17 years ago

patio114• 17 years ago

This is largely inspired from a conversation tptacek and I had at his offices earlier in the break. (His company is like two blocks from my dentist. Small world!)

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.

pchristensen• 17 years ago

Patrick, I was surprised to find out that you're from Chicago. Look me up next time you're back in town.

gcheong2• 17 years ago

"...I have heard that this is not true in some markets comprising of very technical experts who are looking for exactly the tool to fit their problem..."

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.

notauser2• 17 years ago

My only question at this point is - why bingo cards?

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

patio114• 17 years ago

My biggest reason is that it takes me very little work to continue doing what I'm doing and a whole lot of work to start a new business. It is not feasible for me to do a whole lot of work while full-time employed as a Japanese salaryman.

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.)

tptacek6• 17 years ago

I love this post because it mentions me!#!

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.

patio114• 17 years ago

If you listen to one thing I say in 2009, let it be this: Bookmark the above comment and execute on it.

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").

tptacek6• 17 years ago

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.

DanielBMarkham• 17 years ago

I love this post because it mentions me!#!

Some good material here, whether it mentions you or not ;)

tptacek6• 17 years ago

ps: I nominate 'username as the HN username quoting convention, instead of @username.

mbrubeck• 17 years ago

Do we really need any quoting convention? Will I accidentally execute you if I type tptacek instead of 'tptacek? :)

gcheong2• 17 years ago

"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."

Which, apparently, is still preferable to a visit to the dentist.

tptacek6• 17 years ago

I think he did both. What a great day for him!

jamiequint• 17 years ago

"I did this by repurposing the same content I use for my website and slotting it into a landing page template, which gives me about 750 distinct landing pages to work with."

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?

ohashi2• 17 years ago

I don't understand the argument for your own CMS. I currently use Drupal and don't see any problems creating modules (many of them already exist) to add all sorts of functionality I come up with for many different types of sites. Creating your own CMS sounds like a nice idea, but to me it seems like reinventing a lot of different wheels which already exist. If they don't exist, they are pretty easy to attach. Am I missing something?

tptacek6• 17 years ago

If you are a Drupal expert, if Drupal is the fastest way you can build a tiny new webapp, then use Drupal. I'm a Ruby person, and the fastest way for us to get interesting features onto our existing product site was to serve them with Ruby.

ohashi2• 17 years ago

That seems like a different notion from the one presented in the article was my point. I agree with what you've written, you should stick to what you can build it most efficiently in. However the article had a section:

>"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.

Engineering Your Way To Marketing Success

Related Stories