Productive Friction: What to Remove and What to Keep

Friction Is Not the Enemy of Expertise

The useful question is not whether to remove friction. It is whether the friction produces learning, judgment, safety, or a result the person can reproduce.

Delay, duplicate entry, unclear ownership, preventable waiting, file conversion, and repeated formatting usually teach nothing. Remove them.

The effort required to retrieve an answer, test a decision, notice an error, and correct the next attempt can build a capability that remains after the task is over. Removing that effort may improve the immediate output while weakening the person's ability to recognize when the output is wrong.

The distinction matters more as AI makes a plausible result available before the user has formed the judgment that used to accompany it.

The result and the capability are different assets

Episode 115 framed the problem through a simple question: what remains after the shortcut disappears?

A correct answer is valuable. Expertise is the ability to decide when the answer applies, explain the evidence, detect an exception, and produce another good result when the context changes.

Those assets can travel together. A skilled person uses a tool and produces a better result faster. They can also separate. A person receives polished language, a finished design, or a calculated recommendation without owning the hidden choices.

The output is not fake merely because a tool helped create it. The risk appears when the organization treats the output as proof of the operator's capacity.

That mistake becomes expensive when the tool encounters a condition it was not designed to handle and the person cannot see the failure.

flowchart TD
    A["Difficult step"] --> B{"Does it create useful information or judgment?"}
    B -->|No| C["Remove or automate it"]
    B -->|Yes| D{"Can the learner respond with current knowledge and feedback?"}
    D -->|No| E["Add instruction, support, or a smaller challenge"]
    D -->|Yes| F["Preserve the learning function"]
    F --> G["Automate surrounding setup and repetition"]
    G --> H["Test delayed performance and transfer"]

Keep the learning function, not the inconvenience around it.

Productive friction returns information

Dalton used a video-game level as the intuitive example in E115. The player fails, notices a shell, changes the timing, encounters the next obstacle, and gradually learns the structure.

The failure becomes useful because the environment returns information soon enough for the player to adjust. The next attempt tests the updated model.

Workplaces often preserve the failure and remove the feedback. A person struggles through an unclear process, receives a late score, and learns little about which decision mattered. That is not productive friction. It is opacity.

Useful friction exposes a decision, produces interpretable feedback, and gives the person another chance to apply the correction. It improves the next attempt or reveals that the current strategy should stop.

The absence of any one part changes the experience. A difficult task without feedback creates frustration. Feedback without another attempt creates evaluation rather than learning. Repetition without a decision creates motion rather than judgment.

Desirable difficulty has strict conditions

Robert and Elizabeth Bjork's Desirable Difficulties in Theory and Practice explains an important difference between visible performance during practice and longer-term learning.

Conditions that make practice feel easy can produce rapid short-term performance without durable retention or transfer. Spacing, variation, generation, and retrieval can slow the apparent rate of learning while strengthening later access or application.

The authors also emphasize the word "desirable." Many difficulties are undesirable during instruction and remain undesirable afterward. A difficulty supports learning only when it triggers useful encoding or retrieval and the learner has enough background knowledge or skill to respond.

Making a novice solve an advanced problem without instruction is not automatically developmental. Requiring an expert to repeat clerical setup is not practice. The difficulty has to meet the learner at a challenge they can use.

This boundary is especially important in product design. Teams can romanticize a confusing interface as something users should learn. If the friction does not improve the user's later capability or safety, it is usually the product asking the customer to absorb its own disorder.

The IKEA effect warns against worshipping effort

Labor can increase attachment without improving quality.

Norton, Mochon, and Ariely's original IKEA-effect paper reported four studies involving IKEA boxes, origami, and Lego sets. Participants valued products they had successfully assembled more highly. In some conditions, they valued amateur work close to expert work and expected others to share that valuation.

The effect dissipated when participants failed to complete the task or built and then destroyed their creation. An author copy from Harvard Business School contains the complete report.

The paper does not show that building something makes it objectively better. It shows that successful labor can change the builder's valuation.

That is the warning inside any defense of productive friction. A team may protect a manual process because it worked hard to create it. A founder may overvalue a product because of the years invested. A writer may resist an edit because the sentence was difficult to produce.

Effort can create skill. It can also create attachment to the artifact and blindness to alternatives.

The remedy is not to remove labor. It is to compare the result with evidence that did not come from the maker's effort.

