Y Media Labs is a San Francisco based premiere digital mobile and web agency. Focused on creating the best human interactive experiences by leading with design and following through with a complete development expertise. Y Media Labs has strengths in finance, IoT, eCommerce, social, and healthcare technology. Some works include PayPal, Apple, Staples, L’Oreal, and several others.
We recently sat down with two mobile specialists from Y Media Labs to learn their perspective on release process. The interview below is with Venkat, QA Manager in the Delivery and Solutions Group and Harry Lee, VP of Business Development/Strategy.
Q: For a typical client, what is your release cadence and how often do you release?
When we’re developing a brand new app, depending on the scope, it can take anywhere from two or three months to one year to get to our first release. We operate in two-week sprint cycles both before and after that first release. Our releases are called “milestone” builds; those specific milestones are alpha, alpha2, beta, and finally app store release.
Once we have a build in the app store, again depending on the client and features, we push updates anywhere from once a month to every few months.
Q: When you release a build before the app store release, who receives those builds?
That depends on the client’s preference as to whether they’d prefer to keep testing completely in-house or if they’d like to utilize external testers. We do internal and partner with third-party companies who perform user testing based on demographics criteria we work with our clients to establish. Client’s like to get real feedback throughout the process as we lead them through our Agile approach with changing variable change iterations on the fly.
Q: Who signs off on each release?
QA is the keeper that signs off and says, “now all of the requirements have been met.” Once QA signs off, the release is then handed to the product owner/manager. The product owner is directly in touch with the client and may come back with questions or concerns about the release. Ultimately, he or she is the final person to make sure we are meeting the requirements. Fundamentally, we go through a series of checks internally before handing a client the finished result.
Q: What goals do you set for the release of the app?
- Build has to be 100% feature complete
- No crashes
- No functionality breakage
We also instrument analytics for every release. We work with clients to set goals around user acquisition and growth.
Q: What tools do you use today to aid with your releases, other than Apteligent?
We’ve built an internal tool for ad hoc distribution of our alpha, alpha2, and beta milestone builds. This tool allows us to share the build both internally with other employees and also with the client. For the builds themselves, we leverage Jenkins. Once the app is released, in addition to Apteligent, we look at the analytics provided by the respective app stores and figure out where any potential improve upon spots are. This saves us time and effort going back after a release is launched.
Do you leverage the staged rollout functionality on Google Play?
Not typically, but we have the experience and ability.
How has the App Store review process impacted your release process & cadence?
We need to plan our releases a bit more ahead of time for iOS because of Apple’s approval process. We always leave at least an additional week to account for it to make sure we hit the client’s requested release date. Also, while we have Apple’s requirements memorized, it is constantly changing and we focus on keeping apps ahead of requirements pace.
Do you ever launch in non-US, English speaking markets (i.e., Canada, Australia, etc.) to test the app before you launch it in the US?
We’ve typically done language-specific launches of course, but we typically try to do it all at once. We have worked with clients to launch in specific, smaller countries but it doesn’t happen too much. When we receive a request like that, it’s usually a retail brand.
When you launch in a new geographic region, what steps do you take to prepare?
Most of our clients are based in the US and are large enterprises with a global presence, so we need to account for language localization. Bandwidth limitations in certain countries isn’t a common concern — but a handful of our clients do pay attention to it. One neat capability of ours is that we can build apps that use demographic profile settings so the same app can change depending on your region.
What metrics do you look at immediately post-launch?
We track many metrics including: downloads, users using the app, crashes, user engagement by screen, as well as any client-specific metrics we’ve established.
Do you restrict the launch on legacy devices?
We obviously cannot support all hardware and software configurations. We have an agreement with the client that specifies how far back we’ll go in terms of support. For example, on Android there are thousands of devices, so it’s not possible to check each one. In that sense, we agree on which operating system versions and device classes the app will support. In terms of Android device class support, we at minimum support Nexus and Samsung, and then we work with the client to make informed decisions about broader device support.
In addition to best practices for developing an app, what are other aspects of release management do your customers find important?
We actually have a team of designers that specialize in creating app store landing pages. Part of our service includes a set of recommendations to the client, and most of the time, they accept those recommendations. In some cases, the clients will take care of landing pages themselves.
A few years ago, everyone was new to mobile. Now everyone is trying to get smarter and make the next generation of apps more useful. To this end, we’ve expanded our services to include growth hacking as well as A/B testing to continue to drive growth and optimization of our clients’ mobile apps.