Let’s talk about two very important artifacts that play a pivotal role within our product development teams: roadmaps and release plans.
The Product Roadmap
The product roadmap is a key component of the Momentum Formula. If you’re a regular visitor to the ITX blog, you know that software teams can create momentum to support the products they build by inspiring the people within their ecosystem. The product roadmap is a key ingredient in generating that momentum.
If you’re new to the ITX blog, here’s a simple graphic of the Momentum Formula that provides context as to how it works:
As the formula shows, software product teams establish critical momentum for their digital products when they combine all the right ingredients. This momentum helps eliminate obstacles that get in the way of team and client goals. Care is required, though. Failure to include even one ingredient can result in unwanted outcomes.
The product roadmap is intended to be dynamic and flexible as product and market needs shift and evolve. It reflects a high-level understanding of the product’s current status, what problems or objectives the team might be tackling next, and the longer-term opportunities to improve the product on the more distant horizon.
User feedback, customer usage data, and market demands can change the product evolution periodically, and these same factors influence and inform your roadmap. Remember that your roadmap is designed to flex and adapt to changing circumstances. So it should change and evolve. Therefore, you should be revisiting it regularly and refining it as needed.
To keep your teams motivated and continuously delivering value to your users, be sure to create bold commitments for both your short- and long-term roadmap.
Frame roadmap checkpoints through the outcome-based lens of “what problems are we solving?” instead of the outputs-based perspective that leans toward “what features can we build?”
Friend of ITX Jared Spool described that mindset shift during a December 2018 Product Momentum podcast. In defining innovation, Jared said, “We get to innovation not by generating additional features, necessarily, but by investing the time needed to study problems.”
When you do that, your roadmap assumes exponentially greater value.
A roadmap is a promise to solve problems, not a promise to build features.
– Jared Spool, Maker of Awesomeness at Center Centre – UIE
Your roadmap is not – and shall never be – your release plan. Your roadmap answers the why and the what of the equation. “What problems are we solving for our customers? Why have we chosen to solve those specific problems?”
The Release Plan
Your release plan is not – and shall never be – your roadmap.
Your product’s release plan is a product of your roadmap; it answers the when and the how. “When can we forecast the solution to be delivered? How are we going to deliver?”
The release plan supports your roadmap as a tactical artifact that forecasts when specific milestones will be met and, in most cases, when new features or feature-updates will be delivered to end users. It should also contain more granular information about what you’re delivering, including schedule dependencies, budget information, dates, and release versions.
Based on your product vision and the strategy driving your efforts, your product development teams can begin to assemble around the product backlog and to outline how they will execute the scope of work to deliver on roadmap objectives.
This includes, but is not limited to, leveraging exercises (such as epic and story mapping) within your scrum teams, assumption hunting, and dependency mapping.
These exercises and discussion that follows bring clarity to the team early on. They are critical to ensuring that teams have the resources they require to deliver meaningful product solutions – truly impactful outcomes.
Vision, a clear roadmap, and a release plan are great amplifiers when grounded in what they deliver for a core customer. Having a clear vision aligns people and focuses them on delivering value. The roadmap and release plan then take that vision and provide the steps for how we are moving toward the vision.
– Fred Beer, President, ITX Corp.
The timeline for your product release plan will likely be much shorter than for your product roadmap. It is largely driven by how often your organization chooses to deliver software iterations to end users.
For some product teams, the cycle is yearly. But it’s not uncommon in software product development to see release schedules compressed down to every 1-4 months. Timelines vary depending on how frequently the team or organization makes changes to the roadmap and strategic vision.
If an opportunity presents itself to differentiate their product due to shifting market conditions, product leaders may decide to change tack entirely – a decision that would result in considerable waste if your product’s release plan had locked in with a 12-month cycle.
The product roadmap and release plan are critical to building momentum and sustaining the team’s alignment, confidence, and predictability. They confirm your team’s readiness and competence. Revisit them regularly, and be sure not to silo them away, permitting access to only a small percentage of the team. These artifacts should be shared broadly and discussed with the entire team, because we’re all in this together.
For more on roadmaps, check out the Product Momentum podcast and blog, featuring Rohini Pandhi, a member of the product management team at Square.
