When I look back at my career over the last decade, it is interesting that I have spent most of my time working with companies that has software product outsourcing at its center. The company that I have spent most of my time at, the one that I founded and was CEO of – Tekriti Software, was a core outsourced product development company (OPD) and Kellton Tech also has OPD as a significant percentage of the business. So, naturally, I get asked a lot about the various models with product outsourcing and the best way to take advantage of this to build software products.
Kellton Tech has given me enough flexibility and time to actually think on these various models that I was unable to do with the other companies that I founded / co-founded and was involved far more operationally. In addition to this, I have spent some time talking to companies of different sizes and from different geographies including Asia, America and Eastern Europe. I have also spoken to a few Venture Capitalists who regularly fund the companies that create these software products.
I am trying to outline the various points that one should consider while trying to outsource the development of a new product:
1. RFP model on the software product outsourcing is broken: If you, as a customer, are trying to create a RFP documenting product features that are to be developed, there is a good chance that you have no idea of how a software product is to created in today’s world. The ONLY way to create a product is to do it iteratively, irrespective of how good a product manager you are or you have. So if you think that you have been able to document ALL product features in the RFP and trying to invite a vendor to quote on it, do yourself a favor and fire the product manager. Instead, create a business requirement document and work with the outsourced team to convert those into system requirements per milestone – each of which should not be more than a calendar month or so long. Also, if you are a service provider, be very selective with these customers even if you can’t say No to them. You will not make money on the project, the product will not be something that anybody will use and both parties will only end up blaming each other for the failure.
2. Fixed cost vs Agile based time and material engagement model: Never, and I repeat never, engage on a fixed cost model if the effort in building your product is more than a very low few man-months effort. As I said in the earlier point, the only way to create a product is to do it iteratively. So an agile based time and material with a team that you are comfortable with is the way to go. You should definitely speak to the team-members as the product development starts and give them the confidence that you want to work as a team and are flexible with the product requirements for the optimised results as long as it solves the business requirement. Treat the team as partner and not vendor. If you have a fixed budget in mind (and you will likely have it), break the product requirements into multiple iterations and prioritize these iterations. Be transparent about your constraints (budgets / timelines) and work with your chosen team to accomplish those. So, the selection process for the team has to be capability first (and by a degree of magnitude), the cost should be a much lower criteria. This is because a capable team will actually help define your product in a way that in spite of higher per hour rate, they can accomplish the business requirements more effectively in the same cost.
3. Communication – frequency and tools: Your outsourced team has to be your partner and friend in business. So, work out a schedule with the team so that you can talk to them frequently (at least twice a week) and be updated on the general progress. And when you do this, be aware that you will see lots of work-in-progress and you need to know when to give feedback and when to just see the progress so that you don’t make the team members defensive. Motivate the team, and encourage them to do well – I have seen enough customers who will start with issues on every call and that doesn’t help anyone.
4. Technology stack, and architecture: Always understand the technology high-level architecture of your product, not because you don’t trust the outsourced team because you will yourself realize why certain features take more time to implement and may be able to tweak those requirements in a way that it takes less time as well as meet the same business requirements. As an example, the technology stack to implement a real time chat based system is to be designed different from a not-so-real-time web-service based system. Be realistic about the number of users you are expecting and design the product accordingly.
I am confident that if one follows ALL of the above points, the chances of them creating a good product will be many times higher. And, don’t make the mistake of following half of these points and then expecting the vendor / outsourced team to support you the way they would do if you were following all of these points.
