This is weird to me in a thread about requirements gathering. The OP isn't making the case weighing good, but slow, programmers and bad, but fast, programmers.

This is weird to me in a thread about requirements gathering. The OP isn't making the case weighing good, but slow, programmers and bad, but fast, programmers. They're specifically calling out C2 moving slowly to gather requirements and talk with the product/design team. Which is very likely NOT a "technical purist" type, since I doubt the technical purists are the kind to give two shits about the domain (I'm one of them, even though I realize caring about the domain is now my job as Lead, doesn't mean I have to like it). If C1 delivers quickly on bad requirements, there is no guarantee that product will make revenue. Ask any startup founder who started building a product before doing market research and validation. I think when we add the archetypes of "fast but sloppy" and "slow but clean", we end up with more permutations than C1 and C2 since the matrix looks more like: [ Business Oriented, Technology Oriented Quick/Sloppy , Slow/Clean ]