Agile roadmap: how to get your teams on board

The tension is a classic. The product manager works iteratively to find market fit as fast as possible. The developer wants to avoid weighing down the codebase with features that will be abandoned. Both are right, and the roadmap is where that tension gets resolved, or festers.

One simple rule: nobody likes working through a task list without understanding why. Developers should be consulted from the moment the roadmap is being designed. You collect essential feedback before committing, your teams gain autonomy, and the result is better. Here are the eight principles I apply, followed by a worked quarter that puts them into practice.

1. Master the fundamentals

Reason from the foundations of your product: the problem, the target, the hypotheses. What works in one organization does not necessarily work in another, because every product and every market is different. Before presenting a roadmap, be ready to answer:

• What does your hypothesis roadmap look like?
• Which features make up your MVP?
• For each hypothesis, what needs to be built to test it?
• What do you still not know, and can the tech team help find out?

2. Choose substance over buzzwords

In 2022, the buzzwords were big data and the internet of things. In 2026, they are “generative AI” and “agents”. These labels sometimes help win over leadership. A tech team can do nothing with them.

Your team needs to know exactly what it is building, how it fits with what already exists, how it will be delivered, who will use it, and for what purpose. Big themes give the roadmap its structure; do not stop there.

3. Give context

Engineers need to know why an item is on the roadmap, and ideally to be consulted on the solution. Backlog grooming and sprint planning are the right moments for that.

When you present the roadmap, let the data speak, but also tell a story from the users’ point of view. Talk about the options you ruled out, and why. For the whole team, the “why” matters as much as the “what” when deciding the “how”.

4. Weigh every commitment

If a feature is not tied to any hypothesis and exists only to please someone, raise the alarm. Your team commits on the strength of trusting you to prioritize. If you accept arbitrary requests, it disengages.

Bear in mind that most of a feature’s cost comes after it ships: maintenance, support, added complexity. The “quick little things to keep someone happy” often turn out to be the most expensive.

5. Make realistic plans

A vision is only useful if the team believes it can be reached. Build the plan and the deadlines with the team, check that the workload is spread fairly, and anticipate what happens if a hypothesis is invalidated. A clear action plan, discussed up front, is much easier for everyone to carry.

A simple test: ask each team member what they think they can deliver by the end of the quarter. If the gap with the roadmap is large, it is not the team you need to convince; it is the plan you need to rework.

6. Think big, start small

Assess the team’s current skills honestly against the goals. Motivation only lasts if the team regularly hits its targets. Set modest sprint goals, help everyone build their skills, and start by validating the first hypotheses. Consistency matters more than headline ambition.

7. Share the business case

Once market fit is found, product work becomes optimization: conversion, profitability, key metrics. Keep involving the teams in the optimization hypotheses. Developers care about the impact of their work too, and their business sense is an underrated source of ideas.

8. There is no such thing as a trivial feature

Everyone wants to contribute to a product they can be proud of. Every request is a building block in a larger whole, however small, and it has a reason to exist. If you cannot explain that reason, perhaps it does not have one.

And think beyond the launch: after the MVP and the first version comes the optimization and scaling phase, built on the foundations of the previous one. Choices made under pressure early on are paid for at that point.

A quarter of planning, in practice

A fictional example. A mid-sized logistics company: three development teams, one product manager per team, business teams in the warehouses and in customer service. Here is how the eight principles translate into a quarter’s calendar.

Notice that developers and business teams contribute before the decision meeting, not during it. The meeting settles what they raised; it does not collect opinions live. That split is what lets you involve many people without turning the review into a general assembly.

Involving people without turning the roadmap into a committee

The risk of involvement is the consensus roadmap: everyone gets a small piece, and the whole leads nowhere. A few rules prevent it:

1. Consulting is not voting. Say so from the start: you are looking for risks, facts and ideas; the decision belongs to the product manager. The RASCI matrix makes that split explicit.
2. Rotating representatives. Rather than the whole team at every workshop, two different developers each quarter. Everyone ends up taking part, without fifteen-person meetings.
3. Writing before talking. Written comments make room for people who do not speak up in meetings, often the ones who know the details best.
4. An answer to every objection. Accepted or not, every objection gets a reply in the decision note. That is what makes people want to do it again next quarter.
5. Disagree, then commit. You can disagree with a decision and still commit to making it work. Say it explicitly, or the disagreement resurfaces mid-sprint.

Small team or large organization

In a team of eight, the whole calendar above fits in half a day: draft shared in the morning, discussion in the afternoon, decision by the evening. What matters is keeping the order (write, consult, decide, publish), not the duration. In a large organization, the challenge is the reverse: protecting developers’ time. A one-hour workshop per quarter and written comments are enough; do not invite them to every alignment meeting between departments.

Signs that involvement is not taking hold

• The line from the introduction comes back: “anyway, in six months they’ll ask me to take it out.”
• Comments on the draft are rare, or uniformly positive.
• The same objections return every quarter, with no written answer.
• Developers’ estimates arrive after the decision, not before.

In hindsight

I wrote these eight principles in 2022, drawing on my startup experience, at TIAO in particular. I have applied them since in much larger organizations, at Home Partners of America and then as CPO of Dotworld. They have held up, but not all in the same way.

What I would keep

Context before the task, and refusing features with no reason to exist. These are the two principles whose absence shows up fastest: when they are missing, the fatalism from the introduction appears within weeks, whatever the size of the company.

What I would nuance

I wrote that developers should be consulted from the design stage. I still think so, but I have learned to calibrate: consulting everyone on everything wears a team out as surely as never consulting it. The calendar above, with rotating representatives, is the most sustainable form I have found.

I would also nuance principle 7. Sharing the business case is not always enough; you also need to share the numbers after delivery. A team that never sees the effect of its work eventually stops asking.

What AI assistants have changed

AI assistants lower the cost of preparation: a roadmap draft, a summary of written comments, workshop prep all go faster. A prototype built in a day also lets you show an idea to business teams instead of describing it, which makes their feedback much more precise.

But automated summaries of objections have a flaw: they smooth things out. A minority objection that is right can vanish in a summary. Read the original comments, at least those from the people who know the field. Involving teams is precisely the part of the work you do not delegate.

Where does AI fit in?

Everything above applies even more strongly to AI projects, for a simple reason: an AI system changes the work of the teams that use it, not just the teams that build it. Customer service agents, case handlers and operations teams are stakeholders in the roadmap just as much as developers.

They are the ones who know the business vocabulary, the edge cases and the workarounds. Leaving them out guarantees a system that works in the demo and gets bypassed in production. This is the heart of the thesis I stand by: a successful AI transformation is 70% organizational. How you allocate roles, which I describe with the RASCI matrix, and how you involve teams from the scoping stage do more for success than the choice of model. I go through the consequences in from AI POC to production.

In the quarterly calendar, this translates simply: for an AI initiative, the interview with business teams becomes a workshop on their real cases, and they are the ones who define what a good answer is. The metrics to track afterwards are described in measuring an AI support assistant. To prepare those teams to work with AI, the guide on choosing AI training for your company lists the criteria to check.