Outsourcing mobile dev - how to think about your app

How much does it cost to build an app? How long does it take to build an app? Well, it depends on several factors. Apps can be built for as little as a couple of thousand to dollars, or as much as hundreds of thousands of dollars. It all depends on what you want your app to accomplish. We have a created a framework to help you think through your app in some very concrete terms, which can help determine the cost and time to required to build the app.

Requirements v01 MA 9Mar2014.png

We look at this framework as the building blocks for an app. Like with any structure, building it requires setting a strong foundation. This requires having a good grasp of the platform(s) on which you'd like the app to be developed, knowing your localization and internationalization strategy, not leaving security to be an after thought, and having a good sense of which APIs - both internal and external - your app needs to integrate with. Once the foundation has been set you can move to building the core of your application. This involves having at least a feature level grasp of what your application will do. Finally, to maximize the value delivered by your app, you need to understand and implement your apps reporting & administrative needs and how you plan to support the app once it hits production. Let's take a closer look at each of these areas.

The Foundations:

Platform: Knowing which platforms your app needs to be built on is of paramount importance. The wrong decision here can mean the difference between a great app, and one that delivers extremely poor performance and generates little or even negative interest. Some of the key considerations here include:

  • iOS vs. Android vs. Others: This might seem like a pretty simple decision at first, but based on the demographic and region of the world you are targeting, going iOS first or Android first, is not a given. We were helping scope an app targeted towards the lower income market in the emerging world for which a simple text message based service made more sense than an extensive app. On the other hand for some apps to gain maximum virality you might have to go cross-platform from the get-go.
  • Native vs. mobile web - A few years ago HTML5 was all the rage. Today developers have begun to recognize the limitations of HTML5, and the pendulum has swung the other way. The right decision here though is not whats in vogue, but what makes sense for your app - perhaps the limitations of HTML5 are not an impediment for your app.
  • Develop native vs. using a mobile application development platform (MADP) - We will cover this top in a more in-depth manner in a future post, but at a minimum you need to know what the advantages of developing using a MADP platform vs. developing a native app are and why your development team is recommending one over the other. The comparison is usually made between the cost advantages of MADPs vs. the performance advantages of native, however in reality the comparison is rarely that straight forward.

Localization: This aspect of app development is usually not given much thought, and perhaps is as simple as starting off as an English-only app that needs to be deployed in the iTunes app store. However, what if you were an international airline carrier with passengers from all over the world? Suddenly, a seemingly simple decision requires at least some analysis to know which languages your apps needs to support and which countries app stores the app needs to be made available in.

Security: Like with localization, security is too often an after thought. Some very popular apps have taken security lightly and have seen it come back to bite them. Recently the Starbucks app, the most used mobile payments app in the US, was caught up in an embarrassing security breach when it was revealed that it was storing its customers' username, email address, and password in clear text on their mobile phone. Our recommendation is to not take security for granted from the get-go. Do not assume that your app developer will build your app to meet best practice security requirements. Be explicit about the security requirements you expect - particularly as it relates to encryption, authentication, and authentication information retrieval policies. You at least owe this much to your prospective users.

APIs: Today APIs are available for a variety of different popular external B2C applications in particular Facebook, Twitter, LinkedIn, etc., as well as B2B applications such as Salesforce. At a minimum, we recommend that project owners know which applications they need to access through their app and the feature(s) they expect to be able to provide to the end-user by enabling said access. "I'd like my application to connect to LinkedIn" is usually not very informative. "I'd like my application to connect to LinkedIn to be able to auto populate x, y, and z user profile fields" is a lot more useful.

The Core:

Features: Most of the better development teams today either completely or partially adhere to the agile development philosophy. In agile development, the primary unit of work at the team level moves away from a discussion of requirements to a discussion of user stories. These user stories are generally developed in conjunction with the development team and are too granular to invest too much time in up front. Our recommendation here is for you as the project owner to think one level up - at the level of features. 

Screen Shot 2014-03-09 at 3.54.39 PM.png

