DEV Community: Anton Kleshchev

Replacing Intuition-based Roadmaps with a Lightweight Data-Driven Approach

Anton Kleshchev — Wed, 15 Jul 2026 20:28:50 +0000

Why Building Roadmaps through Intuition Creates Major Risks

Overruns remain a big problem in the software development industry. A study by McKinsey & Company found that businesses have IT projects running at 45% over budget on average while delivering 56% less value than the original forecast. This inefficiency leads to millions of dollars in losses and threatens the sole company existence for 17% of businesses. [1] The study indicates lack of business focus, unrealistic schedules, and unaligned teams as the major causes of project failures.

In software companies, roadmaps play two important roles. They show the list of business initiatives the company is focusing on and present how many of those initiatives they aim to deliver within the next few months. Such representation serves multiple purposes:

Alignment of teams and leadership on the company’s priorities, backed up by financial and timeline constraints
Helicopter view and scoping on strategic initiatives
Prediction on future needs for resources and scarce talent

While such representation is critical for a company's performance, very few companies dedicate the necessary amount of time on creating roadmaps. Usually no formal process is introduced, and roadmap creation is performed by surface data and intuition. [2] Items are sketched on a whiteboard or in Excel where:

Engineering teams may not be present or participate in validating the commitments
Items are positioned manually without proper adjustment for risk buffers, strict control of work-in-progress, or dependencies
Scope and assumptions are not recorded and communicated verbally

While intuition-based approach looks simple and straightforward on surface, studies show that it is highly vulnerable to a cognitive bias. People systematically underestimate the time, costs, and risks of future tasks while overestimating their benefits. [3] A better approach would be using more reliable planning methods and developing proper governance over the planning process [4] while maintaining short delivery cycles to avoid waste. [1] Such a strategy can improve deliverability and performance. [1]

Is Intuition the Only Option for Building Roadmaps?

Certainty-Related Argument
Many developers, or even product leaders, don’t like to look long-term, and so claim that the reason for the gap is that software development is too uncertain to be planned ahead. But is it really?

Interestingly enough, many software development companies have departments called “Research and Development.” In other industries, such as construction or manufacturing, the term “research” is not used widely. There is analysis, execution, and handoff, but not research. This is the term that we hear much more widely in scientific projects, along with some other terms such as “hypothesis” or “probabilities.”

Indeed, in software development, there are often many unknowns. Just like in science. Or in VC investments. Or when people built a project to go to the Moon. And yet, despite all the complexities and volatilities, people manage to figure out the way to achieve great and satisfactory results with long-term goals and commitments validated ahead of time with reasonable precision.

Of course, software development has its unique flavor and challenges, but probability planning models in that industry are absolutely possible. Some examples include the famous Cone of Uncertainty model, Monte-Carlo Simulations, and Planning Poker. All of those models are implementations of different techniques taken from probability theory and statistics and have proven their efficiency. [5]

High Roadmap Volatility Argument
Many managers admit that roadmaps should be a verified vision, not just a wishlist. However, nobody wants to dedicate the necessary time on creating roadmaps with verified resource allocations, dependencies, and risk balancing while knowing that, next month, priorities will shift and everything will need to be changed once again. In other words, they don’t want to spend a lot of time on something extremely volatile.

While this argument makes sense, it’s important to realize that as mentioned earlier, bad alignment and unrealistic commitments can cost a very high price from a company’s overruns, which may substantially exceed the cost of time spent on a quality roadmap reassessment. [1] This right approach would be maintaining a balance between the simplicity of the process and roadmap reliability.

Conclusion
Main reasons for the intuitive process include high uncertainty of software development and big volatility of business priorities. These constraints however can be addressed by two things respectively: using appropriate probabilistic planning techniques and keeping the balance between simplicity of the planning process and roadmap reliability.

Presenting an Alternative Solution: Building Roadmaps with a Lightweight, Data-Driven Approach

To pivot from the research, here is a quick word from my viewpoint as a practitioner. A major problem exists with the intuitive process, and I have personally encountered it multiple times in my career. Throughout my work in different companies I couldn’t find a comprehensive replacement to address the problems. Now I want to share an alternative lightweight, data-driven solution for building roadmaps that I have personally developed and used for years as a Software Architect in Enterprise.

