Friction Logging
Adopt a specific user's identity, walk your own product end-to-end, and log every point of friction.
- Difficulty
- Easy
- Time to result
- ~weeks to results
- Steps
- 6
- Confidence
- 95%
Friction logging is Stripe's operational answer to the question 'where do we sweat the details?' Rather than polishing everywhere (which stalls shipping) or nowhere (which erodes craft), you pick a named user persona, go through the real end-to-end product flow as that person, and keep a stream-of-consciousness log of every place you get stuck. The friction points become the prioritised investment list; the delights get praised. It runs on a repeating cadence at every level, from IC to CTO.
Origin
Described by David Singleton, CTO of Stripe, as a practice widely used across Stripe product teams and internal-tools teams. Stripe published a template publicly on stripe.dev. Singleton personally has onboarded as a new Stripe user roughly once a month for years and written a friction log each time.
Core principles
- 01Meticulousness must be targeted, not universal — being meticulous everywhere grinds progress to a halt.
- 02You cannot log friction generically; you have to model one specific, real user in one specific situation.
- 03Stream-of-consciousness beats a tidy after-the-fact summary — the raw stuck moments are the signal.
- 04Praise is part of the log; recognising great work is as important as flagging breakage.
- 05At scale, thousands of people all caring about detail still produce divergent experiences — a regular whole-flow pass is what re-cohere them.
- 06The log has no authority; it must be routed to owners who can act.
How to run it
- 1
Declare what you are trying to do
State the concrete job at the top of the log — e.g. 'integrate the Billing API to automate revenue', not 'look at the product'. A vague goal produces a vague log.
Pro tip Pick a job a real user actually paid you to do, not a hypothetical one.
- 2
Name the user whose shoes you are in
Be explicit about the person you are mental-modelling: their company, their role, their level of context. Singleton's example is an engineer at Atlassian who already uses Stripe Billing for revenue automation. This choice drives every judgement call about whether something counts as friction.
Pro tip Log persona quality is downstream of user contact. If you have recently met that person, your mental model is far sharper.
Watch out Skipping this step is the most common failure — a log written as 'me, an insider' finds nothing, because insiders route around friction unconsciously.
- 3
Do the real flow, in the real product
Start where the user starts — the dashboard, the docs page, the first line of code — and go all the way through. Do not read the code or the spec; use the product.
Watch out Do not fix things as you go. Fixing breaks the flow and destroys the record of how bad the experience actually was.
- 4
Keep a stream-of-consciousness log
Write down everything as it happens, with particular attention to the moments where your named user would have found it difficult. Also log what delighted you — Singleton cites Stripe's API error messages that link directly to the docs page that solves the problem.
Pro tip Record time spent stuck, not just the fact of being stuck. Duration is what makes friction fundable.
- 5
Tag in the owners
Circulate the log and tag the specific people and teams across the company who can act on each item. Being widely read is what converts a document into a prioritisation input.
Pro tip Sending it broadly doubles as recognition — a public 'this is awesome, nice work' on a delight lands harder than a private one.
- 6
Put it on a repeating cadence and reserve bandwidth for the output
Assign a standing owner per product team (often the PM, sometimes the EM) who runs the end-to-end flow on a rhythm. Teams then reserve a self-chosen slice of roadmap capacity to fix what the logs surface.
Pro tip Trust each team to set its own reserve percentage by product stage rather than mandating a company-wide number.
Watch out A friction log with no reserved engineering capacity behind it becomes a guilt document that teams learn to ignore.
In the wild
Before joining Stripe, Singleton integrated the product and misconfigured the API. The error message he got back linked directly to the docs section that explained how to solve it. Stripe carried this so far that there is more code in the jobs serving the Stripe API to handle these edge cases than in the actual main flow.
→ Users repeatedly cite this as a reason they adopt Stripe faster and keep adopting additional Stripe products; it was a material factor in Singleton deciding to join.
For years, Singleton has onboarded as a new user to Stripe roughly once a month, written a friction log, and tagged in the teams across the company that need to act on what he found.
→ With thousands of engineers working in parallel, the regular whole-flow pass is what keeps the product a cohesive whole rather than a set of individually-polished but divergent experiences.
Common mistakes
Logging as yourself instead of as a named user
Without an explicit persona you have no basis for deciding what counts as friction, so you either flag everything or nothing. The persona is the filter.
Only logging the bad
A friction log that is a pure complaint list gets read defensively. Praising what works makes the log a recognition channel and keeps teams reading it.
Expecting instant fixes
Friction logging is a longitudinal prioritisation input, not a bug bash. Treating each item as a same-day escalation, especially when a senior leader wrote the log, turns an offhand remark into a fire drill.
Is it for you?
Best for
PMs, engineering managers and senior leaders at companies past the stage where one person can hold the whole product experience in their head, who need a repeatable way to decide where craft investment actually pays.
Not ideal for
Pre-product-market-fit teams whose flow changes weekly, or products with no self-serve surface where the user never touches the interface directly.
From the transcript
“we have a process that is widely used across product teams and even like folks building stuff for internally for Stripes to use, which we…”
“stream of consciousness notes, but paying particular attention to the places where I ran into friction”
“almost every product team has someone, it's often the PM, sometimes it's the engineering manager, who has a regular repeating loop of going through the…”
“praise the stuff that's good”
From the episode
Building a culture of excellence
David Singleton (CTO of Stripe)