Agile Product Roadmapping in Practice — How We Ran It at IPLAND | Alexey Krivitsky

This piece describes a way of building long- and mid-term product plans, written up after a two-day workshop with the Ukrainian product company IPLAND and their product effie.

Roadmapping — is it a map of the product's future?

"Responding to change over following a plan" is a core line of the agile philosophy. It does not mean no plans.

Plans or response to change? Predictability or adaptivity? Long-term strategy or tactical goals? — picking between two essential halves of one whole is what science calls a false dichotomy and Buddhism calls dualism. Both halves matter. One does not work without the other.

Plans are useful. Updating them as new information arrives is also useful. This is common sense. We do it in life: we plan vacations long in advance, knowing the weather may force a tweak. We plan a renovation knowing the money and patience will run short and something will have to be sacrificed. We answer the "where do you see yourself in five years" question knowing full well it will turn out nothing like we picture today.

Even so, lifting your head from the desk and looking into the distance is a useful exercise. Product roadmapping is doing it not alone, but together with colleagues and leadership.

Roadmapping as a process

The word "roadmap" — or as politicians like to say, "the road map" — is not quite the right metaphor.

On a road map every detail is drawn at the same level of resolution, regardless of how far away it is. That's not what we want when building plans for a product. We don't want to spend time fleshing out things that are very likely to change before we get to them. We want to clarify things as our horizon of understanding widens, without burning effort now on details that will move.

So from here on we'll say roadmapping — to underline that it is not an artifact (a roadmap), but a process (~ing) of clarifying goals, milestones, metrics, and the other things that matter for the product.

Artifacts come out of it, of course. They help drive the process and make shared understanding visible. But they are a side effect, not the point.

Roadmapping for the bigger picture

However good your organization is at agile, however hard you push cross-functionality inside Scrum teams, however tightly customer representatives, the Product Owner, analysts, and developers work together — information will always be somewhat fragmented, and the bigger picture will live in pieces, never wholly with anyone.

But when the bigger picture is missing, there will always be a shortage of details to act on. The classical fix — strengthen the analysis phase, write more documentation, sharpen the input requirements — counter-intuitively makes the situation worse. Don't believe me? Run a small experiment.

Ask every workshop participant to take a sheet of paper and a pen and draw a sofa.
When the sofas are ready, walk around and add feedback: it should be small, red, and stand in the middle of the room.
Now ask each person to draw a framed picture hanging on the wall behind the sofa.
The clever ones will smell a trap and ask for detail — dimensions, position, orientation. Provide them: rectangular, landscape, hanging on the left.
Now ask them to add hair. Everyone gets stuck.
Then show them the photo from the Dalí museum below — and I promise it all clicks into place.
Now ask them to draw a second picture on the wall. They'll do it without further clarification.
Ask them to add a fireplace-nose. No trouble at all.

So what's the punchline?

When the bigger picture is clear, you need far fewer details to do the work correctly. And the inverse holds: when the bigger picture isn't clear, no amount of added detail will get you the quality you want — only rework and frustration.

That's why product development needs sessions for building the bigger picture from time to time. Those sessions are product roadmapping.

Is roadmapping the same as product backlog refinement?

Product backlog refinement (often called grooming) is a useful joint exercise to work out details. Mature Scrum teams have learned to do it on a regular cadence. It is a chance to look past the current sprint, peek at what's ahead, and dig into upcoming work.

This joint work between the Product Owner and the team helps maintain enough ready detail to forecast feature dates, plan architectural improvements, and avoid duplicate or throw-away work.

But the refinement horizon is normally limited to a few sprints — a couple of weeks to a month and a half, at best — and the meetings are squeezed into the flow of normal delivery, usually an hour or two a week. From experience, that's not enough to see the bigger picture. Questions pile up, the vision blurs, fragmentation grows.

Refinements don't deliver a coherent bigger picture. Remember the exercise with the Dalí photo: when the picture is missing, details will always feel insufficient. Refinements without roadmapping are weak. Refinements after roadmapping click — from the larger to the smaller, from the general to the specific.

Who attends a roadmapping session

Since the task is to assemble the product puzzle from scattered pieces, we bring everyone into the room — both the people who hold the pieces and the people who will benefit from seeing them.

We call this group the extended product circle. Depending on the product and the company, it includes:

