Developers are Oil, Marketers are Vinegar: Mix Them Wisely

An emulsion is a mixture of two or more liquids that are normally immiscible (nonmixable or unblendable).


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.

No, you don’t need a real-time data dashboard*

When Circle of Friends started to grow really quickly in 2007, it was really tough for Ephraim and me to stay focused.

Many times over the course of a the day, Ephraim would turn and ask me how many signups we’d had in the last ten minutes. That might have been annoying, but for the fact that I was just as curious: I’d just run the query and had an immediate answer.

Rapid viral growth can be unbelievably addictive for the people who are working to propagate it. You tweaked a key part of your flow and you want to see what kind of impact it’s having — right now. You’ve added more users in the last hour than you’ve ever added in an hour before, and you wonder if the next hour will be even better.

That addictiveness can be a great asset to growth hackers; I’d argue that anyone who doesn’t have that sort of jittery restlessness probably wouldn’t be the right fit in a growth hacking role. Restlessness is a huge motivator: I want to grow the user base, so I’m going to implement this feature and push it out as quickly as possible just so I can see what impact it will have. And if this feature doesn’t work, I’m going to try and get something else out before I leave the office so I can see if I’ve uncovered something else before it’s time to go to bed.

One day, I came up with a feature idea as I was walking to the train station in the morning. I coded it up and pushed it out while on the 35 minute train ride. There was a ten minute walk from the train station to my office; by the time I got to the office I saw that my feature was increasing invitations by around 20%.

I loved telling that story to potential engineering hires.

Here’s the thing, though: if everyone in your company behaves like that, you may acquire a huge user base, but you’ll likely never build anything of long-term value. You’ll wind up optimizing purely for short-term performance, never moving toward a strong vision

Back during that Circle of Friends growth period, I decided to automate an hourly stats email to Ephraim and myself. It satisfied our curiosity about how things were growing right now, but it stopped me from running SQL queries every five minutes. At least in theory, that meant we were focused on real work for 58 minutes every hour. In retrospect, it seems ridiculous that we needed stats updates every sixty minutes, but that actually was an improvement.

My distracted experience is why I worry about the effect of analytics companies that now promote a real-time dashboard as an awesome new feature.

It’s technically impressive that they’ve implemented real-time functionality. And at first glance, it’s very cool that I as a user can log in mid-day and see how stats are trending.

But the key distinction — and about 60% of analytics questions I’ve seen people ask over the years are on the wrong side — is if you’re looking at stats now because you’re curious and impatient, or because those stats will actually drive business decisions.

I’m afraid that in most cases, real-time stats are being used by people who aren’t iterating as quickly as growth hackers. The “need” for stats is driven more by curiosity and impatience than by decision-making.

Execs who are making big picture decisions are probably better served by looking at data less frequently. Growth hackers and IT ops types can and should attack problems restlessly — a big part of their job is optimizing everything for the immediate future. But executives are best-served waiting (perhaps until the end of the week), so they can take a long, deep look at the data and think more strategically.

* unless you’re a growth hacker or something similar

Data Scale – why big data trumps small data

As I walk into a coffee shop, the guy behind the counter sees that I’m in a hurry and that I’m by myself. He’s seen me a few times before, and knows that I don’t usually order sweet snacks. He knows I tip reasonably well. He’s likely to treat me a certain way: efficiently, without small talk, and not trying to sell me a muffin.

In the “real world”, his behavior — and my user experience — is largely the result of subconscious change (in Daniel Kahneman’s terrific book this is called System 1). Online, personalization and improvement of my experience usually comes from lots of data. Offline, the cashier’s “data set” is the personal experiences he’s had. Online, it’s the same thing for the site I’m visiting. The big difference is that most working humans are between 15 and 75 — a difference of 5x. Online, Facebook has nearly a billion users, and my blog has… less than one fifth that number. Online differences are orders of magnitude larger.

That advantage compounds over time, as companies with many millions of users attain data scale. Data scale is the millions of pieces of information that allow a company to improve the user experience in ways that competitors with fewer users cannot. I saw this firsthand at PayPal, LinkedIn, and Circle of Moms: all three companies were able to provide features and additional value to new and returning users because of what we’d learned from millions of others.

Network Effects and Big Data

Network effects are well-known and understood in the consumer Internet world. As Facebook grows more popular, more of your friends are on the site with you, and it becomes more and more useful (or at least, entertaining) for you. And that size distinguishes it from an upstart: why sign up for a new site with just three of your friends when you can be on Facebook with almost everyone? Network effects have clear and well-defined values for both websites and users.

By contrast, consider the opening sentence for the big data Wikipedia entry:

In information technology, big data consists of data sets that grow so large and complex that they become awkward to work with using on-hand database management tools

