Archives for posts with tag: software-development

After spending the best part of the last few years talking to companies of various shapes and sizes about their hiring preferences, I developed a simple framework to help answer the question “when do I hire full time developers internally vs. outsourcing development?”

Outsourcing Framework

Tech company building a core product:  If you are an tech 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?

Tech or non-tech company building a non-core product: If you are a tech, or a non-tech 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 offered to them

Non-tech company building a core product: This is the most interesting combination, and one that companies are increasingly finding difficult to answer. Why is this? This is because as more and more legacy companies start to build digital products and services, they are increasingly looking to transform themselves into tech-companies. However even if a legacy company considers itself a tech company, it should really think hard about whether the digital product it is building is truly core. Lets try and explain this via two (somewhat) 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 out-muscle 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 customer experience (CX) 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 tech 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 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.

Advertisements

As an enterprise focussed technology consultant, you generally wait until you have something close to the “perfect” product with all the bells and whistles a v1.0  is expected to have prior to launching the product into a production environment. Truth be told there are some big differences between an enterprise product and the soft launch of a new Internet based product or service, not the least of which includes concerns around security and performance. The truth is, given that you are launching a product into an environment that has a concrete business need for it, there could be some significant negative business impact if the product fails to behave as expected. In the Internet startup space however, other than some market validation and A/B testing that you might have done, you don’t even know if anyone cares about your product. Chances are on day 1 other than your core team and a few early supporters nobody does. Hence its critical for you to get the product out as quickly as possible, and begin getting some real world engagement and quality feedback. This step is countless times more important at this stage of the venture, than building out the new cute widget that you think your product needs.

On July 16th we launched our product and invited a handful of users to begin using the product. Boy, are we glad that we made that decision. Waiting a few more weeks, and building out a few more features might have helped a bit, but would probably have hurt us more. Lets provide some concrete insight into what I mean by this. Our product, Neulantis, currently is being built with the objective of enabling designers, developers and domain experts to incubate their ideas on the platform, and to help them find a team to kick start their vision. All version 1.0 of the product had to enable this was:

  • the ability to create a profile
  • the ability to initiate a project and add required skills
  • the ability to provide project updates
  • the ability to follow or join a project

Some of the key features that were not included in version 1.0 included:

  • the ability to communicate with other users either through a messaging system or through a discussion forum on the platform
  • the ability for updates to be broadcast to project followers and team members

Now, while some might consider this to be a broken product, particularly with the inability to initiate conversations with others on the platform or go back and forth with project initiators, we believe that the core functionality required to convey the idea to people and begin true market validation was already there. Up to this point we had no concrete way of knowing if people even cared to post their ideas on the platform, however following the release when people began posting their project ideas we knew that this could work. This was the ultimate purpose of R1.0, to test our most basic assumptions – that people would be willing to post their project ideas, and other were willing to join or follow these projects.

On the same token, some will argue that we could theoretically have tested this assumption with surveys, basic mockups and splash pages, but the truth is at that point people are still not using the product, and from our perspective the sweet spot to truly test your most basic product assumptions lies somewhere between a splash page, and a fully functioning robust product. You need people using the product in some concrete way before your assumptions can be really validated. Further without an actual product, it very difficult for people to provide any quality feedback, and at this stage of the venture engaging your early user base, and providing them a sense of ownership is as critical as having them take the first step of registering on the platform. Since we launched our product, almost our entire development process has been guided by early user feedback, and hypothesis validation vs. master planning, and the product is better off because of this.