An emulsion is a mixture of two or more liquids that are normally immiscible (nonmixable or unblendable).
— http://en.wikipedia.org/wiki/Emulsion
Developers are like olive oil. Valuable in a variety of settings. Full of substance and flavor. The good ones are a little peppery.
Marketing people are like balsamic vinegar. Sometimes a little sweet. Sometimes a little acidic. Always capable of adding flavor and zing.
Let’s say you take out your favorite small mixing bowl, and throw in some oil and vinegar. You can do it however you want: oil first then vinegar, vinegar first then oil, a little of each. The end result will be the same: balsamic vinegar on the bottom of the bowl, olive oil on the top.
The chemistry of oil and vinegar problem is surprisingly complicated, and beyond the scope of this blog. If that’s what you’re here for, please have a look at Wikipedia for an overview of the emulsion process and Cook Smarts for some great vinaigrette ideas.
How about mixing developers and marketers?
At Circle of Moms in 2010, we had a challenge and an opportunity. Our Facebook traffic was drying up and we weren’t doing a good job of re-engaging our users with email. Ephraim and I felt that email could be a great channel for us: we’d seen BabyCenter build a business with email as a central tenet, we had a user base hungry for great content, and we knew lots of valuable facts about our users.
We were sending out weekly newsletters with uncustomized, low-quality content. We had tested one or two small changes to those emails, but were still seeing low clickthrough rates and high unsubscribe rates.
Unfortunately, our existing team didn’t seem poised to solve that problem. On one side, we had olive oil: a strong team of developers who loved building out features. But none of them gravitated toward the email problem: improving the content of an email newsletter feels like a product marketing feature and not a technology one. What developer wants to spend all of her time doing text and UI tweaks?
On the other side, vinegar. Sending out millions of emails is a complicated operation, and understanding the dynamics of populating emails is hard. Moreover, actual testing of email content is more easily accomplished by someone who both understands the technology and can be hands on with data. Some of my more frustrating moments were spent with non-technical colleagues, trying to detail exactly how, when, and why we sent different emails to our users. Several marketing people and a product manager were interested in solving the email problem, but none had the technical or analytical skills to really take it on properly.
With two poor options, I wasn’t sure how to proceed. Short of shifting my role to one where I’d spend 90% of my time revamping our email system, I didn’t see a solution.
Fortunately, the solution found me. While recruiting for engineering roles at a Stanford Career Fair, two interesting people came to talk to us. Both knew how to write code and had an engineering degree or two from Stanford. Both were happy to code a little bit, but neither had the skills or desire to be a pure developer. Each was also quite interested in product and data, wanting to work with others across the company. As such, they weren’t interested in any of the developer job listings we’d printed out, but were obviously smart and seemed like they could be great contributors.
I followed up with one of them shortly afterward, and quickly realized she had precisely the skills we needed to solve our email problem. After bringing her in for formal interviews with people across the company, we quickly made an offer to perhaps the world’s first “Marketing and Analytics Engineer.”
The title sucked — clearly I should have consulted whoever coined the term growth hacker — but the end result was terrific. Erin quickly came to understand our codebase, our usage patterns, our product, and the psychology of our users. On the technical side, she could dive in and write code, run a/b tests, and do SQL queries. For more complex technical tasks, she worked directly with a pure developer to implement a new feature. But she also had as strong a product marketing sense as almost anyone else at the company, and spent time with our editorial/marketing team to understand what they were doing and figure out how to productize and optimize it.
Ultimately, Erin would simplify the product to enable inputs from the marketing team, in effect enabling them to better do their jobs. She would also automate and optimize many of the marketing team’s processes, bringing a great set of analytical and technological skills to their part of the company. In the process, she emulsified the awkwardly separate oil-vinegar mixture; it helped us immensely.
The next year, Erin gave us the unfortunate news that she had accepted a product management role at Workday. Fortunately, we had a natural successor: we’d brought Emma on as a summer intern to play a similar role, and Emma quickly accepted a part-time-turning-into-full-time position as a Marketing and Analytics Engineer.
Emma would ably step into Erin’s old shoes. She had done a lot less software development than Erin had, so it took her some time to get up to speed on that front. Fortunately, it’s manageable for a smart and driven person to learn basic coding skills. Like Erin, Emma focused on technology iterations, while working with other developers who built the deeper core technology. The end results were great: Emma served as an interface and emulsifier between our editorial team and our development team, and became the single force responsible for propelling our email product forward.
The term growth hacker is too specific to describe the positions of Emma and Erin: neither spent much time on growth, instead re-engaging users and building products to serve an emulsion of goals. Marketing and Analytics Engineer is a boring title, but a correct one. Both were developers — formally and culturally part of the development team — with goals more focused on business metrics than technology.
To startup companies: I strongly recommend hiring this kind of person, or several of them. Skills are less important than the ability to learn and execute. But please note the last word in the title, engineer: this needs to be someone who will write code. Otherwise, the emulsion is not likely to happen.
To recent college grads: if you want to be a product-y, marketing-y generalist in technology companies, great. People with product and marketing skills are tremendously valuable. But please, please, please: learn to write a little code. You don’t need to be able to build a scalable back-end system. You may just need to be able to change the text in an email and then write a SQL query to see what effect it’s had. Then you become dangerous in a really good way… and hopefully you’ll be able to emulsify with the best of them.