So what is the difference between a feature and a user story? Let's take the example of a recent that app we helped facilitate the development of that helps you find things to do based on your mood and your location. The ability to determine your location is a feature. However, your location can be determined based on your current coordinates, some future coordinates, or the neighborhood that you live or work in - each of these comprises a different user story. Knowing what can and cannot be done at the user-story level generally requires the guidance of the development team, and is best left to be determined in conjunction with the team.

The Accelerators:

Reporting: Why is reporting important? Shouldn't I be able to capture stats via the number of downloads and the rating that my app has received directly from the app store? That is correct, but that is not really enough information to determine what features within your app are being used, or in what conditions your app crashes, or how long it has been since a specific user has logged into your app, etc. Usually developing your app is just the first step towards attaining a greater goal, and it is impossible to predict whether or not you are making headway towards that greater goal without some deeper insight into how your users are using an app. We highly recommend thinking about what user activities and experiences you'd like to keep track of and accounting for those capabilities when developing your app. Again, like with security, don't take for granted that your development team has a good sense of what those capabilities need to be - it's your app, and you need to take ownership of it. These days, integrating reporting capabilities - even advanced ones - into your app usually doesn't require a ton of additional development effort, but it does require identifying and integrating with the right reporting tools made available by external providers (e.g., Flurry, App Annie, Google Analytics). Knowing which reporting tool to integrate with to deliver which capability is something you should defer to the development team on, but knowing which reporting capability is required in the first place is your responsibility as the project owner.

Admin: There are very few apps that require no administrative capabilities. Below are some common examples of admin capabilities that apps require:

  • Roles administration: Not all users are created equal. Some users might be considered super users and require special privileges associated to a role that they perform on your app - for example adding new stores or restaurants to a curated recommendation app. 
  • Content administration: Your app might be dealing with content submission from your users and you might want to feature or highlight certain pieces of content more than others. This might require content curation capabilities that need to be provided to you as a superuser, but not to every user.
  • Security administration: You might want to be able to change the security policies related to your app, for example the password strength requirements or how often passwords are set to expire. You might want to lock down certain users from your app until certain verification steps are complete. 

When working with an experienced development team, one of the first things they are likely to do is build user personas that are related to different user stories. This should help define the specific actions that you'd like different types of users, including admin users, to be able to perform. However, at a minimum we suggest giving some though to what constitutes an admin user and what features the admin user should be able to control.

Support: Apps don't upgrade themselves, and just because an app works close to perfectly in the beginning, it doesn't mean it will continue to do so into eternity. Apps can break for a variety of reasons ranging from OS upgrades, to API changes, to experiencing a heavier load than they have been tested against. All of these problems can generally be fixed, but not if you don't have the right support mechanism in place to help you. Most teams that develop an app might give you a 2-week or one month warranty window where they will support the app for break-fix type issues, but often you might need support for a longer than a month on app. Additionally, it is critical to know the different between break-fix and a new change. Adding a new capability to an app is not a break-fix issue, in technical terms it is considered a change request, and - depending on the complexity of the app - a change request can be more complex and expensive than developing the app itself. 

In summary, there are lots of things to consider when you go down the path of developing an app. Maybe your app is a use and discard marketing app for which many of the above considerations are an overkill, but even if that is the case it makes more sense to start with a more holistic framework like this and eliminate what you don't need, vs. start something bare and then realize two months into the project that there were several aspects of the app that had not been thought through. Spending and extra week or two researching some of the capabilities that your app needs to support is not a waste of time when you consider that not having those capabilities can easily cost you an extra couple of months or, in the worst case, your reputation.

The "digitalization" of the enterprise & why traditional sourcing fails

A few weeks ago Gartner published a research report titled, "Taming the Digital Dragon: The 2014 CIO Agenda". Effectively the report says that CIOs have spent the last decade focused on how to keep the lights running with more and more efficiency, but now need to start focusing on building innovative digital products and services (as well as keeping the lights running as efficiently as possible). Gartner calls this duality a bimodal future and points out to a few key things CIOs need to do to succeed, including:

  • increased migration to the public cloud.
  • changes to legacy technology and sourcing relationships.
  • implementation of agile methodologies and beyond (e.g., creation of multidisciplinary teams and alternative sourcing models).

It was interesting to note that the words "sourcing" and "talent" appeared a total of 6 times in under a 1,000 words. So why is sourcing so important, and why are current sourcing models not well equipped to handle the "digitalization" process?