The entry depicts a purely technical set of requirements, with no bearing on the product or user. But lots of data is more than just awkwardness and data management tools. Companies with data scale can create a set of features and processes — prediction, testing, understanding, and segmentation — that aren’t possible to those with small user bases. Collectively, they allow a company to block access to fraudsters, tailor products to users, and understand them in deep ways. Data scale improves both the user experience and the bottom line.

The 4 Advantages of Data Scale

In my twelve years working with consumer Internet data, I’ve seen four things that companies with data scale can do much better than smaller competitors:

  1. Predict

    Fraud nearly destroyed PayPal’s business in its early years. Fortunately, we figured out how to accurately detect it, and wound up reducing fraud rates by 80-90%. After predicting which transactions were most risky, we’d block and reverse the bad ones — helping PayPal move from bleeding money in 2000 to profitability+IPO in 2002.

    Data scale was necessary for that detection. More transactions — and more fraudulent transactions — give smart scientists the data they need to discover complex but statistically valid predictors of fraud. Start with a set of only 10,000 transactions and 100 fraudulent transactions, and you can put together a few simple rules to find fraud. But with millions of transactions and tens of thousands of fraudulent transactions, our fraud analytics team could find subtler patterns and detect fraud more accurately. A mini-PayPal might have the world’s smartest predictive modelers, but without a large data set, there’s only so much they could do.

    Incidentally, this was a major reason PayPal needed to raise lots of capital. Losing a lot of money to fraud was a necessary byproduct in gathering the data needed to understand the problem and build good predictive models. A “lean startup” approach makes sense in some cases, but wouldn’t have cut it for PayPal.

    User perspective: if a company can figure out that you’re very likely a good, non-fraudulent customer, they can provide you with services they’d never want to offer their riskier users. That figuring out process is much more accurate when they have data scale.

  2. Understand

    Most websites start off with less structured data — their databases contain lots of text. Free form fields are easier for developers to code, and (early on) often make it easier for users to enter information. But unstructured data quickly get messy, and without scale, they don’t allow for easy inferences. But more unstructured data — along with a clever data scientist or two — can be a ticket to intelligently structure and build the corresponding features and insights. A few examples:

    • Until 2006, LinkedIn had no structure around company names. Users could type anything they wanted into a company field, and we had no way of automatically detecting that HP, H-P, Hewlett Packard, and HP, Inc. were all the same company. By parsing the data and matching it against other sources like email domain and address books, we were able to detect that those four names were synonyms. Without manual intervention, those processes are only possible with data scale: one person at “HP, Inc.” with an email address could be random, but when 97 out of 100 users have that property it’s a safe bet that it’s not a random fluke.

      Having an accurate list of companies allows LinkedIn to better guess who you know, it facilitates good company pages, and by using autocomplete, it improves data quality going forward.

    • Before we built Circle of Moms, we built a Facebook app called Circle of Friends. Less than a year in, with millions of users but weakening growth and minimal revenue, we started to search for ways we might shift our business. We found that moms were creating “circles of moms” and using them more than anyone else was using their circles.

      Data scale enabled us to find that trend, and understand what was going on. And that wound up being the insight that ultimately pushed us toward being a successful company.

    User perspective: younger, smaller companies don’t really know what users want, and thus have to keep their product open-ended. When you use the product of a company with lots of data, they’ve learned what people actually want to do, and you get a cleaner, more structured experience.

  3. Test

    Circle of Moms was fanatical about a/b testing on day one (LinkedIn was not — much to my chagrin — but I digress). But in order to decide between a and b, you need meaningful differences in outcomes. If there’s a large difference (say, 40-50%), then 100 outcomes (signups, clicks, whatever the company is optimizing for) in each group is often sufficient for establishing statistical significance. If the difference is 10% or less, you’ll need on the order of 1000+ outcomes.

    Let’s take a graphical look. Below are overall simulated clickthrough rates (CTRs) for different-sized user bases.

    clickthrough by population size

    [Technical details: I ran a simulation where a company a/b tests a variety of emails or subject lines. Each subject has clickthrough rate between 0.75% and 3%, randomly selected with a uniform distribution. All tests are pairwise, so A is tested against B, the winner is tested against C, that winner against D, etc. Tests are resolved at p=.99. A few aspects of this are unrealistic -- uniformly distributed CTRs, non-improving (on average) subjects, only tests with two participants, the same rules for resolving tests for big user bases and small, etc. -- but it's close enough for these purposes.]

    With a small user base, CTR will be mediocre: about 1.9%, and slow to improve. As a user base gets bigger and bigger, a higher and higher percentage of users wind up receiving a very good, well-tested subject line: big companies see a CTR very close to 3%. The largest improvement comes between 100,000 users and 1,000,000 users — in this case, that represents data scale. Most of our successful emails at Circle of Moms would go to a few hundred thousand or a few million people; we were right on the edge of having data scale. If we’d had fewer users, a high percentage of our users would have been “guinea pigs”. With millions of registered moms, we had (roughly) the same number of guinea pigs, but many more users for whom we could use our guinea pig learnings and send the very best content.

    Note the magnitudes of these differences. With data scale, testing can mean a bump of 50% or more; the testing bump is much less for a small operation. For a product close to being viral, an additional 10% — a “small data” bump — might be huge and a/b testing worthwhile. For a product with millions of users, a 50% jump is large almost regardless of application. On the other hand, for a small product where 10-20% doesn’t represent the difference between success and failure, time is best spent somewhere else. In other words, a/b testing is something every company with a large user base should do; for smaller companies the value varies.

    User perspective: if you’re part of a large group, you likely get better content because of feedback from those before you. If you’re part of a small group, you are more likely to be giving feedback rather than profiting from the feedback of those before you.

  4. Segment

    At Circle of Moms, segmenting was essentially a mix of predicting and testing. After we tested emails and subject lines with small batches of users, we’d create predictive models to figure out which future users would be likely to click on them.

    This meant we could figure out the odds that someone would click on each of twenty possible emails we might send. And we’d send the very best one for her.

    For Circle of Moms, predictive models were relatively simple and didn’t need as many users/observations as PayPal’s did. But because we were testing twenty different emails at a time and didn’t want to test everything on everyone, scale still mattered. 50,000 people is usually enough to create a model; multiply that by 20 and you have a million. That calls for a million people just in the training set (i.e., the guinea pigs). If you only have 1.5 million users, the benefit of this type of segmentation will be small — 2/3 of users will have received a “random” email to gather data for the models. At 5 million, a company is at data scale, and the vast majority of its users (80%) will get a personalized email.

    I got started on a segmentation-type problem at LinkedIn — matching people to jobs. Job matching means segmenting people into thousands of buckets (each job is a bucket), rather than only 20. Back in 2006, the quality and quantity of LinkedIn’s data made the job very difficult: 5 million users and only a few thousand past job listings was not enough data to do matching well. Today, with 20-30 times as many users, 7 years of job listings, and some scientists who are likely much better than I, LinkedIn does much better finding jobs for people than I did in 2006. That’s data scale (plus a talent upgrade) at work.

    Automated segmentation is harder to simulate and precisely quantify than testing. But the overall picture is clear: it’s useless at small scale, but usually far more valuable than testing at data scale.

    User perspective: when a company can figure out what you like, they can provide you with content uniquely suited to your needs and interests. The more data they have — both on you and on others — the better they can perform this service.

Things I don’t know I don’t know?

I’m both a data guy and an early stage startup guy, and that generally constrains the problems I see. I left PayPal a little while after the company was acquired by Ebay; I left LinkedIn when it was an 80-person company that I found too slow-moving; I left Circle of Moms after Sugar’s acquisition. That means I’ve never worked on a product with over ten million users. No doubt I’m missing out on some of the advantages that truly massive companies have. Others have more firsthand knowledge on the topic of really big data scale — those of you in that category, ping me about your favorite post and I’ll add a link.

Cutting the Facebook Cord

Balancing Platform Distribution and Platform Diversification

When Ephraim (my co-founder) and I first went out to raise money for Circle of Moms, we had nothing but a Facebook app. It was 2009 and the investors we pitched were nervous about the idea of a business built entirely on a platform controlled by Facebook. We had great traction — millions of moms using our product within six months of going live — but our platform dependence was seen as a major liability. Facebook, the VCs said, could suddenly turn off all of their communication channels and we’d collapse.

We thought they were full of it, but they wound up being about half right. Within 18 months, Facebook would close down most of the channels we were using for growth and engagement. But thanks to a mix of foresight, paranoia, luck, and determination, we’d soon wean ourselves from Facebook and become a valuable and well-diversified site.

On Top of the Hill

In 2008 and 2009, we grabbed onto the speeding Facebook train (and its trailing Platform). We figured out that a mom’s intimate “circle” was central to her view of the world, and designed a Facebook app to allow her to invite these trusted friends into the broader Circle of Moms.

Early on, this proved to be quite viral: within a few months a million moms were using our product. Many a mom used the app to share a photo of her child’s first steps on a Circle of Moms box in her Facebook profile. Others posted updates to their Facebook feeds and used Facebook invitations to add moms to their personal circles. We were growing and prospering, and millions of moms were using our product to share their lives with people important to them.

In The Ditch

And then everything changed. Many Facebook users had lost interest in receiving virtual crops from their virtual neighbors’ virtual farms: app spam had become a real concern for Facebook. Just as important, companies like Zynga were making many millions of dollars, and Facebook realized that they could shut off some of their user acquisition channels and make money by forcing Zynga to advertise instead.

So Facebook acted rationally, optimizing for their own best interests and those of their users. They killed the notifications feature (which we used to tell someone her friend’s child was turning two). They removed boxes and tabs from profile pages (which over a million moms had added to show off their kids’ accomplishments). And they hid invitations (which moms used to tell their friends about our product).

At that time, we were almost completely dependent on Facebook’s channels to communicate with our users and find new ones. We felt like a beer maker preparing for the government banning beer sales in markets, shutting down bars, and only allowing people to drink in restaurants on Tuesdays. Not quite prohibition, but pretty darned close.

Sure enough, as Facebook removed communication channels, we took a hit. Over the course of 2010, we lost half of our traffic.

Fortunately, that’s not the end of the story. By using three separate ladders we diversified from Facebook and slowly made our way out of the ditch. When I left Circle of Moms in early 2012, our traffic was far higher than it had ever been before; it continues to grow.

The “Standalone Site” Ladder

We knew from day one that life as a Facebook app would come with baggage both good and bad. The key advantage was social context: moms were in a place they knew, with people they knew (this also resonated with advertisers). Being an app meant moms could engage with Circle of Moms without leaving Facebook. On the other hand, we didn’t have control: we had a small canvas for our product, we didn’t completely own the advertising context, page loads were slower, and it was more difficult to own our brand.

Early on, we allowed moms to access our product at, but we didn’t make an effort to drive traffic there. All of our outbound communications — through both Facebook and email — linked to Our users identified us as a Facebook app, and they accessed us there.

In mid-2009, about nine months after launch, we started to test pushing more traffic to Initially, we only did this through non-Facebook channels like email, running a/b tests to send some email clickers to and others to When the results looked good, we began to test pushing people coming from Facebook to

The results were mixed. The positives: we saw quicker page loads and deeper engagement from people on The negatives: Facebook users who were sent to the site were slightly less likely to come back than those who were sent to the app; many complained that they were surprised by where they were and couldn’t figure out how to get back to Facebook.

At Circle of Moms, the usual approach is to a/b test and then iterate on those tests. Within the group going to the site, we tested several different ways to link back to Facebook. Ultimately, we found that a “back to facebook” link in the top left gave people a clear way to navigate back to Facebook, in the process creating the best of both worlds. Our site was fast, we had control, moms were viewing more pages, and they could navigate back to Facebook.

We monitored the longitudinal effects of this change for a long time — we wanted to make sure that sending our links to didn’t have any long-term negatives for usage patterns. We made a few more tweaks along the way, and by mid-2010 — a full year after starting the test — we were sending almost all links to After our users grew accustomed to, we were able to remove the “back to Facebook” link without any negative effect. This new experience deepened engagement, improved our ability generate ad revenue, and set us up for the two other big changes we were making.

The “Content” Ladder

When Circle of Moms was purely a Facebook app, the content was available only to Facebook users who were logged in. That meant that Google’s bots could not access the hundreds of thousands of conversations on our site, so Circle of Moms content wasn’t showing up on Google.

Early on, keeping that content closed off was probably the right decision for us: opening it up would have created a substantial amount of additional technical work, and distracted us from growing our community of moms.

But come 2010, diversification was important to us, and the responses to hundreds of thousands of questions would be useful to many of the moms who weren’t already using our product.

Opening up Circle of Moms to search engines was not an easy process — in addition to moving content to, we had to make sure that our users were comfortable privacy-wise. We told community administrators in advance, and gave them the ability to make their communities private. In public communities, we obfuscated users’ names so conversations would be found from topical keyword searches and not searches for people.

Ultimately, we found a strong niche with longer-tail search terms. As a relatively new company, it would be tough to compete with the BabyCenters of the world on terms like “18 weeks pregnant”, but slightly less common terms like “hiccups in the womb” would frequently show up among our many conversations.

After a slow start, we saw lots of search growth in 2010, 2011, and 2012. It’s now one of Circle of Moms’ top traffic sources, and a great way for new moms to discover the product.

The “Email” Ladder

Because we never fully trusted Facebook, we’d long asked our users for an email address immediately after they connected their Facebook accounts. Most moms gave us their email, allowing us to communicate with them independent of Facebook. Up until 2010, this was a defensive, speculative tactic, since Facebook was more effective than email as a communication channel.

(One interesting exception: users over 40 were much more likely to click on email communications than Facebook communications — the exact opposite of women in their 20s.)

As 2010 came to a close, the proverbial feces was hitting the proverbial fan, and we started to look at email as a way out of the ditch. Up until then, our users received weekly emails, each with a summary of what was going on in their communities. The exact content appearing in those digests was essentially random — we were manually removing anything grossly offensive, but otherwise just including headlines from the most recent posts by in the communities they’d joined. We were making no effort to find what was best for the recipient. In a sense, it was the worst of two worlds: neither manicured and professional like a newspaper, nor optimized and personalized like a technology company.

Our first few iterations, we a/b tested swapping out our standard content with an article we’d written in-house. The articles were clearly more professional than the “control” we’d been sending before, but the clickthrough rate wasn’t any higher.

Then just before Christmas, we figured out how we could extend our ladder and start to climb from the ditch. An email about the Top 10 Baby Names of 2010 had four times the clickthrough rate of our normal digest emails. We quickly resolved the a/b test and sent the top baby name list to all of our users. Though we knew that we couldn’t send our users top baby name lists every week, we had a case study in how to use email to re-engage our millions of moms.

Over the course of 2011, we streamlined our content-writing and emailing operations, in the process turning email into a viable re-engagement channel for millions of moms. My next post will go into detail on this operation, specifically focusing on how we were able to use scale to our advantage.

Lessons from the Ditch

One ditch, three ladders to get us out. What are the lessons I take away? There are four pieces of advice I’d give to a company looking to build on top of a single platform (Facebook, Android, iOS, Pinterest, etc.).

1)If you have a short term opportunity to quickly grow on top of a platform, take advantage of it. Early movers can have large advantages; as I believe the saying goes, the bird that over-obsesses about building out a perfect and complete user experience doesn’t get the worm. In 2008 and 2009, we were able to grow Circle of Moms on Facebook much more quickly than we could have anywhere else. For that reason, we were right to spend much (not all) of our time on viral growth rather than building out a perfect experience. Given what I know now, I probably would have been more aggressive in growing Circle of Moms’ user base when we had the opportunity: it was much easier to grow a Facebook app virally in 2009 than it is today, and a few million more registered moms would have helped a lot with the things we were trying to do later.

