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:
- Release a high-quality app
- Release it quickly, to iterate with lots of funding in the bank
- 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.