Why is sourcing important? 

What the Gartner article does not get into (as it probably assumes its readers are already aware of this), is how IT services are delivered today. It's been over a decade since IT was delivered by IT. Through the "noughties" IT services have largely been sourced through external vendors, and companies spend a lot of money on this. Below is a break down global IT spend across various key categories:

Credit: Gartner

Credit: Gartner

Approaching $1T globally, IT services spend by companies represents the second largest spend item by most enterprise IT organizations. In addition to this, when you consider that telecom spend is also services spend, and that both software and hardware spend is increasingly becoming services spend (via. PaaS, SaaS, and IaaS), you very quickly realize that the modern IT organization's #1 focus is generally vendor sourcing and management.

How does the current sourcing model work?

Let's assume you are an enterprise that is looking for a vendor to come in and perform a $10M network refresh, how do you go about sourcing the appropriate vendor to handle this? A well managed procurement process would look something like this:

RFP Process Flow.png

The above process represents an ideal scenario where the IT organization has the skills in-house to develop the RFP and manage the vendor selection process. In many cases this turns out not to be the case, and a process similar to that depicted above needs to be undertaken to source a vendor to manage the vendor selection process for the network refresh. This could easily take two months by itself, and extend out the above vendor selection process into a six month long process.

What is the "digitalization" of IT?

Gartner sees IT entering its third era - the era of "digitaliztion". The first era was marked by automation of hitherto manual processes, and the second era was marked by the industrialization of IT. This is roughly similar to our depiction (shown below) of the eras of personal productivity (the PC era) and organizational productivity (the client-server era).

What Gartner refers to as the era of "digitialization", we refer to as the era of "collaborative engagement". Additionally, as we pointed out in another post, this era is significantly different from the previous two eras (both of which focused on driving internal efficiencies) in a few key ways, the most important of which is its focus on building consumer facing, revenue generating products and services. The most successful IT (or digital) organizations in this era will not be the ones that successfully deploy Microsoft office on 200,000 PCs worldwide, or implement SAP R/3 across 5 business units, but the ones that help their companies quickly and cost-effectively test new ideas and iteratively build high quality products and services.

Why does the current sourcing model fail?

It is this success criteria that is the Achilles' heel of the sourcing model in play across IT organizations today. To be successful in this new era of "digitalization" IT has to deliver in a fast, cost-effective, and high-quality manner. The current sourcing model fails on all three of these fronts. Why is that?

  • Speed: It cannot take 4-6 months to select a vendor. While that might work for a network refresh that happens once every 5-10 years, it doesn't work when speed to market can be the differentiator between you and your competition.
  • Cost:  The average consumer facing mobile app costs less than a $250K to develop. A six-month vendor sourcing process, involving an external consulting firm to help with vendor selection, can cost multiples of that by itself. Again, this may be OK when selecting a vendor to execute a $100M ERP transformation, but doesn't work when building out a $100K mobile application.
  • Quality: The vendors that build the best consumer facing products and services are quite different, and significantly more numerous, than the vendors that can successfully implement a CRM system. There only a handful of world-class vendors that can effectively execute $100M+ projects, and they well known to most IT organizations. There are lot more high-quality vendors that can deliver a $100K project, but they are not as easy to identify in the extremely fragmented ecosystem that exists at this price point.

What can companies do about it? 

While there are no easy answers to this question, a good starting point to begin thinking about "digitialization" is to determine whether to build internally - which requires having the right team with the right set of skills for this new era - or whether to outsource software development. Below is a framework that we presented in a previous post on this subject that is worth revisiting:

Outsourcing Model.png

While this might seem a bit simplistic a first, there are a two things that require some deep thinking. The more obvious of the two is whether the digital product that you are building is a core or non-core product. Lets take the example of airline building its primary app - yes the app is an important part of the overall customer experience that the airline offers, but its not the core product that the airline offers, it is a supporting product. On the other hand if NCR were to build a competing product (they are planning to do just that in partnership with PayPal) to Square Wallet, it would very much be a core product of the company.

