A product-development plan for a series of projects to be completed in a year. An Anti-Pattern. Project-oriented Roadmaps are counter-productive for Software Product Teams
In a StartUp, investors may want a 3-yr plan. This is supposed to do things like
- Show that you're realistic enough not to think you'll be Done in a year.
- Show that you are prepared for waves of bigger-market-attack (bowling pin), vs being a Life-Style Business
- Create an expectation of progress MileStones which you will inevitably fail to meet. (A cynic might suggest this is a tool designed to provide a basis for removing an uncooperative founder.)
Sept'2015: Martin Cagan sketches an alternative to the Road Map. Earlier I said we needed to acknowledge the two drivers for old-style roadmaps. The first was the desire to work on the highest Business Value items first. (see Nature Of Software Development) Hopefully it is clear that this need is addressed by management providing the specific objectives for the organization and their prioritization. The difference is that they are now prioritizing the importance of business results, rather than perceived value of features. The second driver was the need for Commitments. We address this with the concept of high-integrity commitments. We do this for those [rare] situations where we need to actually commit to a date or a specific deliverable.
A more-mature company may use a 1-yr RoadMap to
- justify staffing (budget cycle)
- try and encourage teams to Think (not-too-) Big with Project packaging (also creating implicit Commitments way too early for realism).
A process I'm trying to encourage
- Start by prioritizing Problems/BottleNecks that need solving. Get group agreement on the top-3. Stop talking/thinking about others.
- Spend lots of time on Idea Generation for attacking each those 3 Problems.
- Rank/prioritize the Ideas, taking into account rough Cost and Odds of Success (see RICE model). (Avoid justifying an Idea by its attack on Multiple Problems, as that's (usually) more a source of distraction/diffusion than benefit.)
- Restructure each Idea to start delivering results faster, (a) to accelerate benefit, and (b) to accelerate learning whether there will be benefit.
- Stop working an idea once you've made Good Enough progress.
- Periodically repeat Problem ranking and Idea Generation.
The MetaVerse Road Map Group provides a different Framing: A roadmap is the outcome of a collaborative foresight process that considers a broad set of factors and strategies important to reaching a future goal. cf Theory of Change
They emerge in a collaboration network of multidisciplinary and competing experts,
They emphasize uncertainties and challenges as much as probable and preferred futures, and
They have long-term time horizons (five to fifteen years is common) by comparison to traditional forecasts and plans.
The way people figured out where to drive before GPS, like animals.