By Kendrick Wang
By now, quite a few companies have adopted agile methodologies on the Web, but when it comes to mobile, teams are still struggling to apply the same techniques.
Apple, at its core, is a hardware company and their App Store methodology reflects that:
- New versions are shipped every 1-4 months
- Each update is subject to a 3-9 day app review process before release
- Every user gets the exact same version of the app
- Devs often scramble to fix bugs after a large release
- Users are expected to update on their own time
Sounds more akin to shipping boxed software than a modern-day SaaS product to me.
Apple’s model for launching their new iPhone, Macbook, or iPad each year with huge amounts of PR and pageantry are too far removed from what the industry has learned about Web products over the last decade, resulting in a huge step backwards for mobile development.
Although the majority of the industry is still learning to deal with the constraints, a few teams have still managed to flourish.
By refashioning agile techniques for the mobile apps landscape, companies like Lyft, Dropbox, and Yahoo! have been able to make smarter, data-driven decisions and adjust quickly to the volatile space. Here are some of the things they’ve learned:
1. Choose Iteration Over Perfection
“Smart people really like to over complicate the problem because you can see four steps ahead, so it’s very tempting to say like, ‘Oh let me go build that final version.’ But when you do that…you don’t get something that actually increases your users’ metrics,” says Waseem Daher, a PM at Dropbox.
The mobile team at Dropbox learned this the hard way when they built the first activity stream. After working on it for months, creating detailed specs, mockups, and prototypes, they presented it to the rest of the team…only to find that no one liked it.
Even though users had requested an activity stream, the prototype was built in isolation, shielded away from valuable user feedback.
If you’re aiming to move faster on mobile, you and your team have to accept that the goal is to learn and iterate your way to a product, rather than planning everything up front and expecting it to work.
Building the correct product for your users requires learning as much as you can from actual users and seeing how different changes to your product affect their behavior.
2. Experiment to Learn
It’s easy to fall into the trap of just copying best practices and patterns from around the Web, whether they be onboarding tutorials, tabbed menu bars, or empty states. However, simply adapting these best practices for your app means you could be making a lot of assumptions.
Figure 1: Don’t fall into the trap
Photo credit: Kendrick Wang. Licensed Under CC0 https://unsplash.com/photos/696Nn_zm-iA
“It’s not just good enough for somebody to come up and say ‘I have this perfect idea. It has to work,'” says Sergei Sorokin, a PM at Yahoo! Growth. “Every situation, every product, every user base, every app is different and what works for us does not necessarily work for you.“
That’s where testing and validation come in. Test a new change or feature, then measure how it affects user behavior. If it increases key metrics, keep it in. If it doesn’t, figure out why and apply those things learned to future iterations.
3. Get Comfortable Shipping Small, Frequent Changes
If you want to iterate and learn faster, you’ll have to become comfortable with small releases. Most teams don’t like to do small, bug-only fixes. But, small changes can go a long way to improving the overall UX.
Making small changes maximizes learning. Instead of deploying large releases every 3-4 months, you can isolate the effects of each release to correlate changes in user behavior to specific changes you made. This prevents confounding the reasons why your metrics increased or decreased.
Making small changes like this also helps you adapt to changes in the market quickly. If you’re Lyft or Uber, you have to constantly be releasing to keep up with changes regulation and demand, as well as the competition.
Lastly, releasing often helps improve overall code quality as Chuck Rossi, the Release Engineering Director at Facebook, has shared. But more on that in #4.
The problem with releasing often is obviously the app store review processes. They’re a huge blocker for continuous delivery. Even with these constraints, though, a few teams have figured out how to adapt.
4. Use Mobile Release Trains
Most apps do feature-based releases. That is, they release a new version based on when a big feature is completed and ready to be shipped. However, this often means that releases come every 12-18 weeks and release dates are not very predictable.
The problem with feature-based releases is the uncertainty of when the next release is going to go out. Any delay or hiccup can push an entire release back indefinitely.
No one wants to wait weeks or months to get their feature out to users. So, teams will often scramble to get all their features and updates in by the next release, even if they’re not yet perfect, says Rossi. This methodology places a focus on getting things shipped, but not getting things right.
Facebook, Lyft, Dropbox, and quite a few others have shifted to release train cycles instead, where their teams are constantly pushing code to the app stores every 1-2 weeks. Like a train, if features (passengers) aren’t ready to ship out, they’ll have to catch the next train.
This changes the focus from getting code out, to getting the user experience right.
“The less you release, the less confident you are as a company that whatever you’re pushing out to your users isn’t going to crash, and you’re not going to be able to fix a major bug that affects all your users”—David Dryjanski, Creator of Lyft Line.
5. Gradually Increase Release Speed
In early 2014, Facebook was still shipping once every 4 weeks. But by committing to change, they sped up that cadence to once every 2 weeks by October of that same year.
“[Feature flags] allow you to minimize risk when releasing a feature,” says David Dryjanski, the creator of Lyft Line.
This also allows teams to deploy code that may not be in a production ready state. By shipping it in an off state, teams can turn it on only for specific users and test it out.
7. MVP Your MVP
Releasing an update to your users is a time-consuming process, which makes validating ideas early on vital to save time and resources.
So, before you release your next feature to thousands (if not millions) of users in one fell sweep, use some of these techniques to gather as much data and feedback as possible:
- Storyboarding/Mockups: Validate your idea internally before building anything.
- Prototyping: Using prototypes to get a clearer picture of exactly how the changes would look and feel.
- User testing: User tests often offer invaluable qualitative feedback on a product. Running these tests early can save you a lot of pain later on.
- Beta testing: Using TestFlight, feature flags, or their equivalent can help you validate ideas on actual users, though it is important to note that these are the innovator/early adopter crowd.
- Field testing: Using conditional logic (release only to users with X attribute) or feature flags, some teams have been running field tests on small segments of their userbase. This allows them to get feedback from more average users, rather than the early adopter crowd. We’ve seen Facebook do this with multiple releases such as Timeline, Live Profile Pictures, or Uber doing this with their new upfront pricing.
8. iOS First, then Android
Even though a large majority of the world runs on Android, there’s still one key advantage of making changes on iOS first: There is a significantly smaller chance of introducing bugs or small problems due to hardware and operating system fragmentation.
This means that teams are much more likely to get accurate data from iOS experiments, instead of having to worry about supporting thousands of different instances.
This makes it easier to attribute differences in user behavior to specific changes you’ve made. Once you know the impact of changes, test them on Android to see if there are significant differences.
9. Methods to Identify Opportunities
Figure 4: Gain children’s attention
Photo credit: Kendrick Wang. Liscenced under CC0 http://finda.photo/image/11212
If you plan on continually improving your product, you should have a handful of methods in your pocket to identify opportunities.
One of the best ways to do so is by utilizing user tests. In an interview with Audrey Tsang, the director of product at HotelTonight, Tsang stressed how important these tools were to their constant improvement.
“It’s really important to building great customer experiences. Because if we build in a black box without getting any feedback, what pops out almost never hits the markets.”—Audrey Tsang.
This, combined with analytics, beta tests, surveys, and open communication with customers provided the team with many data points to help prioritize what they should work on.
10. Make It a Company Priority
Moving toward faster iteration cycles isn’t a simple process. It requires a shift in focus to adapt the methodologies to mobile. However, the benefits definitely outweigh the challenges.
Iterating quickly by using agile methodologies allows you to:
- Make data-driven decisions
- Adjust quickly to market changes
- Provide a better user experience
- Deliver changes frequently and predictably
- Focus on UX
- Improve quality
That’s why so many top companies have already adopted this cycle of release-train schedules. Rather than dropping large releases every 3-4 months, they’re constantly pushing out changes every few weeks to iterate their way to product success.
About the Author
Kendrick Wang is a product marketer at Apptimize. He writes about UX, onboarding, retention, and growth for mobile teams. Kendrick also works with teams to develop experiment roadmaps, helping businesses provide a better mobile experience.
Find him on Twitter at @kendrickwang.
This article was contributed for exclusive use on Developer.com. All rights reserved.