[[TITLE]]

[[SUBTITLE]]

Published Updated By MetalHatsCats Team

A few winters ago, my apartment radiator died on the first cold night of the year. I had no space heater, no toolbox, and a sleepless cat named Pistachio giving me side-eye. I did have a pizza box, two racks from the oven, a desk fan, and way too many binder clips. Ten minutes later, I had a passable heat reflector and a fan-driven airflow rig pushing warm oven air (low and safe) into the living room. Not beautiful. Definitely not in the manual. But it worked.

That scramble is the opposite of functional fixedness—the mind’s habit of seeing an object only in its usual role. Functional fixedness is the tendency to treat things as they “should” be used and miss how they could be used.

We’re the MetalHatsCats team, and we’re building a Cognitive Biases app because bias doesn’t just warp our choices; it also cages our creativity. Functional fixedness is one of those quiet cages. Today we’ll kick its door open.

What is Functional Fixedness – when objects can do more than you think and why it matters

Functional fixedness is a cognitive bias where we cling to an object's conventional purpose and fail to imagine alternatives. It shows up when the mind matches “cup = drink” instead of “cup = scoop, spacer, weight, mold, sound amplifier.” The label becomes a leash.

The classic demo: the candle problem. You’re given a candle, a book of matches, and a box of thumbtacks. Your task: fix the candle to a wall so wax doesn’t drip on the table. Most people fight gravity, angle the candle, melt wax, and curse. The solution: dump the tacks, tack the box to the wall, put the candle in the box. The hitch? We see “box of tacks” instead of “box” (Duncker, 1945). The packaging fooled the purpose.

  • Creativity and problem-solving: When deadlines hit, fixedness kills options. A broader view saves projects.
  • Engineering and design: Over-attachment to familiar components leads to brittle systems and boring products.
  • Safety and resilience: In emergencies, the most available object becomes the most useful one—if you can see it differently.
  • Cost and sustainability: Reuse beats buying. Seeing alternate functions reduces waste and spend.
  • Learning and leadership: Teams mirror their leaders’ framing. If you call it a hammer, they’ll look for nails.

Why it matters:

Functional fixedness is not stupidity. It’s efficiency. Brains compress the world into schemas to save energy. Most days, that’s helpful. On the days it isn’t, you need a way out.

Stories: Examples that pry the lid off “normal”

Stories make this real. Here are scenes where functional fixedness either blocked a solution or made magic possible.

Apollo 13 and the square peg filter

Crisis: rising CO₂ would kill the crew. The working scrubbers were square; the spare cartridges were round. No correct adapter. Only what was onboard: plastic bags, cardboard, a hose, duct tape. The team on the ground built a “mailbox” adapter from kit items and walked the crew through it. The fix saved lives. The key move: tape is not “for sealing,” it’s a structural fastener; cardboard is not “for packing,” it’s a pressure-guiding panel. When the stakes spike, labels loosen.

The cafeteria tray that stopped the leak

A hospital had a slow but maddening leak from a ceiling panel over a corridor. Facilities was swamped; a plumber would take hours. A nurse grabbed a cafeteria tray, zip-tied it to a ladder, taped a section of IV tubing to a corner, and ran it into a waste bucket. Makeshift gutter. Dry hallway. Nobody taught this. It worked because “tray” became “roof,” “IV tube” became “spout.”

The suitcase that powered a campsite

Two friends forgot a lantern. One had a rolling suitcase with a hard plastic shell. They propped a phone’s flashlight inside the suitcase and pointed it at the tent ceiling. The shell turned the phone into a diffuse area light. “Suitcase” turned “lampshade.” Evening saved.

The code that shipped on time, thanks to a spreadsheet

A small team needed a CRUD interface for internal data. The backend was ready, the frontend dev was sick, and the demo was tomorrow. They duct-taped Google Sheets as the UI, used Apps Script to sync, and threw a simple auth gate in front. Not ideal, but the client saw working flows. “Spreadsheet” became “temporary app.” Fixedness whispers “use a framework.” Pragmatism whispers “use what’s in your hands.”

The pen that became a tripod

