LinkedIn behind the scenes: How multiple apps evolved into a mobile platform for your work life

When LinkedIn decided to prioritize mobile development, it didn’t just double down on apps, it went all-in. The company-wide initiative, dubbed Mobilize, included a new multi-app strategy, the creation of platform-ready infrastructure and mobile product training for both engineers and non-engineers.

After years of laying the groundwork, those efforts are beginning to pay off. LinkedIn now sees over 40 percent of traffic come from mobile devices, and the company expects to pass the 50 percent mark sometime this year.

For part two of our behind the scenes series, we sat down with Kiran Prasad, Senior Director of Engineering – Mobile, to discuss how LinkedIn approaches each of its apps.

This interview has been edited for clarity and length.

The 💜 of EU tech

The latest rumblings from the EU tech scene, a story from our wise ol' founder Boris, and some questionable AI art. It's free, every week, in your inbox. Sign up now!

TNW: What are the different parts that go into a multi-app strategy? What’s the overhead view of how you need to put it into place?

Prasad: There’s the product design and technology side of it. I’ll start on the tech side. The second you decide you have to have a multi-app strategy, the first thing you need to do is create APIs that all of your applications can access.

You now don’t just have the profile page or the profile view in the flagship application. It’s actually going to show up in the Recruiter application, the Contacts app [Ed. note: Contacts has since been replaced with Connected], and the Pulse app. Creating an API is step 1. That’s a process we’ve been calling Rest.li. We’ve been doing that for 2-3 years to prepare.

The other big thing is in addition to creating those APIs, you have to start figuring out what the core pieces of data are that you want available across all of these applications.  We call them Superblocks: companies, profiles, jobs, universities, groups, etc. They’re like the big nouns that you want to show up in all the different applications.

On the technology side, those first two tasks are just changing your architecture to have these API layers, to have these big clear blocks and know what they are.

Once you’ve figured that out, the next step is to build a mobile platform that people can build applications quickly and easily on. That’s what we call our Mobilize platform. It’s a mobile SDK that we have internal to the company.

You don’t want everybody to build authentication, tracking, logging, crash analytics or a cross-linking library. There’s this suite of libraries and tools that we build in order for you to build an application quickly, with Rest.li and Superblocks allowing you to get to the data that you want to build that app.

The next natural thing on the technology side is: how do you release these? What’s the release model?

In the Web, server-side-driven world, you can release whenever you want. In the mobile driven world, you have to figure out how often you’re going to release. It harkens back to the shrink-wrapped software days of golden master CDs.

So we’ve created something called the Train Model. We’ve actually borrowed heavily from the way Google Chrome does its release models. We pre-pick the dates for the apps that are going to release for the entire year at the beginning of the year. We actually know literally down to the day that each build is going to go to the App Store.

What we do is we build all of our functionality in a way where any part of it, any new feature, can be turned on or off. We submit it to the App Store, and then what we do is we turn on features and see what it does: how it impacts our product metrics, whether it causes any more crashes, customer feedback, all of that. We can turn it off if we want to.

The whole point of the train, though, is on that date, no matter what stage your code is at – good enough, not good enough; fully featured, not fully featured, whatever – it’s going out in that build. The train’s leaving on time.

The benefit of that model is that you get this very good rhythmic ability to release on the technology side, which actually has a huge benefit on the PR side and the marketing side, which is that they can plan around a fixed release model. It helps us on an execution side for revenue, our ability to predict and project is much more structured into these monthly cycles.

That’s the hardest shift. It’s not deploy when you want; it’s going to deploy this date, get in or out. The biggest conflict this creates, which I think is the hard part where the tooling and the technology really help, is everybody wants to be on the train right when it’s going out the door. So the natural tendency is everybody checks a bunch of stuff in right before the train leaves, and it can break the train.

That’s why we have Lix, our experimentation and A/B testing and ramping framework. It allows us on the server side to control turning on or off these features or these sets of functionalities, so it’s okay that everybody’s dumping stuff in because when it goes out, nothing’s on, everything’s off. We can turn on parts of it to specific demographics.

With this ability to target countries, languages, and internal demographics such as job seekers, we can see what the impact is. If it’s good we can ramp it up to everybody and if it’s bad we can easily turn it off and it had no real impact to the majority of users.

So let’s say an update goes live in the app store, is it the first few days that you’re turning things on, or is it continual experimentation?

It’s continual experimentation. The releases happen on that monthly cycle, we turn on and off things continually to gauge the benefit of that feature for the member and LinkedIn, and to check the quality.

The one thing that is different, which is very interesting from a mobile development standpoint, is that even for each of the applications, we have to put them each on a train model. They don’t all have to ship on the same date, but each app has to have a defined release date and a cadence. Shifting an organization into that model from a Web model is pretty big.

