
Engineering Your Way To Marketing Success - patio11
http://www.kalzumeus.com/2009/12/31/engineering-your-way-to-marketing-success/
======
patio11
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.

~~~
notauser
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

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

~~~
notauser
Thanks for taking the time to answer :-)

------
jamiequint
"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?

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

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

~~~
tptacek
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.

~~~
patio11
I agree with all of the above. It is almost the shadow case for Rails or your
web framework of choice: the last 2+ years of development of my website has
been starting with a 300 line core and then just bolting stuff on. (And when I
say "stuff", I mean everything from my own automated bookkeeping system to A/B
testing to the web version of my product.)

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

~~~
tptacek
It turned out the content we were generating for search marketing: very
valuable in the product as well. Wouldn't have thought about it, except that
we had the content staring us in the face. _You have to start doing stuff to
get the better ideas_.

------
ohashi
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?

~~~
tptacek
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.

~~~
ohashi
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.

