Confetti fires at level 2—mastery arrives at level 11

Every product team eventually faces the same question: why do users celebrate the first small win and then vanish before the real value arrives? The confetti at level 2 is cheap to build and feels great to ship. The problem is that the behaviour it rewards—showing up once—is not the behaviour that keeps a business alive. So what actually happens between the dopamine hit of an early win and the quieter, stickier satisfaction of genuine mastery, and how do you design a website or app that survives the gap?

The reward that fires too early

B.F. Skinner's work on variable-ratio reinforcement is the most cited idea in behavioural design for a reason: unpredictable rewards produce the most persistent behaviour. It's why notification badges work. It's also why they're dangerous when misapplied. A confetti burst on sign-up is a predictable, one-off reward attached to a trivial action. It teaches the user that the product hands out prizes for arriving, not for improving.

Contrast that with what mastery feels like. Nobody gets a parade when they finally understand how to structure a spreadsheet formula, parallel park, or read a balance sheet. The reward is internal: the task gets easier, the feedback loop tightens, and competence itself becomes the thing you're chasing. Daniel Kahneman's framing helps here—people evaluate experiences through peaks and ends, and they overweight small, immediate gains against larger, delayed ones. A confetti cannon is a peak. Mastery is a slow-building end that you only appreciate in retrospect.

The design implication is uncomfortable. If your onboarding is optimised entirely around the level-2 moment, you're training users to expect extrinsic rewards for shallow engagement. When those stop—and they always stop, because you can't confetti every session—there's nothing underneath to hold them.

Loss aversion is doing more work than you think

Here's where it gets interesting for anyone building for businesses. Kahneman and Tversky's loss aversion research found that losses loom roughly twice as large as equivalent gains. In product terms, a user who has invested effort into your platform—set up their workspace, imported data, invited a colleague—now has something to lose. That's a far more durable retention mechanism than any reward.

The catch is that this investment has to be real. A progress bar that fills because someone clicked "next" four times is theatre. A progress bar that fills because they've genuinely configured something useful is a commitment device. The behavioural principle is the sunk cost effect, and while economists wring their hands about it, product designers should understand it plainly: people protect what they've built.

For Australian small and medium businesses especially, the calculus is practical. A tradie evaluating a job-management tool doesn't have time for gamified tutorials. What they respond to is the moment the tool saves them a phone call or a double-booking. That's not level 2. That's closer to level 11, and it's worth designing backwards from.

What competitive play teaches about the middle levels

There's a useful distinction in game design between extrinsic and intrinsic motivation that maps cleanly onto business software. Extrinsic rewards—badges, streaks, points—work well for habit formation in the first week. Intrinsic motivation—autonomy, competence, relatedness, the three needs in self-determination theory—is what sustains engagement over months.

The middle levels are where this transition has to happen, and it's where most products lose people. The novelty has worn off. The confetti has stopped. The user can see the shape of the work ahead and it looks like effort. This is the decision point, and it's where risk-taking behaviour matters: users who perceive the next step as a manageable stretch will take it; users who perceive it as a cliff will quietly leave.

One concrete pattern worth studying is Duolingo's streak mechanic, which is often misread as pure extrinsic gamification. The streak works not because of the flame icon but because it converts a vague intention ("I should practise") into a specific daily commitment with a visible cost of breaking. The reward shifts from "you did a lesson" to "you are the kind of person who doesn't break streaks." That's identity, not confetti, and it's why the feature survives long after the novelty of the app does.

Designing the bridge from level 2 to level 11

A few practical moves for teams building websites and applications for business audiences:

Make the early win a doorway, not a destination. The first success should reveal the next, more substantive thing. If signing up gets you a dashboard, the dashboard should make the next meaningful action obvious—not bury it behind a tooltip.

Instrument the middle, not just the edges. Most analytics setups track activation and churn. The interesting data lives in between: how many sessions between first login and first genuine outcome? Where do people stall? A funnel that ends at "account created" tells you nothing about mastery.

Let investment accumulate visibly. Saved templates, connected integrations, historical data—these are loss-aversion anchors. Show users what they've built, not what they haven't.

Reward competence, not attendance. A notification that says "you've saved 4 hours this month" beats one that says "you haven't logged in for 3 days." The first reinforces mastery. The second is a guilt trip dressed as engagement.

Design for the plateau. Every learning curve flattens. The products that retain business users are the ones that make the plateau useful—reporting, automation, integrations—rather than pretending the curve keeps climbing.

The forward question

The next wave of behavioural design in business software won't be won by whoever builds the most delightful first minute. It'll be won by teams who take the unglamorous middle seriously—who treat the stretch between novelty and mastery as the actual product, not the gap between two marketing moments. If you're building something now, the question worth sitting with is simple: what does your user have to lose by leaving, and have you made that thing worth protecting?