Andrew Chen Archives

I recently wrote a blog post about how Mobile Startups are Failing Like it’s 1999. The idea is that they are taking too long to ship their initial versions and then spending too much time between updates. As a result, they fail in a way that’s reminiscent of 1999 “waterfall”-style product development practices. We can do better.

The post was meant to be a challenge to the whole tech community, and I got a bunch of great responses back on how we might improve the iteration cycle. The ideas and suggestions tended to fall into a couple different categories:

• Picking the right (minimum) product
• Testing the market before launch
• Coding and shipping quickly

I got some great thoughts, particularly from YCombinator alumi, and I wanted to highlight some of the comments. They were very, very good.

Picking the right (minimum) product
The first thing is that it’s important to pick the right minimum product to build. Startups working in the Apple App Store have to satisfy three contradictory things:

1. Release a high-quality app
2. Release it quickly, to iterate with lots of funding in the bank
3. Get enough downloads with <$1M in funding to get the next round

The classic way to say this is, you can have it good, cheap, or quick – pick 2. Most of the time, what startups have under their control is quality and time to release, so let’s just focus on that. The best way to have good+quick is to create a polished app with limited featureset. That way you’re not skipping out on the polish, but you’re also not taking too much time.

The other big thing is to pick an existing market. If you have competitors but have an obvious way to differentiate, the amount of wandering you need to do before hitting product/market fit will (hopefully) be less. Given that iterations are expensive on mobile, this becomes a big advantage. If you are trying to do something new and the consumer behavior isn’t there to support it, then things might get scary since you’ll need to explore the market which takes time, money, and iterations. Expensive.

Kieran discusses the idea of polished but limited featureset in a comment below:

Kieran O’Neill, Founder of Thread
Technical solutions aside, I think the product development answer is to build nicher/one function/quicker apps initially, then expand to more ambitious, tangential goals once you’ve reached some initial success. You want to do this on the web, also; the problem is just more acute on mobile as you point out.

As does Tony, here:

Tony Wright, Founder of Tomo Guides
This is an awesome post. I used to believe that you need a big launch to succeed in the app store. I thought there was so much gravity in the app store that you needed a PR bomb to get you into the top apps— and that organic downloads from Apple’s “Most Popular” lists would keep you above the crowds. But I’ve seen too many big boom apps fall to the basement once their PR wore off.

I think the solution on our side is to launch earlier and re-embrace the MVP. Don’t gun for PR. Find a beta audience and serve them, even if you (and they) have to wade through the awfulness of TestFlight (“easy over the air betas— HA!”). Focus on scalable/repeatable customer acquisition and don’t Launch (with a capital “L”) until you’ve solved many/most of your product/distribution challenges. That way, you’re launch is throwing gasoline on a fire and not a wet pile o’ wood.

The point is that we’ve been trained to iterate fast, deploy multiple times per day on the web, and that’s now a best practice. Facebook deploys twice per day with nearly 600 developers, for example. However, on mobile that culture hasn’t been ingrained. Because of the app store process, really high quality product management becomes important because otherwise, it’s easy to let things take days, then weeks, and then months, between app releases. That’s not moving fast.

Testing the market before launch
Knowing that your v1 will be solid before releasing it also becomes super important, because of two main factors:

• App store leaderboards, where a sustained spike of traffic drives more traffic
• App store reviews, where you want as many 5 star reviews as possible

This means you want to squash all your bugs and deal with the major design issues before you try to get your big launch spike. Otherwise, you might get a spike plagued with bugs and 2 star reviews – not good.

I got a couple great comments about how to do this, by stealthily releasing and rebranding. Matt Brezina’s genius comment below:

Matt Brezina, Founder of Sincerely
This is a great observation Andrew. One thing we did was launch 2-3 versions of our product under a different apple account, without our personal names on the app, before we launched Postagram. When we did a PR launch the product was basically just a branded version of our work from the past 4 months; we knew it would function well and we knew users would love it. Since then we’ve never spent more than 4 weeks developing a release. And we particularly use Android for quick experiments – the apple 1 week app approval delay can really slow down the iteration cycles – that, and the difficulty in doing a/b tests are my least favorite things about the current mobile development environment.

Kenton, who works at Zynga on Mobile Poker, also mentions the great idea to use Android to prototype since the updates are easier:

