Nearsighted Roadmaps In Action
sponsored by me, as always - this time, I compiled the very best 16 books of the around 100 I read in 2024 into a neat little shortlist.
So recently, I’ve created the MAIA roadmap. As I always do, I defaulted to my personal favorite format for doing so in a B2B environment, the so-called nearsighted roadmap (named by Job van der Voort, then VP of Product at GitLab, now CEO of Remote.com).
The nearsighted roadmap is amazing because it really is all about implementing a nearsighted planning approach - which is essential for all B2B companies but makes or breaks B2B start-ups. The thing is, the concept was introduced in 2017. I started using it extensively in 2019, and ever since, I’ve worked at Arch, where we implemented a nearsighted roadmap and talked to a few amazing founders (like the founders of airbyte.com) who implemented those roadmaps.
And yet, to date, there is next to NO information about nearsighted roadmaps or nearsighted planning to be found anywhere.
So, I’m collecting the things I’ve learned over the years, the things that make my B2B roadmaps & planning processes better.
Intro
I've been reading about Navy SEALs. Not because I'm planning to join (trust me, I wouldn't make it past day one of training), but because I'm fascinated by how the Navy has thought about decision-making in high-stakes, fast-changing environments. (I enjoyed “Extreme Ownership,” the story of “The American Sniper” and “Make Your Own Bed.”)
Who cares? Well, seeing nearsighted roadmaps in action at Arch (where we borrowed the practice from GitLab) and implementing it for a data team serving 700 employees at Unite, I've seen striking parallels between SEAL operations and modern product development. The structure Navy SEALs have established looks remarkably similar to what I've seen work in practice - particularly the concept of the "nearsighted roadmap."
On missions, SEALs must constantly adjust to unfolding events. No one can plan for every contingency - just like no product team can predict exactly what features they'll need 18 months from now. Instead, SEALs work with the concept of "Commander's Intent," decentralizing decision-making while maintaining crystal clear mission objectives. There, the key challenge is aligning multiple actors towards a common goal.
Building on this parallel, I see profound similarities in how modern B2B startups must operate. Like SEAL teams, these companies navigate high-stakes environments where survival depends on balancing strategic clarity with tactical flexibility. A traditional product roadmap that details features 18 months into the future is like trying to plan every movement of a SEAL team months in advance - a recipe for failure in dynamic environments.
But Sven, nearsighted roadmaps seem like a lot of work
Yes, they are hard work for one person: The product manager! The founder, the person responsible for that high-level perspective, whoever that may be. Is there a shortcut? No, because nearsighted planning is essential for B2B startups, even if you don’t want to do it with a nearsighted roadmap. Most people who don't like to be tied down will simply not publish a roadmap beyond the next few weeks.
It'll look something like this:
Now: Current sprint items
Next: Upcoming features
Later: Vague ideas
That's the easy way out. If Navy SEALs were to take that approach, they would never achieve their mission. And it's the same with startups in the B2B space. If you can't show your customers which direction you're heading and which problems you're solving - in short, that you're aligned - you won't form the long-term relationships that are the foundation of B2B selling.
So, provided you don't want to take the shortcut, let's talk about how good nearsighted roadmaps work in reality.
1. Embrace extreme flexibility in implementation
At Unite, I’ve learned this lesson the hard way. Our data team initially tried to plan features months in advance, but every time a department's priorities shifted (which happened roughly every three weeks), we'd have to rebuild our plans. It was like trying to navigate a ship by plotting every turn before leaving port - sounds good in theory but utterly impractical in reality.
The solution? I’m not committing to any feature beyond the next 4-6 weeks. Those should be well-defined and actionable. Beyond that, features shouldn't exist on the roadmap. Instead, focus on problems to solve or directional goals. This means we won't commit to ANY feature that goes beyond the next 6 weeks with a specific deadline and scope.
What we will do is communicate when we tackle topics related to certain features. So we’ll say “I know you love the feature X, from our understanding that is because it is related to problem Y; we will be working on problem Y in Q3 this year.”
I found this approach allowed us, in varying circumstances, to maintain strategic alignment while preserving tactical flexibility - much like how SEAL teams operate with clear mission objectives but adaptable execution plans.
2. Prioritize problems over features beyond the short-term
This is what I messed up initially. I tried to define specific features for the next 12 months, essentially trying to predict the unpredictable. So when I applied (1), I basically left everything else as “future topics,” as a lot of startups will do.
But what I realized is that there IS a middle ground here (which I sometimes think is the essential part of the nearsighted roadmap). It is to focus on problems for the in-between space between the “next 6 weeks” and “the future - aligned by the vision.” So what I like to do is…. to have
Near-Term = Features (next 4-6 weeks)
Mid-Term = Problems to solve
Long-Term = Vision (or large-scale problems)
This shift in thinking transforms your roadmap from a rigid plan into a strategic framework. It's like the difference between a SEAL team being told exactly how to execute a mission versus being given clear objectives and the autonomy to achieve them based on ground reality.
Think about it this way: even if you put “feature X” on your roadmap into the “later” column, what usually happens when “later” arrives? Well duh, the customer who wanted that feature probably moved on. But problems don’t go away, problems are generic, there are always multiple customers with a similar problem, so if you put a problem there, well, your odds a way better at having alignment.
3. Do a weekly alignment: vision, mid-term, short-term
At Unite, when I first learned about nearsighted roadmaps, I also realized it isn’t just a map, it’s a practice (call it nearsighted planning). So, I instituted what I called "Roadmapping Monday."
Roadmapping Mondays happened every single week. I took a big chunk of my time and worked only on alignment, aligning every single planning horizon and incorporating the feedback I received the week before. Then, I’d share and discuss every horizon with the broader team (still on Monday).
The horizons I always looked at:
Revisiting the vision - almost never changed of course, but sometimes it did! And you don’t want to catch that wave too late.
Adjusting mid-term plans based on new insights is a problem, and of course, there was way more dynamic there than at the vision level. Sometimes I refined problems, sometimes it was about chopping the vision into smaller pieces, rarely it is about exchanging problems for other problems.
Refining short-term execution means changing the details of how we’re doing things at the moment.
This regular cadence keeps everyone aligned without constraining tactical decisions. It's similar to how SEAL teams maintain mission focus while adapting to changing conditions on the ground.
4. Maintain problem-solving continuity
Now while I was pretty happy with the initial version of the roadmap, through Roadmapping Mondays, I noticed a subtle drift happening. There’s a thing called “deployment drift,” which means after you deploy a machine, the status of it will inevitably shift from the deployed defined state.
With roadmaps, it is the same. Through this practice, I often noticed that while I sometimes refined the broader problem context to new incoming information, I also needed to bring that down to the feature level.
Short-term implementation work should always ladder back to solving mid-term problems and achieving the overarching vision.
It happens when you get to implementing and planning out features that you think, “Wait, what was the point here again?”. If you don’t know, how a feature helps to solve a problem, it probably doesn’t.
If your short-term plan doesn’t ladder up to your bigger mid-term problem, you’re not solving a problem; you’re creating bloat. Don’t create bloat, align, kick out features, and solve big problems.
At Unite I had a simple rule: If we look at the feature list, let’s simply assume 90% won’t be implemented ever. That freed us from feeling bad if we had to kill a feature (and FWIW, that number did hold up for most teams at Unite I saw and all of the product teams I’ve seen ever since).
5. Use a structured framework for clear communication
Now, after I’ve embraced nearsighted planning for a couple of months, I realized the strength of the idea is also a weakness: Let’s spell it out, almost no one is using nearsighted roadmaps, and as such, there are no tools for it to display them properly, and no one really knows how to work them.
My personal solution? Text! And education. I tend to keep a banner on top of my roadmaps saying, “This roadmap embraces nearsighted planning as outlined in …” that then goes on to explain in 1-2 sentences how nearsighted formats work.
The framework you choose should reflect an iterative process while serving as a clear communication tool for both internal teams and external stakeholders. At Unite, we found that different audiences needed different levels of detail:
Engineers needed near-term specifics and mid-term problems - the same roadmap, but coupled with a detailed backlog and weekly roadmapping sessions.
Executives and customers needed vision and progress on major problems - the same roadmap, but monthly updates (at most), potentially coupled with regular public demos.
The key is maintaining transparency about the approach. Just as SEAL teams brief their mission objectives at different levels of detail to different stakeholders, your roadmap should adapt its message while maintaining consistent strategic intent.
Remember, the goal isn't to predict the future - it's to create a framework that allows for rapid adaptation while maintaining strategic direction. As one SEAL commander put it, "Plans are worthless, but planning is everything." The same holds true for product roadmaps in fast-moving environments.
More resources and examples!
For some reason (I assume because they are hard to do), people don’t write about nearsighted roadmaps, and few implement them. But let’s face it, it’s the best way to work as a B2B tech company, so get used to it and read up:
4 examples of excellent nearsighted roadmaps (written by me)
The nearsighted roadmap (Post from Job, ex-Product at GitLab, now CEO of Remote.com, and creator of the nearsighted roadmap idea)
If you want to check out the latest nearsighted roadmap I created, of course, take a look at the public roadmap for MAIA