Product Management 2.0: A Growth Story
Alex Davis

I think this methodology is good for simple features that lend themselves to easily quantifiable a/b-tested solutions. 
Bigger commitments and development efforts need roadmaps. Architecture decisions, platform selection, major redesign/UX changes, extensive new functionality, etc. all benefit from a roadmap. The roadmap becomes the litmus test that can be used to detect feature-creep and drift. 
Not every software development project considers 4–6 weeks a “long development cycle”! Some platforms have enough complexity and QA requirements that 4–6 months would be considered very rushed! One of the hazards of restricting improvements/features to short cycles is that the really important complex architectural needs (ex: converting to a fully relational model from a simple flat structure for data) are never tackled and therefore never met because they would ‘take too long’.
A good PM knows how to use a variety of tools, and which tool to take out of the toolbox to best fix the problem at hand. Sometimes it’s a pipeline, sometimes it’s a roadmap.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.