The other thing that this brings up is, because there are 12 releases, whatever the UI variations that you want to do – if you want to test whether the person goes to screen A or screen B – they have to all be implemented in each of those releases. The total number of tests you can run is actually significantly lower than before. Where before on the Web you could do hundreds and hundreds of tests, you’re now talking like 20-40 tests per app per year. Your ability to be a good product and engineering leader to make choices of what’s the right thing to put in becomes way more important for these applications.

We can’t really use Lean Startup’s fail fast, fail often mantra. That worked in a model where you can release a lot of the time. When you only have twelve releases, you have to be better about making your choices. It’s definitely a slightly different model.

When you move to a multi-app strategy, you can’t just throw everything out there. As product teams and managers, how do you think through when a new app is justified?

The way we look at it is actually completely use case dependent. I think one thing that people tend to lean towards is, “Oh, maybe we should do it based on how large we think the addressable market is for that app.” You can actually start to think of them as like little businesses. They have to solve all the same problems that a large company has to solve. They have to figure out growth (how do I get people to download the application), they have to figure out engagement (if that’s important to them, and I’ll explain why it might not be important to them) and they have to figure out monetization.

You almost want to evaluate whether that app can solve those three problems. Just like when you’re looking at a new startup as a VC in terms of funding, you want to evaluate: how big is the total market, how fast do I think it can grow, what does its traction look like and what is its revenue model. You use that and then you make an evaluation of whether or not that makes sense.

I’ll explain why I say engagement isn’t necessarily the most important thing because it depends on the application. Take the Recruiter app we launched. It’s probably not an app that hundreds of millions of people are going to use because there are only so many recruiters in the world. But, it has huge revenue potential for us. It’s a use case that’s very clear.

People definitely are going to use it, but it’s maybe a much smaller pool of people. Growth is actually very clear because our sales organization which sells the recruiter products has a way to get them to get the application. We know that growth can be solved, we know it has a huge revenue potential, engagement’s not a big deal, that’s a good app to build.

You take something like Pulse. We have to solve the growth problem. How do we get a ton of LinkedIn users over to the Pulse application? We know engagement can be phenomenal because news reading applications have really high engagement. People love reading articles, reading news.

And then we have to figure out a monetization strategy. This is where we’ve done the sponsored content in the stream. We’re looking at things like that, making sure that we have a revenue model. That doesn’t mean you have to turn on the ads right away, it’s very much like every other startup.

You have to figure out when the right time is. What we do is we look at use cases for our members almost like verticals.  Then we try to say, “Is that a use case that can be big enough to be a good business under the guise of growth, engagement and monetization?” If it can, then that’s an investment we’re willing to make.

Do the teams have a startup feel to them?  Does it enable LinkedIn to be nimble and have that entrepreneurial energy?

This is another evolution that I think we went through, which is we were a central mobile team where we built everything that is mobile, and then we said, “We’re going to mobilize the entire organization and everybody’s going to be checking into the primary flagship app.” As we trained everybody and enabled tools, we started checking and thought, “Wow, our ability to release becomes much, much harder. We have 200-300 people checking in into a very small code base.”

By creating these multiple applications, one of the huge benefits you get is you have these smaller teams, 30-50 people teams, that can work on a full app.

That gives some autonomy, so you have these independent groups that are able to grow and evolve and develop at a rate. You don’t want them to develop divergently. You want them all to depend on a LinkedIn login, a LinkedIn profile, or LinkedIn news. So that’s why Rest.li and Superblocks, which I talked about earlier, are so important.

You don’t want them to feel like apps from separate companies, want them to feel like a suite, that they work together adjacent to each other.

I was trying to think of a good metaphor for this. The best way to think about it is actually an operating system. If you think about OS X, Apple does a phenomenal job of this. Google does as well, so does Microsoft. Any major large corporation over time moves into this model.

You have the OS and all of the services that it provides, then you have the iLife suite of applications, which are each independent applications, but they all work with each other. If you’re in iMovie and you want to add a song to your movie, iTunes stuff shows up. You also have global services, things like Spotlight, that let you search across all your applications and data.

In that same metaphor, you can start to think of LinkedIn as a place where we’re going to provide a professional suite of applications. We will also provide OS level services like search and notifications that are going to work across all of the applications at the system level.

So we’re starting to think about it as an operating system with little independent units that are trying to solve their own business needs, but there are services the platform is trying to provide for them. That’s probably the best metaphor of how we’re looking at our multi-app strategy.

I actually think this is somewhat different from the way Facebook is approaching [mobile] right now in the sense that you have Instagram and Facebook and they’re generally independent of each other. It’s not the same feed, stream, or data. They’re just very different apps.

