Most training products are good at recording what happened. Fewer are good at telling you what to do next.
That distinction became the central product problem behind Balance Point.
Balance Point is an iPhone training product I am developing for riders learning to find, hold and improve wheelie balance. The interesting part was never the idea of logging sessions. A rider can already remember whether a session felt good or bad. The real question was whether software could turn evidence from practice into a recommendation that felt clear, specific and believable.
That pushed the product toward a deterministic model.
The next action is the product
The core loop became deliberately simple:
Baseline → Diagnosis → Training → Review
The sequence matters.
A baseline establishes what is happening now. Diagnosis interprets the evidence. Training gives the rider something specific to work on. Review captures what happened and updates the next recommendation.
The important part is that the chain is visible.
I did not want a rider to complete a session, see a number move from 62 to 67, and have no idea why. If the product changes its recommendation, there should be a reason the rider can understand.
That sounds obvious, but it rules out a surprising amount of conventional product behavior.
Deterministic does not mean simplistic
I use “deterministic” here in a practical product sense: the same evidence should lead to the same decision under the same rules.
That gives the system a few useful properties.
It is testable. If a particular set of observations should produce a particular recommendation, that behavior can be checked repeatedly.
It is explainable. The product can tell the rider what it saw and why the next session is changing.
It is recoverable. If something goes wrong, the system has a known state rather than an opaque model output that is difficult to reproduce.
And it creates trust. A rider can disagree with a recommendation and still understand how the product arrived there.
That last point matters more than making the system appear clever.
Designing the interface around state
Once the training model was clear, the interface had to reflect it.
The product shape settled around four main sections:
Today / Train / Progress / Review
Today is the current state and next action. Train is structured access to training. Progress shows competency over time. Review keeps the evidence visible.
Quick Start provides an immediate path into a session alongside those sections.
The goal was to reduce the number of times a rider has to ask, “What am I supposed to do now?”
That principle also changed smaller interaction decisions. A prescribed session should not silently begin because a baseline was completed. Pausing and resuming should mean something specific. Ending one block should not accidentally terminate unrelated work. A safety stop should provide a clear choice rather than behave like an error state.
These are not glamorous features, but they are where deterministic products are either earned or lost.
Evidence without dashboard theatre
Training products naturally attract metrics.
That creates a temptation to surface everything: scores, streaks, graphs, badges, percentages, trends and increasingly elaborate progress systems.
Balance Point takes a more restrained position.
Evidence is useful when it changes a decision.
The product should show enough information for the rider to understand progression, but not turn practice into dashboard management. Progress is there to support training, not to become a second activity competing with it.
That also means avoiding gamification for its own sake. A rider does not need a synthetic reward for completing something that already has a meaningful real-world outcome.
The wheelie itself is the reward.
The design lesson
The main lesson from Balance Point is that product intelligence does not have to look mysterious.
In some categories, the strongest experience is the one that can explain itself.
The rider gives the product evidence. The product interprets it according to known rules. The next session follows from that interpretation. Review updates the state. The cycle repeats.
There is still plenty of complexity underneath that loop. The difference is that the complexity is not allowed to leak into the rider’s decision-making.
The interface should always return to one question:
What is the most useful next action?
That became the organizing principle for the product, the navigation and the training model.
Not smarter-looking software.
Clearer training.
