Roadmaps for Product Designers
The roadmap sits in the product manager or product owner’s toolbox, but all team members need it as well, as it is the simplest way of laying down product vision and how to achieve it.
Three Product design steps
Product design is simple, yet trifold. Features that the product consists of are (tentative) solutions. They are the result of research, design, and development work. What we learn after releasing a feature feeds back into our research in the endless build, measure, learn cycle.
The product is a list of goal-answering features. We do not develop all of them at once, they have different priorities. Every feature is a result of research-design-deliver steps.
Each step consists of various activities, different methods of research, different ways of solution finding and experimenting with the solution, user testing, hand-off and development that also consists of several steps. Features have to be aligned with marketing activities and fill into a broader company timeline, thus answer to planned outcomes. A feature is how the product allows for desired outcomes.
Company vision trickles down and affects product vision. Product vision tells us how the product will contribute to the company’s vision. Roadmap is a handy communication frame to organize this wish list into a plan for outcomes. The roadmap is a list of outcomes we wish to achieve with the product, without describing how exactly we will achieve it.
Only then the design process, based on research input, can start. Once we have the solution tested and handed over, then we can move it to the top of the product backlog. The backlog is an organized plan of activities leading to features development and release. It is composed of epics, user stories (or product backlog items) tasks and sometimes lower tiers. Its relation to roadmap is that once a feature is implemented, its operating should provide a desired outcome, stated in the roadmap. The feature’s success is to be measured by how well the outcome is achieved.
Why the roadmap is important?
It is a low-level artifact, comprehensible by everyone on the team, and when kept fresh, it guides the team towards the successful product delivery. It also helps newcomers and stakeholders grasp where we are and where we are heading to, what the outcomes will be of our efforts. The roadmap is built of outcomes, that together will make the product vision come true.
The way how we approach achieving these outcomes, by building features, is expressed in a backlog.
A roadmap is a communication tool, that explains where — we as a product team — are going and what the promised land will look like. A product roadmap communicates the product strategy, which is itself an expression of the organization’s larger strategy.
„Converting the wishes and ideas of an org into a clear, usable roadmap is a fundamental responsibility of the product team, and it doesn’t ever come easy.”
Christian Crumlish
In his book, Product Management for UX People, Christian Crumlish, proposes a very simple, three column roadmap, divided by the time perspective. Now, Next and Later.
Roadmap maps outcomes into three time perspectives.
- „Now” refers to this quarter, a roughly 1–3 month period. Outcomes that we know how to map onto features and that features are well planned.
- „Next” is the six month period following the current quarter. The items in that bucket will likely come to fruition in that period.
- „Later” is the nine-month period that takes you out to about a year and a half from the start of the current quarter. It’s pretty much impossible to make plans farther out than 18 months, and the items parked here are necessarily broad and subject to revision every time you reevaluate your roadmap.
Start with your objectives, find problems to solve, and run discovery to better understand how different items give you the desired outcome. Frameworks help understand and visualize information, foster conversations, and discussions. They are not there to make decisions for you.
Andrea Saez
Is there a role for a designer?
Definitively, designer owns a significant part of the „Later” column, researching problems, exploring solutions, experimenting and testing. Making sure features are designed to answer outcomes (that it is measurable) and that outcomes can be moved slowly to the „Next” column. The designer is not creating the roadmap, but has to follow „Now” and „Next” columns, and help shape „Later” column. Outcomes that are listed in the „Now” column have to be development-ready, that means design hand-off is there and success measures of the feature are agreed upon. Outcomes in the „Next” column are these that the designer works on currently, but he never can lose from sight the „Later”.
Designer has plenty of activities in his hat, and has to keep track of what lies ahead. The „Now” column is where hand-off, guidelines and documentation happens. It’s mostly time for developers, but designer guides, explains and sometimes adjusts the final feature design. „Next” is the design phase (preparation and testing of solutions). The „Future” column is for research, when designer identifies underlying problem, deepens its understanding, defines outcomes and precise desired key results of future features. Here most strategic work happens and numerous stakeholders’ management. It means design is doing all types of work simultaneously, being mostly focused onto activities at the edge of „Now” and „Next” with a significant time investment into „Next”.
Although designer is not building this roadmap, he is following it and his work has an impact on this what goes from „Later” to „Next”, or is abandoned. The designer is a siever, that sieves through vague ideas and wishes in that column, and discovers if there is any underlying problem that can be an opportunity for the product, sets objective measures of success, workshops the solution, prototypes and tests it against measures of success, and communicates with stakeholders.
What the roadmap is for?
Products are more than just a bundle of features and bug fixes, and roadmaps are more than just a giant wish list. The roadmap is a laying of the strategy.
Roadmap is a place where vision and desired outcomes are communicated and then translated into backlog and divided into actionable chunks of work. Where strategic thinking becomes translated into delivery. It is where the team is accountable for planning the work and obeying time frames.
Outcomes that build the Roadmap, are answers to user needs, pain-points or desires. Outcomes feed business opportunities. Outcome communicates uncertainty, „(…) it says, we know we need this problem solved, but we don’t know the best way to solve it. Outcome communicates the team how they should be measuring success (…) A clear outcome helps the team align around the work they should be prioritizing” Teresa Torres. How we write down outcomes is how we frame problems, then how we answer with solutions.
The build trap is when organizations become stuck measuring their success by outputs rather than outcomes. It’s when they focus more on building and shipping features rather than on the actual value those things produce.
Melissa Perri
The roadmap is kept fresh. It communicates where we are on our way, and must be updated on regular bases, each time an increment is released. The roadmap facilitates transparency for the team and stakeholders. It must be accessible for everyone.
Commitment to time frames
The product designer doesn’t own the roadmap, it is the Product Owner that owns a part of it, or Product Manager. They are accountable for the promised value. What interests stakeholders most, are deadlines. A roadmap presented in three columns way is convenient for the team, but rarely acceptable by stakeholders.
Stakeholders always want commitment to time frames. They would be just about satisfied with the Gantt chart, being a release plan. Roadmap is very useful for presenting the Big Picture and the interrelation of outcomes. It helps other departments align their efforts, but only commitment to dates can be made on „Now” outcomes. Sometimes Product Managers simply have to present a Gantt chart, that is also a big picture timeline, but of features. It is a linear way of presenting your backlog, and here once again, you newer can plan precisely for more than 3 sprints ahead. So any time stamps on Next are rather wishes, and on Later are divination. It is the role of Product Manager or Product Owner, how to manage stakeholders’ impatience and need for clear commitments. Delivery plan should loom out easily from product backlog.
But it is far too granular to discuss strategic decisions, especially when stakeholders are used to owning the decision, and they come up with wishes and ideas. The roadmap is the point of reference in discussions of strategic impact.
Summary
- Roadmap is not a Gantt chart (with it commitment to dates).
- It is composed of outcomes, not features and three time frames: „Now”, „Next”, „Later” what immune it against deadline commitments.
- Roadmap is owned by the Product Manager or Product Owner, but must be coordinated with a Product Designer, whose work is to design a successful answer to outcomes.
- Designer need to know what the future be like but also need to limit work in progress and effectively allocate time and effort resources in which roadmap is very handy.
- A product roadmap communicates the product strategy, which is itself an expression of the organization’s larger strategy
Reading
Product Management For UX People. From Designing to Thriving in a Product World by Christian Crumlish.
