How to Build a Roadmap for an Ultra Agile Team

When I talk about roadmaps with younger product leaders, I often hear things like “we don’t need one, we are agile” or “why build a roadmap when things will surely change”. This couldn’t be farther from the truth. The roadmap sets the strategic direction of the company, and when built right it also doesn’t have to change that frequently, despite your agility. But there are times of real uncertainty that raise the bar on why and how to build a roadmap that will serve you well. Here is a quick guide to help you guide the team through the unknown.

One of my customers recently shifted from a classic enterprise sales approach to a product-led growth model. We worked on this change for quite some time, and when the first release of the no-touch product was ready it was a major milestone. In my next meeting with the CPO, I asked him what’s next, and he said that they will wait for feedback and act accordingly. While this is an accurate answer and is indeed the practice, leaving it at that isn’t going to help the team and the product to meet their goals. 

When I pushed the CPO to tell me more about what they have in plan, he insisted that they truly don’t know and that they have to wait and see, and react in near real-time to the performance of the product in the market. But when I didn’t give up and we looked deeper, the CPO, too, realized that there was still a lot of information that they can share and would prepare the team better for bringing the product to success.

The Benefits of a Roadmap Do Not Contradict Agility

The roadmap is not a work plan. It is a map. And even if you know that many things will change, and you will meet roadblocks and will need to adjust accordingly, a high-level map can help both you and the team. Think about an elite squad in the army for example. By definition, they know that they will be surprised and would need to improvise. But does that mean that they don’t plan? The contrary is actually true: they plan harder and tighter. They have plans A, B, and sometimes C to cover for what they don’t know. 

While I don’t think that you should plan every little detail – simply because you don’t have time, and the impact of not knowing the details shouldn’t be as bad as the impact on an elite squad in a special operation – planning, in general, can still help you a lot.

When you are asked to build a roadmap or even a plan for the next few months, the easiest thing to do is talk about features and timelines. But the roadmap starts much earlier and at a much higher level. The mere opportunity to rise above the hectic day-to-day and ask yourself where you want to be in a few months adds a lot of clarity and helps you focus on the right things.

Furthermore, since you need people to follow your guidance, it is important to let them know what to expect. This is true both in terms of what you will be working on and in terms of the mindset. Let’s address the first point first. 

If you ever attended a team-building event that included having your eyes blindfolded and being led by a teammate, you will understand this well. This activity is usually seen as a trust exercise, helping team members understand that they must trust each other to succeed. But even if you do it with people you fully trust (surprise party anyone?), it is still much harder to follow someone when you don’t know what’s ahead of you. If you know there is a downward slope ahead, you will set your posture in a certain way. If you know that you are going to turn left, you will start feeling what’s going on on your left side before the turn actually happens. The lack of a roadmap – even a very high-level one – takes away all of these abilities from the team, and leads to them having a larger dependency on you in everything they would be doing in the foreseeable future. You are losing here twice: once, in pace, since they won’t be able to move without you, and again in the quality of work since more would need to come from you instead of having real teamwork to come up with better solutions. 

The second point here is the team’s mindset. This is true especially if the coming months are an exception and the team isn’t used to working with rapid changes and adjusting to a new reality every day. If this is what the team can expect, for the time being, it is important to acknowledge it and discuss it openly. Again, knowing what to expect helps the team deliver, even if you can’t discuss specific features and dates.

Even When You Don’t Know, You Still Know a Lot

Even in times of great uncertainty, when you know that you need to re-read reality on a daily basis and adjust everything accordingly, there are still anchors that you can rely on. For example, you still have goals and priorities that set the stage for everything you will be doing next. Sharing them, and even more importantly – thinking about them and clarifying them – goes a long way in your ability to make sure you are doing the right thing.

Let’s take the product-led growth example I started with. Product-led growth calls for an optimization mindset, where you find a new bottleneck each time the previous one is resolved. You often cannot know where the bottlenecks would be before you meet them, so your ability to plan per bottleneck is limited. 

However, if you take a higher-level perspective, there are definitely things you can say. For example, our goal is to make this no-touch/low-touch funnel work well and bring us X paying customers by the end of the year/quarter/month. Note that even in filling the blanks on this short sentence there is a lot of thinking that needs to be done. As a guideline, your timeline shouldn’t be too specific and you should understand why this is the number and this is the timeline.

Next, you should ask what are the major outcomes that you need to achieve in order to achieve this overall goal. In our example, customers should have the technical ability to pay themselves (assuming this capability wasn’t released yet), the funnel should work well at the single customer level (let’s take the perspective of (any) one customer and help them complete the customer journey successfully and become a paying customer), and then we can start discussing scaling the funnel (so that it works in more cases and in larger numbers). 

These three aren’t necessarily streamlined (which is also an important statement), but you can say for sure that scaling is the last priority. 

So your high-level roadmap for the foreseeable future could be something like: generally, we will be reading the data (which data?) on a daily/weekly basis, find our bottlenecks, and resolve them one by one. Until we have enough data (since we are only starting) we will make progress on providing the ability to pay through our platform, but we won’t necessarily complete it as a first priority if we see issues elsewhere (for example, if our landing page which is the beginning of the customer journey doesn’t convert well). Once we have seen the first paying customers through the platform, we can start discussing scale and expansion.

As you can see this isn’t a very detailed roadmap, but it is still much clearer than just saying “we will improvise”. Moreover, it helps you understand what matters outside of the product itself (in the example above – marketing’s performance on the landing page) and make sure everyone involved understands how this is going to work and is set for success to the extent that you can prepare them.

You can say that especially in times of many unknowns, this guidance is more important than ever. And it is up to you – the product leader – to provide it.


Our free e-book “Speed-Up the Journey to Product-Market Fit” — an executive’s guide to strategic product management is waiting for you

Share this post

Never Miss a Blog Post

Subscribe to my newsletter in your preferred language to get new blog posts to your inbox, and unlock unique special offers

Registration for the 11th

CPO Bootcamp

in now open!

Registration for the 11th

CPO Bootcamp

is now open!

A special earlybirds discount:

10% off

the early registration price,

until April 13th.