Kenton Kivestu Senior PM, Mobile Poker at Zynga
Part of the solution is to develop / test features on Android where you don’t face the rigor or delay of the Apple approval process. Also, I think Kieran’s point is valid as well. Apple may have a high quality standard but there is no inherent reason that you need to spend 6 months developing something to get Apple approval. The 6 month development time is probably more indicative of feature creep, broad scope, testing too many things, over-polishing, etc.

Another interesting idea is to test your app initially in another geography so that you can get things right. That might be Canada or New Zealand, where you have high smartphone penetration and an English-speaking audience that’s similar to the US.

Coding and shipping quickly
When it comes to the actual product development execution, you have to ask yourself, what’s the real bottleneck? Is it submitting to Apple? Well, let’s say that you can do that every 7-10 days. Then let’s work backwards and say that you set yourself a simple goal.

Whenever you have an opportunity to submit something to Apple, you have something to submit.

What would it mean to try to satisfy this goal? I think what it means is that you end up building your product out in 1-week chunks. You end up scoping down a lot of the featureset so that you can deliver it incrementally in 1-week timelines, with some testing on day 5. For some longer features, you try to get it as close to 1-week as possible, and spare the minimum wait in between.

Similarly, even as you submit an app every week, you can still have a daily build – just use Testflight. This means you can do an internal release of your app every day, and your friends and family can try things out.

How feasible is this? Well, again, on the web we’ve gotten used to the idea of deploying multiple times a day- why not in mobile apps as well? It’s doable.

Conclusion
So those are the ingredients for iterating quickly: Simple but polished v1 app. Systematic market testing before launch. Strong, iterative product management. Weekly app submissions and daily testflights. Combine that with ample mobile startup funding, and the strong teams we have in tech, and hopefully we’re getting somewhere!

More ideas and suggestions for how to go better, faster, and stronger are welcome. Please comment below.

2012 has been good to startups.
It’s never been easier to raise seed funding, and there’s warnings that we’re in the midst of a “seed stage bubble.” Whether you think it’s a bubble or a boom things are good- you have to ask, how long will the party go on?

My theory is, we’re currently in a golden age for early stage startups, and the early stage market will stay hot for at least the next 3-5 years.

Here’s why the good times will continue
My reasoning looks something like this:

1. Right now, startups with strong teams can easily raise seed funding ($200-$1.5M or so)
2. They can easily raise seed money because there’s a lot of willing investors in the ecosystem. VCs are seeding deals without any price sensitivity, and a lot of angels seeing exits even when the teams fail
3. Angels are willing to invest because they have downside protection due to acquihires. They can invest $50-200k per deal and in the event of a startup failure, they get their money back (and sometimes even get marked up to a profit!). If the startups succeed, they have tremendous upside.
4. The downside protection is driven by acquihires from companies like Twitter, Facebook, Groupon, and others which are paying $1M-$3M per engineer. This makes sense to them because there are multiple billion-dollar markets at play.
5. And ironically, because this whole system exists, the engineers at great startups feel like they can splinter off and start their own thing, which feeds into the whole thing

Given that team acquisitions provide downside protection while the hits drive the real returns, it’s hard for investors behind top teams to lose money. So the question is, when will the downside protection, in the form of acquihires, disappear?

Mobile as the driver
IMHO, the answer to that key question is, I think we’re another 3-5 years because of one key thing that’s driving all of it: iPhone. (And Android, and the rest of the smartphone industry).

It’s going to take 3-5 years for the mobile market to sort itself out. As long as smartphones are still progressing from their current 100s of millions to the final 3B active users number, every company will be investing in this new platform, and they’ll keep buying as to not get left behind. Otherwise, they’ll be left on a previous platform as a new competitor emerges that’s mobile centric, and smokes them.

There’s a whole host of companies in the Bay Area, in Asia, and around the world that are investing heavily on mobile. They’ll buy any team they can get their hands on.

So they’ll keep acquihiring talent, supporting the whole thing, until the mobile market is set.

Whether you think this is a good thing or a bad thing, IMHO the mobile wave is so huge that it has the ability to power the early stage investing marketplace for years. Agree? Disagree? Tell me in the comments.

Stop the madness
The long cycle times for developing mobile apps have led to startup failures that look more like 1999 – it’s like we’ve forgotten all the agile and rapid iteration stuff that we learned over the last 10 years. Stop the madness!