2) Own your relationship with your users, or at least have a plan to own it. Sounds trivial, but many Facebook apps had no good way to communicate with users when Facebook turned off notifications. A similar relationship exists for many top iOS and Android apps today. By collecting our users’ email addresses, we preserved the option to contact them without any involvement from Facebook. There’s a tradeoff — the more you ask someone for, the more likely they are to run away — so in our case we asked users for email addresses upfront but didn’t require it.

3) It’s usually overkill to build out your first technology to be multi-platform. Building for multiple platforms wastes time you could have spent optimizing for today’s most important platform — but it’s still important to design it in a way that allows you to be multi-platform in the future. In our case, our technology would ultimately allow both a Facebook app and a standalone site, and enable logins through Facebook and through email/password.

4) Build a product that allows users to form relationships, write great content, and/or contribute valuable data. My co-founder Ephraim likes to talk about building something cumulative: a product where users’ actions make the product better either for themselves or for others. We did this best with communities — moms build relationships with others like them, and contribute to a base of hundreds of thousands of conversations that other parents can learn from. That base of creates incentive for contributors to come back to add to what they’ve already create, and build on existing relationships, and it forms a set of content and community that will be useful for future users. Many of the early viral Facebook apps had millions of users, but nothing else: no relationship reason to come back to the app, and no valuable content.