The less obvious point to consider in the framework above, is whether or not you are a tech company - again, we wrote a piece on this subject quite recently. This would have been a non-point even a decade ago, when tech companies were primarily software, hardware, and IT services companies. However, isn't this what the "digitalization" of business is all about? Where what were traditionally non-tech companies (Nike for example), are today being considered tech companies? The primary driver behind this is "digitalization" as Gartner puts it, or "collaborative engagement" with the user (customer, employee etc.) that we describe.

The framework above is simply a starting point, albeit a very useful one. Once you have determined what kind of company you are (or the kind of company you want to be when you're all grown up) and the kind of product you are building, you can work on the sourcing strategy that you should adopt. If you are tech company building your core product, then having the right internal team is of paramount importance. In the current competitive environment we find ourselves in, this is not simply about going out and offering creatives and engineers the highest salary possible - if anything the soft incentives are as important, if not more important to the individuals that possess these skills. This particularly holds true for millennials. However, in this uber competitive market for top talent, even if you check of all the boxes, you might still be unable hire or retain the best talent, in which case you might have little choice but to outsource even core product development.

What further complicates the era of "digitalization" is that ideas for "digitalization" can originate from anywhere in an organization. Often the best ideas originate not from management, but from rank and file employees that are digital natives. Mechanisms needs to exist to drive the best of these ideas from concept to execution to market in a manner that maintains a healthy balance between speed, cost, and quality.  How can organizations achieve this? Lets take a quick look:

Speed: Companies can leverage ideation platforms to identify and build support around their best ideas, sourcing platforms to quickly find and source the best teams to build products that bring these ideas to life, and project management and collaboration platforms to track execution and delivery.

Cost: Leveraging SaaS platforms vs. hiring expensive consultants to prioritize ideation and to manage procurement will help reduce sourcing costs in itself. Additionally, working with independent, agile product development teams vs. large, general purpose consulting firms will help further reduce cost by minimizing management overhead and maximizing speed to market.

Quality:  Hiring the right team to do the job can win half the battle in terms of delivering a quality product. To win the other half, organizations should emulate how startups build digital products. Startups don't get everything right from the get-go, however they do get to market quickly, fail-fast, and iterate off those failures to build a better product. 

In Closing:

While this era of "digtitalization" is really very different from the eras that have passed, it is arguably much more exciting than the pervious two eras. If the last two eras were about developing the infrastructure layer of the digital age (PC's, networking, client-server computing, and the early stages of cloud computing), this era will be about building out the application layer that will power the digital age. IT organizations will have to adapt to delivering quality (vs. cost), adopting new sourcing models, and perhaps even look at evolving into a new operating model

The golden rules of outsourcing

In previous posts, we have covered when to outsource and the development options to consider when outsourcing. In this post we are making the assumption that you've already decided to outsource. Also, this post, as is the case with most of our posts, is in regards to outsourcing software design and/or development, not outsourcing the development of a physical good. Once you've decided to outsource, our experience is that the three most important to rules to adhere to are as follows:

1) Don't outsource without experience - If you are outsourcing for the first time, then it's not a question of if you will make mistakes, it's a question of when you will make a mistake (and how expensive it will be). If you are an entrepreneur that has raised a small friends and family round (say sub $50K) and you are outsourcing application development for the first time, then it could mean ending up with a lemon of an app, having no recourse to upgrade the app from a lemon to even just a pomegranate, and sitting through a few embarrassing thanksgiving dinners over the next few years (Note: we have made the argument before that in the scenario that you are a startup tech company you should ideally be building the app in house, but we know that this is not always an option). If you are a marketer that has an idea for an app but have never outsourced a technology project before, it could mean your job. So what if you are outsourcing for the first time? Well, in that case try to utilize at least one of the following suggestions:

  • Use the help of someone that has experience outsourcing - If you are an entrepreneur this could be a friend or a family member that has worked in tech and has outsourced before. If you are a marketer working for a large organization try to leverage the help of a full-time or contract PM.
  • Outsource something non-core first - For example, if you are a marketer working for a large company then start by outsourcing an app whose development, if it blows up, won't cost you your job (and hope that you are right).
  • Work for someone that has experience outsourcing, and learn from them - This especially makes sense for folks that are looking to become professional PMs. It also works an entrepreneur learning the ropes prior to outsourcing the development of his/her own app.

2) Do your due diligence - This might seem a bit obvious, but the devil is in the details. It's probably easier to get this point across by providing some examples of what due diligence does not mean. In particular, due diligence is not:

  • Outsourcing to the first referral you get from a friend or colleague. If anything, this is just the starting point towards building your target list of potential outsourcers.
  • Interviewing the CEO, president, or sales representative of the company that you are outsourcing to - unless they are personally going to manage, design, or develop your project.
  • Being impressed by a client list that includes some of the worlds largest brands. Many of these brands are not the best at policing who uses their logo and in what context. Additionally, just because a team has built a two-page jingle app with a dancing Santa for PepsiCo, does not suddenly qualify you them to develop Snapchat.

