As chuck McM said, start looking for a problem, rather than an idea but i would like to add this caveat:
1) Look at the background of you 3 guys, and list out problems which were being worked around in the areas of your business development or private equity or the domain of your phd friend.
There is a much higher probability of you guys having domain expertise in the areas you have been exposed to in the past, and a lot of business contacts as well - and solving a problem in those areas means that you will be able to address problems you have personally faced before - through a combination of software and services.
Note that there is no dearth of problems to be solved, but problems you have faced before personally can be a much more fruitful area for automated solutions.
A package manager is generally not part of the language per se and should not be part of the language, but rather be part of the tooling ecosystem around it. Don't get me wrong. A de facto package manager is extremely important for any major language - and it's high time someone in the C++ community builds and promotes one. It just doesn't belong in the spec.
Why would you care where people learned programming from?
If you know how to spot a good programmer with a real interest in programming, what does it matter where he started?
Only people who don't know how to spot or attract a good programmer fall back to big school names, and years of experience and all the rest of the fake stuff.
a) Send senior management to personally oversee the outsourced work in india ( at least initially )?
b) Send detailed SRS (Software Requirement Specification) to the outsourced team?
c) Personally interview and hire the programmers who will be working on their projects?
d) Personally perform a skills audit and then try to correct any deficiencies noticed through training for the programmers?
e) perform a thorough software estimation exercise based on the previous work history of the group they plan to work with?
The reason i raise the following questions is that i notice a tendency among many to stereotype the indian programmer for various reasons, but the reason for most software failures is probably a combination of bad management, poor tracking, bad estimation practises, lack of domain expertise among programmers, and the need to save a quick buck by the folks at cxo levels.
1) Look at the background of you 3 guys, and list out problems which were being worked around in the areas of your business development or private equity or the domain of your phd friend.
There is a much higher probability of you guys having domain expertise in the areas you have been exposed to in the past, and a lot of business contacts as well - and solving a problem in those areas means that you will be able to address problems you have personally faced before - through a combination of software and services.
Note that there is no dearth of problems to be solved, but problems you have faced before personally can be a much more fruitful area for automated solutions.