“There falls a shadow, as T. S. Eliot noted, between the conception and the creation. In the annals of innovation, new ideas are only part of the equation. Execution is just as important.”

Excerpt From: Walter Isaacson’s “Steve Jobs”

Observations from the Fueled team

NOTE: This is a live document that is frequently being modified, including with draft content and incomplete thoughts. #agile

Everyone knows only a few tech startups out of the thousands started each year will actually succeed. But what many don’t realize is that success and failure in the tech industry has little to do with chance. And to that end, Fueled has endeavored to list out the biggest myths in app development and head off some common mistakes that founders make.

In no particular order:

Bugs at Launch
People have this idea in their head that when an app launches, it won’t have any bugs. If that were true, apps would take much longer to launch. Instead, the best practice is to fix show-stopping issues and then wrap up other bugs post-launch. Of course, established apps with a huge base of users will have a lower tolerance for bugs, but even products from Facebook, Apple, Google, and all the other big-name tech companies are regularly updated to fix bugs.

Launch Dates
People think that they can pick a fixed date in the future and launch at that point. In reality, launch dates should only be decided upon once an app is ready for release. There is simply too much unpredictability. There are a million reasons a software project might get delayed.

The Big Launch
Some founders seem to believe startups are projectiles rather than powered aircrafts, and that they'll make it big if and only if they're launched with sufficient initial velocity. They want to launch simultaneously in 8 different publications, with embargoes. And on a Tuesday, of course, since they read somewhere that's the optimum day to launch something. It's easy to see how little launches matter. How many successful startup launches do you remember? All you need from a launch is some initial core of users. So why do founders think launches matter? A combination of solipsism and laziness. They think what they're building is so great that everyone who hears about it will immediately sign up. Plus it would be so much less work if you could get users merely by broadcasting your existence, rather than recruiting them one at a time. But even if what you're building really is great, getting users will always be a gradual process -- partly because great things are usually also novel, but mainly because users have other things to think about.

Launch Parties
“We launched, we threw a party, we're successful and have a ton of users,” said no one ever. You should only consider a launch party as a way to celebrate your launch with friends and your team. A good time, a celebration. But it's only the slightest bit useful as a way to get your app out there and gain users. Most people will show up, drink your free booze, and never download your app. Sure, it creates a bit of awareness, but the cost-per-install is way worse than if you just bought users with CPI-based advertising networks. Throw a party for fun, not profit.

Partnerships
These usually don't work as well as you might think. They don't work for startups in general, but they especially don't work as a way to get growth started. It's a common mistake among inexperienced founders to believe that a partnership with a big company will be their big break. Six months later they're all saying the same thing: that was way more work than we expected, and we ended up getting practically nothing out of it. It's not enough just to do something extraordinary initially. You have to make an extraordinary effort initially. Any strategy that omits the effort -- whether it's expecting a big launch to get you users, or a big partner -- is suspect.

The "Apps I Use" Fallacy
Founders tend to look at the apps they use regularly, like Spotify, Facebook, Instagram, etc and expect similar levels of complexity, functionality, and polish from the products they are building. Exacting standards and high expectations are good, but they also need to be realistic. Some of those products (e.g. Facebook) are literally over a decade old. And, at the very least, have dozens of dedicated developers and multi-million dollar payrolls behind them. This conflation of what a mature app looks like with what a newly launched product should look like skews a new founder’s expectations in terms of what a startup's app can actually do and they think they can get an app of a similarly sized feature set and design polish for a fraction of the price.

Clarity of Apple App Store Rules
There is this notion that Apple's App Submission Guidelines are clear and easy to interpret. In reality, they're often vague and full of holes and unclarified, nebulous statements. And worst of all, Apple basically refuses to give binding--or even firm--answers to questions before developers go and spend tens or hundreds of thousands of dollars on development. The only way to really know if an app is acceptable is to just go ahead and submit it. And even then, there are at least a handful examples of Apple kicking apps out of the store after initially accepting them!

Scalability
People think they need their app to handle tens of thousands of users on launch. For a startup, that's a waste of money, time, and energy. If your app is slowing down because it has too many users, that's a champagne problem. In reality, you're more likely to have dozens or a few hundred users early on. Pour all your attention into launching a great, lean initial version of the app and getting users on that and gathering feedback. Don't pay for the infrastructure of a hit until you know you have one on your hands.

Early Monetization
Similar to the scalability issue, it’s not always prudent to worry about monetization at launch if you don't have any users to monetize. Instead, focus on making the best possible app and luring users onto your platform. Wait until you've reached scale to worry about monetization. I've seen people waste $50k on a feature that would aid monetization, only to pivot the company before they made even $1k back. If your monetization is to simply drop in some ads, then that’s relatively quick and there’s little reason to hold back at launch. But for anything more complex, think twice about the timing of rolling out that feature.