In other words: drive significant distribution through one channel, but always take a couple of steps to hedge your bets. Facebook is still a key platform for Circle of Moms, but it’s no longer the only one.

The Visionary and The Pivoter

A tale of two startups

Last month, my startup of 4.5 years, Circle of Moms, was acquired by Sugar. I’m proud of what my team created over that time: the product behind a large and strong community of moms, a set of technologies that allowed us to move quickly and make sound data-driven decisions, and a positive team culture conducive to both good work and employee happiness.

A month out, I’ve had a little bit of time to reflect, and the lessons I’ve learned from the process are still fresh in my mind. By almost any measure, Circle of Moms was a success, but not a “rocket ship”, either of the quick (YouTube) or slow (Facebook) variety. We did lots of good things and lots of bad things along the way, and this is a great time to write about a few of them.

I’m going to recount a few pieces of my experience as honestly as possible, trying not to pretend that we were more clever than we actually were. Circle of Moms has usually been an environment where people are comfortable owning up to mistakes and weaknesses; hopefully I can maintain that spirit and provide some interesting lessons in the process.

What is a Pivot?

A year ago, I wrote about why I was building technology for moms. I outlined the thought process we went through in 2008 when we transitioned from “Google+ Circles for Facebook” to “LinkedIn for moms”.