In a fast-paced and highly-volatile environment, we were able to use this solution to deliver numerous successful projects that involved international cross-team collaborations and tight coordination with product and project managers. Every project contained different levels of uncertainty, as well as multiple internal and external risk factors. All were delivered on time, including when delays were negotiated due to priority shifts, and without major disruptions. Some projects were mid-size (3-4 months), some required a longer timeline (1-2 years). This solution helped the company avoid risky investment decisions, properly allocate the load between development teams, and build trust with stakeholders. Not once was the process rigid or overly tedious, it only required basic effort to keep the governance.

Let’s get into it.

First Step: Define the Portfolio
To replace an intuitive process with a more structured one, we need to take a step back and define a portfolio first. The portfolio defines the signals worth exploring. Similar to scientific or VC planning, the hypothesis, or signal, is defined as being worth investment and testing. Once enough information about a particular signal is collected, it can be either reinforced or cancelled to leave opportunity for new developments.

In the era of AI, this becomes particularly relevant. Some signals can be tested in a single day, while others may need more steps and a month of research and development. Which signals are worth exploring? Without portfolio modelling, this question isn’t possible to answer properly.
Now is when roadmaps come into play. The roadmap should serve not just an execution plan, but first of all, as a proof of portfolio feasibility.

Build the Portfolio
The portfolio should contain current business hypotheses the company wants to test with clients. Normally, we talk about initiatives and features that represent underlying business ideas. Each feature or subset of features could be prioritized against their potential ROI using different product management frameworks (such as RICE, Kano, etc).

Collect the Data
All requirements, dependencies and other inputs should be carefully collected, verified with teams, and recorded for current and future reference. Some technical inputs, such as high-level estimates, must include a level of uncertainty and assumptions. The data shouldn’t necessarily be 100% or even 50% complete, but if there is any level of risk, it must be recorded. Different techniques could be used for estimation, such as using historical data, planning poker, etc. The book Software Estimation: Demystifying the Black Art by Steve McConnell provides excellent insight into highly effective methods of estimation, even for incomplete or lost reference data [5].

Do the Sequencing
Once the data is available, the next important step is execution sequencing. All data pieces must be evaluated:

Which scope do we assume for each feature?
Which teams will be performing the features?
Are there any dependencies?
What is the risk buffer? How does the buffer correlate with uncertainty and risk appetite?
How calendar days allocated for the tasks relate to the teams’ availability and velocity?

These steps will ensure teams’ productivity by limiting work-in-progress and minimizing delays caused by local disruptions [6].
The sequencing is a tedious process so it’s better to use specialized project management tools to keep the process bias-free and lightweight. I used Excel, MS Project, and Wiki to calculate dates and store assumptions. Right now I’m using my own probabilistic planning tool built in-house that makes this tiresome process easier.

Perform Alignment
Developers, stakeholders, managers and other parties must be invited into the roadmap alignment. There could be multiple rounds of reviews where parties will be able to verbalize gaps in data, scope preferences, or claim ownership of features. This is also a good time to reassess the portfolio hypothesis in case it wasn’t proven practical. A properly aligned roadmap serves both as a proof of portfolio visibility and an execution strategy.

Execute and Track the Status
The roadmap can be executed using normal short development cycles, like sprints. Measuring the portfolio progress should be connected to measuring the progress and completion status of the underlying initiatives, features, and their dependencies. This should be an ongoing and frequent process—ideally, synced to the short development cycles—to address the potential risks and make any necessary adjustments early. To update the roadmap, follow the same steps, starting from updating the portfolio inputs, and proceed downstream.

Summary

Roadmaps treated as static promises or intuition-driven sketches pose major risks for companies performance and deliverability. Organizations can avoid the trouble by validating portfolios using a lightweight approach featuring structured data, explicit assumptions, and good alignment. The goal is not to eliminate uncertainty but to make it visible and manageable, thereby significantly reducing the risk.

Links

