When people begin building software, they often think in terms of features.
A dashboard. Reporting. Organizations. Roles. Notifications. Billing. Analytics.
Each of those capabilities may eventually matter, but none of them explain why the product deserves to exist.
Before adding significant features to a product, I try to identify what I call the product kernel.
The product kernel is the smallest repeatable workflow that creates meaningful value for the user.
It is the reason someone uses the product, completes the workflow and has a reason to return.
Everything else should either strengthen that workflow, make it easier to access or help the business deliver it reliably.
The temptation to build the finished platform
When I started building PassPaperOnes, it was easy to imagine the complete platform.
I could already see teacher dashboards, school administration, organization accounts, subscriptions, reporting, analytics and AI-supported feedback.
Those ideas were useful because they gave the product direction. However, they were not the first problem that needed to be solved.
The first question was much simpler:
Can a student open a question, submit an answer and receive feedback that genuinely helps them learn?
That was the kernel of PassPaperOnes.
The original value was not the dashboard surrounding the practice experience. It was the learning loop itself.
A student needed to be able to choose an area of study, answer a question, understand whether the response was correct and learn from the explanation.
If that experience was weak, then adding school dashboards would not rescue the product. Adding more roles would not rescue it. A more polished billing page would not rescue it.
The product had to earn its surrounding systems.
PassPaperOnes grew around the learning loop
Once the student practice workflow became useful, the next layers became easier to justify.
Multiple-choice practice expanded into stronger explanations and more structured subject coverage.
Short-answer practice introduced a different challenge. The platform could no longer simply compare one selected option against an answer key. It needed to interpret meaning, award partial credit and explain why a response earned or lost marks.
That created a new version of the same kernel:
A student responds, the system evaluates the response and the student receives useful guidance for improvement.
The technology changed, but the value loop remained recognizable.
Teacher assignments came later because they improved access to the kernel. They gave teachers a way to direct students toward specific practice activities.
School dashboards came later because they helped organizations observe whether students were completing those activities and where support might be needed.
Subscriptions and access plans came later because the business needed a reliable way to fund delivery of the kernel.
These were not unrelated features. They were layers around a working learning experience.
The kernel is not the management interface
One common product mistake is confusing the software used to manage the service with the service itself.
A learning platform is not primarily its dashboard.
A booking system is not primarily its calendar.
A certification platform is not primarily its reporting screen.
Those tools are important, but they usually support the value rather than create it.
This distinction matters because management features are often easier to imagine than the actual user outcome.
Dashboards look complete. They create the impression of a mature platform. They are also easy to overbuild before there is enough real activity to manage.
The kernel forces the product back toward the user.
The same lesson appeared in MakoraDesk
MakoraDesk presented a different product problem, but the same principle applied.
The platform could potentially support assessments, training events, participants, certification, administration, reporting and operational workflows.
It would have been easy to begin by designing a large organization management system.
That could have meant complex permissions, multiple organization structures, extensive configuration screens, large dashboards and advanced reports before the primary workflow had been proven.
Instead, the more useful question was:
Can an organization create an assessment or training activity, manage the people involved and produce a reliable outcome?
That is closer to the kernel.
The value is not simply that an administrator can open a dashboard. The value is that an organization can take an activity from setup to completion without losing control of the process.
The workflow may include creating the activity, adding participants, recording results and producing evidence of completion.
Reporting, certification and expanded administration become valuable because they strengthen that process.
The platform grows around a dependable operational loop rather than trying to discover its purpose after the surrounding software has already been built.
Growth should follow evidence
Identifying the kernel changes how development priorities are chosen.
Instead of asking:
What impressive feature should I build next?
The better question becomes:
What is preventing more users from completing the core workflow successfully?
Sometimes the answer is onboarding.
Sometimes it is poor feedback.
Sometimes it is unclear navigation, weak authorization, slow loading or a workflow that requires too many steps.
Sometimes the next valuable improvement is not a new feature at all. It may be reliability, clarity or better support for an existing action.
This is why evidence matters.
Real usage reveals where the kernel is breaking. It also reveals which surrounding capabilities users actually need.
The product begins to expand in response to observed friction rather than imagined completeness.
The kernel becomes a decision filter
As a product grows, feature requests never stop.
Users ask for exports, integrations, notifications, custom reports, additional roles, advanced settings and AI features.
Many of those ideas are reasonable. The difficulty is deciding which one deserves development time now.
The kernel creates a filter.
For each proposed feature, I can ask:
- Does this improve the core workflow?
- Does it help more people access the workflow?
- Does it help users complete the workflow more successfully?
- Does it help the business deliver the workflow reliably?
If the answer is no, the feature may still be useful, but it is probably not urgent.
That does not always mean rejecting the idea.
Often it simply means saying: not yet.
Build for extension without paying for the future immediately
Focusing on the kernel does not mean ignoring the future.
A product can remain small while still making sensible architectural choices.
Data can be structured so ownership can expand later. Authorization rules can be centralized. Routes and naming can remain consistent. Core workflows can avoid assumptions that would make future growth unnecessarily difficult.
The goal is not to build every future capability.
The goal is to avoid carelessly blocking the future while remaining focused on what is valuable today.
PassPaperOnes did not need every school workflow before the student learning experience was useful.
MakoraDesk did not need every organizational configuration before its operational workflow was clear.
Both products could grow because the surrounding systems were added around a recognizable source of value.
The platform should earn its complexity
Platforms become complex naturally.
They accumulate users, roles, permissions, billing rules, support tools, reports and operational requirements.
Some of that complexity is unavoidable. The danger is paying for it before the product has earned it.
A clear kernel provides discipline.
Build the smallest repeatable workflow that creates meaningful value.
Make it reliable.
Observe where users struggle.
Add the systems that help the workflow expand.
Then allow the platform to grow around something that already works.
The platform is not the starting point. It is what forms around a valuable kernel after the product earns the right to expand.