A good way to start a lively debate in a group of P* Management types is to ask "what the right team size is".  ​

Opinions vary between:

• what team?
• ​the Ringelmann effect says 5
• I'll take as many people as I can afford​

I personally like a 3 person team.  

One of them should be an extrinsic/extroverted type who can build consensus and orient towards customers or executive management.  One of them should be a died in the wool hacker who will pull all-nighters for the sheer joy of writing code.  One should be a creative problem solver who can think around corners and design elegant but practical user interfaces.  

That doesn't necessarily mean one of each, in fact, it's vastly preferable if each person can hold down one or both of the other two roles in a pinch.  People do go on vacations, or get sick, or decide to quit to pursue their lifelong dream of being a musician.

3 is better than 2 because there's always someone to break ties.  3 is better than 4 or 5 because a larger group never really gets into the "zone".  That magical place where you have a whole day of pure productivity, barely speaking to each other but acting in perfect alignment.

​Another benefit of 3 over larger teams is the possibility of creating product diversity.  Instead of one team of 6, how about two teams of 3 working on decoupled products that serve related goals?  

Ah, but ​you say, why not have a team of 6 develop two products serially?  

Well, because of the law of diminishing returns for both time and risk.  Sure, you'll plan to deliver two products in six months, but in month four when you haven't quite worked out all the features in the first product, it will seem brutally logical to keep throwing the good money after the not-yet-bad.

​Plus, good products need time just as much as effort.  Customers will always come slower than you expect them to and the team will need time to marinate in the problem and marshal expertise with the technology and processes.

But you say, some problems simply can't be tackled by 3 people!  

I'm not so sure.  Every problem I've encountered can be broken down into smaller ones.  Sometimes these sub-problems are coupled, such that one cannot deliver value without the other also succeeding, but in these instances the successful team will probably figure out a workaround to buy the other team some time, or even make their sub-problem irrelevant.  

​And that last point is very important.  Resiliency to failure.  The survival rate from start of development to successful product is something like 40%.   Having more product teams building a diverse set of products greatly increases your chances of at least one being successful.  Ask any successful VC how many baskets their eggs are into.