[1] - Research “Delivering large-scale IT projects on time, on budget, and on value” by Oxford.
[2] - Research “Decision-making in Software Product Management: Identifying Research Directions from Practice” by Andrey Saltan, Slinger Jansen and Kari Smolander
[3] - Research “Exploring the “Planning Fallacy”: Why People Underestimate Their Task Completion Times” by Roger Buehler, Dale Griffin, and Michael Ross
[4] - Research “Eliminating Bias in Early Project Development through Reference Class Forecasting and Good Governance” by Oxford
[5] - Steve, McConnell. Software Estimation: Demystifying the Black Art (Developer Best Practices) . Pearson Education. Kindle Edition.
[6] - Research “Implementing critical chain to improve product development performance” by Stanford.

Beyond Sprints: A Scalable Milestone-Based Planning Model for Midsize Companies

Anton Kleshchev — Wed, 12 Nov 2025 17:46:34 +0000

Imagine a scenario. A software startup company, featuring 3 development teams and utilizing a Scrum framework, starts working on something promising and significant: AI integration to their existing product solution. They decide that the next quarter will focus on developing an AI that aims to deliver the minimum necessary toolset for their clients. They define a backlog and stuff it with features and priorities. Teams Eagle, Tiger, and Lion pull features from the backlog for their sprints.

This is where problems start. Team Eagle discovers that the feature they pulled depends on the feature that Team Tiger has pulled. They decide to wait until Team Tiger has completed development. Simultaneously, Team Lion’s work is shuddered to a halt when they realize they don’t have enough members with a sufficient skillset in the domain area. Lion must learn it from scratch and waste time on catching up. For all three teams, Eagle, Tiger, and Lion, the majority of features remain in the backlog. Complex and tedious, these neglected features gather dust in the backlog as teams prioritize those that will meet deadlines. The work on them will only start after an additional decomposition and the manager's pitch. In the best case scenario, a company spends 60%-70% of time on features and the rest on figuring out planning.

This scenario isn’t rare but a pattern that often plagues growing tech companies. For many years, Scrum has been a popular framework to organize and execute software development. The process is pretty straightforward: define and prioritize a backlog, break down the release cycle into iterations, and pull the important items in each iteration from the top of the list for team execution. Team members select work they’d like to do from the iteration tasks based on their preferences. Sounds simple and easy to follow. However, there are some nuances:

Scrum is designed to work perfectly for only one team. When more teams are involved, the process doesn’t scale well. The backlog grows massive. Work items have many dependencies and are specific to particular modules and domain areas. Task allocation is based on the tightrope of juggling between priorities and particular team member preferences. Consequently, sprint planning is messy and time consuming.
Short term planning by sprints may answer the question of delivering particular features or use cases within the next weeks or a month. However, many projects require months or even quarters to deliver with no way to prioritize and track the progress for those projects in the scrum process. For teams, scrum is essential. From the strategy standpoint of the company and its clients, it’s chaos.
Sprints put boundaries on release timing, which does not necessarily fit the feature MVP size. This creates an artificial need to place barriers, such as feature flags for functionality that are deployed within the sprint but dormant until the feature is completed.

The Solution
Now let’s think about alternatives or potential improvements to this process.
Let’s craft a thought experiment with a few adjustments:

We remove the boundaries for sprint planning and replace it with the boundaries for company planning. A milestone that features a particular strategic goal (such as a key result or direction) and time constraints that match it (quarter, year, etc).
Instead of allowing teams to select tasks, we allow them to select their domain area and specialization. We then allocate those tasks between teams manually or, preferably, by developing a script or using the automated scheduling and planning app Deep Planner, which takes into account task estimates, priorities, dependencies, and team capacities.
Teams perform tasks based on their assignments and use a continuous delivery to commit their work. No more feature flags.
Upon changes in priorities or delays in implementation the remaining tasks on schedule are re-allocated based on the new conditions by maintaining the strategic milestone direction. It is important to let the teams finish their work on tasks in progress or replan them wisely to avoid disruptions in development and teams’ dissatisfaction.