Filmmakers in a pinch needed a static shot but had only a phone and a table. They rubber-banded three pens into a triangle and wedged the phone in the gap. It was ugly. The footage was steady. “Pen = writing” loses to “pen = structural member.”

The onboarding that solved a support backlog

A SaaS startup had a flood of “Where is X?” tickets. They kept adding docs. A junior PM blocked new docs for a week and turned the top 20 support questions into the product’s first-run checklist. “FAQ” became “wizard.” Tickets dropped by half. The object of our fixedness wasn’t physical, but the same trap existed: “Documentation is a help-center thing.” No, sometimes it’s a product thing.

The shipping pallet that grew a garden

A neighborhood with limited green space wanted raised beds but had no budget. A carpenter flipped shipping pallets, stapled landscape fabric, filled them with soil, and grew herbs in the slats. Pallet turned planter. Kids watered basil through barcodes.

The bug report that became a user story engine

A team treated bug reports as “things to close.” A new engineer reframed them as “evidence of unmet intent.” She tagged recurring bug themes to inform roadmap decisions. “Bug” became “signal.” Burnout eased because work made forward progress, not just fire suppression.

The brittle process that broke until someone color-coded it

A warehouse mis-shipped parts. Every morning, the team beat on training and vigilance. Nothing stuck. A night-shift worker colored the bin labels by size and added a cheap set of colored magnets to carts. Errors plummeted. The magnet wasn’t a “hold a note” tool; it was a “carry a code” tool.

The lecture hall that turned into a prototype lab

A professor had no budget for a prototyping lab. Students were assigned to redesign a campus experience using only items in the lecture hall. Whiteboards became walls. Desks became city blocks. Index cards were people. They discovered bottlenecks by literally bumping into each other. The exercise landed because it denied “proper tools.”

We could do this all day. The point is not “be clever.” The point is to notice that your labels map your prison.

How to recognize and avoid functional fixedness

Functional fixedness hides in how we name things, how we store them, and how we talk about them. You can catch it early if you know the signals.

Early warning signs

  • You feel stuck and start looking for the “right” tool rather than a workable one.
  • You reject an idea because it’s “not what this is for.”
  • You keep repeating the same approach despite weak results.
  • You can list more reasons something won’t work than ways to test it quickly.
  • Your team uses objects’ brand names or product categories as if they were functions: “We need a Kubernetes,” “We need a Figma,” “We need a data scientist.”

Why we do it (and why it’s normal)

Brains love categories. They save time. They also narrow our search. In controlled studies, when objects are presented in packaging that implies their use, people solve fewer insight problems and take longer to see alternatives (Duncker, 1945; Adamson, 1952). High cognitive load or distractions can worsen fixation, while short breaks can help people step around it (Smith & Blankenship, 1991; Wiley, 1998). Kids often show less fixedness than adults because they haven’t learned the “proper” uses yet (German & Barrett, 2005).

We won’t beat biology. We’ll work with it.

Tactics: train your eyes and hands

Pick a few that fit your world. Practice beats reading.

  • Verb-storming: Pick an object. List 15 verbs it can support: clamp, wedge, reflect, amplify, insulate, measure, weigh, block, channel, label, signal, mask, shield, brace, texture. Force yourself past “hold” and “contain.”
  • Attribute first, function later: Describe material, shape, weight, friction, conductivity, opacity, porosity, flexibility, magnetism. What can those properties do in your situation?
  • The wrong-room test: Move an object to a room where its usual role makes no sense. What can a whisk do in a garage? What can a bicycle tire do in a kitchen?
  • Constraint swapping: If you can’t change the object, change the constraint. Time, budget, people, space. If you can’t change the constraint, change the object. Either swap should cause new options.
  • Pack and unpack: Practice depackaging. Dump containers. Spread components. Ask: is the packaging itself a part? This breaks the “box of tacks” trap.
  • Incubation on purpose: Walk away. Do a different task for 10 minutes. Your brain will weaken the wrong framing in the background (Smith & Blankenship, 1991).
  • Scarcity drills: Work with “wrong” tools on purpose. Ban the obvious tool for a simple task. Build a stand with office supplies. Cook a meal with one pan. Write a report with only sticky notes.
  • Verb swap in code: Replace nouns with verbs when naming modules. “PaymentValidator” becomes “ValidatePayment.” This nudges you to think behavior, not identity.
  • Alternate affordance hunt: Ask what signals the object gives: handles suggest pulling; texture suggests grip; holes suggest mounting. Flip one: what else could a handle do (lever, hook, hang)?
  • Use the environment: A wall is not a background. It’s a clamp, a reflector, a heat sink, a measuring stick, a calendar, a reminder, a drawing surface.

