Start From the Task
The mismatch between what somebody needs and what they buy is introduced at a specific moment: when a task in ordinary words is translated into a category name. For a related reference point, Monitask has a guide to self-reporting bias, which is useful when comparing whether a dedicated tool is warranted.
Where the translation happens
"I keep losing track of what I said I'd do."
Typed into a search box, that becomes "project management software" — and the category contains tools built for construction programmes, product teams of eighty, and agencies billing against multiple clients.
None of that was in the original sentence.
Categories are named by the people selling into them, and they are named for the largest buyer rather than the most common one, because that is where the revenue is. The name is a marketing decision that the buyer then inherits.
What to do instead
Write the task down before searching, in the words you would use to a colleague.
Then add three things:
How many people are involved. One, a handful, or many — this single fact eliminates most of any category.
How often it happens. Daily, weekly, or twice a year. A twice-a-year task rarely justifies a subscription and frequently justifies doing it by hand.
And what happens if it goes wrong. A missed personal reminder and a missed client deadline are different problems and warrant different amounts of machinery.
Four sentences. They take two minutes and they are the difference between searching for a category and searching for a fit.
The question before the search
Can this be done with something you already have?
Frequently yes, and the answer is systematically absent from search results because search results are written by people selling software.
A spreadsheet, a shared folder, a calendar, an email thread with a consistent subject line — each of these solves a class of task that has an entire software category built on top of it.
This is not an argument for doing everything by hand. It is an argument for knowing what the paid tool is buying you over the free version, which is a question with an answer.
Sizing the answer
The smallest thing that solves it is the working rule, and it holds for a specific reason: a tool that is too small announces itself quickly and a tool that is too large does not.
Outgrowing something is visible. You hit a limit, you notice, you move.
Being oversold is invisible. You use 15% of a platform, pay for all of it, and there is no moment at which anything tells you.
Which makes the errors asymmetric, and the asymmetry is the argument for starting small.
When the category is right after all
Some tasks genuinely belong to a category, and pretending otherwise wastes time.
Where the task is regulated — payroll, accounts, anything with statutory formats — the category exists because the requirements do.
Where several people must work in the same thing at once, informal arrangements fail predictably.
And where the task is your core operation rather than an administrative edge, buying the developed thing is usually right. A firm whose whole business runs through customer conversations should have a real system for them, not a spreadsheet.
The distinction is whether the task is central or peripheral, and most software is bought for peripheral tasks at prices set for central ones.
The phrase to avoid
"We need a proper system for this."
It is the sentence that converts a task into a category, and it usually means the current arrangement is annoying rather than inadequate.
Ask what specifically fails. If the answer is a named, repeated failure — things get lost, two people did the same work, a deadline was missed — that is a requirement and it can be matched.
If the answer is that it feels ad hoc, that is an aesthetic preference, and it is an expensive one to satisfy with a subscription.
Describing it to somebody who sells software
The four sentences work in a demonstration too, and they change what you are shown.
A vendor given a category name shows you the platform. A vendor given a task, a headcount, a frequency and a consequence shows you the part of it that applies — or says it is not a fit, which good ones do and is worth a great deal.
Ask directly: "Is this more than we need?" The answer is occasionally yes, and a vendor who says so has told you something about themselves worth knowing.
What to write down before you look
A single note, kept.
The task. The people. The frequency. The consequence. And what you do now.
That last one matters most and is usually omitted — because whatever you do now is the baseline, and any tool has to beat it rather than merely be better than nothing.
"We do it in a shared spreadsheet and it works except when two people edit at once" is a specification. It names the thing to fix and implies the thing to keep, and it is a better brief than any list of desired features.
The task nobody writes down
"Somebody should be keeping an eye on this."
Not a task — a worry, and it produces the most expensive purchases because there is no specification to constrain the answer.
Turn it into a task by asking what you would want to know and when. "I want to know on Friday if anything is more than a week late" is a task. It has a frequency, an output and a trigger, and it is answerable with a filter rather than a platform.
Worries buy dashboards. Tasks buy tools. Additional context is available from CNET.
The short version
- The size mismatch is introduced when a task in ordinary words becomes a category name in a search box
- Categories are named by sellers for the largest buyer rather than the most common one
- Write the task down first, then add how many people, how often, and what happens if it goes wrong
- Ask whether something you already have does it, which search results systematically will not tell you
- Errors are asymmetric: outgrowing a tool announces itself, being oversold never does
- "We need a proper system" usually means the current one is annoying rather than inadequate — ask what specifically fails