Not Every User Difficulty Belongs on the Roadmap

Imagine a hypothetical enterprise SaaS planning meeting. The next feature request sounds straightforward: add more guidance to onboarding. Someone suggests a walkthrough. Someone else proposes a learning module. Another person wants the workflow redesigned.

All three suggestions might be reasonable. But they describe different problems, and choosing between them is a product strategy decision—not simply a question of what can be built next.

My direct answer: before choosing the next feature, define which user difficulty the product should remove, which understanding learning should support, and which decision belongs to the customer’s organisation. A roadmap becomes more coherent when those responsibilities are explicit.

A request does not tell us where the problem lives

As Founder & Growth Head at Vahmine Technologies, I see enterprise SaaS strategy as a set of choices about the work a product takes responsibility for. A feature list can express those choices, but it cannot substitute for them.

Consider a hypothetical employee who stops midway through an onboarding task. “The user needs help” is a description of the moment, not an explanation.

Perhaps the interface uses an unfamiliar label. Perhaps the employee understands the label but does not know the organisation’s approval policy. Perhaps the task requires professional judgement that no interface instruction can supply.

These are not interchangeable needs.

A clearer label belongs in the product. An unsettled approval policy needs an organisational decision. A recurring judgement may need learning, practice or access to appropriate guidance.

If I treat every hesitation as a missing feature, I risk making the software carry responsibilities it cannot fulfil. If I treat every hesitation as a training need, I risk asking users to study around avoidable design problems.

Onboarding is where these responsibilities meet

Onboarding is useful to this discussion because it brings unfamiliar software, unfamiliar work and unfamiliar expectations into the same experience.

A product team needs to distinguish among them before deciding what to build.

In a hypothetical customer onboarding journey, a person might understand how to enter information but not why their organisation needs it. A tutorial about the form would answer the wrong question. Equally, a detailed explanation of business purpose would not repair a confusing form.

I would write the intended onboarding experience in plain language before discussing features:

The product makes the required action understandable. Learning explains the concepts needed to perform it thoughtfully. The organisation supplies its own rules and authority.

That statement is not a universal architecture. It is a starting agreement that a team can challenge. Its value is that it prevents “improve onboarding” from becoming an unlimited container for unrelated work.

Learning should have a defined job

Acadle is a Vahmine product for customer and employee learning. That context makes the relationship between learning and software particularly relevant to my product thinking.

I would not start by asking how much learning material a user should receive. I would ask what kind of understanding should exist outside the immediate interface.

Some knowledge is local to an action: what a field means, what happens when an option is selected, or how to correct an entry. Other knowledge travels across tasks: why a process exists, how responsibilities differ, or how to recognise an exception.

That distinction matters when deciding whether a need calls for interface work, learning support or both.

Learning should not become a storage room for explanations the product team could not place properly. Nor should the interface become a textbook merely because the subject requires understanding.

For me, strategy means choosing a purposeful relationship between the two. The product supports action; learning provides room for understanding that deserves more attention than an instruction beside a button.

A practical test before approving the feature

Before moving a proposed feature into delivery, I would use this checklist:

• Name the user and task. Who is struggling, and what are they trying to accomplish?
• Describe the difficulty without naming a solution. Avoid starting with “we need a walkthrough” or “we need a course.”
• Locate the missing support. Is it interface clarity, subject understanding, organisational policy or authority to act?
• Assign responsibility. What should the product provide, what should learning address, and what must the organisation supply?
• Check for displaced work. Are we using training to compensate for poor design, or software to conceal an unresolved policy?
• State the feature’s purpose. Explain what it will resolve and what it deliberately will not.

I do not expect this exercise to eliminate ambiguity. I expect it to make the ambiguity discussable before it becomes software.

The next feature may still be the right choice. But I want to approve it because we understand where the difficulty belongs—not because building something feels more decisive than examining it.