Today, seed stage startups can now get funded, release 1 or 2 versions of their app spread over 9 months, and then fail without making a peep. We learned the benefits of how to iterate fast on the web, and we can do better on mobile too.

How things worked in 1999
How’d we get here? Back in 1999, we did a similar thing:

• Raise millions in funding with an idea and impressive founders
• Spend 9 months building up a product
• Launch with much PR fanfare
• Fail to hit product/market fit
• Relaunch with version 2.0, 6 months later
• Repeat until you run out of money

This was Pets.com, Kozmo, and so on. Maybe you’d fire your VP Marketing in the process too, out of frustration.

Between 2002-2009, we learned a lot of great ways to work quickly, deploy code a few times a week, and get very iterative about proving out your product.

How things work today
Then, with the arrival of the big smartphone platforms, we’ve reverted. It looks like 1999 but instead of launching, we submit into the iOS App Store.

It looks like this instead:

• Raise funding with an idea and impressive founders
• Spend 6 months building up a product
• Submit to the app store and launch with much PR fanfare
• Fail to hit product/market fit
• Relaunch with version 2.0, 6 months later
• Add Facebook Open Graph
• Try buying installs with Tapjoy, FreeAppADay, etc.
• Repeat until you run out of money

Not much different, unfortunately.

The platform reflects its master
We’ve gotten here because the App Store reflects Apple’s DNA of great products plus big launches. They are a 1980s hardware company that’s mastered that strategy, and when developers build on their platform, they have no choice but to emulate the approach as well.

Worse yet, it lets people indulge in a little fantasy that they too are Steve Jobs, and once they launch a polished product after months of work, they’ll be a huge success too. The emphasis on highly polished design for mobile products reverts us back to a waterfall development mentality.

Don’t burn 1/2 of your funding to get to a v1
Startups today have a super high bar for initial quality in their version 1. They also want to make a big press release about it, to drive traffic, since there’s really no other approach to succeed in mobile. And so we see startups burn 1/3 to 1/2 of their seed round before they release anything, it becomes really dangerous when the initial launch inevitably fails to catch fire. Then the rest of the funding isn’t enough to do a substantive update.

What can we do?
How can we stop the madness? What can do we do to combine the agility we learned in the past decade with the requirements of the App Store?

If we can answer this question, we’ll be much better off as an industry.

One of the most compelling organizational things I’ve read about lately is Square’s practice of referring to their product team as Product Editors and the product editorial team, rather than the traditional “Product Management” title. Wanted to share some quick thoughts below about it.

Product managers: One of the toughest and worst defined jobs in tech
The role of “product manager” “program manager” “project manager” is one of the toughest, and worst defined jobs in tech. And it often doesn’t lead to good products. The various PM roles often have no direct reports, but you have the responsibility of getting products out the door. It often becomes a detail-oriented role that are as much about hitting milestones and schedules as much as delivering a great product experience.

Thus PMs sometimes end up in the world of Gantt charts, 100-page spec documents, and spreadsheets rather than thinking about products. Now, all the scheduling and management tasks matter, but it’s too easy for PMs to lead with them rather than leading with products first.

Bad ideas are often good ideas that don’t fit
In the context of literature, books, and newspapers, it’s the job of the editor to pick the good stuff and weave it into a coherent story. You remove the bad stuff, but “bad” can mean it’s a good idea but just doesn’t fit into the story. It’s a compelling and important distinction for consumer internet.

Cohesion and consistency is difficult. When you have an organization with lots of very smart people all with their own good ideas, it’s difficult to decide which path to take. So often, products are compromised as the product “manager” doesn’t feel the responsibility to build up that cohesion as an ends in itself, and instead just tries to do as much as possible with the product given some set timeframe. Focus, people!

Jack Dorsey in his own words
In a recent talk at Stanford, Jack Dorsey describes his idea of editors:

“I’ve often spoken to the editorial nature of what I think my job is, I think I’m just an editor, and I think every CEO is an editor. I think every leader in any company is an editor. Taking all of these ideas and editing them down to one cohesive story, and in my case my job is to edit the team, so we have a great team that can produce the great work and that means bringing people on and in some cases having to let people go. That means editing the support for the company, which means having money in the bank, or making money, and that means editing what the vision and the communication of the company is, so that’s internal and external, what we’re saying internally and what we’re saying to the world – that’s my job. And that’s what every person in this company is also doing. We have all these inputs, we have all these places that we could go – all these things that we could do – but we need to present one cohesive story to the world.”

