4 things to do before you outsource your Product Development
Outsourcing is an obvious option to consider when you have an idea for a software application but don't have the technical expertise to implement it yourself. You bring in the domain expertise and take care of the business side, and outsource the technical aspects to experts in that field. But this is easier said than done, and there have been many stories of product development outsourcing gone wrong. So what do you do?
You could learn coding and develop the product yourself, or you could find a technical co-founder or just hire a team of developers. But these options aren't always feasible and you may decide that outsourcing is your best bet.
Here are some things you should keep in mind before you outsource your product development.
(Don't bother reading further if you think product development should never be outsourced)
You have to get involved in product development
Don't expect that you can provide all requirements at the beginning and then just do a status check once a week. Plan to spend at least a couple of hours on product development every day – answering queries from the development team on detailed requirements, reviewing and testing progress, thinking about the next set of items to be built, reviewing and testing what has been done so far, and so on.
If the product to be built is complex and the development team is bigger than 2-3 members, you might have to spend even more time. If you can't commit that kind of that time, you must hire someone who understands the domain and someone you can trust – this person can be a bridge between you and the development team. If the development team is remote, this person should be local to you and he/she needs to have the authority to make day-to-day product decisions.
Fixed-bid contract may not be as profitable as you think
Cost saving is probably an important reason you want to outsource. And you are afraid that if you keep your wallet open then the outsourcing vendor will have less incentive to complete the project on time. These are valid concerns, but unfortunately there is no easy solution.
If you go for a fix bid contract, it means freezing the requirements at the start of the project. Anyone who has done product development knows that this is not realistic. Your requirements will change and it could be due to any reason – your own ideas of what the end product should be like, feedback from potential customers, market forces, or just technological changes. In a fixed-bid contract, every change will take negotiations on scope, cost and timing – impacting your ability to create a good product.
Also, the development team working on the project usually notices a number of things that can be done different or better and this could be valuable feedback for you. But if it's a fixed-bid contract, their focus is on "delivery", not on "development".
You should go for an engagement-based contract if you want to build a good product and want to use the experience of development team you are paying for. Go for a fixed-bid contract if short-term cost savings is your main goal.
Good dedicated resources might be better than the "best" resources
When you are negotiating with outsourcing vendors, they would put their best developers in front of you. But are those developers going to be dedicated to your product? Probably not. Every company has a few star performers: the rest are just good or average. In a bid to win a deal they might make you believe all their best people will work on your project, but that's unlikely to happen in practice. Make sure you get a realistic team of good dedicated developers.
You want your developers to think about your product all the time, give it full attention and be available to meet with your or respond to your communication. A part-time genius could impress you in the short term or fix some critical issue quickly, but will not add as much value to your development process in the long term as a less experienced but dedicated developer will.
Don't over-think the technology stack
Why do you want your product built in Java (or Python or DotNet)? If you have a preference for a particular technology, make sure it is for the right reasons. Do you want to use Java because your application has a complex calculations engine and requires heavy processing, or because that is what you used for your college project 10 years back (or because your friend who is a Java developer recommended it)?
Don't keep strong preferences on technology unless you can sit down and code yourself. Almost all modern and popular languages are powerful enough for building regular applications. Don't put technology as a constraint while looking for an outsourcing partner. Look for how good they are in whatever technology they use and recommend.
On a closing note
I was associated with process and technology outsourcing industry for over seven years and have seen it from different angles. I have seen more projects fail due to miss-matched expectations and conflicting objectives (between client and vendor) than due to bad software development.
What have been your experience with outsourcing of software development? If you have any tips, share with us in the comments!
The author can be reached out at [email protected]
