RESEARCH SYNTHESIS

Lean_Mobile_App_Development_----_Chapter_3_Challenges_in_Applying_Lean_to_Building_Mobile_Apps.pdf

Home >Business & Finance homework help >Operations Management homework help >RESEARCH SYNTHESIS

3 Challenges in Applying Lean to

Building Mobile Apps In the last chapter, we covered a few core principles of the Lean startup. We discussed the business model canvas, agile development, customer development, and the MVP.

In this chapter, we'll delve into the underlying premise behind this book and explore some of the biggest challenges you will face as a Lean app developer. While there are a number of books about Lean in general, applying Lean to building mobile apps is relatively new territory. Next, we will introduce some of these core challenges, many of which will be revisited in detail later on in the book:

The higher design bar that app developers face when developing mobile apps as opposed to web apps App Store submission cycles, which create delays between your completed iterations and the time they are made available to the public The challenges posed by developing multiple platforms Difficulties presented to early testers, and how that makes it difficult to grow an early user base App ratings, which have a direct impact on your ability to grow your user base and run certain types of experiments

Let's dive into a few of the main challenges and see why they are significant for a developer seeking to apply experimentation.

Drongelen, Mike van, et al. Lean Mobile App Development, Packt Publishing, Limited, 2017. ProQuest Ebook Central, http://ebookcentral.proquest.com/lib/harrisburg-ebooks/detail.action?docID=5165112. Created from harrisburg-ebooks on 2020-12-01 07:18:26.

C op

yr ig

ht ©

2 01

7. P

ac kt

P ub

lis hi

ng , L

im ite

d. A

ll rig

ht s

re se

rv ed

Challenges in Applying Lean to Building Mobile Apps Chapter 3

[ 31 ]

Higher design bar From the humdrum of the mid-2000s web apps, Apple radically changed the mobile world with the iPhone, offering well-designed apps of their own and curating apps that were accepted into the App Store. Thanks to Apple's higher standards for design, consumers began expecting intuitive, well-designed apps. That influence has been far reaching, prompting Google to push their boundaries and develop material design, a design language that has become the distinctive hallmark of Android apps.

Compared to the web world where some popular apps could get away with mediocre design, mobile apps face a higher design bar.

A Lean developer is trying to validate an initial concept with a simple experiment. However, the underlying value of the app can be clouded by poor design and experience, resulting in false negatives.

On the other hand, fear of false negatives can lead the developer down the path of adding far more polish than necessary in order to test out their hypothesis.

As we will caution later, it is important to avoid analysis paralysis and early onset perfectionism. The goal is finding a sweet spot between a poorly-designed prototype, which could interfere with testing and data, and an over-polished app, which could cost you time and money.

Apple's App Store submission cycles Apple's App Store review process-which is more strict than Google Play's-can cause major delays between the time an app iteration is ready for release and the time it actually goes live. This lag creates headaches that makes timing difficult and extends the time it takes to learn from your customers.

With web apps, developers have the luxury of being able to push an experiment over coffee at breakfast and then roll that back by the time they get into work. A range of tools that power continuous integration and continuous deployment enable significant agility in the web arena.

However, mobile app developers have often waited for weeks, and, at times, months in order to see their apps listed in the App Store. Apple's draconian review processes have left developers feeling like they would be better off talking to a wall.

C op

yr ig

ht ©

2 01

7. P

ac kt

P ub

lis hi

ng , L

im ite

d. A

ll rig

ht s

re se

rv ed

Challenges in Applying Lean to Building Mobile Apps Chapter 3

[ 32 ]

During the early days of the App Store, companies fell over each other trying to build relationships with Apple to ensure that their submissions went through smoothly. I remember app submissions that took months, requiring several email exchanges between our team and the category leader at Apple:

Fortunately, times have changed, and today Apple is committed to prompt reviews.

However, when in doubt, check out www.appreviewtimes.com to see the average app store review times for the iOS and Mac App Stores. At the time of writing this book, the review times were in days, but that changes quickly around holidays and important Apple announcements.

App Store submission cycles must be taken into account by Lean developers, who focus on shortening the time it takes to complete a cycle of the Build-Measure-Learn loop. Progress can quickly grind to a halt when you are left waiting with uncertainty about when you can actually start testing with your users. The unpredictable nature of the App Store makes it hard to run an agile cycle with rhythm and velocity, and rapidly run through a closed loop with your customers.

C op

yr ig

ht ©

2 01

7. P

ac kt

P ub

lis hi

ng , L

im ite

d. A

ll rig

ht s

re se

rv ed

http://www.appreviewtimes.com

Challenges in Applying Lean to Building Mobile Apps Chapter 3

[ 33 ]

Inability to dynamically load libraries Native app development tool chains only permit static linking of libraries. What this means is that there is no straightforward way to dynamically load library components into your app, the way that a web developer may choose to pull different JavaScript modules over the web on the fly.

In the case of iOS, there are a few tricks through which libraries can be loaded. The default iOS Xcode settings don't permit you to create a dynamic library, but that can be worked around by copying over the MacOS settings. However, while this can be tested out locally, roadblocks appear during code signing, and the kernel kills app libraries that are not signed by Apple with the same certificate. That said, since the app review process bars dynamic loading, it's unlikely to make it through their checklist.

Workarounds such as this-or others that can be found online-can be tried and tested to see if they will make it through the submission process. However, in the event that they don't succeed, it may pay to develop a static-loading strategy for your app:

In case of Android, there are similar tricks through which a Dex file may be loaded, extracted, and invoked. This is because the Dalvik VM permits some levels of custom class loading from alternate locations such as local storage or a remote network. However, this is not suitable for all apps and has a fair bit of complexity when it comes to properly dealing with all scenarios.

Whereas a web developer can easily flip a switch and change the components rendering on his dashboard, the app developer needs to perform a juggling act. If he would rather focus on the core problem of his app, he would need to push a new app build to the marketplaces and then wait for users to download the new version.

In real-world terms, this could translate into anything from weeks to months before an experiment starts to hit the target user base. Though such delays could be very problematic, in the later chapters we will discuss workflows and techniques that can help you workaround technical roadblocks such as these.

C op

yr ig

ht ©

2 01

7. P

ac kt

P ub

lis hi

ng , L

im ite

d. A

ll rig

ht s

re se

rv ed

Challenges in Applying Lean to Building Mobile Apps Chapter 3

[ 34 ]

Cross-platform releases If you are launching a new app, having to choose between iOS and Android quickly becomes an early decision point. If you are bootstrapped, you will likely end up choosing one or the other. While hybrid solutions exist, they can end up compromising some experiential aspects. We will cover hybrid versus native issues in Chapter 9, Native, Hybrid, or Cross-Platform.

Web developers about a decade back faced, in certain ways, similar issues with the browser wars. Building for IE, Mozilla, and Opera felt like three completely different browsers at times. Developers launching a new product often had to play it safe and focus on just one popular primary platform to start with.

For mobile app developers, choosing just one platform to start with works for a number of utilitarian apps. However, many apps, such as messenger apps, involve interacting with others in your community. This quickly becomes difficult in an experimentation context since it requires others to be on the same platform. This also gets slightly tricky while recruiting users for testing, since you need to focus on users who are on the same platform that you are targeting.

Later in the book, we will explore the benefits and drawbacks of cross-platform apps versus native apps, then discuss techniques for choosing the right approach for your initial business.

Getting users to download an app As a web developer, getting someone to check out your app is as simple as dropping them a link and asking them to let you know what they think. You might even get onto a Skype call with them, get them to share their screen with you as they go through the app and observe their interactions.

A significant hurdle for mobile apps, on the other hand, is getting users to go to the store and download your app. You can send them the link, but they then have to follow it to the relevant store, go through the downloading process, and then access the app to test it out. And iOS makes the process even harder by requiring a password for you to be able to download the app.

C op

yr ig

ht ©

2 01

7. P

ac kt

P ub

lis hi

ng , L

im ite

d. A

ll rig

ht s

re se

rv ed

Challenges in Applying Lean to Building Mobile Apps Chapter 3

[ 35 ]

Irrespective of how you recruit users for your experiments, making the series of steps as seamless as possible is important. In Chapter 11, Onboarding and Registration, we will discuss how to streamline the onboarding and testing processes in order to reduce such friction, using services such as TestFlight, HockeyApp, and the PlayStore's Alpha/Beta channels:

These tools will help simplify this process, but it's still not quite as smooth if your target audience isn't tech-savvy. Targeting early adopters, which will also be discussed later in the book, is one way to help you find users whose need for your app can be enough to push them past the onboarding friction.

Maintaining app ratings If you've already got a significant user base on your app, you are likely pressured to maintain a 4+ rating on the app stores. App ratings determine the likelihood that your app may be featured prominently in listings and search results, which has a natural and direct correlation to your ability to expand your user base organically.

C op

yr ig

ht ©

2 01

7. P

ac kt

P ub

lis hi

ng , L

im ite

d. A

ll rig

ht s

re se

rv ed

Challenges in Applying Lean to Building Mobile Apps Chapter 3

[ 36 ]

For instance, at a company like Intuit, despite the fact that there are a number of experiments that run during tax season, the pressure to keep ratings above 4.0-download rates decreases significantly as ratings drop:

Running experiments, which are necessary to evolve your app, can have uncertain impacts on the ratings.

Healthy ratings and ongoing experimentation are both necessary when applying the Lean approach to app development. However, since reduced ratings negatively impact user acquisition, you will need to find a way to minimize such impacts. Finding a balance between potentially disruptive experimentation and good ratings is an ongoing challenge, especially as an app matures.

C op

yr ig

ht ©

2 01

7. P

ac kt

P ub

lis hi

ng , L

im ite

d. A

ll rig

ht s

re se

rv ed

Challenges in Applying Lean to Building Mobile Apps Chapter 3

[ 37 ]

In the early stages, moving fast and breaking things works well. However, for an established app with healthy ratings and a healthy user base, it can be difficult to rationalize experiments that could cut ratings. After all, lower ratings decreases the likelihood that your app will be featured or receive an editorial listing, both of which can massively increase exposure and downloads.

Justifying experiments to other team leads may be challenging, but it can also be necessary, even after an app is well established. After all, the more an app becomes successful, the more likely it is to gain competition. Later, we will discuss ways to run split tests that provide useful data without causing too much disruption.

Summary Applying Lean methods to mobile app development is not easy. There are certain unique challenges that get in the way of running a tight Build-Measure-Learn loop with customers and maximizing validated learning. In this chapter, we covered some of the biggest challenges, such as the ones presented by the platforms, the App Stores, and the users themselves.

In the next chapter, we will explore why you should take a pragmatic approach to app development, how to be pragmatic and structured at the same time, and we will look at a few real-world tools and techniques to help you stay focused and practical.

C op

yr ig

ht ©

2 01

7. P

ac kt

P ub

lis hi

ng , L

im ite

d. A

ll rig

ht s

re se

rv ed