Team moves that reduce fixedness

  • Rotate tool ownership: Don’t let only one person “own” the fancy machine or the deploy button. Skill silos create object silos.
  • Ban brand-nouning: Instead of “a Slack,” say “asynchronous chat.” Instead of “a Jira,” say “issue tracking.” Functions first, tools second.
  • Hold remix sessions: Once a month, take a common object and brainstorm 20 uses. Pick one and test it in a real workflow that week.
  • Celebrate weird wins: In retros, highlight duct-tape saves as much as polished launches. If you only celebrate “proper” fixes, you’ll train fixedness.
  • Design for de-labeling: Store tools by properties, not categories. Put “things that clamp” together: binder clips, clamps, rubber bands. When you need to clamp, you’ll browse ideas.

The “see more” checklist

Use this before you declare yourself stuck.

  • State the problem without tools: “I need to fasten two flat surfaces” not “I need screws.”
  • List object attributes, not names: shape, material, weight, edges, holes, friction.
  • Depackage anything that’s in a box. Is the box useful?
  • Remove labels and brand names from the conversation.
  • Write three “stupid” options and test the least expensive.
  • Swap one constraint and observe what changes.
  • Ask a novice how they’d try it. Don’t explain first.
  • Take a 10-minute break and revisit.
  • Use one “wrong” object on purpose.
  • If it needs to be pretty later, let it be ugly now.

Tape this list to your desk. Pencil beats memory.

Exercises: build the muscle, not just the mindset

A bias loosens when your hands learn new shortcuts. Try these mini-workouts with your team.

The 30-minute object remix

Grab a random object. Set a timer to 30 minutes. Split into pairs. Your job: build three distinct tools with it. Example: with a plastic bottle, make a funnel, a lamp diffuser, and a bird feeder. You’re allowed tape and string. Debrief: what attribute did each use? What slowed you down?

The scavenger build

Give your group five verbs (clamp, amplify, guide, measure, protect). Send them on a five-minute scavenger hunt around the office or home. Return with one object per verb. Demo how each object fulfills the verb in a simple use case.

The refactor sprint

Engineers: pick a small module suffering from “this is what it’s for” syndrome. Identify its verbs. Extract behavior into smaller functions named with verbs. Replace at least one dependency with something simpler (or pre-existing) to validate it’s a behavior, not an identity.

The packaging puzzle

Provide objects trapped by their packaging (thumbtack box, blister pack, organizer trays). Ask people to create a solution using only the packaging, not the contents. This trains de-labeling.

The time-crush switch

For one week, hold standup with a rule: for every problem, someone must suggest an option that uses fewer resources than the “proper” tool. Even if you won’t choose it, naming it breaks fixedness.

When fixedness hurts: risk zones and real costs

  • Incident response: During outages, teams reach for “the usual playbook.” If the root cause differs, you waste precious minutes.
  • Hiring and roles: “We need a data scientist” becomes a ritual phrase. Sometimes you need a good analyst and a strong engineer.
  • Budget crunches: A team that can’t see alternatives spends to buy its way out. Dollars replace imagination. That works—until the money runs out.
  • Education: Students who learn objects by brand (“Kleenex,” “Google”) show less transfer. They struggle to carry a skill from one context to the next.
  • Home repairs: Calling a pro for “specialized” jobs that need only basic tools is fine when you have the cash. It’s not fine in an emergency.

Preventative medicine beats heroics. Build the habit now so it’s there when the adrenaline spikes.

