What Should the Product Teach—and What Must the Organisation Explain?

Imagine a hypothetical employee opening a new enterprise application for the first time. The interface explains how to submit a request. The employee follows the instructions, reaches the final screen, and hesitates: is this the kind of request their organisation expects them to submit?

Another feature might make submission easier. It would not necessarily resolve that hesitation.

My direct answer is this: define an enterprise SaaS strategy by separating what the product must make understandable from what the organisation must make clear. Then decide how those two kinds of knowledge meet during actual work. Onboarding and learning belong inside that decision, not after the feature list is settled.

Two kinds of uncertainty can look like one problem

I find it useful to distinguish product knowledge from organisational knowledge.

Product knowledge concerns the application itself: what an action does, what information it requires, and what happens next. Organisational knowledge concerns the setting in which the application is used: why a task matters, which local expectations apply, and what constitutes an appropriate choice.

A user can understand the interface and still lack the context to act. Equally, someone can know the business process well and struggle to express it through the software.

From a distance, both situations can look like poor onboarding. But they suggest different product decisions.

In the hypothetical request workflow, adding a clearer button addresses navigation. Explaining when the organisation expects a request addresses judgement. Treating these as interchangeable risks producing an elaborate interface around an unanswered question.

For me, strategy begins by naming which uncertainty we intend to resolve—and which uncertainty we cannot responsibly resolve on the customer's behalf.

Make the learning promise specific

As Founder & Growth Head at Vahmine Technologies, I see customer and employee learning as a product question. Acadle is a Vahmine product for that purpose. This context makes the distinction especially relevant, without implying that a learning product should decide an organisation's operating practices.

A broad promise such as “help people get started” leaves too much unsettled.

Does getting started mean understanding the software? Understanding an employer's process? Knowing how to apply a customer's service in a particular role? These purposes may overlap, but they are not identical.

I would rather write the strategic promise in plain language:

We will help this kind of user understand this part of their work, while making space for the organisation to explain the context it owns.

The wording is deliberately unfinished. A product team must fill it in. The choices reveal the intended user, the scope of the learning experience, and the limits of the product's authority.

That is more useful than declaring that the next release will make onboarding “better.”

Design the meeting point, not just the content

Consider a second hypothetical example: customer onboarding for an enterprise application.

The software provider can explain what an action does. The customer organisation may need to explain who should take that action and under which circumstances. If these explanations live entirely apart, the user must assemble the meaning alone.

The strategic question is therefore not simply whether to add more learning material. It is how product guidance and customer-specific context should meet without becoming confused.

Should organisational context appear during initial orientation or when a relevant task arises? Who is responsible for keeping that context accurate? Can the user tell the difference between an explanation of software behaviour and a local instruction?

These are questions to settle before choosing a feature. Otherwise, a team may build a place to store information without deciding what role that information plays.

I would also resist using learning to excuse an unclear interface. Instructions should explain necessary complexity, not preserve avoidable confusion.

A checklist before the feature brief

Before approving the next feature, I would ask:

• Name the user: Whose work are we helping, rather than which buyer are we reassuring?
• Locate the uncertainty: Is it about operating the product or understanding the organisation's expectations?
• State the promise: What understanding should our product provide?
• Assign the context: What must the organisation explain and maintain?
• Choose the moment: When does the user need that explanation to make a sensible decision?
• Challenge the feature: Could clearer interaction or better-placed context address the need instead?

The employee in the opening scene does not necessarily need another capability. They need the application and their organisation to give complementary answers.

That is the strategy I would want to clarify before building: not merely what the software will allow, but how a person will understand when and why to use it.