People say that Google has a "Darwinian" product development process, where they pitch products against each other and only the "strong" products survive. I th

People say that Google has a "Darwinian" product development process, where they pitch products against each other and only the "strong" products survive. I think most of the product fragmentation/churn at Google comes from four things: 1. Googlers need to "explore all the possibilities their minds have to offer" (direct quote from a coworker) 2. Managers (both engineering and product) generally won't tell you "no" 3. Internal consensus building burns people out 4. The promotion process is based shipping things that demonstrate growth Google hires lots of very smart, very creative engineers, and asking them to ["maintain legacy code", "answer support questions", "deal with rot but important tasks"] is a tough sell. Many of those people could easily go anywhere else and do whatever they want (this is the talent most companies are trying to hire for), and managers realize this. Since managers don't want to lose talent, they kinda let engineers do whatever they want, within a given field. The way managers tell you "no" is by not funding/staffing your product/feature--shifting resources to something else. I've very rarely been told an outright, "no, we won't build that" and am more often faced with "that's an interesting idea, let's investigate that more" only to not have sufficient headcount to "investigate that possibility" by building a PoC, etc. I assume there probably were efforts to "upgrade" Hangouts to have AI integration and a more modern mobile interface vs replace it with Allo. I assume there was a roving band of 10-20 engineers who were in between projects and thought "wouldn't be be great if...", prototyped Allo together on Hangouts infra, and then went to the Hangouts team and said, "hey, we built this cool thing, let's integrate and Make Hangouts Great Again™!" I assume this was met with initial enthusiasm, until people started digging in to the cost of maintaining the "legacy" Hangouts infrastructure and supporting all the new features asked of them. There were also probably product differences like "Allo wants to log you in via phone #, Hangouts is Google usernames" that slowly became irreconcilable. Resources shifted, and the roving band of engineers probably said, "We'll build our own Hangouts, with phone numbers and chat bots. In fact, forget the Hangouts." [1] Along similar lines, the path to promotion while building a new product is far more clear than upgrading/maintaining a legacy product. It's faster to build, easier to show growth, and probably "more fun." I think it's not so much "no leadership" at Google, just an engineering driven culture with a different set of incentives. Instead of "Darwinian" I think Google has a "probabilistic" product development process: Keep smart engineers happy/engaged, there's a reasonable probability they will eventually create 10x products, since 10x products are better for users/developers/Google than 2x products, it's better for Google to have churn on 2x products than not have 10x products, even if that churn burns users/developers. The main problem is that while 10x products can offer breaking changes, it's generally not reasonably for 2x products to do so. I think many things that are originally intended as incremental changes are touted as 10x improvements to get around having to maintain interoperability (which implies maintaining legacy stacks), but result in a poor user/developer experience. I just think too few of the things touted as 10x improvements actually are, leading to, "deprecations of the old product before the new product is ready." (Disclosure: I work @ Google but not on any comms products, these are my opinions and not necessarily those of Google) [1] https://www.youtube.com/watch?v=e35AQK014tI https://www.youtube.com/watch?v=e35AQK014tI