Andrew Chen Archives

This is a guest post by a friend of mine on email marketing. Elizabeth Yin is the CEO and a co-founder of LaunchBit, an ad network for email newsletters.  Previously, she worked at startups and Google, and went to MIT for her MBA, and Stanford before that. PS. I’m training growth hackers. Email me.

image credit: SilentMode

Hey, I’ve got this great idea for a startup…do you know any developers who might be interested in working with me?

I get asked this question a lot.  So, my co-founder Jennifer and I were curious and surveyed developers on what would compel them to team up with a non-technical co-founder.

The results were surprising.  This survey was not particularly scientific.  We received 104 submissions from developers, of which 35 were actively working on their own projects full-time and 69 were not.  We asked participants to rate how important a particular criteria was to them in deciding whether to join a non-technical person’s startup.  1 = Not important.  5 = very important.

Location is not a deal-breaker

I would’ve expected location to be a deal-breaker for just about everyone.  I would have expected all would-be technical founders to strongly prefer being in the same city as his/her non-technical counterpart.  But, only about half said location was a deal-breaker.

Idea validation is extremely important

In contrast, idea validation was extremely important to potential technical co-founders.  You, as a non-technical entrepreneur, are not selling a dream or the vision.  You are selling traction.  Some people who took our survey commented about their ideal proof of validation, “If they have $1M in sales and have shown that people are willing to buy this thing without it even existing.”  Another mentioned, “Validated early adopters/customers [are people] who said they’re going to pay for the product when their minimum viable product is out for their use.”

Prior relationship is not a deal-breaker

Also interestingly, I would’ve expected developers to overwhelmingly prefer to work with people they’ve already worked with or know from before.  And while, the data shows that many people would prefer to work with someone from their past, about 40% of technical folks don’t really care.

Pulling this all together, if you’re looking for a technical founder, the number one thing you should be doing is to get traction for your startup idea.  This means validating your idea, getting customers or users, and ideally getting revenue.

Getting traction without a product
So how do you get traction without a developer to build the product?  Very much in the spirit of the Lean Startup Methodology, there are a number of successful tech startups that got started without doing any programming.  Here are 3 companies that took off without writing any code in the beginning.

Yipit
Fast-growing startup Yipit, a deals-aggregation company, got started in 2010 as a side project without any code.  The founders, Vin Vacanti and Jim Moran, wanted to just get Yipit out the door in a couple of days, so in the beginning they manually aggregated deals from major daily deal sites — Groupon, LivingSocial, et al — by hand.

They put up a landing page to aggregate email addresses and collect category preferences.  Then, they manually categorized each of the deals they collected and emailed their subscribers based on indicated preferences.  In a the true spirit of hustling, they did not build a web crawler to aggregate the deals — they manually aggregated deals themselves at 3am everyday.  As Yipit started getting traction, it was getting more unwieldy to handle, but instead of hiring developers to build out web scrapers, they hired more people to continue manually aggregating, categorizing and emailing deals for 9 months, because the Yipit team wanted to continue to learn how to tweak the product quickly to make it better.  Since those early days, Yipit has since raised $7M+ in total.

Beat the GMAT
Beat the GMAT, a social networking site for prospective MBA students, started in 2005 as a side project — just as a blog.  The founder, Eric Bahn, used his blog to solve his own GMAT problems to help him practice for the exam.  His blog became so popular, readers started emailing him to ask for help on problems.  Although Eric would email people back, he was soon receiving 50+ emails per day from blog readers.  He realized he needed to scale himself.  So, he replaced his blog with forum software so that readers could help each other.

However, the number of visitors to his site was not large enough to make the forums particularly lively or helpful.  So, he continued personally answering a lot of people’s GMAT questions in the forums.  He took this a step further — he wanted to wow his visitors with quick responses, so he made sure each posted question in his forums received a response within 1 hour.  It turned out that a lot of prospective MBA students, however, lived in Asia, so he hired a contractor to call him whenever a prospective MBA student posted a question in his forums.  This often required Eric to jump out of bed in the middle of the night to answer forum questions.  But, a year into following this exhausting routine, Eric found that he had built up enough traffic in the forums, and other people were now responding to questions before he could even reach his computer.

The MBA community started clamoring for more, so the Beat the GMAT team decided to transform their forums into a full-fledged social networking site.  Since the team wasn’t technical, they outsourced the development of their site to what it is today.  Beat the GMAT bootstrapped its way to $1M+ in annual revenue with just 4 full-time employees and was acquired by Hobson’s in 2012.

AngelList
Founders Naval Ravikant and Babak Nivi had already been successful entrepreneurs by the time they started AngelList, a social networking site for angel investments.  They had the resources to build out a huge site for AngelList, and they initially did, but they quickly found they had overbuilt and did not have users.  So, they took a step back and dumped  everything.  They started again using a mailing list and Wufoo forms to hack together a community of entrepreneurs and angel investors.  They asked both sides to fill out forms with information about their companies and investments.  They manually brokered introductions between relevant entrepreneurs and investors.

