We'll first dive into the paradox that the app ecosystem presents--the prospect of fame and fortune, but the obscurity of being lost amongst the millions. We'll also cover critical questions that every intrapreneur or entrepreneur needs to think about before they venture into building a new app. The same principles apply also for new ideas for an existing app. The first things you should ask yourself are:

• Why would users want to use my app?
• For what purpose or when would they actually need it?
• Why would they keep coming back to use it?

Creating a profitable app is hard, but not impossible. There are many well-known examples. One of them is Flappy Bird. In May 2013, an obscure solo app developer living in Vietnam named Nguyen Ha Dong released a game in the iOS App Store. The initial response to the app was muted, with just a few downloads. Several months later in early 2014, the game revived with a surge in popularity, and became the most downloaded game in the App Store at that time.

At the height of its popularity in January 2014, the game was earning $50,000 a day, from in-app advertisements as well as sales. A month later in February 2014, Dong famously pulled the game from the stores. This led to a short, frenzied period when phones with the app installed were being sold at a premium online.

The app is now a much-storied example of a rags-to-riches overnight success story. But whether by serendipity or by design, Dong's success is far from typical. Few solo app developers have succeeded in monetizing their apps.

For every intrapreneur or entrepreneur with shiny, bright, new ideas, the odds are stacked against them. When Steve Jobs famously quipped There's an app for that, he really did mean it. There's an app for just about everything! So, why does your bright new idea matter?

If you build it, they will come. Well, that obviously is not true. Just publishing your app in the App Store or Play Store will not be sufficient. On both Google Play and the Apple App Store, 9 out of 10 apps that are published by developers see fewer than 5,000 downloads, ever. There are so many apps already available. How will people ever notice your app?

No matter how good your app is, it will drown in an ocean of apps without a good plan. To succeed, you first need to ask yourself some important questions:

• Who needs your app?
• How will people find out about your app?
• Why would someone download your app?
• Why would they keep coming back to use it?
• How would others hear about the app?
• What stops others from copying your app once it is successful?

Apps that make it to the top of the charts dwarf apps that don't by a large order of magnitude. There's a case to be made about long-tail characteristics in a marketplace. Amazon is known for having said that they make more money selling books that were never stocked earlier than the ones that are. Their marketplace has strong, long-tail characteristics, with several niche books finding an audience.

However, the App Store dynamics don't work well in favor of niche segments. The discoverability of an app continues to be a challenge, making it hard for publishers to succeed in niche categories. Apart from discoverability itself, there's just a little more friction involved in someone having to download an app over just visiting a mobile website.

Today's mobile world is well past the gold rush frenzy of the late 2000s. Google Play has 1.9 million apps with over 50 billion downloads. Apple's App Store has 1.4 million apps with 100 billion downloads. Most app categories are fairly saturated, and there are free apps for most things. The design of the marketplace incentivizes app developers to drop their prices in order to hit the top of the charts, giving them wide distribution.

Should you be dissuaded by all this? Does this mean that the chances of success are so low, and the field so daunting, that we might as well give up? Far from it! As time has shown, there are always new opportunities. Famously, today's leading companies, such as Google and Facebook, emerged from the dust of the dot com bust of the early 2000s.

But instead of the big bang approach that companies took to building products earlier, we are now equipped with more scientific approaches for taking new ideas to market. And here's where the Lean Startup methodology outlined by Eric Ries has radically changed how several start-ups and large companies develop software.

Lean start-up principles help realize your vision through rapid experimentation. They provide an approach for taking a bright new idea, and first identifying key high-risk assumptions that you are making. These are assumptions whose failure would mean that your idea would fail. The next step is to craft small market experiments to test these assumptions in the field. A successful experiment would validate an assumption, which lets you move on to your next assumption and craft the next experiment. Failure of an experiment would invalidate an assumption, which means that your idea in its current form would fail.

If you are a developer, you may wonder if the Lean Startup methodology is just a bunch of business management speak reserved for stuffy types in dark suits. That would be an unfortunate misconception. Eric Ries attempted to develop an easily understood management principle for entrepreneurship, which was otherwise seen as a mysterious dark art form.

However, Eric's own roots are closer to the developer community than to the busniess community. It was his experiences building software at IMVU that inspired his Lean Startup ideas. He was one of the early pioneers in endorsing continuous development and continuous integration in the software development process. It was an attempt to strip out all the wasteful cycles that developers spend time on, and help them focus on building things that mattered most to their customers.