marketing
sales
customer care
product support
development teams
product management
project management (where this function exists)
top management and executives

For IPLAND and their product effie, that came out to about 20 people, and we worked together for two days.

One exception to the "pick a representative per function" rule: regardless of how big the development team is, or how many teams there are in a large-scale product, we strongly recommend bringing every engineer. Attendance is mandatory, and they will most likely enjoy these sessions a lot.

Is roadmapping the same as PI-Planning in SAFe?

Not really. Or rather, not at all.

Even though for large-scale development (hundreds of people, dozens of teams) we still recommend inviting every team member to the roadmapping session, do not confuse this with what SAFe calls Program Increment Planning, or PI-Planning.

What's the difference?

PI-Planning in SAFe (as I understand it) targets a detailed delivery plan for the next several sprints and a commitment from teams up to management. In our experience, that process has upsides — the same bigger picture, goal discussion, tactical clarity — but its downside is producing internal "contractual obligations" between teams and management about detailed sprint plans.

In my view, that reduces system flexibility and pulls in the well-known negative effects of waterfall: the process fixes both time and scope, and that's dangerous. To meet the plan, developers have little choice but to open their "secret toolbox of corner-cutting" — clean code, tests, refactoring — and start trimming. Quality and motivation suffer. Then everyone suffers: management, customers, end users.

So PI-Planning in its pure form is not what we want. Really, it isn't.

Roadmapping is about collectively clarifying product goals and strategy. The output is clarity of the long-term perspective onto which the teams and the Product Owner will, sprint by sprint, day by day, feature by feature, thread effective tactical decisions. No one promises anything here. What can we promise each other about the future anyway? Only that it will look nothing like what we picture today. So we paint with broad strokes.

Roadmapping — what exactly do we discuss?

As I said above, the point is to pull together the scattered pieces of the bigger picture. That covers four vectors:

Understanding of the current state of the product (except, of course, for a true greenfield where there's no product yet).
Business strategy and goals.
Knowledge of the market and user needs.
Technical constraints and risks.

The session format really comes down to bringing these four vectors together. How? Simple: give the people who hold information about each one a chance to present what they know. (A rough two-day schedule follows.)

Sounds banal? It is, probably. That doesn't take away from the remarkable effect we see in roadmappings with clients.

A rough two-day schedule

Participants: the whole product circle.

Workshop goals:

Bring four vectors of product development into one place: current product state, users, business, engineering.
Build a high-level strategic product map across the three vectors at the epic level.
Start placing epics on time horizons (summer, autumn, winter).

Both days run 10:00–19:00.

Day one — gathering information

We bring in everyone involved in building, growing, and supporting the product. That can be 20+ people. The day's program is built so that every group can present its current understanding of the product and where it should go.

10:00–12:00 — Product demo and recent evolution. Get everyone on the same page about the current state. Take a moment to be proud of what's done. Start thinking together about what's next.
12:00–13:30 — Current picture from the business side. Describe the product vision from a business and market angle.
13:30–15:00 — Extended lunch break.
15:00–17:00 — Insights from the market and users. Outline key persona types and their needs so this vector enters the roadmap.
17:00–19:00 — Aggregation, open questions, buffer. Time to digest and rework what was gathered.

Day two — building the product map

At IPLAND, day two mostly worked the development team and its Product Owner, drawing on the cross-functional input from day one.

10:00–12:00 — Building the product roadmap. Visual map work.
13:00–16:00 — First-pass refinement of near-term ideas. Mini-training on writing good backlog items, with a lot of practice on the freshly drawn roadmap.
17:00–19:00 — Lessons learned. A whole day in — time to widen the circle again, look at the roadmap, and close out.

What product roadmapping buys you

More alignment. Everyone in the product process — stakeholders, business representatives, management, engineers — gets the same picture. That creates alignment on strategy, on long- and mid-term goals, and makes sure people walk in the same direction.

Less management and process. Strategic alignment lowers the need for management overhead (and documentation in particular). When goals are agreed and clear to all, far fewer written details are needed to keep shared understanding intact.

More self-organization. Clear goals — endorsed by everyone in the room — let teams and engineers make day-to-day decisions and experiment freely without waiting for sign-off from above.

Better products. That's the real goal, of course, but you only get there indirectly. We believe regular roadmapping sessions (our recommendation: once a quarter) make for better products.