With those adjustments Team Eagle will have work allocated before Team Tiger completes the blocker. Lion will never work on the task which they lack skillset. Instead, it will be assigned to the team that is better suited for it. All tasks from the backlog will be allocated efficiently and will use all of the teams’ potential.

In my work as a Product Owner, I practiced this approach multiple times. I called it a Milestone-based Planning Framework. I found that it shows very encouraging results. Our planning time and the related communication has decreased by 70% with almost 90% backlog completion by the end of the milestone. My team has a clear vision of priorities, agency over the work they prefer to accomplish, and less anxiety and confusion over the features we will be capable of delivering by the deadline - very important for us and clients. We can still be flexible and predictable and use all of our teams’ resources wisely.

I want to emphasize that this approach only becomes effective when using automated tools that enable quick and effective planning and adjustments. Use Deep Planner to:

Quickly create a blueprint of a plan using backlog and team configuration
Adjust plans and re-plan items that were delayed or de-prioritized in seconds
Provide real-time visibility for roadmap and current team priorities for developers and stakeholders

I also highly recommend Git and Azure DevOps for continuous delivery.

Try it and share your experience!

Make Agile more Flexible

Anton Kleshchev — Thu, 22 Aug 2024 19:01:00 +0000

Introduction

We all know that Agile is a methodology designed to make project planning and implementation dynamic and flexible. Today we're creating a schedule for one set of features and tomorrow after reviewing a demo we can change it according to our adjusted needs and purposes. This sounds really great, however this has a price: the planning we perform needs to be constantly changed and maintained according to the needs and priorities of all parties: team leads, managers, corporate leaders and stakeholders. Often such hierarchy of product owners makes planning stiff and highly resource consuming and leads to hesitation in making radical and frequent changes to the company roadmap. Therefore there is a space to make this process a bit more flexible by introducing a clear continuous algorithm for the planning process.

The Algorithm of a Continuous Planning Process

I call this algorithm an "Evolutionary Timeboxing".
This algorithm can be used any time at any point whether it's in the middle of the sprint or the beginning of the quarter, in general at any time.
Let's go over the main steps:

Define planning horizon you want to plan for. This is similar to military where you can perform strategic (year+), operational (quarterly) or tactical (iteration or N weeks time span) planning.
Decompose the business requirements of the project(s) into system components for all levels (where it's necessary). Define an estimate, nature of work for all activities. Define clear dependencies between system components and dependencies on the components of other projects.
Define a timebox which is the target of your planning. Add or adjust the system components as deliverables for that timebox. Account for level of effort and available teams.
Adjust or define all other timeboxes for the current and all other layers according to the new changes. Keep all layers synchronized. Notify the teams accordingly.

By following this algorithm it's possible to maintain a continuous and very flexible process of planning which is clear and transparent to both stakeholders who require high level vision (i.e. strategic level), project and product managers (operational level) and regular developers (tactical level). Currently I'm working on automating the reshuffling part which should make the process even more easier.
Let me know what you think about and your general thoughts of this practice!

Should Senior Software Engineers do Project Management?

Anton Kleshchev — Tue, 20 Aug 2024 19:33:39 +0000

Hello everyone, this is my first post here which I wanted to start with a discussion which was the point of curiosity for me for many years of my work in IT. Here is the question: should senior software engineers do project management?
Let me give you some context here. My career path like many others started with coding only. Later it progressed to other levels where coding was becoming less and less of the main responsibility and in the end I had very little of it or not at all. Instead one of the main tasks of a senior technical lead person is to decompose business requirements into functional system components and provide an estimate and team recommendations to implement it. And this is where things start to be really interesting.
Think about it. The primary goal of any Product Manager is not just to understand the cost of the project but also the timeline of when it's going to be implemented. I had this question coming all the time from PMs and stakeholders. To build this timeline you need to be really well aware of technical specifications of the project, its dependencies and nature of work to be completed. Usually Project Managers don't have such insights so they ask developers to help with that. So major part of my work was building draft schedules and working on project design not just from technical but also from execution side of things. I even created an app which can automate this and hopefully help simplify this process in future (if you're interested you can check it out here ).
What do you think of this question? Should responsibilities of Tech Lead/Architect include partially the responsibilities of a Project Manager?