Users do not hate friction. They hate broken promises.

Day 32 on AffiSpark.

I think founders mislabel a lot of friction.

Not every heavy step feels bad because the step itself is bad.

Sometimes it feels bad because the previous step promised a different kind of experience.

That feels like a much more useful way to think about product flows.

A page says:

safe to explore

Then the next step says:

pay now

A CTA says:

take the next step

Then the click says:

leave the browser and finish this somewhere else

A product says:

we track attribution

Then the real-world buying journey gets a little messy and the signal falls apart

Those are not just friction problems.

They are broken promise problems.

That distinction matters because it changes the fix.

For AffiSpark, the public preview was not really about adding more marketing.

It was about making the pricing ask match the promise of the earlier step.

If I want users to feel they can inspect the workflow safely, I cannot ask for payment before they have actually seen it.

The walkthrough flow was the same lesson in a different place.

A CTA that looks like the next step should lead to a finishable next step.

When it opened a mail client, the flow broke its own promise.

And promo-code attribution came from the same underlying issue too.

Affiliate software makes an implicit promise:

tracking should survive real buying behavior, not just the cleanest possible referral-link path.

If attribution only works when the journey is perfectly tidy, the product is promising something more robust than it really is.

That is why I think users often do not reject the cost of a step.

They reject the mismatch.

The ask feels wrong because it does not fit the story the product has already been telling.

That is a much better diagnostic rule than just saying:

this step has too much friction

Because the right question becomes:

what did the previous step promise that this step failed to honor?

My current rule is simple:

when a step feels heavier than it should, I want to check whether the product changed its promise mid-flow.

Curious how others think about this:

what part of your product was really failing because it broke a promise made by the step before it?