The raft metaphor is a good one. I've often used a similar one: "first we build a go-kart. It's a cool little go-kart, and will help us overcome certain barrie

The raft metaphor is a good one. I've often used a similar one: "first we build a go-kart. It's a cool little go-kart, and will help us overcome certain barriers to adoption with a certain kind of customer for whom a go-kart meets their needs." I find that the main arguments against the raft/go-kart strategy (from the the business leader) are along the lines of "we need a Ferrari man! not a go-kart; our target customers won't even consider a go-kart". Its at this point that an very important discussion has to be had about how customer development and barriers to adoption are overcome. BTW - the applies to both new product development and features for existing products. This is not easy. This discussion must include "Look, the experts who are building this are telling you ________ and ________; you can choose to accept that or continue down a path of uncertainty and investigation until they come up with another set of recommendations...". The goal for the technical leader is to setup a set of options for the business leaders to choose - none of which are allowed to be chaos. If chaos is the norm, either the business leader or technical leader will be removed - or the business will likely fail due to that chaos and its effects on the team.