Developing a Product Roadmap
Sense making for strategy
Sizing estimates are primarily useful to product managers and business people. The estimates provide a frame for evaluating the importance of a feature, identifying level of effort and cost, and informing a prioritization schedule.
The process for arriving at a sizing estimate session includes defining features within a screen. These can be grouped by hero flow, common elements, or macro feature sets. Defining the features is a sense making activity to understand the underlying logic that supports a user’s narrative structure.
Armed with this background, we can then begin to unpack features through a prioritization framework. These frameworks function as a sense making process for strategic planning.
This, that, or the other
I started with the ICE framework which evaluates a feature based on impact, confidence, and ease on a 1-10 scale. Features are prioritized by the average of those 3 variables.
ICE didn’t seem a robust enough framework for evaluating macro feature sets, but I can see this as a more practical framework for evaluating micro features within the larger set. The 1-10 scale felt arbitrary and subjective but the exercise was a useful forcing function to then run those features through different frameworks to compare and contrast.
Product roadmaps = shared ledger of truth
Roadmaps provide visibility and can function as a neutral document to facilitate conversation around business needs and team capabilities. The roadmap lays out jobs to be done, assigns persons to each task, and dictates the order in which those tasks should be completed.
After completing a high level roadmap based on macro feature sets, we assumed that we had a 20% reduction in resources. I created a thin slice roadmap that would allow us to accomplish the must-have and should-have features at a reduced 80% capacity.
Key Learnings & Insights
- Wireframes are a game of logic flows. Articulating the narrative structure through user stories helped me recognize linguistic similarities between designers and developers.
- Developers are people first. I felt irrationally surprised that developer Pete was a normal human and an easy conversationalist. The mythology surrounding developers is something to be mindful of, but they aren’t a monolith either.
- Everything is sense making. We are trying to determine all the parts that make up the whole to investigate what is meaningful and define what is essential.
- Screens are relatable, spreadsheets are not. Walking through screens is helpful because it allows the developer to see scope of work in relation to things they’ve done before.