We try to make [our apps] more complementary to each other. Other companies that do this really well are Microsoft, with the Office suite, or Google, with Gmail, Calendar, Search and Maps. They’re clear in their use case and then they cross launch within each other to provide value.

Do you have someone leading the visual design and aesthetics across the different apps?

Yeah. Steve Johnson is our design lead, he runs all of the design at LinkedIn. Me, him and our product counterpart, we all work together specifically trying to make sure that the visual aspects the same. A metaphor we use is, if you’ve ever seen the Pixar movie The Incredibles, you see that each member of the family all has different super powers, but when they’re all wearing their Incredibles suits, they’re all one family.

That’s what we’re trying to strive towards. If you look at any app, it should have its own super power, but if you step back and look at them as a whole, they should all look like “Oh, those are all LinkedIn.” That’s how we’re trying to attack it.

So you set the direction from the top and communicate it to the teams?

Yeah, they’re able to really create the user experience that’s appropriate to them in terms of the interaction. We do reviews to make sure that it still feels like part of the family, but we really give them autonomy to do what’s right for the user.

For instance, what are the four tabs if you’re doing tabs at the bottom? Do you even need tabs at the bottom? What does the profile look like for this app?

Do you view a multi-app strategy as essential to platform-level companies?

Moving from being a Web-based company to a mobile company requires the movement to multi-app because applications are implicitly very specific use cases. This happened even before the first iPhone; I used to work at Palm.

If you look at the desktop, you have Outlook. Outlook has mail, contacts, calendars, notes and tasks, all in one application. If you look at any phone operating system, even from way back when, those have always been split up into specific cases because you’re interacting in these short two-minute windows of interaction. Any company, whether you’re talking about Salesforce, Walmart, whatever you want to talk about, the theory that you can do it all in one app is not going to scale over time. You have to create these brand silos that people can use to be able to interact with stuff.

Just the fact that you start separating those capabilities means that you have to go to a multi-app strategy on mobile for any company that wants to take more than one value proposition and present it to the user.

Foursquare is another example. They believe they have two value propositions. And they’re like, “We have to split because there’s no other solution.”

How will your mobile approach continue to evolve?

One thing you’re going to start seeing us move toward in addition to the multi-app strategy, which is focused around providing very use case specific applications, is a focus on a shift from intent to inference.

Right now, in order for you to remember to use LinkedIn, you have to think about it 10 minutes before our meeting, take out your phone, launch the LinkedIn app, type in my name and then hopefully you see me and learn a little bit about me before we meet.

What we really want to do is know that that’s on your calendar, know that you’re about to meet them as you’re driving to the meeting, be able to beep you and tell you, “This is what you need to know about this person.” [Ed. note: LinkedIn is starting to pursue this kind of predictive functionality with its new Connected app.]

The big difference is we’re removing your intent to have to remember to go find one of these use cases in these specific applications. We’ll be able to take the data we have about you and tell you when it’s useful for you.

Let’s say you went onto Yahoo’s campus. Who are the people that you know in your contacts that work at Yahoo and are there? Maybe our apps would give you a chance to reach out to them by beeping you and saying, “Hey, these two people changed jobs two months ago. You haven’t talked to them in a while, you happen to be on the campus, they’re here too, maybe you should reach out to them.”

So we want to give you these useful pieces of short information to help you manage and maintain your relationships. It’s sort of Google Now for your relationships.

Over time, it’s not immediate, but we believe that mobile will eventually evolve from use cases where you have to constantly do things to use cases where these applications will tell you useful information when it’s necessary.

If you look at any of the stuff we’ve talked about at LinkedIn, we talk a lot about data, about how our data is so important to us and we believe it’s so important because in a mobile world with a small scree and multiple apps, the only way to get your attention and engagement – to provide value to you – is if we can mine all that data and get useful information at just the right time.

If you don’t have enough data, we will give you non-useful information at not the right time, which is just annoying and you’ll delete us. How much data you have, the whole connection to the big data world, how does it actually impact LinkedIn and how is that related to mobile, there’s a really strong tie for us.

We’re headed to where personalization, relevancy, big data and analytics all lead to a successful mobile product. If you don’t solve those sides of it you eventually will be lost in all the apps installed on your phone.

You need to come out from the noise at just the right time. The personalization relevancy threshold is way higher on mobile. The data’s the only way we can make you more productive and successful.

Part three of our behind the scenes series will examine LinkedIn’s publishing efforts.

Read next: LinkedIn behind the scenes: How open source software can transform a company – and the world

Image credit: Karen Bleier / AFP / Getty Images, Disney