Our story is occasionally highlighted in entrepreneurship classes as an example of a successful pivot. The term “pivot” has become something of a cliche, but unlike many business cliches it has real meaning. The outline for the pivot story is often abbreviated to:

  • Team has an idea they think is brilliant.
  • They build it out, and find out it wasn’t brilliant.
  • Team realizes that some byproduct of what they built was in fact brilliant. Byproduct = pivot opportunity!
  • They pivot the company in this new direction and immediately achieve success, fame, and fortune.

Does that story apply to what actually happened at Circle of Moms? Yes and no.

  • Original idea not being brilliant? Yep.
  • Byproduct = pivot opportunity? Yep.
  • Immediate success, fame, and fortune? Not so much: the pivot is only the beginning of the story.

The Pivoters

In 2008, when we decided to shift our company’s focus to moms, my co-founder Ephraim and I were guided by both personal goals and a business opportunity. On the personal side, we wanted to create a substantial website that would truly improve the world. I admire Zynga’s data-driven approach and relentless execution, but I wouldn’t derive a lot of satisfaction from building up a casual gaming property.

On the business side, four things were pushing us forward:

1) We were confident we could quickly drive distribution among moms. We’d been very successful with viral growth as Circle of Friends, and Circle of Friends’ viral mechanism had been far more effective among moms than anywhere else.