A video of Jack Dorsey talking about the concept can be seen here:

Lead with product
What’s compelling to me about this is that it really orients the role of product to be about cohesive experiences first and foremost. OK, yes, there’s still schedules first, but it doesn’t drive the thing- great products drive the process.

Similarly, you don’t just jam lots of characters and plot points in a story just because. Even if they are good characters, it can bloat the story. Same with features- sometimes you have many, many good ideas for your product, but if you come to do all of them, you ultimately make it a confusing mess. Instead, you have to “edit” down the feature list until you have a clean, tight experience.

Anyway, I hope to see this trend continue in the tech industry – it sets the right tone for where we should all be focused.

Design is in.

Consumer startups no longer need to argue about product quality – it’s a prerequisite to even an initial launch. This is a good thing, but this post isn’t about that.

For social apps, what you design directly is only half the user experience. The people are just as important! So if you build a really great linksharing site that’s extremely polished and full-featured, but the community consists of Nazis, it won’t work for people.

I’m often reminded of this fact when trying XBox Live, which consists of prepubescents killing you repeated on Halo while calling you gay. The Halo content is amazing, of course, but the community around it is… um… different than me.

Dribbble as an example
Similarly, you could build a product that was an exact replica of uber-design site Dribbble, yet still fail if you didn’t have their users. Half the work is the functionality, but the other half is “designing” the right users. If you haven’t seen the rules, a lot of things have to happen before you’re allowed to actually post content there:

• Why are players drafted? http://dribbble.com/site/faq#faq-why-drafted
• “Undrafted prospects” http://dribbble.com/designers/prospects

Basically, they have a long line of “prospects” which have to be nominated by the community in order to be able to post content. They limit membership like this so that all the content on the site will only be the very best.

Eventually, opening up is key
Perhaps naturally you eventually open up and evolve beyond this, but I think at the beginning you still need a lot of authenticity.

I think the reason why this whole concept feels unfamiliar to me is that for most consumer products, the problem is getting more people, not rejecting them :) Yet at the same time, I’ve learned through a lot of first-hand experience that if you don’t curate the initial community and scale your traffic as a function of this group, you can easily fall into the trap of “designed product, but undesigned community.” That’s no good either.

Surprisingly, it can be hard to figure out if you’re at Product/Market Fit or not, and one of the big reasons is that comparable numbers are difficult or impossible to come by. You have to look at comps for products in a similar or equal product category, and sometimes they just aren’t available.

Nature versus nurture
One way to think about this is that products have a nature/nurture element to their metrics. Some product categories, like chat or email, are naturally high-frequency. You use them a lot. Other products, like tax software, might give you value but you only use it once per year. A lot of ecommerce products are in-between, where you might buy gadgets every couple months but not every day. Just because people only use your product once a year doesn’t mean you don’t have product/market fit, as long as you’re building a tax product and not chat.

The two extremes are interesting:

• Medical apps: They may have high retention since if you have a chronic ailment, you may constantly be using an app relevant to your condition, but maybe not every day
• Books/Games: You read them nonstop for a few days or a week or two, and then once you’ve consumed the content, you never go back

The point I’ll make on this is that due to the nature of certain product categories, there’s a natural range of DAU/MAUs, +1 day and +1 week retention metrics. That’s the “nature” part of the product category. No matter how good your tax software is, you won’t get people to use it every day.

Based on your product execution though, you can maximize the the metrics within the natural range. A really good news product like Flipboard is able to drive 50%+ DAU/MAUs, which are fantastic.

Some product categories cannot get high DAU/MAUs
One key conclusion of this is that it doesn’t make sense to try to compare against Twitter or Facebook’s 50% DAU/MAU unless you are in the same category as them. A lot of social games target 30% DAU/MAU, but we can also see from the Flurry chart that social games are also amongst the highest DAU/MAU categories.

That said, if you are in the same category, then these rival products really tell you how good your metrics could really be, if you executed them in the right way.

Either way, don’t fight your nature :)

Update: New chart from Flurry
A while after I wrote this, Flurry released a new version of their chart, which you can see below. Full article here. It’s interesting to see which categories have shifted a bit, I imagine because the number of new apps in each category has changed a lot.