Only once they started getting interactions going did they decide to build out the product that we see as AngelList today.  “We always do it manually…until we know how it works and then we automate it,” explained Naval.  Today, over 1000 startups have been funded on AngelList, and the company is rumored to be raising a first round of funding at $150M valuation.

The truth is — traction matters.  And, if you’re a non-technical founder with just an idea, it’s probably tough to find a technical co-founder.  Having traction on that idea will make it a world easier to find technical talent.

P.S. But, I know that figuring out how to get traction isn’t easy.  So, I’m organizing a conference called Hustle Con (July 9 in Mountain View) to teach new entrepreneurs on how to get customers first.  We’ll be talking about topics such as how to go from 0 to $5M in revenue and how to build an audience before you have a product.  We have a great full line up of speakers including Scott Cook (founder of Intuit), Gagan Biyani (co-founder of Udemy), Jess Lee (CEO of Polyvore), and Arjun Arora (CEO of Retargeter) who will share how they acquired customers.  And, I’m giving away one free ticket on this blog.  All you have to do is tweet why you want a @hustlecon ticket before June 27th, and the best tweet will win.  For those who don’t win, get 25% off with this discount code: “andrew-hustler”

About the author: Kenton wrote this fantastic piece about analyzing in-app revenue, drawing from his work experience at both Zynga, where he runs their mobile poker product, and before that, Google. You can follow him at @kivestu and his blog here. -Andrew

When I worked at Google, Eric Schmidt used to say “Revenue solves all known problems.” He was right.

And if you’re monetizing a mobile app today, there is a good chance that in-app purchases (IAP) are a critical component of your monetization (if not the sole pillar).* Yet we don’t have great tools for understanding the mechanics of revenue models driven by IAP. Financial analysts who wrestle with similar problems can shed some light.

Financial analysts often use a technique called DuPont Analysis – named after the famous chemical company that created it – to understand what components of a business are driving financial returns.

The DuPont Analysis equation looks like this:

This equation states that if you take a company’s profit margin, asset turnover and financial leverage, multiply them together, you’ll get Return on Equity (ROE) – a measure of how much profit a company generates per the amount invested into the company. It’s an insightful way to quickly understand what is the driving force behind returns (and also known to be one of Buffet’s favorite metrics).

The key insight from DuPont analysis is the principle of decomposing a common metric into the components that drive it.

To successfully monetize via IAP you need a deeper understanding of revenue drivers – top line revenue or even revenue / daily user (aka ARPU) is not enough. A more sophisticated understanding starts with the Transactions Payers Revenue (TPR**) equation:

Rev/DAU (aka ARPU) is a quick measure of how much revenue you’ll make for each user you have on a given day – it’s an overall indicator of your ability to monetize your users.

Payers/DAU measures how many of your users on any given day actually pay – meaning on that particular day X people actually transacted within your app.

Rev/txn measures how much each transaction was worth – this is particularly important for developers that have a large range of price points available in their app (as many games do, for example). Note: If you only sell a single item this metric will be a constant equal to the price of that item.

Txns/payer measures the number of transaction you got for each payer you had in the app in any given day (eg how many transactions did the avg. payer complete.)

Let’s run through a mechanical example. Let’s say two different mobile apps have a $0.10 rev/DAU. On the surface, it might seem like these apps are similar:

But if you dig a little deeper and collect the other key metrics we’ll need for TPR analysis, differences will manifest themselves:

And if you run the calculations, your picture now looks like this:

So what?

The chart above is critical to understand if you’re focusing on improving monetization because it tells you where your leverage points are. For example, if you’re the CEO of product B and you tell your VC that the critical way you’re going to grow revenue is by converting more payers, your VC ought to call BS. Why? Because 5% of daily users paying is already pretty damn good. You might be able to get 5.1% or even 5.5%, but that won’t move the bottom line much. A 10% improvement on an already stellar number, would equate to an extra $10 / day (10% improvement on payers means 5 incremental payers, each doing 5 txns / day, giving you $10+ bucks a day).

However, if you instead focused on increasing the revenue per transaction, you might find there is significant upside. After all, people shell out in excess of $0.99 for a single Coke in most places around the world, so it seems like your revenue per transaction has head room to grow. Maybe by highlighting volume discounts (or some other product tweak) you could get revenue per transaction up to $0.60. It’s not quite a Coke yet, but hey, its an improvement. That would be pretty great though – and it’d net you a $50 bottom line improvement, not bad!

What next?

The TPR equation, while helpful, is just the first step. Any thorough understanding of IAP revenue will require peeling back another layer of the data. For example, is payers / DAU being driven by active payers or new payer conversion? Or what about lapsed payers returning to the app? What about “red herrings”? In some cases, an increasing rev/DAU metric might actually point to long term problems acquiring and monetizing new payer (this can happen when new DAU starts declining, new payer conversion dips and rev/DAU looks healthy because committed, elder users of the app are pushing it up). More on these more nuanced layers in a followup post.

