@andrewchen

Subscribe · Featured · Recent · The Cold Start Problem 📘

How mobile startups can iterate better, faster, stronger

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.

PS. Get new updates/analysis on tech and startups

I write a high-quality, weekly newsletter covering what's happening in Silicon Valley, focused on startups, marketing, and mobile.

Views expressed in “content” (including posts, podcasts, videos) linked on this website or posted in social media and other platforms (collectively, “content distribution outlets”) are my own and are not the views of AH Capital Management, L.L.C. (“a16z”) or its respective affiliates. AH Capital Management is an investment adviser registered with the Securities and Exchange Commission. Registration as an investment adviser does not imply any special skill or training. The posts are not directed to any investors or potential investors, and do not constitute an offer to sell -- or a solicitation of an offer to buy -- any securities, and may not be used or relied upon in evaluating the merits of any investment.

The content should not be construed as or relied upon in any manner as investment, legal, tax, or other advice. You should consult your own advisers as to legal, business, tax, and other related matters concerning any investment. Any projections, estimates, forecasts, targets, prospects and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Any charts provided here are for informational purposes only, and should not be relied upon when making any investment decision. Certain information contained in here has been obtained from third-party sources. While taken from sources believed to be reliable, I have not independently verified such information and makes no representations about the enduring accuracy of the information or its appropriateness for a given situation. The content speaks only as of the date indicated.

Under no circumstances should any posts or other information provided on this website -- or on associated content distribution outlets -- be construed as an offer soliciting the purchase or sale of any security or interest in any pooled investment vehicle sponsored, discussed, or mentioned by a16z personnel. Nor should it be construed as an offer to provide investment advisory services; an offer to invest in an a16z-managed pooled investment vehicle will be made separately and only by means of the confidential offering documents of the specific pooled investment vehicles -- which should be read in their entirety, and only to those who, among other requirements, meet certain qualifications under federal securities laws. Such investors, defined as accredited investors and qualified purchasers, are generally deemed capable of evaluating the merits and risks of prospective investments and financial matters. There can be no assurances that a16z’s investment objectives will be achieved or investment strategies will be successful. Any investment in a vehicle managed by a16z involves a high degree of risk including the risk that the entire amount invested is lost. Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by a16z and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by a16z is available at https://a16z.com/investments/. Excluded from this list are investments for which the issuer has not provided permission for a16z to disclose publicly as well as unannounced investments in publicly traded digital assets. Past results of Andreessen Horowitz’s investments, pooled investment vehicles, or investment strategies are not necessarily indicative of future results. Please see https://a16z.com/disclosures for additional important information.