2) Moms were frustrated with the online products available to them. No good ways to meet other moms, poor information available online, difficulty storing and sharing their kids’ special moments, and decade-old tools to communicate with others like them.

3) Advertisers were willing to pay to reach moms. That meant that with moderate scale, we could get to profitability.

4) Moms told us they’d pay for tools and features that make their lives better and simpler. The now quaint-sounding quip I made in 2008 was that our customers weren’t 15-year-olds who had nothing better to buy than fancy ringtones.

In short, four positive indicators: a distribution mechanism (something all too many startups overlook), a high-level consumer need, and two possibilities for monetization.

Great, right? Well, yes — but there was one key constraint. Let me explain by making a comparison.

The Visionary

When I joined Reid Hoffman’s team at LinkedIn in early 2004, LinkedIn had 250,000 users and similar dynamics on items 1-4: a promising if not fully built out viral mechanism, a strong set of needs from a valuable audience, and a couple of potential revenue drivers. But in Reid, LinkedIn also had one unfair advantage.

Before LinkedIn even existed, Reid forcefully described a changing world in which everyone needed a place to hang their professional shingle. His vision of the future professional world was fluid and efficient on one hand, and relationship-driven on the other. This stood in sharp contrast to both the slow-moving, stay-at-a-company-all-your-life world of the 1960s, 1970s, and 1980s, and the transactional career-oriented sites that grew up in the 1990s. And this vision was truly a manifestation of his life: Reid cares deeply both about making the professional world more efficient, and about fostering relationships that can help all parties involved.

Very few founders have the ability to forecast where the world is going and then mix in their startup’s product. Reid’s correct vision of how LinkedIn could succeed — albeit with tactical shifts along the way — allowed the company to make big smart bets and helped its prospects immensely. The execution at LinkedIn was fine but not exceptional; many tactical choices were sub-optimal; the team was solid but not as the level of PayPal’s early team. But the combination of clarity of purpose, a good distribution model, and an ultimately correct view of the world allowed LinkedIn to overcome a number of challenges and become an influential and highly valued company.

The Two Climbers

Imagine two climbers. The first is a mountaineer. He knows he wants to climb Everest — it’s the most famous mountain in the world. He identifies the best people to help him, maps out the route, understands the challenge. When he actually goes to climb it, he encounters a blizzard and one of his colleagues gets sick — so he has to adjust his strategy. But he knows where he’s going and has a good understanding of how to get there.

Then picture a second climber. His goal is to get up as high as possible. He finds himself in San Francisco, on a foggy day. He knows from Wikipedia that Mt. Davidson is the city’s highest point. He can’t see more than a few feet ahead, but he can tell the difference between up and down, and sets off to cleverly find a way to the top.

Now map these types to two entrepreneurs starting companies. At Circle of Moms, I was the guy wading through the fog (and no, I didn’t have Google Maps on my phone). That wasn’t necessarily by choice: I’d spent several years working for a visionary founder, and would have emulated him had that been realistic.

Though you might not know it from reading popular accounts of startup stories, my non-visionary status wasn’t unusual: a pivoting company almost always starts out in the “fighting through the fog” mode. Circle of Moms was an extreme pivot case, a business largely chanced into by two men without kids. As such, we were unlikely to ever be blessed with an intuitive vision like Reid’s to guide our team. What were the biggest challenges our users were facing, and how was our company uniquely positioned to combine our resources and the technologies du jour to solve them? Those were questions Reid was able to answer instinctively and intuitively about LinkedIn; I found I really had to work to make progress on them for Circle of Moms.

Not having that intuition makes it harder to get one’s hands around a sense of purpose; I don’t think I ever perfected my elevator pitch. It was a challenge to find something like “the place to hang your professional shingle” (LinkedIn), “holding the Internet in your hands” (iPad), or even the smart journal that helps you share life with the ones you love (Path).

Embracing the Pivot Style

We ultimately settled on “motherhood, shared and simplified” as a tagline for Circle of Moms. It’s pithy, but not descriptive: better as part of the logo on a website than as a hook to convince potential recruits to join a team.