So, what does a half way decent due diligence process look like? At a minimum, it should include:

  • Developing a list of "trusted" outsourcers through referrals or through your own organization's procurement group.
  • Interviewing as many of the key stakeholders as possible that will be responsible for delivery (i.e., not the sales people). This might only be the lead product or project manager in the case of a larger organization, or could mean everyone on the team (designer, developer, and PM) if its a relatively small organization.
  • Checking in on client references. The easy part is making the call, the harder part is doing the research to ensure that the reference being provided is legitimate (try to establish the legitimacy of the relationship through LinkedIn), and knowing what questions to ask (focus on their management practices in dealing with the client and not just on how brilliant the app that the outsourcer built turned out).

Now for a bit of self promotion: if you'd like to do better than the minimum in terms of due diligence, then you could always use our services.

3) Manage your outsourcer - Outsourcing is NEVER about delegating away your management responsibilities. Even if you are Fortune 50 company that has hired a firm like Accenture or Deloitte to manage your $100M CRM transformation, you will still have a small army of your own VPs, directors, and senior managers that oversee the work of the consulting firm's partners, associate partners, and senior managers. Now this might seem like overkill but, having worked on both sides of the equation, we can tell you that very often there is no other way. When it comes to outsourcing application development, it's much better to be known as a helicopter client than a UFO by your outsourcer - at least if you want what is delivered to match your expectations.

The best practices in terms of managing your outsourcer can (and mostly likely will) be a series of blog posts in itself, but at a high level it should include:

  • Daily calls or scrum sessions to provide the necessary feedback, and to keep tabs on everyday activities.
  • Helping your outsourcer mitigate risks and manage issues that arise. Please note, these are not one and the same - an issue is a risk that has been realized, and if something becomes an issue without ever being a risk, then that is quite often the sign of poor project management.
  • Having a transition plan.  Outsourcing app development has a finite time bound, at some point an internal team or a different outsourcer will take over the project. If you haven't thought about what that transition plan will look like once project execution comes to an end, then you might be in for some rude surprises.

Note, that there are no silver bullets to outsourcing, but neither is it evil like some people make it sound. In fact, as we have pointed out before, in many cases it is the optimal operating model. As with anything else that you do, you get better at it with experience.

Hiring creatives and engineers? Understand the soft incentives

A study by Princeton University scholars Daniel Kahneman and Angus Deaton has shown that the quality of an individual's everyday experience is not impacted much beyond an annual income of approximately $75,000. This is probably doubly true of creative and engineering talent. To motivate these people to come and work for you, rather than another employer generally requires one or more of the following incentives:

Challenge: The best talent likes to be challenged. They would much rather work around the clock to design a unique user experience or develop an innovative app than a meaningless app which doesn’t extend their skills or challenge their faculties. For a case in point, compare the challenge posed to the Ikea team that built out their 2014 catalog, which leverages augmented reality to give a virtual preview of furniture in a room, to the numerous other catalog apps that litter iTunes and Google Play.

Collaboration: Yes, the best talent can sometimes be difficult to collaborate with, but that’s usually if they are forced to collaborate with team members that are not on par with their own abilities or they are posed with a task that's too trivial for a top notch team to pursue. Put them in a high performing team and ask them to collaborate on a seemingly insurmountable challenge, and this can quickly change. Picture the team that worked together to make this happen: 

Credit:  GQ  

Credit: GQ 

