The Tool Is Not Broken. It's Just Wrong for Your Job.

A sales team at a mid-sized software company got Salesforce rolled out last year. Adoption numbers looked fine. The VP of sales sent a note about the successful deployment. Three months later, the field reps were still keeping shadow spreadsheets to track their accounts, opening Salesforce only when a manager asked for a report. The implementation team blamed user resistance. The training team blamed insufficient onboarding. Nobody asked the more obvious question: is Salesforce the right tool for what these reps actually do all day?

That question is what Goodhue and Thompson (1995) built Task-Technology Fit around. Their core argument is almost insultingly simple once you see it: technology improves performance when its capabilities fit the task requirements. The same tool can be useful for one task and genuinely harmful for another. Fit is not a global property of a technology. It is a relationship between a specific task, a specific technology, and a specific user type. A tool that fits one configuration perfectly can fail a different configuration completely.

This sounds obvious when you say it out loud. But the IS field spent the better part of two decades running adoption studies that ignored it. TAM and its descendants ask whether the user perceives the technology as useful and easy to use. UTAUT asks about social influence and facilitating conditions. These are perception models. They sit between the technology and the user's head. TTF sits between the technology and the work. The question TAM asks is "do you think this tool will help?" The question TTF asks is "does this tool actually match what you need to do?"

Those are different questions, and they predict different things. I kept noticing this asymmetry while studying for comps. The theories.html file from my study hub is pretty explicit about it: "Fit between task needs and technology functionality shapes performance." Not attitude. Not intention. Performance. TTF is designed as a performance predictor, not an acceptance predictor, which means it operates at a different level of analysis than most adoption work.

Goodhue and Thompson's model has three components: task requirements, technology functionality, and fit. Fit is assessed per task. This is important. A CRM fits the task of maintaining a rich account history very well. It supports structured data entry, relationship maps, contact histories, opportunity tracking. That is what it was built for. The same CRM fits the task of quickly logging a cold call very poorly. The reps who do a hundred short calls a day do not need deep relationship structures. They need speed. They need to enter a quick note and move on. The CRM fights that task. Every time a rep has to navigate menus and fill required fields to log a two-minute call, the technology is creating friction instead of removing it. The fit is wrong.

Vessey (1991) worked on a related problem from the cognitive side. Cognitive fit theory says that performance improves when the problem representation matches the task type. Spatial tasks, tasks that involve understanding spatial relationships or patterns, are served better by visual displays like charts and maps. Symbolic tasks, tasks that involve precise values and exact comparisons, are served better by tables and numbers. When you put the wrong representation format on a task, the user has to do extra mental work to transform the information into a usable form. That transformation takes effort and introduces error. My notes from the oral prep document are pretty precise about this: "problem-solving performance improves when problem representation (spatial vs. symbolic) matches task type (spatial vs. symbolic); mismatch degrades performance."

The Minnesota Experiments that Dickson, Senn, and Chervany (1977) ran showed this empirically. They found that decision support systems do not consistently improve decision quality. Whether DSS helps depends on whether the presentation format fits the decision task. This was a surprising result for the field at the time, because the dominant assumption was that more information and more analytical power automatically produce better decisions. Cognitive fit theory explains why that assumption is wrong. More is not better. Fit is better.

What strikes me about TTF and cognitive fit together is that they expose a design failure hiding inside what looks like a training failure. When users struggle with a system, the instinct is to give them more training. Train them harder. Make them more comfortable. Improve the change management. Sometimes that works. But sometimes the struggle is because the tool is wrong for the job, and no amount of training fixes a mismatched tool. Vessey's (1991) logic applies: if I am doing a task that requires spatial reasoning and you give me a table of numbers, training me to read that table faster does not solve my problem. It makes me better at the wrong thing.

I think this is where the IS field made a serious mistake for about twenty years. The obsession with adoption models, starting with TAM in 1989 and running through UTAUT in 2003, produced an enormous amount of research on how to get people to accept systems. Intentions. Beliefs. Social norms. Perceived ease of use. All of that is real and matters. But it drew attention away from the prior question: is the system the right one for the task? You can get a hundred percent acceptance of a system that does not fit the work it is supposed to support. The acceptance model gives you green lights. The performance model tells you whether anything useful happened.

The theories.html comparison matrix from my study notes captures this cleanly. The limitation listed for TTF is: "Fit alone does not explain attitudes, trust, or organizational pressure." That is fair. TTF is not trying to explain attitudes. But the symmetric limitation of TAM is that perceived usefulness does not guarantee actual fit, and a system perceived as useful in the abstract can be deeply mismatched with specific tasks. TTF and TAM answer different questions. Treating them as substitutes, rather than complements, is where the field went wrong.

The practical examples multiply fast when you look through this lens. Analytics platforms get deployed for operational teams who need speed and summary, not depth and exploration. The platform fits data science work. It does not fit the operational work. Knowledge management systems fit the task of storing and retrieving documentation. They do not fit the task of answering a quick question from a colleague. Slack works for async teams who need to communicate across time zones with a searchable history. It fights synchronous engineering workflows where the constant interruption destroys focus. Same tool. Different tasks. Different fit outcomes.

The internal link I keep thinking about is what I wrote on effective use and why logging in tells you nothing. Burton-Jones and Grange's (2013) framework asks whether use is faithful to the domain representation the system was designed for. TTF adds the prior layer: is the system designed for the domain this user is actually working in? Effective use assumes fit; it asks whether people engage the system deeply. TTF asks whether engagement is even the right word for the relationship between this tool and this task. The two theories are examining the same outcome, performance, from adjacent angles: fit determines whether use can produce anything, and effective use determines whether use actually does.

Affordance theory as I read it in my post on affordances not being just features covers the action-possibility side of this: an affordance only exists relative to a specific actor with a specific goal. A feature that is useful for one actor with one goal is invisible or actively constraining for a different actor with a different goal. TTF says essentially the same thing about systems at the aggregate level: functionality that supports one task configuration does not automatically support another. They are different languages for the same relational observation.

My read is that TTF is probably the most consistently under-applied framework in enterprise technology evaluation. It is less popular than adoption models because it is harder to operationalize. "Fit" requires specifying the task, specifying the technology functionality at the task level, and measuring performance. That is harder than administering a TAM survey. But the resulting prediction is much more useful: not whether people intend to use the system, but whether using the system will produce the performance benefit it was deployed to deliver.

The Salesforce story at the top is not really about Salesforce. It is about the difference between a good tool and the right tool. A fit mismatch does not show up in adoption metrics. It shows up in shadow spreadsheets.