Related or confusable ideas

  • Einstellung effect: You keep using a familiar solution even when a better one exists. It’s similar, but it applies to strategies as much as objects.
  • Design fixation: Designers fixate on initial examples or early sketches, reducing the diversity of later ideas. It’s functional fixedness in design clothing.
  • Confirmation bias: You notice evidence that supports your first idea. Different family, same trapdoor.
  • Anchoring: The first number or option frames your expectations. It pushes you to cling to original references.
  • Affordances: The cues an object gives about its possible uses. You can expand your options by reading affordances beyond the obvious (Norman popularized the term).
  • Sunk cost fallacy: “We already invested in X, so we must use X.” That can lock you to a tool long after its usefulness ends.
  • Premature optimization: You commit to the “proper” architecture too early. This can fossilize bad choices: a rigid stack for a flexible problem.

Knowing the neighbors helps you pick the right antidote. If your issue is “we only think of a hammer’s normal use,” it’s functional fixedness. If your issue is “we only use the method we know,” it’s Einstellung. If your issue is “we’re attached to our early sketch,” it’s design fixation.

Research corner, short and sweet

  • Candle problem: Packaging blinds us to alternative uses (Duncker, 1945).
  • Fixation and materials: Removing an object from its container reduces fixedness; seeing parts increases insight (Adamson, 1952).
  • Incubation helps: Stepping away can break fixation (Smith & Blankenship, 1991).
  • Cognitive load hurts insight: Heavy load reduces the chance you’ll restructure the problem (Wiley, 1998).
  • Developmental angle: Young children show less fixedness; learning “proper uses” increases it (German & Barrett, 2005).

Use research like a compass, not a cage.

Practical domains: what “seeing more” looks like in your world

Software and product

  • When you need an admin interface, question “we must build a frontend.” Try spreadsheets, Retool, or command-line scripts for short-term wins.
  • Feature toggles can double as experiments. Use them to test workflow variants with a small cohort before you “design it right.”
  • Logs are not just diagnostics. They’re product analytics. Tag meaningful events early and you’ll know how users really move.

Hardware and ops

  • A clamp isn’t only a clamp. It’s a temporary vise, a cable organizer, a tactile reminder to not touch something.
  • A shipping tube can hold blueprints, serve as a protective sleeve, or become a wire conduit in a pinch.
  • Pallets can be tables, ramps, or sacrificial surfaces for messy work.

Education and workshops

  • Chairs can become circles, lines, or obstacles. Movement frames conversation. Change the topology to change group behavior.
  • Sticky notes aren’t just labels. They’re tokens. Move them like pieces on a board to simulate processes.

Home and everyday life

  • Rubber bands: jar opener grip, cable manager, phone stand strap, visual marker on bottles.
  • Aluminum foil: light reflector, pan lid, drip guard for grill handles.
  • Tote bags: packing cubes, laundry sorter, pillow in a pinch, knee pad for garden work.

You already own more tools than you think. Rename them by what they can do.

Avoiding the traps under pressure

Pressure magnifies fixedness. Here’s how to stop the spiral when the clock is ticking.

  • Simplify the problem sentence. Replace nouns with verbs. “Mount to wall” becomes “hold up.” Options multiply.
  • Ask, “If I didn’t have X, how would I try?” Even entertaining the question frees you.
  • Execute the cheapest test of a weird idea. If it fails fast, you’ve paid pennies for clarity.
  • Keep a “junk drawer” of safe, varied materials: clips, rubber bands, zip ties, cardboard, tape, string. Variety equals affordances.
  • Precommit to ugly. Say out loud, “The first solution can be ugly.” Your team will stop self-censoring clever hacks.

What if it goes too far?

Sometimes people swing hard the other way and treat every object as everything. That’s fun until a “hack” becomes a hazard.

  • Safety first: No improvisation where failure risks injury or damage beyond your willingness to own it.
  • Respect load, heat, electricity, and chemicals. If you don’t know, don’t guess.
  • Timebox hacks. A quick patch can calcify into a permanent liability. Name it a “temporary fix,” set a date to replace it, and actually replace it.

Creativity without guardrails is chaos. Guardrails without creativity is a rut. Aim for flexible rigor.

Frequently asked questions

Q: How do I spot functional fixedness in myself fast? A: Listen for “we can’t do that because this isn’t meant for it.” Replace that sentence with a question: “What property of this thing stops us?” If the answer is “none, just convention,” try it.