Experienced developers care about efficiency and writing code that actually has an impact. Compared to other industries, the software industry has numerous examples where millions of lines of code are discarded because they go into building features no one wants. That's a waste of endless hours of developer effort that could be better used building useful software.

The Lean Startup approach is also closely associated with agile software development. Agile development outlines an important cycle for how software is built. This cycle is typically inward, and happens within a software development team between managers, developers, and testers. Lean Startup adds the concept of customer development. Customer development is an outward cycle that happens between the software development team and the customer. The cycle involves working with the customer by running interviews, observing customer behavior, testing with market experiments, and collating the results.

If you are a developer in an organization with a top-down culture, where suits with hand-waving skills and mastery with PowerPoint hold sway, Lean Startup can help. Decisions in many organizations still happen based on who has the best PowerPoint presentation and the power of key lobbies to influence decisions. Few things can hurt ground-up innovation in an enterprise more.

Lean Startup provides developers with a framework to influence decisions with real data from customer experiments. If a decision needs to be made, push others at the table to either bring data to justify it, or to run an experiment to collect it. This is critical.

Agile development has been embraced by most organizations over the last decade, with Scrum and extreme programming becoming commonplace. In the coming years, knowledge of Lean Startup will be a valuable asset for developers looking to enhance their skills.

Lean Startup isn't a defined hard and fast process set in stone. It's a set of principles to help chart your way through unknown territory. In the wild, a compass and a map are tools that enable hikers to navigate and avoid dangerous pitfalls that potentially be fatal. Much like a compass and a map, Lean provides a framework to navigate through new discoveries. These discoveries enable you to make crucial decisions about what steps to take next and in which direction.

A Lean approach is no guarantee of a next Flappy Bird. But think about it this way: we're still in an age where taking new ideas from concept to market is still serendipitous. This is much like how fire was discovered and how the wheel was invented, likely as much by chance and gradual evolution than deliberate choices. It took us centuries before science got us to the point where we developed systematic ways of running laboratory experiments. Despite that, it took legendary inventor Thomas Alva Edison hundreds of failed experiments before he invented the light bulb.

What science did do, though, was accelerate the process. Serendipity took centuries. The last century has seen the acceleration of new discoveries and significant scientific advancements. Experiments still fail, and research projects that are pursued for years are often abandoned. But today, the chances of a laboratory scientist's success are significantly higher than that of a caveman in the wild.

Lean Startup has changed how we understand customer needs, and how we build products to meet those needs. Our chances of success are so much higher than they were for a software developer even just a decade ago. How can this methodology help developers do things using the right tools at the right time? The answer is in this book. It is aimed at technical cofounders and other developers involved with a startup company. It can help you learn how to apply the Lean Startup methodology to mobile app development specifically. It will give you insights on how to balance between a pragmatic and hands-on approach while still doing things the right way.

One of the key elements is early validation. Whether you are a solution or problem-oriented person, you have certain assumptions. These assumptions may be right, but most likely they will be wrong. The only way to find the answer is by creating an app, or a simulated app, that you can build very quickly and that you can use to gather feedback. Such a solution is known as the Minimal Viable Product (MVP). An MVP contains only the functionality that you need to have to prove your hypotheses. Everything else in the app that cannot contribute to gathering feedback is waste and should not be there.

For a business guy, the idea of an MVP may sound odd. You only have one chance for a first impression, right? Also, as a developer you do not want to write a bunch of code only to throw it away later. So what exactly should be in an MVP? A more in-depth explanation of an MVP will follow in Chapter 5, A Pragmatic Approach.

Not only do 9 out of 10 apps see fewer than 5,000 downloads, also 9 out of 10 apps are not launched more than once. You can do the math. Right there, you can see that the chances of having an app that's regularly used by more than 5,000 people dropped to 0.01, or 1 in a 100.

There are a number of reasons why this happens. Some users install an app they hear about, but don't like it and may choose to uninstall it right away. If they've liked the app, they may keep it. While this may sound like a win, it's not always the case. Often, users just forget about the app and may not think about launching it again, even if it fulfils a need that they have.

You may have built a fabulous app that helps the user save money through budgeting, but unless the user remembers to launch the app regularly and track her finances, it will not help her. In Chapter 15, Growing Traction and Improving Retention, which discusses traction and retention, we will see some practical implementations to get the attention of the user. For example, sending (relevant) push notifications is often an effective method to draw the user's attention back to the app.

