Add draft blog post

blog/_posts/2023-12-12-roadmap-transformation.md

@@ -0,0 +1,64 @@
+---
+title: Feature roadmap transformation
+description: How to migrate to a now/next/later product roadmap, one step at a time
+layout: hh
+tags: product roadmaps
+---
+
+[Feature lifecycle management](feature-lifecycle) helps internal stakeholders prepare for
+[feature rollout](feature-rollout).
+It also creates the opportunity to transform your roadmap.
+
+[Ditch the Timeline Roadmap](https://www.prodpad.com/resources/guides/ditch-the-timeline-roadmap/)
+explains the benefits of a lean roadmap, and how to get people on board with the idea, but not how to get there.
+
+> Request book by ISBN, Share bookshelfie photo, Update status in The StoryGraph
+
+You could do worse than throwing your existing feature-based timeline roadmap away, and starting from scratch, but you might prefer to start from your existing feature roadmap.
+Use the following steps to rephrase your plan instead of discarding it.
+
+## Features → opportunities
+
+Start by making the dates less important, by replacing each feature with the underlying
+[opportunity](https://www.producttalk.org/2019/02/prioritize-opportunities/) it addresses.
+This step assumes you know why you put those features on the roadmap; if you didn’t, figure that out first.
+It works because these opportunities typically have a broader scope, and longer lifetime, than any particular roadmap item.
+
+> Discover books, Connect with other readers
+
+Replacing features with opportunities improves the roadmap in two ways:
+
+1. **simplifies** the roadmap, reducing the number of items, possibly increasing their size
+2. **rephrases** - shifts the language from software solutions to business problems.
+
+In general, releasing a feature doesn’t completely resolve the opportunity, and in some cases you could work on an opportunity indefinitely.
+This means that instead of planning a feature (with a specific scope), your roadmap plan now identifies a problem that you’ll work on for a particular period, such as a month or two.
+
+## Dates → months
+
+After you have replaced the features, it makes less sense to plan to work on a problem until a particular date (no longer a release date).
+Now you can reduce the time scale precision to whole calendar months.
+
+> Discover books, Connect with other readers
+
+Instead of showing how many days you plan to work on a feature for, the roadmap now shows in which months you’ll work on which opportunity.
+This works works because a product strategy roadmap doesn’t need to show how much effort you’ll spend on each problem.
+Instead, you show what the team will work on now, next, and later.
+
+## Months → now/next/later
+
+Your calendar month (or quarter) opportunity roadmap’s
+[lack of detail makes it more stable](product-roadmap-triangle), and easier to keep accurate.
+You could stop here, with a greatly-improved roadmap, but you’ll get even more benefits from a lean roadmap, which answers three questions:
+
+1. Which opportunity do you focus on right **now**?
+2. Which opportunity will you address **next**, given what you know now?
+3. Which other opportunities have you identified, that align with your product strategy, and you might work on **later**?
+
+In practice, these three buckets may correspond to the opportunities you expect to work on this quarter, next quarter and 6-12 months from now.
+But not necessarily: the _later_ column could look further ahead, as well as including multiple options.
+
+> Discover books, Connect with other readers, Acquire books, Trade books
+
+On a date-based roadmap, you can’t add options for 6-12 months in the future without them looking like definite plans.
+Switching from an absolute timescale to this relative prioritisation makes it easier to add options in the _later_ column, and for stakeholders to understand that they don’t represent commitments.