Q: Is functional fixedness always bad? A: No. It keeps you efficient most of the time. You don’t want to reinvent uses for a toothbrush every morning. It’s bad when novelty or constraints demand flexibility. The trick is choosing when to switch modes.

Q: What’s a quick exercise I can do with my team this week? A: Run a 20-minute object remix. Give every pair a binder clip. Ask them to demo three uses that solve real problems at your workplace. Debrief attributes: grip, spring, edge, loop.

Q: How does this show up in software? A: We label services and then defend those labels. “This API is for users only” blocks using it for partners, even when it fits with minor changes. We also keep insisting on “the right stack” when a script would do.

Q: How do I avoid hacks turning into permanent messes? A: Timebox and tag them. In code, add a comment like “TEMP-HACK remove by 2025-10-01” and create a ticket. In physical spaces, put a bright tag with a date. Review weekly.

Q: My manager hates “hacks.” How do I get buy-in? A: Don’t sell the hack. Sell the outcome and the safety. Show a 5-minute demo that reduces a blocker today. Promise a plan to replace it. Many managers fear permanent duct tape, not temporary ingenuity.

Q: Can I train kids (or my team) out of fixedness? A: Yes. Use open-ended materials. Ask them to find three uses for a spoon that aren’t eating. Reward curiosity. Over time, they’ll carry that flexibility into bigger problems.

Q: What if the “alternative use” fails embarrassingly? A: Great. You just bought data for cheap. Share the failure, name what didn’t work, and show the next move. A culture that treats small failures as tuition learns faster.

Q: Are there tools that encourage less fixedness? A: Yes. Multi-use tools, modular kits, whiteboards, magnetic systems, Lego, cardboard, and tape. In software, scripting languages, notebooks, and low-code tools like Airtable can unlock quick tries.

Q: Does taking breaks really help? A: Often. Short incubation periods reduce fixation and improve insight problem solving (Smith & Blankenship, 1991). Walk, stretch, drink water, then return with fresh eyes.

A simple checklist to pin above your desk

  • Name the verb, not the object.
  • List three properties before one brand.
  • Depackage and spread parts.
  • Swap one constraint; observe what shifts.
  • Try one “wrong” tool for five minutes.
  • Pause for ten; return and reframe.
  • Ask a novice for their first try.
  • Timebox hacks and date-tag them.

Wrap-up: the day the box lost its crown

Functional fixedness is a neat trick your brain plays to keep daily life quick. But it’s also the reason your “box of tacks” stays a box of tacks when it should be a tiny shelf. The world gets bigger when labels get lighter. Pistachio the cat and I were warm because a pizza box stopped being trash and started being a reflector.

This week, pick one stubborn problem and solve it with an object you’ve never used for that purpose. Not to be quirky. To remind yourself that “what it’s for” is a suggestion, not a sentence.

We’re building a Cognitive Biases app because we want these tiny mind-clicks to happen on purpose, not by accident. If you want nudges that loosen labels right when you need them—during planning, in a meeting, at home while your radiator gives up—come along with MetalHatsCats. We’ll help you see more than what’s printed on the box.

References (light touch)

  • Duncker, K. (1945). On problem-solving.
  • Adamson, R. (1952). Functional fixedness as related to problem solving.
  • Smith, S. M., & Blankenship, S. E. (1991). Incubation and the persistence of fixation.
  • Wiley, J. (1998). Expertise as mental set.
  • German, T. P., & Barrett, H. C. (2005). Functional fixedness in a technologically sparse culture.
Cognitive Biases

Cognitive Biases — #1 place to explore & learn

Discover 160+ biases with clear definitions, examples, and minimization tips. We are evolving this app to help people make better decisions every day.

Get it on Google PlayDownload on the App Store

People also ask

What is this bias in simple terms?
It’s when our brain misjudges reality in a consistent way—use the page’s checklists to spot and counter it.

Related Biases

About Our Team — the Authors

MetalHatsCats is a creative development studio and knowledge hub. Our team are the authors behind this project: we build creative software products, explore design systems, and share knowledge. We also research cognitive biases to help people understand and improve decision-making.

Contact us