Footnotes
*The most recent Distimo data suggests that revenue from IAP no accounts for 70%+ of app store total revenues, up from ~50% in Jan. 2012.
**TPR stands for Transactions Payers Revenue. I didn’t want to be narcissistic and name if after myself and TPR sounds official, akin to those TPS reports (albeit hopefully more valuable).

If there’s one thing I could tell every graduating student, this is what I’d say:

Jobs suck. At least the traditional version of a job, in which you do something you sorta hate, from 9-5p, and are paid for your time to just grit your teeth and do it. Let’s call this the “sell your time” version of a personal business model: You sell your time to an employer, and they pay you for that time.

Turns out this personal business model sucks.

Even The Onion agrees, in their article Find The Thing You’re Most Passionate About, Then Do It On Nights And Weekends For The Rest Of Your Life.

There’s so much conflict stemming from the fact that this is the predominant mode of work in our society. All the hand-wringing about work/life balance, finding what you love, kids versus work, etc. – an important source of these anxieties come from the fact that a “sell your time” model of work means you’ve set your personal time (and goals) in direct conflict with the time you have to sell for work.

Stop selling your time
There’s a better way – though it might not be the easiest way. The key is to find a way to stop selling your time, and to find another business model instead. And the important aspect of this personal business model is that you’ll be able to make money even if you are sleeping.

1) Learn to make something. Anything.
First and foremost, I think it’s important to learn to make something. Anything. It could be an app, blog, table, YouTube channel, video tutorial, or anything else. Then study the people who have become successful enough to support themselves in this craft, and study them, copy them, stalk them, and meet them.

It always shocks me when people don’t really know how to make anything. Or haven’t ever tried. It’s something we’ve all done as kids – drawings, crafts, etc. – but somehow a very large number of professional workers find themselves in a state where they only know how to repackage other peoples’ work rather than doing anything themselves. Weird.

2) Create a feedback loop with your audience/customers
Remember that the end goal isn’t to make art, it’s to get out of selling your time for a living. So even while you’re learning to make stuff, you’ll want to learn how to make stuff that people actually want. This means you need to create a feedback loop between you and your customers, whoever they may be. This means you’ll want to constantly show people your work, no matter how bad it is. You’ll want to try and build an audience, or a customer base. Again, this is a skill in itself and may take years to figure out.

It’ll also be an opportunity to find small wins in what you do- whether that’s improvements in craftsmanship, or from finding an audience for your work. This kind of positive feedback will keep you going.

3) It’ll take years to become competent
It’s been discussed endlessly in books like Malcolm Gladwell’s Outliers, but it takes years of solid practice to be any good at anything. And then 10,000 hours (roughly 10 years) to become a world-class expert.

But even before you sink years into something, you’ll get frustrated much earlier on because you’ll think that you suck at it. There’s a great quote from Ira Glass (of This American Life) about the difficulty of getting good at anything, starting as a beginner:

“What nobody tells people who are beginners — and I really wish someone had told this to me . . . is that all of us who do creative work, we get into it because we have good taste. But there is this gap. For the first couple years you make stuff, and it’s just not that good. It’s trying to be good, it has potential, but it’s not.

But your taste, the thing that got you into the game, is still killer. And your taste is why your work disappoints you. A lot of people never get past this phase. They quit. Most people I know who do interesting, creative work went through years of this. We know our work doesn’t have this special thing that we want it to have. We all go through this. And if you are just starting out or you are still in this phase, you gotta know it’s normal and the most important thing you can do is do a lot of work. Put yourself on a deadline so that every week you will finish one story.

It is only by going through a volume of work that you will close that gap, and your work will be as good as your ambitions. And I took longer to figure out how to do this than anyone I’ve ever met. It’s gonna take awhile. It’s normal to take awhile. You’ve just gotta fight your way through.”

The period where your taste outpaces your ability to produce it is a hard one. You know your goals but don’t quite know how to fulfill them. That’s why it’s easier to be a film critic rather than a film director :)

Startups
The point of all of this isn’t to do it alone. In fact, you’ll find that it’s rare you can do something substantial by yourself. Instead, the above feedback loop most usually involves teams of people, at least once the basic groundwork has been done.

Technology startups are a perfect example of this- it exemplifies the process of getting a bunch of smart people together to learn and make something valuable for the world. It’s a remarkable thing to get the experience of creating something from scratch, and seeing it through to its success in the market. But even if startups aren’t right for you, and  you choose to write books for a living, in a success case you’ll work with editors, research assistants, other writers, etc.

On a final note, if this essay reminds you that your job sucks, just watch this clip from Office Space where they beat up a fax machine.

PS. I’m training Growth Hackers. Email me.