It’s Wednesday. Ewelina, an experienced Program Manager at a B2B SaaS company, feels as if she is living in two parallel realities. In the morning, in a conference room on the top floor, she presents a beautifully prepared, multi-quarter product roadmap in front of the steering committee. Gantt charts, feature lists with precise delivery dates, resource allocation - everything is buttoned up. Management is happy. They value the “predictability” and “control” that this detailed plan gives them. In the afternoon, Evelina goes downstairs to the bustling space where her agile development teams work. There, the atmosphere is completely different. The technical leader of one of the teams shows her an analysis of a groundbreaking new feature that their main competitor has just released. “We have to respond to it, and fast,” she says. “If we don’t reprioritize now, in three months it will be too late.” Ewelina feels the immense pressure of this fundamental conflict. How is she supposed to reconcile the promise of predictability given to management with the need for immediate adaptation demanded by the market? How can she stick to the “plan” while still being “agile”? This internal conflict for Ewelina is a daily reality for countless technology leaders, product and program managers around the world. It is one of the most difficult and fundamental challenges in modern technology management. On the one hand, business needs vision, strategy and a degree of predictability to plan investments, sales and marketing. On the other hand, we live in a VUCA (volatility, uncertainty, complexity and ambiguity) world where the only constant is change, and the ability to adapt quickly is the key to survival. Over the years, a false belief has grown up that strategic planning and agility are two opposite poles. This article aims to dispel that myth. We will show that it is not an “either-or” choice. It’s a “both-and” challenge. We will present a strategic framework and practical techniques that will enable IT leaders to build a coherent operating system - a system that combines long-term strategic vision with short-term agile execution, transforming the tension between plan and adaptation into a source of dynamic competitive advantage.
Why is the traditional, feature-based roadmap the anti-pattern in an agile world?
“Organizations that invest in proven project management practices waste 28x less money because more of their strategic initiatives are completed successfully.”
— PMI, Pulse of the Profession 2024 | Source
The traditional product roadmap, which we inherited from the industrial era and the waterfall approach to project management, is essentially a list of functions assigned to a timeline. It looks like a Gantt chart where we have promises: “Function A will be delivered in Q1, Function B in Q2,” etc. While at first glance this looks professional and gives a sense of control, in today’s dynamic environment, such a model is not only inefficient - it is actively harmful for several reasons.
1. creates the illusion of certainty where there is none: The world of software development is full of uncertainty. We don’t know in advance exactly how long it will take to implement a complex function. We don’t know what technical problems we will encounter. Most importantly, we don’t know if customers will actually love a feature we planned six months ago. Date-based roadmap creates a false sense of certainty and leads to making promises that almost certainly caot be kept. This generates frustration, destroys trust between IT and the business, and leads to a culture of “blame.”
2 It focuses on “delivery” (output) rather than “results” (outcomes): Such a roadmap measures success by “ticking off” more items from a list. The team is rewarded for delivering Feature A on time, regardless of whether that feature solved any real customer problem or made the company any profit. This leads to “feature factories” - teams that are extremely busy delivering code, but have no idea whether their work has any meaning or value.
3 It kills agility and learning: When the plan is predetermined and “dibs” on 12 months ahead, there is no room for adaptation. Even if the team discovers a better way to solve a customer problem in the course of its work, or if the market changes, the pressure to “stick to the plan” is too great. Such a roadmap discourages experimentation and learning, because any change is treated as a failure in planning, not as intelligent adaptation.
4 It leads to superficial discussions: Discussions about a feature-based roadmap amount to haggling over “which feature will go into Q2 and which must wait until Q3.” It’s a conversation about solutions, not problems. It lacks strategic depth and discussion about what business goals we want to achieve and which customer problems are most important to solve.
The traditional roadmap is a tool from another era. In an agile world, we need something different - not a rigid map with a set route, but a compass that points in the right direction, allowing teams to find the best way on their own.
What is a modern strategic roadmap and how should it be structured?
A modern, agile roadmap is a fundamental shift in thinking - moving from declaring “what we will build” to communicating “why and what problems we will solve.” It stops being a list of features assigned to dates and becomes a visualized strategic document that communicates the vision and direction of the product. Its goal is not to make precise promises, but to build consistency and understanding (alignment) across the organization.
Key features of a modern roadmap:
1 It is Outcome-Oriented: Instead of listing features (e.g., “Implement a new social media login system”), the roadmap focuses on customer problems or business goals that we want to achieve. An item on the roadmap could read: “Simplify and shorten the new user registration process by 50%. ” This wording gives the team autonomy to find the best solution (it could be social media login, or maybe something else entirely) and clearly defines how success will be measured.
2 It is Theme-Based: Instead of individual, unrelated functions, the roadmap is organized around broad strategic themes. A theme is a large, coherent area of investment. Examples of themes for an e-commerce platform include: “Improving the experience on mobile devices,” “Personalizing real-time offers,” “Optimizing the checkout process.” Working within themes allows for more strategic thinking and grouping of related initiatives.
3 It uses broad time horizons rather than specific dates: The modern roadmap dispenses with the illusion of precision. Instead of specific dates, it uses broad time frames that reflect the level of uncertainty. A popular model is:
-
Now (Now): What are we doing this quarter? Here we have a high level of certainty and are working on specific, well-defined initiatives.
-
Next (Next): What do we plan to do in the next quarter? Here we have an outline of the problems to be solved, but there is still room for refinement.
-
Later (Later): What are we considering for the future? This is a place for big, strategic ideas and directions, without any commitment to details.
4 Clearly communicate the level of certainty: Each item on the roadmap should include information on what stage it is at - whether it’s just a loose idea, whether it’s in the research and design phase, or perhaps already in the development phase. This helps manage stakeholder expectations.
A modern roadmap is a strategic communication tool. It is not a stone tablet, but a living document that evolves with our understanding of the market and customer needs. Its purpose is not to control, but to give teams the context and autonomy to make the best possible decisions.
What role do objectives and key results (OKRs) play in linking strategy to agility?
If a modern roadmap is a compass that points in the general direction, OKRs (Objectives and Key Results) are a navigation system that allows you to measure your progress and make sure you’re heading in the right direction for each successive stage of your journey. OKR is a goal-setting framework, popularized by companies such as Intel and Google, that ideally bridges the gap between long-term strategy and short-term, agile execution.
How do the OKRs work? The OKR system is very simple in its concept. It consists of two components:
-
Objective (Objective): This is a qualitative, inspiring and challenging description of what we want to achieve. The objective should be short, engaging and provide clear direction. An example of a company-level objective: “To revolutionize the customer experience in our mobile app.”
-
Key Results (Key Results): This is a set of 2-5 measurable, quantitative results that will show how we intend to achieve the goal. Key Results must be specific, measurable and verifiable. They define what success means. Examples of key results for the above goal:
-
KR1: Increase app store rating from 3.5 to 4.5 stars.
-
KR2: Reduce the loading time of the main screen by 50% (from 4s to 2s).
-
KR3: Increase the weekly user retention rate by 20%.
How do OKRs link strategy to execution? The magic of OKRs lies in their cascading nature and cyclical nature (they are usually scheduled in quarterly cycles).
-
Goal Cascade (Alignment): The process begins with defining several (3-5) company-wide strategic OKRs for the quarter. These goals flow directly from the long-term vision and roadmap.
-
Defining team OKRs: Next, each department and each agile development team defines its own quarterly OKRs that directly contribute to company goals. For example, an application performance team, seeing a company goal of “revolutionize the experience,” might set its own goal: “Ensure lightning-fast application performance,” with key deliverables on API response time and memory usage.
-
Autonomy in action: Once the team has its OKRs defined, it has full autonomy to decide what specific tasks, functions and initiatives (i.e., what will go into the sprint backlog) will best contribute to achieving those results. The team is not held accountable for “delivering feature X,” but for “moving metric Y.”
Shutterstock
With OKR, the conversation with management and stakeholders changes fundamentally. Instead of asking, “Will you deliver feature X by the end of the quarter?” the question is, “What progress have we made toward increasing user retention by 20%?” This shifts the focus from activities (outputs) to outcomes (outcomes) and gives teams room to be nimble, creative and adaptive, while ensuring that the entire organization, like an orchestra, plays to the same tune set by the company’s strategy.
How do you build a planning process that works on different time horizons?
Successfully reconciling strategy with agility requires the creation of a coherent planning system that operates at different levels of “zoom” - from a multi-year vision to daily tasks. Instead of a single, monolithic plan, we need a system of nested, regular cycles (cadences), each with a different time horizon, a different level of detail and different participants. Such a model, often called an “agile operating system,” ensures that work at the lowest level is always consistent with goals at the highest level.
Level 1: Vision and Strategy (Horizon: 1-5 years)
-
Artifact: Product vision, business strategy, strategic roadmap based on themes.
-
Cadence: continuous process, with formal review and update once a year.
-
Participants: management, product leaders, technology leaders.
-
The main question is, “Where are we going as a company and how will technology help us get there?” At this level, we define our “why,” target market and key competitive differentiators.
Level 2: Medium-term planning (Horizon: Quarter).
-
Artifact: Quarterly OKRs of the company and teams, roadmap for the coming quarter (column “Now”).
-
Cadence: Quarterly. This process is often called “Big Room Pla
ing,” “PI Pla
ing” (in SAFe) or simply quarterly planning.
-
Participants: product and technology leaders, all agile development teams.
-
The main question is, “What are the most important outcomes (outcomes) we need to focus on this quarter in order to take a significant step toward our vision?” At this level, strategy is translated into specific, measurable goals. Teams also identify key relationships among themselves.
Level 3: Short-term planning (Horizon: 2-4 weeks).
-
Artifact: Sprint Backlog.
-
Cadence: Every sprint (usually every 2 weeks). This is classic agile scheduling.
-
Participants: development team, Product Owner, Scrum Master.
-
**The main questio ** is, “What is the most important, valuable piece of work that we can complete in this sprint to contribute to our quarterly OKRs?” At this level, goals are decomposed into specific user stories and tasks.
Level 4: Daily Execution (Horizon: 24 hours).
-
Artifact: Sprint task board.
-
Cadence: Daily (Daily Stand-up).
-
Participants: development team.
-
**The main questio ** is, “What does our plan look like for today, and what is standing in our way of achieving the sprint goal?” This is the level of tactical coordination and problem solving.
Such a system of nested feedback loops creates a consistent information bloodstream within the organization. Strategy flows from the top down in the form of goals and context. Information about progress, problems and lessons learned flows from the bottom up, allowing plans at higher levels to be adjusted in real time. It is this mechanism that allows for simultaneous maintenance of direction and flexible adaptation.
How to communicate progress and changes in the roadmap to business stakeholders?
One of the biggest challenges in the transition to agile, results-based planning is changing the mindset of business stakeholders (sales, marketing, management) who are used to receiving specific dates and feature lists. Trying to take away their old, “predictable” roadmap without offering anything in return is a recipe for disaster. The key is proactive, regular and transparent communication that builds trust and changes the nature of the conversation.
1 Educate and explain the “why.” Start by explaining why the old planning model is failing. Use simple analogies. Show historical data that proves that previous, date-based roadmaps were never implemented on time anyway. Explain that the goal of the new roadmap is not less predictability, but a greater chance of building a product that will succeed in the marketplace.
2. regular and structured meetings: Replace chaotic, ad hoc status inquiries with regular, periodic meetings that provide a forum for communication.
-
Quarterly Business Review: Hold a meeting with key stakeholders at the end of each quarter. Instead of showing a list of “features delivered,” present progress on quarterly OKRs. Show data: “Our goal was to increase retention by 20%. We accomplished initiatives A, B and C, resulting in a 12% increase. The conclusions we drew from this are such and such…”.
-
End-of-sprint demo (Sprint Review): Invite stakeholders to regular demonstrations of working software. Nothing builds trust like showing real, tangible progress every two weeks. It’s also a great opportunity to gather early feedback.
3 Tailor the communication to the audience: Not everyone needs the same level of detail.
-
For management: Communicate at the level of strategic themes and progress on company OKRs. Focus on business results and ROI.
-
For sales and marketing: Provide them with regular updates on what customer problems you are solving and the benefits of upcoming changes. Give them insight into the roadmap at the “Now” and “Next” levels so they can plan their activities, but clearly communicate that dates are not a commitment.
-
For customer support: keep them informed in advance of upcoming changes so they can prepare for questions from customers.
4 Be transparent about uncertainties: Don’t pretend to know everything. Use language that reflects the level of certainty. Instead of saying “We will deliver this in Q3,” say “Our goal for Q3 is to solve problem X. We are currently investigating several potential solutions, and our goal is to deliver the first one by the end of the quarter.” It’s tough, but it builds a much stronger, trusting relationship in the long run.
The key is to shift the conversation from “when will it be?” to “what progress are we making toward our shared goals?” It’s a shift that takes time and consistency, but is absolutely essential for success.
How do you budget in an agile environment to support flexibility rather than block it?
Traditional a
ual project budgeting is one of the biggest enemies of agility. This process, in which at the beginning of the year teams must plan and price in detail all the projects they intend to complete, creates a rigid framework that prevents any adaptation. If the budget is “glued” to a specific list of functions, there is no way to be flexible. To fully unleash the potential of agility, an organization needs to move to an Agile Budgeting model.
From project budgeting to financing teams: The fundamental shift is from financing temporary “projects” to financing permanent, long-term product teams (or value streams).
-
The traditional model: “We give you X amount of money to build Functions A, B and C in a year.”
-
Agile model: “We give you X amount of money to maintain Team ‘Phoenix’ for a year. We expect this team, working on product Y, to deliver as much business value as possible during that time.”
In this model, the cost becomes fixed and predictable (the cost of maintaining the team), and the variable is the scope (what the team will actually build). This allows for maximum flexibility. The team, in consultation with the Product Owner and as part of its quarterly planning cycle (OKR), is free to reprioritize and decide what initiatives will best contribute to goals without having to ask for a change in the budget each time.
Principles of agile budgeting:
-
Fund value streams, not projects: Identify key value streams in your organization (e.g., “mobile platform development,” “core system maintenance”) and allocate budget to maintain them.
-
Budget cadence aligned with planning cadence: Instead of a single, rigid a
ual budget, use a rolling model. Approve the budget at the strategic level once a year, but review and reallocate it quarterly, based on performance and changing business priorities.
-
Separate the investment decision from the scoping decision: The decision to fund the team is a strategic decision. Decisions about what specifically this team is to build are made iteratively, in much shorter cycles.
-
Measure return on investment (ROI) at the value stream level: Instead of trying to calculate ROI for each small function, measure how the entire investment in a team or product translates into key business metrics.
The transition to agile budgeting is often a difficult cultural change for finance departments, but it is absolutely essential. Without the flexibility to allocate funds, the whole idea of agile remains only at the level of individual teams and never scales to the entire organization. This is a topic we’ve also touched on in the context of FinOps, where cost-consciousness is built into how teams operate.
What are the most common pitfalls and mistakes in trying to reconcile planning and adaptation?
The road to harmoniously combining long-term vision with short-term agility is fraught with pitfalls. Many organizations, when trying to implement the practices described here, fall into the same repetitive anti-patterns that lead to frustration and a return to old, ineffective methods. Awareness of these pitfalls is key.
1. “Agile Waterfall” (Agile Waterfall): This is the most common mistake. The organization implements agile practices at the team level (sprints, stand-ups), but at the strategic level it still operates in a waterfall model. At the beginning of the year, a detailed a
ual function plan is created, which is then broken down into “sprints.” In reality, there is no room for adaptation and learning. Teams simply execute a predetermined plan in two-week segments.
2 OKR as a To-Do List: Teams and managers do not understand the difference between outcomes and activities (outputs). They create “Key Results” that are actually a list of functions to be delivered, e.g., “OKR: Deliver the social media login function.” This completely distorts the idea of an OKR. The correct KR should read: “KR: Increase the rate of successful registrations by 30%.”
3 Roadmap as a Commitment: Despite the implementation of a modern, theme-based roadmap, business stakeholders (and often IT leaders themselves) still treat it like a hard commitment. Items in the “Next” column are interpreted as promises for the next quarter. This leads to the same problems as the old roadmap - pressure to “stick to the plan” and lack of flexibility.
4 Inconsistency between vision and execution (The “Gap of Why”): Management creates a lofty vision and strategy, but fails to effectively translate it into quarterly goals (OKRs). Development teams, left to their own devices, work on tasks in sprints, but fail to understand how their daily work contributes to the company’s larger goals. A “meaning vacuum” is created, leading to decreased motivation and wasted resources.
5 Fear of “saying no” and over-commitment: In a culture that fails to prioritize, the roadmap and backlog become a wish list where everything is “top priority.” Teams become overloaded, trying to accomplish too many initiatives at once, leading to declining quality, burnout and failure to deliver any of them on time and in good quality.
Avoiding these pitfalls requires ongoing education, discipline and, most importantly, courageous leadership that is willing to fundamentally change the way we think about planning, success and failure.
What does an agile operating system look like from vision to daily execution?
To effectively combine strategy with agility, an organization must build a coherent “operating system” - a set of interconnected rituals and planning artifacts that operate on different time horizons. The table below synthesizes this model, showing how vision is translated into daily execution in a way that provides both consistency and flexibility.
| Time horizo | Plaing artifact | Cadence (cycle) | Key participants | Main questio |
| **Long-term (1-3 years)** | Product vision and strategy. Strategic roadmap based on themes. | Once a year (review and update). | Management, product and technology leaders. | Where are we headed? What market problems do we want to solve? How will we win? |
| **Medium-term (Quarter)** | Quarterly goals and key results (OKRs). Tactical roadmap ("Now" and "Next"). | Every 3 months (e.g., Quarterly Pla
ing). | Leaders, Product Owners, Development Teams. | What results do we need to focus on this quarter to get closer to our vision? |
| Short-term (2-4 weeks) | Sprint backlog. Sprint Objective. | Every 2-4 weeks (Sprint Pla
ing). | Development team, Product Owner, Scrum Master. | What is the most important working piece of the product that we can deliver in this sprint? |
| Daily (24 hours) | Sprint task board. | Daily (Daily Stand-up). | Development team. | What is our plan for today to achieve the sprint goal and what is preventing us from doing so? |
Planning an IT project? Learn about our Software Development services.
See also
- Data Mesh in Practice: A strategic guide to decentralizing data and unleashing true business agility
- A guide for the non-technical leader: How to effectively manage and inspire high-performance engineering teams.
- Agile PMO: How to transform the Project Management Office from a bureaucratic gatekeeper to a strategic value architect?
Let’s discuss your project
Have questions or need support? Contact us – our experts are happy to help.
How does ARDURA Consulting’s partnership approach help leaders build effective IT operating systems?
At ARDURA Consulting, we understand that reconciling strategic planning with agile execution is one of the most difficult challenges of technology leadership. It’s a problem that requires not only the implementation of the right tools and processes, but more importantly, a profound cultural and organizational change. As a strategic technology partner, our role goes far beyond delivering code. We act as a Trusted Advisor, helping IT leaders design and implement effective operational systems that drive growth and innovation.
1. strategic consulting and facilitation: we help you move away from outdated planning models. We facilitate strategy workshops with your leadership team, helping you create a modern, results-based roadmap. We help you implement and scale frameworks such as OKRs in a way that makes sense in your unique organizational context. We act as an external, objective voice to help break down internal silos and build alignment.
2. organization design and transformation support: We understand that the process must be supported by the right structure. Based on Conway’s Law and modern models such as Team Topologies, we help you design a structure for development teams that promotes autonomy, minimizes dependencies and allows for efficient, parallel value delivery.
3 Building a technical foundation for agility: We know that true organizational agility requires the right architecture. Our engineering teams have deep expertise in designing and building systems based on microservices architecture, which is the technical foundation for independent, autonomous teams. We support the **migration ** process from the monolith, unlocking your organization’s agility.
4 Flexible delivery of competencies: Often the biggest barrier to achieving an ambitious roadmap is the lack of the right people. In flexible collaboration models such as **Staff Augmentation ** and Team Leasing, we deliver entire agile teams or individual experts who not only accelerate your goals, but also bring agile software development best practices to your organization.
At ARDURA Consulting, we believe that the best technology organizations are those that can masterfully dance at the edge of plan and adaptation. Our goal is to be the partner that not only provides you with great dancers, but also helps design the stage and teaches your organization the steps of that dance. If you’re struggling with the conflict between the need for vision and the pressure for agility, consult with us on your project. Together we can build an operating system that will allow your company to not only survive, but thrive in a rapidly changing world.