Consumer products as behaviour systems

The phone as environment

Think about the last time you opened an app without consciously deciding to. The thumb moved before the thought arrived. The screen lit up and you were already scrolling before you remembered what you had intended to do instead. That gap, between intention and action, between the person you are and the patterns you are running, is precisely where consumer products do their most significant work.

There is a widespread assumption that apps are passive. That they wait to be used, that the user remains the author of their own behaviour, and that the product is simply a surface made available for when it is needed. This assumption is convenient, especially for those building the products. It places all responsibility for use patterns on the person holding the phone and none on the engineers, designers and product teams who built the system the person is trapped inside.

The assumption is false. Consumer products are not passive instruments. They are environments. And like all environments, they shape the behaviour of the people who inhabit them: gradually, cumulatively, often without those people noticing the shaping until it has already settled into habit. By July 2021, this is not a fringe critique. It is the documented, widely understood output of a decade of engagement optimisation. The question is no longer whether products change behaviour. The question is what they are trying to change it into.

Two design orientations, one mechanism

The mechanism by which a product shapes behaviour is not neutral. Every loop a product closes or leaves open, every signal it amplifies or suppresses, every friction it introduces or removes: these are design decisions that accumulate into a posture. And that posture is either oriented toward increasing what the user can do, or toward increasing how often the user returns to the product.

These are not the same thing, and they do not produce the same outcomes.

A product built around return rate needs the user to remain in a state of unresolved tension. The notification that arrives before the habit is fully formed. The progress bar that looks alarming at 80% complete. The social comparison that lands right when confidence is fragile. None of these are accidents. They are features of a design philosophy that treats engagement as the output, and the user's sustained attention as the raw material. The product succeeds when the user cannot quite stop coming back. The ideal exit from any session is one that leaves a thread still pulling.

A product built around capability is oriented differently. It wants the outcome to occur in the user's life, not inside the app. It is trying to make someone better at something real: stronger, sharper, more consistent, more capable of the decisions that actually matter in their domain. The ideal version of this kind of product is one that becomes less critical over time, because the capability it was cultivating has transferred to the person and no longer requires the scaffold.

This is not an aesthetic preference. It is a structural commitment that runs through every decision in the product: what gets measured, what gets surfaced, what feedback loops are built, what the coaching posture is, what happens when the user has a bad week. The design philosophy is either pointing toward the person's growth or toward the product's retention. When there is a conflict between those two things, and there will always be conflicts, which one wins?

What happens to performance apps that get this wrong

The fitness and performance space is a useful place to examine what the wrong answer looks like in practice.

Most performance apps, at least the consumer variants that have scaled, are built around a motivational model. The assumption is that the user needs to be convinced to act. That the principal obstacle between a person and their desired behaviour is motivation, and the product's job is to supply it externally: reminders, streaks, badges, push notifications calibrated for guilt, leaderboards designed to produce anxious comparison.

This model does produce activity in the short term. It can generate impressive daily active user numbers. It is legible in an engagement report. But it does not produce the thing a performance product exists to produce, which is a person who performs better. What it produces instead is a person who performs only when the product is running the loop for them. That is not capability. That is dependency with a progress bar on top.

The dependency model also has a built-in expiry mechanism. Eventually the user recognises that the app has not changed them: that when they stopped using it, the habits dissolved, the standard dropped, and nothing had actually been internalised. The churn that follows is not a product failure in the conventional sense. The product achieved what it was designed to achieve. The problem is what it was designed to achieve had nothing to do with the stated goal.

There is also a subtler failure mode, harder to observe in the data: what nagging does to agency. When a product externalises the prompt for every action, when the person acts because the notification arrived rather than because they have built a genuine relationship with their own standard, the product is slowly undermining the very thing it claims to be building. Agency is like a muscle. If it is never used, it atrophies. A product that nags is also, in small daily increments, eroding the user's capacity to decide for themselves.

Precision as the alternative

The inverse of nagging is not silence. It is precision.

A performance product built on the right design philosophy speaks when it has something genuinely useful to say. It knows the difference between a moment when the user needs to be challenged and a moment when the decision in front of them needs to be simplified. It treats a missed session as data rather than a moral failure. It understands that the friction worth removing is not the productive friction of the training itself, that friction is load-bearing, but the friction between the intention and the act. The moment when someone knows what they should do and cannot find their way into doing it.

Most of the failure in consumer performance products happens in that gap. The intention is present. The knowledge of what to do is not the problem. What breaks down is the path from knowing to acting, and the systems that are supposed to close that path instead leave it open, or make it harder to navigate by attaching shame to every entry point.

A precision-built system makes the path back simple. It holds a clear standard without weaponising it. It surfaces the right signal at the right moment, not every available signal simultaneously, which is noise, and then it gets out of the way.

Language and the coaching relationship

Something has shifted in the past eighteen months that is directly relevant to what a performance coaching system can be.

The GPT-3 generation of language models, released publicly in 2020 and increasingly accessible through the API by mid-2021, has changed the cost and character of natural language interaction in software. Not in a finished way. There are genuine limitations: factual reliability, consistency across sessions, the quality of reasoning under novel conditions. But for a specific narrow application, capturing a person's experience in natural language and responding usefully, the capability is real and it changes what is possible.

The hardest moment in any coaching loop is the handoff between the lived experience and the record of it. Getting someone to log accurately, reflect honestly, describe what is actually happening: this is where most consumer performance tools bleed out. The friction of structured input (select a category, rate your recovery on a scale of one to ten, choose from these five options) is high enough that people approximate, or they stop logging entirely. Once the log degrades, the system has nothing to work with. The feedback becomes generic. The coaching becomes generic. The loop breaks.

A natural language interface collapses that friction significantly. The record can be captured in the way the person naturally speaks. The follow-up question can feel like a conversation rather than a data entry task. And the response can meet the person where they are, which is the irreducible standard of any coaching relationship worth the name.

This is the operating space for Naira, the AI performance coach built into CheekyGains. The design intent is not to replace the work, nothing replaces the training, the standard, the daily decision to show up or not, but to maintain the coherence of the loop. To help someone capture quickly when time is short. To help them reflect honestly when clarity is elusive. To deliver the right signal before the moment passes and the behaviour settles into the wrong groove.

The commitment underneath CheekyGains

CheekyGains is built around a specific design commitment: the product should increase the user's capability, not their dependence on it.

This is easy to say and expensive to maintain. It means not manufacturing urgency when there is none. It means surfacing metrics that track the user's trajectory in the real domain, their physical performance, their consistency against their own stated standard, rather than metrics that measure their engagement with the app. It means the coaching posture is honest rather than encouraging at all costs. It means the product goal is, in the most useful sense, to eventually become less important: to build habits robust and self-sustaining enough that the scaffold can be removed.

That is a strange thing to design toward. Consumer products do not typically define success as their own reduced necessity. But if you take seriously the claim that a consumer product is a behaviour system, that it is actively shaping how thousands of people live their daily lives, then the question of what it is shaping toward becomes a genuine design responsibility, not an afterthought.

The standard is not elegant engagement funnels. The standard is: does the person perform better because of this product? Do they hold a higher standard, with less external prompting, than they did before? Has something been internalised that belongs to them now, independent of whether they open the app tomorrow?

That is the test. It is harder to pass than an A/B test on notification timing. It requires a longer view, a different relationship with success metrics, and a willingness to build something that works against its own retention when working against its own retention is what the user actually needs.

But it is the only test that corresponds to what a performance product is actually for.