The friction in our product is deliberate. That is not a defence, it is the design. The trouble is that a design is only ever a claim, and the product is what happens in the user's hands.
FitFido has a free tier that is genuinely useful and a paid tier that is faster, and the boundary between them is built from friction chosen on purpose. Freeform meal logging works, and it keeps working forever. It also asks for a small amount of effort every single time. What the paid tier does is take that effort away rather than lift a restriction: label scanning that reads the calories straight off the bag, portion maths that happens without anyone asking for it. This is the Evernote pattern, and it is load-bearing. What you are buying is the time back.
So I had a clear mental model of where the friction in the product was, why it was there, and what it was doing. I could have drawn it on a whiteboard. It would have been a good whiteboard.
Then a number that had been sitting in the dashboard for months finally annoyed me enough to go and look. A large share of people who signed up never logged a single meal. The funnel could tell me that with great precision. It could not tell me anything at all about why, because a funnel measures where people stop, and the reasons live somewhere the funnel cannot reach.
I spent two weeks reading the actual code paths and walking the actual flows, in order, as a stranger would.
The friction was not where I thought it was.
It was not sitting at the free-versus-Member boundary, doing its job. It had migrated to the first minute of the trial. A user who had just given us their intent, the most engaged person we ever encounter, was being asked to do more work to log a meal than a free user was. They had to construct something before they could record anything. Investment before reward, at the exact moment we had the most attention we would ever have and the least credibility.
I want to be clear that nobody decided this. There was no meeting. Each individual step had a decent reason for existing, most of them mine, added at different times to solve real problems. A scheduling step that made sense in isolation. A configuration wizard that was genuinely useful to someone who already understood the product. A default that was correct for the case I had in mind when I wrote it. Every one of them reasonable, none of them evaluated against the whole path, because nobody re-walks the whole path after adding one screen to it.
Friction accretes. That is the finding, and I have come to think it is the general case rather than a fact about my product. You place friction deliberately in one location, and then the product grows, and the friction ends up somewhere else. The design document still says what you intended. The product does something different, and the gap between the two widens quietly, in increments, each of which is too small to notice on its own.
Which raises the obvious question of why it took two weeks and a deliberate search to find something that was happening to a substantial share of everyone who ever signed up.
The answer is that friction is silent, and I mean that quite literally. Nothing broke. There were no errors, no crashes, no failed requests, no support emails, no angry reviews. The people hitting this did not complain, because complaining is work, and someone who has already decided the product is not worth ten more seconds is not about to spend five minutes writing to tell you so. They left. Leaving generates no event. Our instrumentation, like everyone's, was built to record things that happen, and the thing that was happening was an absence.
This is the part I would most like other founders to take seriously, because it inverts an instinct almost everyone has. The support inbox feels like a measure of how much friction exists in a product. It is not. It is a measure of the friction that someone cared enough about to report, which is a small and violently biased sample of the total, skewed towards your most invested users and away from the ones you are currently losing. A quiet inbox is not evidence of a smooth product. It is evidence of nothing at all.
There is a second reason it stayed hidden, and it is less comfortable.
I was the worst available person to catch it. Not because I was not looking, but because I could not stop knowing things. When I tested search, I typed the queries I knew the search could answer. When I read an empty state that said there was nothing there, it read correctly to me, because I knew which sort of nothing it meant. Every screen in that product is legible to me in a way it will never be legible to anyone else, and that legibility is not an advantage during testing. It is a disqualification.
Steve Krug has been saying this for twenty years and I had read him saying it. Reading it does not inoculate you. The fluency is not something you can decide to switch off, which is why the only remedy is structural: put the product in front of people who do not have it, on a schedule, whether or not you currently suspect a problem.
The reason all this is urgent rather than merely interesting is timing.
Almost everyone who ever logs a meal in FitFido does it in the first day. Not the first week. The first day. And the people who get through that first log go on to use the product heavily and convert at several times the rate of those who do not. There is a window, it is roughly twenty-four hours wide, and it does not reopen. Anything standing inside that window is not costing you engagement in some diffuse way. It is being paid for directly in customers.
Which means the ordering question, effort before reward or reward before investment, is not a matter of taste. Every fix worth shipping out of that fortnight turned out to be the same move wearing different clothes: take the investment step, whatever it is, and move it to after the first reward instead of before it. Let someone record one meal and see one answer. Ask them to configure the thing afterwards, once they have a reason to care.
So the principle I would actually write down, having gone through this, is narrower than the one I would have written down beforehand.
It is not that friction is bad. Nate Dooley's point stands and I would defend it: friction is a material, and the job is to remove it from the paths you want travelled and place it on the paths you do not. That framing survived the audit completely intact.
What did not survive is the assumption that placement holds. Friction has a location, and the location decays, and it decays invisibly because the mechanism of decay is a series of individually sensible decisions. So placement has to be audited against the running product on some regular basis, in the same way you would audit anything else that drifts. Not against the design document. A design document is a hypothesis, and it stays one no matter how confident you were when you wrote it.
Three things came out of this that are now standing practice rather than good intentions. Someone who is not me walks the critical paths regularly, in full, in order, without being told what to look for. Anything we change gets instrumented before it gets changed, because we shipped one improvement into a measurement void and then spent a week arguing about whether it had worked, which was a week we did not need to spend. And the first-run path gets re-walked end to end after any change that adds a step to it, on the grounds that this is precisely how the last one accumulated.
None of that is clever. It is maintenance. But the alternative is what we had, which was a whiteboard I was confident about and a product quietly doing something else.