The Roadmap Needs a Budget for Frontline Attention

Imagine a hypothetical field salesperson opening a mobile sales application between two visits. A familiar action has moved. A new mandatory field appears. An additional prompt asks for information that will become available only later. Each change may have a reasonable explanation. Together, they ask the person to stop selling and work out how to satisfy the software.

My answer is straightforward: adoption belongs in the enterprise roadmap because every product change spends user attention. That cost needs to be considered alongside development effort, business value and delivery priorities—not left entirely to training after release.

A release has two different costs

As Founder & Growth Head at Vahmine, I think about enterprise SaaS through both the product being built and the work it is meant to support. Toolyt, Vahmine’s field sales automation product, makes frontline use a relevant lens for that thinking. I am not describing a particular customer experience or claiming an adoption result here.

A roadmap usually makes the cost of building visible. There are dependencies, technical decisions and competing demands on the team.

I believe it should also make the cost of absorbing change visible.

A small engineering change can require a substantial adjustment from a user. Renaming a familiar action, changing when information becomes mandatory or rearranging a frequently used screen may be simple to implement. Understanding the new expectation is someone else’s work.

This does not mean familiar interfaces must remain untouched. It means “small release” and “small disruption” are different judgments.

Mobile usability includes the moment of use

Return to that hypothetical salesperson. The problem is not necessarily an inability to understand the application. The person may understand it perfectly when seated at a desk, with time to explore.

Between visits, the available attention is different.

For me, this changes the mobile usability question. Instead of asking only whether an action is possible, I would ask whether the action is reasonable at that moment. Does the user have the information being requested? Can the task be interrupted without uncertainty? Is it clear what has been completed and what remains?

These are questions for product evaluation, not statements about existing Toolyt features.

A compact screen can still carry an unreasonable demand. Fewer taps do not help much if the user must pause to interpret an unfamiliar instruction. Equally, an extra confirmation may be worthwhile when it prevents an ambiguous commitment.

The objective is not minimum interaction at any cost. It is an interaction that respects the circumstances of the work.

Sequence change, not just delivery

This is where adoption becomes a roadmap decision rather than a communication task.

Consider a hypothetical release plan containing a revised navigation structure, new reporting requirements and a changed approval process. Each proposal might deserve to proceed. Shipping them together, however, creates a combined learning burden that individual feature reviews may miss.

I would want the roadmap discussion to examine that combined burden before deciding the sequence.

Could one change establish a stable foundation for the next? Could a requirement wait until the point where the necessary information exists? If a new step is added, is an obsolete step being removed?

Training can explain a deliberate change. It should not have to compensate for an incoherent sequence of changes.

Nor does every adoption concern require new software. Some require a clearer operating decision, a different rollout order or restraint. Giving adoption a place in the roadmap means making those choices explicit, not creating an unlimited queue of usability requests.

A practical attention check

Before committing a frontline-facing change, I would use this checklist:

• Name the adjustment: What must an existing user do differently?
• Locate the moment: Where and under what constraints will that adjustment happen?
• Check information readiness: Can the user reasonably know what the product asks for at that point?
• Review the combined load: What other changes will the same person need to absorb?
• Identify the subtraction: What old step, instruction or uncertainty can be removed?
• Plan the review: What observations would justify keeping, revising or delaying the change?

I would not turn attention into a falsely precise score. The value is in making a previously hidden cost discussable.

A roadmap tells people what we intend to build. I want it also to show that we have considered what we are asking people to carry.

For enterprise SaaS, progress is not simply more capability reaching a mobile screen. Sometimes it is a carefully chosen change arriving when the person holding that screen can give it the attention it deserves.