Lest you worry that I spent those 4.5 years crying myself to sleep, I’ll assert that tagline clarity rarely makes or breaks a company. But that communication challenge is representative of an area where we weren’t as strong. Like LinkedIn, we did what we could to capitalize on our strengths. In our case, that meant doubling down on execution and making the best of the resources we had.

Data-driven pivoting was certainly one strength of ours, and we were constantly making small shifts. We may not have found the most massive mountain, but we maneuvered the hills around us adeptly. We got features out quickly and then focused on optimizing them. We did well on SEO, figured out what worked on social media, crafted good viral flows, and had success creating and customizing content for email. Early on, we had an ad sales partner who helped us to become an attractive destination for brand advertisers. With revenue from those ad campaigns, we managed to grow the team steadily, while never wasting large amounts of money in unnecessary ways.

We had more trouble in areas like reinventing our home page, coming up with crazy new products, or pulling disparate features into a single experience. And press was probably never our strength.

Keys to Success

All else being equal, I’d rather be a visionary than a pivoter. For Circle of Moms, success happened because we found a good tack and paid attention to our constraints. I never had the vision for Circle of Moms that Reid had for LinkedIn. Yet our team managed to survive and prosper, because of a few key things we did well:

1) Turning the size of our user base into an advantage. Early on, many moms signed up for Circle of Moms, but didn’t do much on our site. In 2011, we built out technology to scientifically test out and optimize many different types of email content. That technology, coupled with a strong team writing new content, allowed us to reinvigorate our base of six million moms. Without that large user base, we never would have been able to find and optimize the best posts.

2) Hedging against Facebook-related risks. When Circle of Moms launched, we were almost 100% dependent on Facebook for traffic; in 2009 many VCs considered that an unacceptable risk and weren’t interested in funding us. That changed so much that 2-3 years down the line, during acquisition conversations with Sugar, I don’t remember the subject of Facebook traffic ever being brought up.

3) Moving away from several ineffective products. Between 2008 and 2012, we had four distinct primary product focus areas: communities of moms with similar interests, Child Page to chronicle each child’s development, local moms’ groups, and blog-style content. I wish we’d found the perfect feature; short of that, the discipline to pull away from things that weren’t working was the next best thing. And our mini-pivots ultimately allowed us to find a path to grow usage 2.5x in our last 14 months as a standalone company.

I’ll be writing future posts on each of those three topics.

Looking back, I’m glad to have both learned and accomplished a lot. Over those 4.5 years, we built a strong team and a community of millions of moms. We succeeded more than we failed. And I left the company in strong hands — Sugar’s and Ephraim’s — when I departed last month. Sugar’s team brings a number of new skills to the table, and I look forward to seeing how the combined companies will address some of the challenges we struggled with on our own.

Thanks to Elaine, Mark, Matt, Ephraim, and Tom for feedback on early drafts of this article

Why An Asocial Geeky Dude is Building Technology for Moms

In early 2007, I left one of the hottest companies in Silicon Valley. LinkedIn had millions of users, top investors and was already profitable. Our 80 person team had grown from twelve when I’d joined in 2004, and was poised to grow by another factor of ten over the next 3-4 years. I’d been leading the LinkedIn analytics team, and for a quantitative Internet guy, the data opportunities don’t get much better than LinkedIn’s.

I left LinkedIn because I had an itch to start my own company, though I wasn’t sure what that company should be. Let’s do a little entrepreneurial counseling exercise. Here was my background:

  • Mathematical and Computational Science degree from Stanford
  • Built PayPal’s early statistical modeling technology for fraud detection
  • Started to rank sports teams and help needy gamblers beat the Vegas spread

And my demographic/psychographic characteristics at the time:

  • 29 year-old married male without kids
  • only marginally less touchy feely than Dick Cheney

Which of the following would you have suggested I build?

  • a) a socially optimized search engine
  • b) a cloud-based collaborative filtering system
  • c) an algorithmically personalized form of social networking
  • d) a high frequency, automated stock trading system
  • e) a company with the tagline “motherhood, shared and simplified”

Yeah, I wouldn’t have guessed (e) either.

How we found moms (and moms found us)

In September 2007, I launched a Facebook application with Ephraim Luft, who was my year at Stanford. Our app, Circle of Friends allowed me to create one circle for my math geek friends, another for my developer friends, and a third for my sports analytics friends (ah, diversity).

The application took off pretty quickly, attracting millions of users within a few months, and I got a crash course on scaling a web app (tip: don’t use MyISAM for tables that might become huge, unless you prefer learning MySQL DBA tricks to sleeping). Thanks in large part to our rapid growth, we secured funding in January 2008 from several top “micro cap” investors — Mike Maples, Jeff Clavier, and Naval Ravikant.