Automation should remove waste and preserve review

The most useful automation pattern separates preparation from accountable judgment.

A tool can collect documents, normalize fields, calculate a result, identify discrepancies, or draft a structure. The operator reviews the evidence, decides how the result applies, and remains able to explain or reject it.

That division is not always correct. Some decisions can be automated safely after the system has a well-defined rule, reliable inputs, monitoring, and recovery. Some preparation carries important learning because gathering the evidence reveals its limitations.

Ask what the person needs to know later. If the operator must diagnose an exception, preserve enough contact with the inputs, assumptions, and failure modes to recognize one. If the operator only needs the reliable output and the system has accountable control, the manual step may be pure cost.

For example, a spreadsheet can calculate a rate without teaching arithmetic each time. A product manager may still need to know the numerator, denominator, exclusions, and decision boundary before using the metric. Automate the calculation. Preserve the interpretation.

Immediate performance can conceal lost learning

A tool-assisted learner can look more capable during the task because the tool supplies the retrieval, structure, or correction.

The evaluation then measures the combined system rather than the person. That may be appropriate when the real job always includes the tool. It becomes misleading when the organization expects the person to handle a novel failure, work without the system, supervise its output, or transfer the skill to a different environment.

Test both assets separately.

Measure whether the tool-assisted result is accurate, efficient, safe, and useful. Then test whether the person can explain the critical choice, detect a planted error, adapt to a new condition, or perform the essential judgment with reduced support.

The second test is not a ritual of suffering. It reveals whether the human role in the combined system is real.

The strongest counterargument

Much of what people call productive friction is waste defended by incumbents.

Professionals may claim that manual repetition builds character when it actually protects status. Teachers may preserve a difficult format because it is familiar. Organizations may force new employees through bad tools and call the experience learning. Product teams may add confirmation screens that users click without thinking.

AI can also expand access. A person who could not previously write, code, analyze, translate, or design at the required level can participate with assistance. Insisting that everyone recreate the historical path to competence can turn expertise into a gate rather than a public benefit.

This argument is correct.

The response is not to keep the old work. It is to identify the capability the system still needs and create the least wasteful way to build, verify, or replace it.

If a reliable control can own the judgment, automate it. If a person must own the judgment, design feedback and practice around the decision. Do not make the user carry unrelated inconvenience as the price of professional credibility.

A decision test for difficult work

Start with the consequence of failure. If the task is low risk and easily reversible, immediate output may matter more than retained capability.

Then identify the future condition. Will the person face novel cases, supervise the tool, explain the result, teach someone else, work when data is incomplete, or respond when the normal system fails? If yes, learning and transfer matter.

Locate the judgment. Which part of the task requires choosing among plausible options rather than following a stable rule?

Inspect the feedback. Does the person learn which choice was good, why, and under what conditions? Can another attempt test the correction?

Check the learner's preparation. A challenge beyond current knowledge may need instruction, scaffolding, or a smaller step.

Finally, separate the productive decision from the surrounding inconvenience. Automate setup, search, formatting, movement, and duplicate entry where they add no learning.

The output of this test may be full automation, assisted judgment, deliberate practice, or a redesigned process. The answer should follow the work, not a general preference for difficulty or convenience.

What this changes

Teams should stop using effort as evidence of quality and speed as evidence of capability.

A faster correct result is good. Ask which system produced it and whether that system remains reliable under the conditions that matter.

A difficult process may be necessary. Ask what the difficulty teaches and how the learner will demonstrate transfer.

The goal is neither frictionless work nor heroic struggle. It is a system that produces the result, leaves the required capability in the right place, and makes failure visible before it becomes expensive.

Episode 119's [[How to Test a Product Where It Will Actually Fail]] supplies the real-use testing method. Episode 116 shows how friction can be placed around risky authority while routine coordination is removed. Episode 100 connects the decision to a founder operating system.

Sources and further reading

The episode argument comes from [[E115 Full Transcript]]. The learning boundary comes from Bjork and Bjork's Desirable Difficulties in Theory and Practice. The effort-and-valuation boundary comes from Norton, Mochon, and Ariely's IKEA-effect paper and the Harvard author copy.

AI assisted with organization, source comparison, and editorial review. Dalton Anderson's transcript and the linked primary research control the factual claims.