Launching with Advertising
Focus on getting users onboard and creating the right combinations of features until you start to see viral growth. Exceptions apply to apps on the freemium model and maybe some content apps. Again, if it’s simply dropping in a third-party advertising solution, then there’s no harm. But if you’re doing something complex or custom, you should probably hold off. Definitely don’t build anything custom for advertisers until you’ve already closed a deal with them.

User Hunger (Eagerness & Dedication to share, use, open, etc.)
People think users will view their app as a godsend and continually use the app, if only they knew about it. That's not even close to true. You've got to really build in stickiness and ways to get users to open your app 3, 4, 5 times. You need to win over your users multiple times before opening the app becomes a regular part of their routine.

User Competence
Don't expect much of your users. They're almost certainly going to exit (and maybe even delete) your app rather than jump through hoops that are difficult to figure out. Don't leave anything up to chance. And most importantly: assume no one will read the instructions.

Hypothesis Stacking
Launching any product–or any business, for that matter–is really just testing a hypothesis. The idea is that if you create XYZ for users, they'll keep coming back over and over again. But getting that feature right isn't easy. Founders too often create secondary and tertiary features that rely on an assumption that their primary feature is implemented correctly. This is a waste of time and money while also risking tainting the results of your hypothesis testing.

Omnipotent Analytics
Analytics aren't a magic solution where you just dump in a line of code and automatically track every little thing in your app. Instead, you need to carefully plot out what you want to measure and coordinate with your development team.

There's An API for That
Product owners often assume that there's an API for every app and website out there and that anything a site can do is fully available through their API. In reality, only some platforms offer APIs. And even when they do, it's almost always with a slew of restrictions and limitations. For example, OpenTable famously still does not offer third-party users the ability to access their inventory and book tables. Every month someone comes into Fueled with an app that they plan to monetize by accepting OpenTable reservations! And just because there’s an API, doesn’t mean it’s easy to integrate with. Not all integrations are created equal.

Single Version Syndrom
Founders sometimes think if they can just build exactly the right app the only next steps will be to put it in the store and watch users flock to it. In reality, good apps usually release dozens or more versions, tweaks, and iterations before they start to really gain meaningful traction. These are aren’t necessarily major releases, but they can often represent serious rethinks in functionality. Bottom line: expect to iterate a ton before you get to critical mass.

Network Externality (The Day One Problem)
Social networks, like any other product, basically have zero users on launch day. Successful social products, without fail, provide some sort of utility on launch day that provide value independent of network effects. In other words, users get something out of it even if they have extremely few friends on the network. Facebook (then called Facesmash) was a side-by-side attractiveness judgment game of students in Harvard’s freshman dorms (similar to hotornot.com). Instagram’s initial key use case was filtering photos and posting them to other social networks (in addition to theirs). To be successful, you have to find your day-one use case.

Test & Measure vs Build
If you have identified a problem, you should be able to produce strong evidence that it’s a real problem. Study the market or interview users. There are ways to test whether your hypothesis is a real problem before investing time and money in building a solution for it to see if anyone needs that solution. The three steps of product iteration are build, test, and measure. Build is the most expensive and time-consuming one, so avoid making it your starting point.

Attacking an Entrenched Competitor
If you’re competing with an established, successful business you need to do by solving a problem with the entrenched product, not by making incremental improvements. Facebook didn’t set out to build a Flickr competitor, but they beat Flickr by leveraging social connections to expose photography. Instagram didn’t set out to build a Facebook competitor, but they beat Facebook (in some important areas) by making social photography work natively on mobile. Snapchat didn’t set out to build an Instagram competitor, but they beat Instagram by removing barriers to social sharing.

Build Super Lean & Super Fast
It’s easy to think a “lean” product takes weeks to build. In reality, within a few days of development you should be able to building something significant enough to gauge if your idea is interesting or not. Here are some examples of products where the first version was build in a few days:
The original version of GroupMe
The emoji URL shortner, http://🍕💩.ws/
BONUS: A 30 story building in 15 days

Next Steps

Do This, Read That (in order of importance)
Take this class
Read every one of these articles (or, at the very least, this one)
App Usage - “Americans spend nearly 2 days a month using mobile apps”
How Apple Develops Incrementally
Google Ventures Product Design Thinking

Between the idea
And the reality
Between the motion
And the act
Falls the Shadow
--T.S. Eliot

“People don’t know what they want until you show it to them.”
-- Steve Jobs