How do you grow your internal mobile app portfolio to 112 different apps over time? Paul Lanzi, the mobile apps team manager for Genetech/Roche, spoke at the 2012 Gartner Catalyst conference in San Diego and shared some of his tips and revelations. Roche is one of the world’s largest biotech companies with over 80,000 worldwide employees spread across 162 different countries with numerous drugs and other healthcare-related inventions to its credit.
Lanzi set out to make their knowledge workers the best mobile-equipped workforce in biotech. They have more than 13,000 iPads, 10,000 iPhones and 18,000 Blackberries at the moment. Half of their users have more than 55 apps, and some even have more than 300 apps on their devices. That is a lot to manage, to be sure.
So how did he get to 112 apps and counting? Here is his program.
— Know your intentions. His driving force was being able to execute his business process from end to end using a single app. That was a tall order, but they didn’t get to that situation easily. Indeed, their first app (a SalesForce.com add-on) took them close to eight months to develop all the various infrastructure pieces, including security, middleware gateways, authentication, and identity management. But once all this was in place, their second app took much less time. “Indeed, we were able to leverage 80% the non SalesForce-related web services that we built for the first app.”
— COTS are for sleeping on. Genetech used a number of commercial off-the-shelf (COTS) components, including their middleware solution, but for the most part developed their own code. “Don’t use COTS to sleep your way into your mobile strategy. The way you need to differentiate your apps is to pull the data together for your business in one app, and you can’t really do that with COTS.”
— Invest in your user experience design. There is a different between interface design and user experience, and make sure your developers know how to distinguish the two. Lanzi mentioned their early experience with their “On the Road” app that has been documented here as an example of what not to do.
— Foster inter-department code sharing. Lanzi spoke about “fostering” the coding that was already developed for his apps so that others in the organization could more readily build there own apps. “Fostering” to get other teams to think and develop mobile apps. “Even if I could scale my team to three times its current size, I still could not meet the demand of all the mobile apps that my users want me to build.” He put in place a series of common code libraries for his iOS native apps for functions such as jail break detection, identity management and authentication, and gave these out to all of their internal developers. They are working on common HTMLv5 libraries and other Web services too.
— Monitor constantly what your users are doing with your apps. “From the very first day you deploy your app you have to monitor what and how your users are doing with it, so you can make it better,” he said. “If you build in the monitoring, you can do it for close to zero additional dollars. And this isn’t a job to outsource to some intern. Don’t entrust the job of talking to your users to anyone other than yourself.” He isn’t talking about just seeing if the app is working, which you should do anyway, but what features are being used or not used. And some of these results are surprising: “We put in a few last minute features that are being used by everyone in the Peeps app.”
— Don’t forget about upgrades. “The day your mobile app goes out the door you will need to upgrade it. You have to come up with your own upgrade strategy, and the app has to know when it is time to upgrade itself.” Lanzi mentioned that some apps will require mandatory upgrades, because of business logic changes or regulatory reasons.
You may not have as many internally-developed apps in your app store as Genetech, but your apps will be better from following their principles. “We have no tolerance for bad apps around here,” said Lanzi, and I would agree with him.