Frequent usage creates more opportunities to encourage people to invite their friends, broadcast content, and share through word of mouth.

Let's take one step back and focus on the question, How will people find out about the app? Unless it gets featured (by Apple, for example), or unless it gets discovered by accident (as happened to Flappy Bird), you need to promote it actively. You can consider Google ads, flyers, and commercials. That can become pretty expensive. However, if you can let it grow organically, the results will probably be way better, and it will cost you less. For example, people might hear on Twitter and other social media platforms how great your app is. To make that happen, people first need to become enthusiastic and regular users of your app before they share it with their friends or business colleagues.

Users who continuously find value in a product are more likely to tell their friends about it.

Some products capture widespread attention. Nir Eyal describes in his book Hooked what makes us engage with certain products out of sheer habit. For example, Pokémon Go!, Facebook, or Instagram are all very addictive apps. People hear about the app, download it, and keep using it, on a daily basis even. Why is that? It seems there is an underlying pattern to the way technology hooks us. Nir Eyal provides answers to this and other questions by introducing the Hook Model. It is a four-step process that is embedded into the products of many successful companies to subtly encourage customer behavior.

Hooked users become brand evangelists-megaphones for your company.

Nir Eyal's classic Hooked Model contains four steps:

• Trigger
• Action
• Reward
• Investment

In a nutshell, this is what you see in this model: The trigger is what brings the user to a product to take an action that results in a reward that's followed by further investment.

At the action step, the user will be asked to perform a simple action that will boost the user's motivation. This phase of the hook draws upon the art and science of usability design, to ensure that the user acts the way the designer intends.

Offering variable and unpredicatable rewards are important tools to hook users. There are many feedback loops already, but they are all predictable. Predictable loops do not create any desire. We should surprise the user and create a desire in the user. Gamification is an example of a tool to accomplish this. We can reward the user with a badge or other digital (or non digital) incentive.

The last phase of the hook is where we will ask the user to do something in return. We do not just want to increase the odds that the user will make another pass through the hook. Besides encouraging the user to continue (unlock a new level and get another badge!), we can ask the user for a rating of the app in the App Store or we can ask the user to share content of the app on social media (challenge a friend!).

If we apply the model to another well-known game, Pokémon Go!, then the model will look like this: The user gets a notification and a pokemon is shown on the screen (Trigger). The user is bored or is looking for fun and wants to play (Action). The user is rewarded with a (special) Pokemon (Variable reward) and continues to play or is asked to share the recent achievement (Investment).

You can apply the model to your app too. What can or will be the addictive features of your app? What can you do to make your users return to your app more frequently? Not only can the process help your app grow, it will also increase the (perceived) value of your company—an investor will be more interested in the number of monthly active users (MAU) than in the number of users alone.

To accomplish this, you need to build an app that people really want to use. To find out what people want, you can ask them what they need. That sounds easier than it actually is. Make sure you ask the right questions, and avoid getting only socially desired answers. Also, make sure you listen carefully to what they tell you. Bear in mind that, sometimes, they will have no clue what they want, until they see it. Here's an example of a survey.

When we started to interact with real prospective users, one of the questions that we asked them were as follows:

"Do you like the app?"

Invariably, the answer would be polite:

"Yeah, it's a really cool idea."

"Wow, this karaoke idea is neat."

Initially, we didn't listen hard enough to comments from users:

"You don't have the songs or lessons that I want."

"My teacher's songs aren't on your app."

"How will this help me find a teacher?"

"Who will review my recording?"

If we'd only listened a little harder and asked the right questions, it would have become obvious to us, sooner rather than later, that we were looking at a marketplace that connected students and teachers, with the app as a tool that enabled this. We eventually went down this route and built a platform with several world-famous musicians and teachers. But we would have saved time and resources early on if we'd asked the right questions from the start.

In this chapter, we have seen that it is important that users become aware of your app. It would be even better if they get hooked to it, hence the introduction to the Hook Model that you have read about. Finally, we have learned how the Lean Startup methodology can help to make better apps.

In the following chapters, we will see what tools and methodologies you can use to shorten the development cycles, and how to reduce waste. In the next chapter, we will look at the business canvas model, where we can outline our assumptions for each element of our business. It can help us to determine our business ideas without the need to write a 100-page business plan that nobody is ever going to read. That sounds like you are going to save time already. How cool is that?