Recognition The best talent likes to be appreciated and recognized for their work, and not just in the context of their own team or department but amongst their peers as well. Find a way to build incentive models where their work is recognized beyond the walls of your company, and by their peers across the industry. Some ways of doing this include:

  • sponsoring creative and technical team members to present in industry and peer conferences
  • permitting designers to showcase select work assets on platforms like Dribbble and Behance
  • encouraging developers to contribute appropriate code to various open source communities via. GitHub

Work environment: Build a work environment that suits your team. Some seemingly trivial items that matter to creative and engineering talent include:

  • dress code - in general creative talent likes to express itself, and technical talent just wants to feel comfortable
  • work time - A Tayloristic 9:00 to 5:00 workday, while potentially great for regimented factory work, doesn't hold the same effectiveness with top talent
  • office layout - cubicle hell can be as uninspiring as a rigid 9:00 to 5:00 schedule
  •  work location - unless you are in all hands on deck turnaround type situation, or you're trying to meet a very tight launch deadline, give talent options here 

The world of work is changing tremendously, and creative and engineering talent today have more options than they have arguably ever had. Options that only a couple of decade ago were considered fringe options at best (e.g., freelancing, working at a startup, being an indie app developer, etc.) are today considered viable alternatives to working a soulless job. Make sure that the job you are offering inspires talent to pursue their best work at work, and doesn't simply become a pay check that finances a much more meaningful side-gig. 

Hiring internally vs. outsourcing development

After spending time over the last 6 months talking to companies of various shapes and sizes about their hiring preferences, we developed a simple framework to help answer the question "when do I hire full time developers internally vs. outsourcing development?" 

Screen Shot 2013-07-16 at 2.50.58 PM.png

IT company building a core product:  If you are an IT company building what you consider to be a core product or service, then you should absolutely look at putting together an internal team, since chances are you will need to iterate rapidly, produce bug-fixes, provide customer support etc related to the product or service. Doing all of this in an outsourced, but yet effective manner becomes cost-prohibitive if the product in question is your companies core product. Perhaps even more critically, if your company is not building product, what exactly is it doing?

IT or non-IT company building a non-core product: If you are an IT, or a non-IT company, building a non-core product, then you first preference should always be to outsource. This is for two reasons:

  • A company that specializes in building what you consider "non-core", is more likely going to be better at it than anyone you hire internally
  • Even if you can hire the best, you will need a consistent and interesting enough pipeline of work to keep the best engaged - remember, very rarely do the best at anything make a decision purely based on the money offerred to them

Non-IT company building a core product: This is the most interesting combination, and one that companies are increasingly finding difficult to answer. Why is this? If you read our last blog post, the answer to this might be a little simpler, but effectively as more and more legacy companies start to build digital products and services, they are increasingly building products and services which might be considered core to the company. However, not every core product or service is created equal. Lets consider two hypothetical examples below:

  • NCR Corporation building a competitor to Square Wallet: Here both NCR and Square are in the business of retail checkouts. If Square starts offering a service via. Square Wallet that offers a significantly superior retail checkout experience, than NCR, then all else being equal Square will outmuscle NCR, and win the retail check-out and digital wallet war. In this scenario NCR's existence depends on building check-out related products and services that match that of Square's, and like their digitally native competition, do rapid and continuous product development, which generally requires an internal team.
  • American Airlines building the most elegant check-in application in industry: Lets assume American Airline's mobile check-in app is so far superior to its competitors, that its starts winning awards at UX and industry conferences, and gets rave reviews from its customer base. Additionally check-in's are a part of any airlines core business process, so it can be considered a core part of an end-user facing service that American Airlines provides. However, the truth is regardless of how elegant and simple to use the app is, the check-in process is only a part of the overall end-user experience that American Airlines provides to its customers, and in isolation, will in all-likelihood not make a significant difference to a customers decision to fly American vs. United. 

In summary, unless you are an IT company building your core product, outsourcing development should always be a serious option on the table.   

Note: We realize this framework does not take into account supply and demand imbalances that a company might be operating under. Today macro economic factors in the technology space, have led to a clear imbalance in favor of supply, and hence even if it makes sense for a company to hire full-time, that choice might not represent a realistic option.