Around the time of our funding, we accidentally did something very clever. We built a small feature to allow users to upload their own (tacky clip art) circle icons. This was well-received, and we soon started to prioritize the new circles/icons that were most popular. I added some Bayesian logic to tie circles to the appropriate demographic, and we soon had a product that would upsell “Drinking Buddies” circles to 20-something males, and “special friends with heart in my life…” circles to 16-year old girls.

Still, as satisfying as it was to see hundreds of thousands of people creating a “WARNING NAUGHTY WHEN DRUNK” circle (see image on right) with 15 of their naughty-when-drunk-iest friends, we had no illusions that we’d discovered the future of human social interaction. We had some traction and some interesting data, but Circle of Friends’ usage was about as deep as a backyard kiddie pool, and revenue prospects were dim. We weren’t quite sure how to proceed, so I did what I do best: dug into the data.

I noticed that several hundred thousand people had created a “Circle of Moms”. It turned out that those circles were way more active than any others — moms shared more photos, had longer and deeper conversations, and accepted more of one another’s invitations.

That was interesting enough to us that we started to think about building out a product just for moms. We asked some questions around consumer demand, revenue opportunity, and our ability to provide real value to mothers. We got deep answers to these questions; I’ll spare the details and summarize in one word: “yes.”

We launched Circle of Moms in October 2008, and haven’t looked back since.

Moms need community, empathy, support… and some kickass algorithms

One of the best things about building Internet technology is the opportunity to do work that touches millions of lives. But a million times ten minutes of mindless game play is nothing but ten million wasted minutes. On the other hand, effectively touching the lives of millions of mothers can help to raise a great next generation of humans.

When a mom wakes up at 3 AM for the sixth straight night, needing to comfort her toddler who had been sleeping through until morning, she needs both support and information. This is hardly a new problem, but the Internet has done relatively little to improve moms’ collective support system or knowledge. Fast forward a few years, and her seven-year-old is having trouble concentrating in school and Mom is concerned he’s falling behind. By combining data and community, we can help a mom — and indirectly, her child — through these tough situations.

Being focused on moms keeps us honest as technologists. Shocking though it may be, many techies — myself included — might on occasion build something that’s cool or interesting but not especially useful. But when you have an audience that actually needs your product, it forces you to keep your eye on the ball.

To fully address these needs, we’re able to combine two great styles of Internet product development. The Google-style algorithmic approach to product development is often great for spam filters, optimized search results, and ad targeting. Facebook-style social incentives are great at encouraging users to do “work” like tagging photos, translating text into different languages, and indicating their likes and interests.

I love this balance. In our case, it means that Circle of Moms is fundamentally about community and connecting people, but we’re not just a social site. To take the next step beyond social, we aim to provide our users with good information and guide them in the right direction based on our understanding of them. Social cues encourage our users to share more information about their kids; we then use that information to improve their content experience in emails and on the site. Likewise, we derived a list of important milestones children accomplish via moms’ contributions; we then algorithmically customize the list each user sees based on what we know about them.

When we decided to build out Circle of Moms, we made a conscious decision to constrain our problem space. That makes this sort of pragmatic approach to technology a lot easier. We can focus on building a playgroup finder for your area, a baby name chooser tailored to your preferences, and a guide to the development of your child, all as separate products.

Like LinkedIn, we’re a vertical social network with an awesome data set. We discovered that at 18 weeks, moms on the East Coast are 40% more likely to give their children solid food than moms on the West Coast. We learned that San Francisco has lots of babies but very few school children. And our data tell us that conservative moms name their kids Reagan and Sarah, while liberal moms prefer Jalen and Jada.

The examples above are interesting stories, but they’re just a start. Connecting moms to knowledgable peers with shared experiences and values is a hard problem, and to get it right we need to be successful across multiple avenues. Parsing conversations for keywords and underlying meaning (which we do) is one step in that direction; getting users to self-identify in intuitive ways is another. One thing that defines us as a company is that we keep iterating in data-driven ways to create a great product and help to solve those 3 AM problems.

And fortunately, I work with an awesome group of engineers who are rapidly pushing our technology forward to build useful products for moms. Brian‘s a low-key dad and a brilliant engineer who does everything from architecting and building complex search systems to writing email copy. Chris is a gold-buying, Tetris-dominating, cloud engineer extraordinaire, who uses the latest ec2 technologies to automate everything except his daily five cups of coffee. Regina, our in-house yoga master, has an awesome mix of front-end and back-end web development skills and puts together different technologies in clever and scalable ways. Hoi Ying is a fun and talented young developer, who’s become a force for us as we beef up our back-end technology (and our Hello Kitty collection!). Emma is a sponge of new information, with a great mix of engineering, product, analytics, and marketing talents: she crunches numbers, builds features, and improves the content our users see.

Collectively, they — and the rest of our eighteen person team — have made us profitable, reached millions of moms, and created a product and community that’s helping both moms and the high school class of 2027. That’s not what I expected when I left LinkedIn four years ago, but it’s pretty darned rewarding.