Before the Next Feature, Define What Customers Can Change

Imagine a hypothetical enterprise SaaS planning meeting. A customer wants a different onboarding sequence. Another wants separate learning paths for employees and customers. Someone suggests adding more settings so both requests can fit. The backlog grows, but a more important question remains unanswered: how much difference should the product accommodate?

My direct answer is this: before building the next feature, define the product’s shared core, the variations customers should control, and the responsibilities that remain outside the software. That distinction gives enterprise SaaS strategy something concrete to govern.

A strategy needs a position on variation

As Founder & Growth Head at Vahmine Technologies, I see enterprise product strategy as a set of choices about how software should serve different organisations without losing its own shape.

“Flexible” is not enough of a position. Flexible for whom? Around which decisions? With what consequences for the person using the product?

A product can allow an administrator to change a process while making that process harder for everyone else to understand. It can also insist on consistency where an organisation has a legitimate reason to work differently.

I would therefore begin a strategy discussion with a distinction: which user needs are shared, and which expressions of those needs belong to the customer’s context?

The shared need might be knowing what to do next. The local expression might be the order of an employee’s induction activities. Those are related, but they should not automatically become the same product requirement.

Onboarding reveals the choices we have postponed

Onboarding is a useful place to examine this distinction because it brings organisational expectations into contact with an individual user’s uncertainty.

Consider a hypothetical learning product serving both customer education and employee induction. A customer may need help understanding how to use an offering. An employee may need to understand responsibilities within an organisation. Both involve learning, but the purpose, ownership and surrounding expectations can differ.

A strategy that treats these as identical may flatten important needs. A strategy that treats every difference as a separate product may fragment the experience.

The question I would ask is: what should remain recognisable across these situations, and what needs to be different?

Perhaps clarity about the next action belongs in the shared core. The organisation’s explanation of why a particular activity matters belongs to its own context. Whether a proposed variation requires software support is a further decision—not an automatic conclusion.

This is why onboarding should enter the strategy conversation before the feature specification. It exposes assumptions about who prepares the experience, who participates, and who decides what participation means.

Learning is part of the product’s division of responsibility

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

I do not see a learning product as responsible for deciding everything an organisation ought to teach. Nor should software become a neutral container that leaves every meaningful choice unexplained.

There is a division of responsibility to establish.

The product team must decide what the software makes clear and coherent. The customer must supply the organisational meaning that software cannot responsibly invent. Where these responsibilities meet, the product needs deliberate choices rather than an accumulation of options.

For example, in a hypothetical employee onboarding programme, the organisation owns the explanation of its internal responsibilities. The product decision is how much structure the software should provide around that learning experience. These are different kinds of ownership, even when they appear together on the same screen.

Write the strategy as a boundary people can use

Before approving another feature, I would use this checklist:

• Name the shared need. Describe what users need across organisations without prescribing a feature.
• Identify the legitimate variation. Explain why customers may need different approaches.
• Assign ownership. Separate product behaviour from customer content, policy and operating decisions.
• Choose the treatment. Decide whether the variation deserves a common behaviour, configuration, or no software accommodation.
• Review the onboarding consequence. Ask what a new user or administrator would now have to understand.
• State the refusal. Record which related requests this strategic choice does not support.

The result need not be a grand document. It should be a position clear enough to guide disagreement.

I want the next feature to express a product strategy, not quietly substitute for one. Before asking what else the software can do, I would ask what customers should be free to change—and what they should be able to rely on staying coherent.