Building and deploying a mobile app is just one step in a mobility strategy. To really unlock the potential of mobility in a business context, it is likely that multiple apps will play a role, including some that are created and fade away quickly and others that are pored over and incrementally improved over a number of years.
In other words, to really succeed in gaining lasting business value from mobile apps, you must master the end-to-end lifecycle of imagining, designing, building, and perfecting various types of applications.
Xtreme Labs, headquartered in Toronto, with offices in Palo Alto, CA and New York, was present when many of today’s smartphones and mobile apps were created. Since day one of the iPhone, Xtreme Labs has been involved in creating mobile apps and has grown alongside the mobile market. The company now creates apps for virtually every platform.
In so doing, Xtreme Labs has worked with major brands worldwide and its leadership has come to understand and codify a process around what needs to be built, how to build it, and how to make it perform, while incrementally evolving it to achieve key goals.
In this interview, Dan Woods, CTO and Editor of CITO Research, talks to Xtreme Labs’ Farhan Thawar, lead engineer, and Imtiaz Jaffer, head of marketing, about their advice to enterprises looking to exploit mobility.
Dan Woods: How should people be addressing mobility? What’s the biggest mistake people make when they want to take advantage of mobility?
Farhan Thawar: I would say the biggest mistake is thinking short term, saying, “We need a mobile presence,” without having an end-to-end idea of what you’re trying to accomplish in mobile from a business perspective. They say, “We need an app.” They hire somebody from Craigslist, put an app in the App Store, and say, “We’re done. Check the box.”
Woods: What ends up happening when you do that?
Thawar: Once the box is checked, everybody thinks that mobile is a completed initiative, and nothing happens. No business goal is satisfied because you’ve got something out there that your customers will find and feel that you’re not listening to them or connecting with them. It’s actually negative.
Woods: How should people think about mobility?
Thawar: Mobile is not a short-term fad. The shift to mobile is permanent. People are moving to smartphones and they’re not coming back to their desktops; they’re moving to tablets and they’re not going back to their laptops. They’re spending more time on mobile devices, and they have more apps on their devices than on their laptops. One of the stats I’ve heard is that if you leave your cellphone at Starbucks, you’ll be back in 8 minutes. If you leave your wallet in Starbucks, you’ll be back in 43 minutes. The value people place on their mobile phone is evident in numbers like that.
Imtiaz Jaffer: This is the whole notion of “mobile first.” Customers are engaging with your brand for the first time on a mobile device, so you’ve got to get that right. You have to take advantage of that opportunity because otherwise you’re going to lose customer satisfaction that you’ve built up through other channels of communication. That’s what we encourage brands to think about: What are the customer interaction points with your brand through different devices, and do you understand what that data is telling you? What kinds of devices are hitting your site, and how do you need to optimize for those devices? You want to drive engagement across all those devices.
Woods: You have a three-stage process that you take people through when you work with them to achieve their goals. It involves strategy, which is what you should do, design engineering QA, which is how you should implement it, and performance, which involves ongoing monitoring analysis and incremental improvements. What happens at each of these stages?
The Discovery Stage
Thawar: The strategy stage, which we call discovery, is based on the idea that you have to start with the business goal in mind. What are you trying to achieve through mobile? Are you trying to defend your brand? As Imtiaz mentioned, if people are coming to your brand first, and they type in “Starbucks,” and there is a crappy Starbucks experience, that’s their first experience, and they’re going to feel like they’re not being treated correctly. So you have to really understand the business goal: Is it to defend your brand? Is it a new channel? Is it to help somebody because your service is location-aware and they need that service right now? That’s what we try to help them figure out.
Jaffer: Part of the strategy is defining a roadmap, understanding what that looks like in the short term, as well as having a longer-term vision. What do you need to address in your organization now to help you be better in the future? That includes strategic things like building the organization with the right talent and tactical things like having devices onsite that people can leverage for testing. Aside from these examples, there are many things you need to do to build a successful organization to attack mobile. We help companies understand what to do and how to put that in place.
Woods: I see. So Xtreme Labs is building an organizational capability in its customers that can help them understand what to do. In that context, it would also be a mistake to think of mobility as something you can completely outsource.
Jaffer: Yes. Part of our job is helping companies understand the steps they need to take if they want to build this capability internally. Many companies look at how Xtreme Labs builds products and then implement some of those best practices in their own organizations.
Thawar: Some companies, for instance, want to eventually own the whole lifecycle. That’s fine. They come to us to help them get there. Some companies will never, ever have engineering and QA, but they may have a product or they may have a design. It depends on the company and it depends on their goals.
Woods: What kinds of questions do you ask during the strategy phase to help customers understand what they need to do?
Thawar: It really depends on the business goal. Some folks are trying to create a new channel. They might say, “Our website is heavily trafficked by iPads, and we don’t have a great iPad experience. Actually, it’s a broken experience. How can we enable those users to interact with us?” Maybe it’s a retail experience. Maybe they want to be able to search for items and check out. It depends on what the client is trying to achieve. But it’s likely that they’re already seeing tons of mobile traffic on their website.
Woods: So one question is, “How can you make better use of mobile traffic?”
Jaffer: It’s all about the experience. What do you want the user to be able to accomplish on a mobile device, whether it’s searching and browsing for items, or being able to purchase a particular item? You need to get down to the nitty-gritty of what the user is expected to be able to do on his or her device.
Thawar: You don’t want to convert the desktop to mobile. We’re not saying if you can do 37 things on the website, you should be able to do them on your mobile device.” That’s the opposite of what saying. Instead, we look at key scenarios. If customers are waiting at the bus stop, are there things that you want them to be able to do very quickly on their phone? That’s much different from researching mortgage options on your desktop. You’re not going to do that while you’re waiting in line for coffee.
Woods: So there’s a process re-engineering aspect where you’re identifying the personality of a mobile scenario and enabling that. You have to determined -- and this is where you can help -- what is a mobile friendly-scenario and what is a mobile-friendly process for handling that scenario? And it’s a subset of what you’re already doing.
Thawar: If you think of it as a Venn diagram, with all the things you can do on a desktop on one side and all the things you can do on a mobile device on the other, the mobile device and the desktop do overlap, but the mobile device itself enables new things that you just couldn’t do on a website.
Woods: What are some examples of that?
Thawar: We worked with a company that allowed us to do mobile check-ins to TV shows. You hold up your phone or your tablet to the television and the app determines what TV show you’re watching and gives you loyalty points for watching it. You’d never do that by dragging your desktop over. It’s essentially “Shazam” for TV with a loyalty program slapped onto it.
Thawar: We work with a loyalty program in Canada where they wanted to have people check into a grocery store. If 15 people checked in, a few more items went on sale. With mobile devices, you can use the context of location in ways you never could with a desktop experience.
Jaffer: I’ll give Uber as the example there. While we didn’t build, it, Uber is a mobile-only scenario; it doesn’t work on the desktop.
Thawar: It very rarely makes sense that you need it from a desktop.
Woods: So some of the mobile functions are a subset of desktop functions, and some are a superset.
Thawar: Right. The Venn diagram shows intersecting circles, where some scenarios overlap, but some are brand new. The whole idea behind discovery is around helping customers build a clear business case for mobile.
We sometimes create the business case for customers to go sell up the chain. We also want to move a little beyond just creating a document, so we may give them wireframes and mockups that provide a good idea of the experience. We’ll put it the mockups on a device that they are targeting, such as an iPhone. Then they can show people and actually test it with them. They can say, “Do you think you would use this application?”
Then they can make a prioritized list of what they want to build. Everyone who comes from the desktop world has the idea that “more is better.” But we say, “These are some key mobile scenarios. What’s important to you? Rank them, because once you start building something, you may realize that you need only two or three key features. You don’t need 37.”
Woods: Do you develop metrics that you expect to achieve? Is that part of the deliverables?
Thawar: Typically the client is expecting some sort of channel engagement, and they might create a metric targeting a percentage of revenue coming from mobile. They might want mobile website users to move to the app instead or at least target a percentage of their traffic moving to the apps.
Jaffer: The brands track things like number of downloads and installs, repeat usage, pages viewed, user reviews and scores, and the like in order to measure ROI. We help them set up a framework to understand what they can track and help them determine which are important to them. You then look at how the metrics relate to your goals.
Thawar: Some things are easy to track, like sharing. If you’ve got an application that has a social media component, whether it’s sharing on Facebook or Twitter or checking in on Foursquare, that is easy to gauge in terms of analytics.
The Product Stage
Woods: The second stage is the Product stage, where you complete the design, do the engineering, and build the app. What's the challenge in this phase?
Thawar: This is typically the phase that people do on their own and fail. Without doing the first part, the “what,” they then only do the “how” and forget about the next part, the tracking. So in the product stage, we focus on design, such as detail design and high-fidelity mockups that show exactly what the app is going to look like. We work with your designers and your brand to make sure it’s true to your vision.
Woods: Do you use things like iRise or other simulation environments?
Thawar: There are some tools that we use for design, such as Notable and Envision, which are apps that allow you to create mockups that you can click through. Click on the button in the corner, and it takes you to a different experience. It allows you to see the design on the device itself, not just a mockup on your screen or a printout.
You look at it on device, go through it and say, “This looks and feels like my brand, but it is uniquely a mobile experience;” be it iPhone, Android or whatever. The step after design engineering. All these steps are iterative, so they change.
We not only design iteratively, but we build iteratively. So let’s say we have a 13 week engagement with you. We’re going to build an application and deliver it to you every single week. If it’s an iPhone application, you’ll install it on your device, play with it, and give us feedback. Then we modify based on that.
Woods: So it’s truly an agile process.
Thawar: Truly agile. It could be a modification of functionality.
Woods: So the first week you just get the sign-on.
Thawar: Typically you wouldn’t get the sign-on because we like to work on the riskiest, craziest features first. Sign-on’s not going to differentiate you.
Woods: So what would you deliver first?
Thawar: Some A-list feature like the landing page, or “Here’s our whiz-bang tutorial,” or something like that.
Woods: So that first piece of functionality works and the rest of it is simulated?
Thawar: The rest of it is typically just framed out, just “scaffolding,” as we call it. There’s no log in, and it’s all dummy data. Because we focus on agile, we want to do the most important scenarios first, creating a really rich experience for the main components of the application and leaving the sign-in until last.
Woods: When you’re building, how often do you do native app development? How often do you use platforms like EachScape, where you can build and configure an app that can be deployed on two or three platforms? What is your opinion about those things?
Thawar: Our opinion, typically, has been that the best experiences tend to be deep, rich, native experiences. That being said, we never turn a blind eye to something by making a generic statement, across the board. We work with our clients to figure out what the scenarios are, what’s important to them in terms of performance, UI flexibility, and other issues, access to sensors, and then make the best-fit solution. Most of the time, it turns out to be native.
That being said, we have great immersive HTML5 experiences, and we’ve worked on some hybrid experiences. However, in most scenarios, it turns out to be native.
We typically talk to the client and say, “Since we’re going to be doing this multi-platform,” meaning iOS, Android, maybe Windows Phone and Blackberry, “these components could be done in HTML5, so let’s do a quick prototype." We do maybe a four-, six-, or eight-week prototype in HTML5, show them what the performance and UI looks like, and make a decision whether to continue.
In every case where we’ve done that, the answer has been, “No, we don’t like this experience. We want to go back to native.” This decision is always the result of a test, versus a blanket statement from us saying, “Let’s go native.” After most tests we do end up native, but we do test it every single time. And it’s probably the number one question we are asked.
Woods: Is there anything else that happens in the product phase?
Thawar: Yes, the product phase also includes QA and beta testing, before the product gets launched.
The Performance Phase
Woods: What happens in the performance phase?
Thawar: In the performance phase, once the application is launched, we have a robust system in place that lets us track, analyze and feed all that information back into the cycle, because it’s not about launching, checking a box, and saying, “We’re mobile! See you later, we now have a brand that’s mobile and we’re discoverable by our users,” and that’s the end-all.
It really is a lifecycle. You’ve launched it, you’re now in the app store, let’s say in Google Play, you’re getting reviews and ratings, and your customers are using your application. What parts of your application are they using the most? Are they having problems in parts of the application? Are they confused? Are there pieces that we’ve worked on, that we spent time on that no one’s ever accessing because it’s hidden or they don’t really care about that part of the application?
All that has to feedback into development.
Don’t forget about all the sharing, the tweets, the app review store ratings that come back, that say, “Oh, it’s one star because we had a horrible server experience,” or “I wasn’t able to check out because the tax was calculated incorrectly.” And they’re tweeting about it, probably, saying, “I hate this app because I wasn’t able to do it,” or “I love this app. I really love this feature,” and everyone’s talking about it.
That whole lifecycle has to feed back into the application, which is why most of our clients are actually multi-year clients. Even though we’re a five-year old company, some of our clients are four-year old clients because we’ve been working with them for so long.
Jaffer: I think another consideration is the distribution. Just putting an app in the app store is not enough for a lot of these brands; it’s about having a robust distribution strategy that is going to drive people to download it. Just putting it in the app store doesn’t mean that people are going to download it.
You want to make sure that you’re in the top ten rated apps in your category, for example, making sure that you’re advertising, promoting it through social media, and so on. There’s a whole distribution strategy to be consider. That has to happen in advance of launching the product.
Jaffer: There’s a timing aspect as well. We have really good relationships with the OEMs, so we are able to say, “Hey, if you’re going to feature it in the app store, we should synchronize that with these other marketing efforts so that we get the biggest bang for the buck, versus featuring it a week later...”
Thawar: And this is also where you track the business metrics that you’ve set up at the beginning, and try to optimize to achieve those.
Jaffer: Right, is it number of downloads, is it sales through this channel, is it number of shares through social? It depends on the metrics.
Woods: I assume that what happens is that you build your first one, you build another one, then you build another one, until you sort of have this cycle where you have the older apps, the medium apps, and the newer apps, and then eventually you prune, and maybe you retire some of them?
Thawar: It depends. For some of our applications that are multi-year, we may retire the old app and put a new application in. We’re very big fans of updating apps often because once you’ve got an app on someone’s device, it’s almost like having a card in their wallet. You don’t want to lose the share of that wallet, you don’t want to lose that icon on their screen, and you might if they have to do something to get the new version.
It’s much better if it just sits on their home screen, their springboard, and they never know that it’s not in the app store anymore. If we update the app, they’ll get a little icon, and as we update it we can change the experience completely, but at least they’re getting that notification. We don’t have to tell them again.
Jaffer: I think the point I would add here is diversification. Look at publishers, for example. Let’s look at Forbes.com. You’ve got a tech section, you’ve got a news section, and so on. We’ve seen publishers diversify by having an app dedicated to each of those verticals. So they might have a lifestyle section in an app. That’s something to consider as well. So you have your core, flagship app and then you’ve got the diversified ones, which are relevant to specific pieces of content. That’s very relevant to publishing.
Thawar: Facebook’s a great example of this. You’ve got the Facebook flagship app; it does everything. But then you’ve got Messenger, you can do that in the regular app, but you can also just do messages in the Messenger app. You’ve got Camera, where you can do photos on the regular app, but you’ve got a specialized one just for Camera. What we’re seeing with our clients is these single-purpose or one- or two-feature apps, multiples of them, so that you can actually say, “Maybe we want to have an app that does everything, but for those who are power-users of one feature, let’s make a particular app just for that.” And then everybody can focus on a great experience.
Woods: So you provide a super simple way doing something in one click.
Thawar: Exactly. In one click. Like Facebook Camera. It’s just about pictures! Just take pictures with that.
Woods: Do you ever create APIs for your clients?
Thawar: All the time. For a lot of clients, the web experience doesn’t necessarily translate easily to the mobile experience, and that’s because the server infrastructure is not set up for mobile. One of our clients actually had a system set up and we were trying to build an iPad app for them. We’d get 4MB of data every time we hit the API. That’s not going to work for even a powerful device like the iPhone 5.
What you need is to actually send the 4MB of data that is relevant to the user at any point, versus sending them 4MB by default. We build lots of server infrastructure for our clients as part of our product suite. That server will interact with their mobile team, with our mobile client, and because they’re in our office, they’re all sitting right next to each other, you get that really rapid flow of information to enable those pieces of data to flow through.
Woods: So, what’s the most important thing for your clients?
Jaffer: I think one big thing is process. We pride ourselves on the way that we engage and collaborate with our clients. It’s a very involved process and we expect our clients to contribute and be part of the development process. So it’s not about saying, “Hey, okay, just go and build this app.” No. We need you to be here once a week, on the phone, using our software, and accepting and rejecting certain things.
Jaffer: You have to be collaborative. You have to be invested in the process beyond just contributing dollars to build the product. You’ve got to know the product inside-out, so that when you’re evangelizing internally, it’s easy to get buy-in.
Thawar: Yeah, so if you start working with Xtreme Labs, you may not know much about mobile before you start, but you’ll know everything about mobile after.