You pick an app on the day you know least about it: before you have used it. Up front, you judge a tool by what it could do; once you are using it, you judge it by the effort it takes. In experiments published in 2005, Debora Viana Thompson, Rebecca Hamilton and Roland Rust found that students choosing between versions of a media player favored the one with the most features, but those who had used the feature-rich version were less likely to choose it for future use.¹

That is why how to choose productivity apps is less a question about apps than about problems. The five steps put the problem first and the app last:

1. Name the problem in one sentence, before you look at any app
2. Pick the smallest tool that could fix it, starting with what you already have
3. Try it on real work for a fixed period, with an end date
4. Judge it on five written criteria: fit, friction, export, cost and privacy
5. Review it, and be willing to let it go, on a date a few months out

Why the app with the most features often disappoints

Feature-rich apps often disappoint because people judge a product differently before and after using it: in advance, what it can do looms large; once it is in use, the effort it takes does. Thompson, Hamilton and Rust examined this shift in three lab studies with university students, and called the result feature fatigue.¹

The authors’ explanation is about distance. A product you have not used yet is abstract, so you ask what it could do for you, and every extra feature is one more reason to say yes. A product in your hands is concrete, so you ask how to make it do the thing you need, and every extra feature is one more menu to search past. Each feature looked useful on its own in their studies; the cost weighed most once people were using the product.¹

The study

Limited evidence

Chosen before use, less often after: the 2005 feature-fatigue study

Students either compared three versions of a video player without using any, or first spent a session doing set tasks on one version. Before use, 66 percent chose the version with the most features. Among those who had used that version, 44 percent picked it to use again, even though they had already put time into learning it. Features weighed more before use; ease of use weighed more after it.¹

The practical point is the shift itself: the version that wins the comparison is not always the one that wins the week. The caveats are real. These were students in a lab using a media player for a single session, not a work app for weeks, and even the richest version was, by the authors’ own account, a relatively simple product, which they argue makes their test a cautious one.¹

Choosing in public pushes the same way. In a 2011 follow-up, Thompson and Michael Norton found that people leaned further toward feature-rich products when they expected others to judge their choice, and away from them when they expected to use the product in front of others.² Remember that when a team picks a tool in a meeting.

1. Before use: people weigh what a product could do, so, on balance, extra features count in its favor
2. After use: how easy it is to use weighs more, so a crowded product loses ground to a simpler one

Picture a small team picking a task app, as an illustration. In the demo, the one with dependencies, dashboards, custom fields and automations looks like the serious option. A month later, half the team is back to email, because adding a quick task means filling in a form.

Fit and usefulness: whether a tool helps, and whether it lasts

A productivity app can improve your work only if it fits the task and you actually use it, according to the task-technology fit model that Dale Goodhue and Ronald Thompson proposed in 1995. Their data from more than 600 people in two companies moderately supported the model.³

Fit is judged task by task, because a tool’s strengths are strengths only for some jobs. A shared shopping list needs speed and everyone in the house on the same list; a project with a dozen moving parts needs dates and dependencies. Put the shopping list in a project tool and it becomes a chore; run the project from a shopping-list app and things slip. Neither app is bad. Each is a poor fit for the other job.

Use is the other half, and it turns more on payoff than on polish. In Fred Davis’s 1989 studies and in a 2006 meta-analysis of 88 studies by William King and Jun He, how useful people judged a tool was more strongly linked to using it, or meaning to, than how easy they found it.⁴⁵ Read practically, a clumsy tool that removes a real problem is more likely to get used than a pleasant one that removes none.

One caution: this research measures whether people intend to use a tool or say they use it, not whether it made them more productive. It tells you which apps are likely to stick, not which ones will help.

Easy to useHard to useFixes a problem you namedFixes nothing you named

Fixes a problem you named, Easy to use: Keep ituseful, and cheap to use daily

Fixes a problem you named, Hard to use: Worth learningbudget time to get past the friction

Fixes nothing you named, Easy to use: Pleasant distractioneasy to open, nothing to show for it

Fixes nothing you named, Hard to use: Drop itno problem to justify the effort

So before asking whether an app is pleasant, ask what it will change about your week. If you cannot answer in one sentence, a smooth interface will not save it.

Too many apps to choose from? A clear problem shrinks the list

A long list of apps is less likely to stall you than its reputation suggests, especially once you know what you need. A 2010 meta-analysis of 50 experiments by Benjamin Scheibehenne, Rainer Greifeneder and Peter Todd found an average choice-overload effect of virtually zero, with wide variation between studies.⁶

Myth

There are so many apps that choosing one is bound to overwhelm you.

Fact

In a 2010 meta-analysis of 50 experiments, more options made little difference on average; a 2015 meta-analysis found overload more likely under certain conditions, such as unclear preferences.

A 2015 meta-analysis by Alexander Chernev and colleagues identified four conditions that make overload more likely: a complex set of options, a difficult decision task, unclear preferences and a goal of choosing with minimal effort. With those conditions taken into account, it found a significant overall effect.⁷ Several of them describe someone scrolling through task managers without having decided what the task manager is for. The jam-aisle story behind this idea, and why it shrank, is covered in how everyday decisions go wrong and which biases hold up.

Of those conditions, unclear preferences is the one you can remove before you start. Without a clear need, every option is a comparison you cannot settle; with one, most options drop out at a glance. A sentence such as “I lose track of what I promised clients in meetings” turns dozens of candidates into a handful, because most of them do not do that job.

How to choose productivity apps in five steps

To choose a productivity app, name the problem in one sentence, pick the smallest fix, test it on real work, judge it on criteria written in advance, and review it after a few months. Each step answers a finding above, and steps that rest on our reasoning say so.

1. 1Name the problemone sentence, no product names
2. 2Pick the smallest fixwhat you already have comes first
3. 3Try it on real worka fixed period, a note of what to check
4. 4Judge it on criteriafit, friction, export, cost, privacy
5. 5Review and let gokeep, simplify or retire

Then repeat from “Name the problem”

1. Name the problem in one sentence

Write down what goes wrong, when it happens and what it costs you, without naming any product: “Follow-ups I promise in meetings get lost, and clients have to chase me.” The sentence keeps you shopping for fit rather than features, and it tells you what to check at the end of the trial.

Sometimes the sentence shows the answer is not an app at all. A habit or method may fix it, which is why matching a productivity method to the problem you have comes before choosing the software to run it.

2. Pick the smallest tool that could fix it

“Smallest” means the fewest new things to learn: a feature in an app you already use, the app that came with your phone, a paper list, or one narrow app, before a platform that promises to run your life. This is the feature-fatigue lesson applied before you shop, while extra features are still easy to turn down.

For the follow-ups problem, the smallest fix might be a recurring calendar reminder to process meeting notes, or a single list where every promise goes, the capture habit behind getting organized when you don’t know where to start. Only if that fails do you need something bigger.

3. Try it on real work for a fixed period

Put your real tasks into the app, not demo ones, and set an end date, such as two weeks, before you start. A demo shows a tool on its best day; your own busy week shows the effort it takes. In Anol Bhattacherjee’s 2001 survey of online banking users, whether people meant to keep using a system was linked to their satisfaction and to how useful they found it, and both were linked to whether use had confirmed their expectations.⁸

On the end date, read the problem sentence again before you look at the app. If the follow-ups still get lost, the trial has answered the question, however much you like the interface.

4. Judge it on five written criteria

Write the criteria down before the trial starts, so the demo cannot rewrite them. Fit and friction come from the research above; export, cost and privacy are practical checks, mostly our own reasoning.

On privacy, the US Federal Trade Commission suggests checking what information apps can reach through your phone’s privacy settings, and turning off unnecessary permissions or deleting apps that ask for more than they need.⁹ The criteria do not weigh the same: a tool that fails on fit should not survive on a low price or a pleasant screen.

5. Review it, and be willing to let it go

Set a date, a few months out, to ask two questions: is the problem sentence still true, and am I still using the tool to fix it? Then keep it, strip it back to the parts you use, or retire it. The review has to be a date in the calendar rather than a feeling, because staying is what happens when nobody decides.

Subscriptions show how strong that default can be. In a 2025 study of US payment-card data covering ten popular subscription services, Liran Einav, Ben Klopack and Neale Mahoney found that cancellations rose sharply in months when a replacement card meant subscribers usually had to update their payment details, which the authors read as a sign that many had kept paying for something they no longer valued. In the authors’ models, that inertia roughly doubled sellers’ revenue from a given set of subscribers, on average.¹⁰

Habit pulls the same way. A 2012 study by Greta Polites and Elena Karahanna largely supported a model in which habit, the perceived cost of moving and costs already sunk into a system are linked to inertia, and inertia to seeing a new system as harder to use and less advantageous.¹¹ A 2015 meta-analysis of 98 effect sizes by Stefan Roth and colleagues found clear evidence of the sunk-cost effect, the pull to stick with something because of money already spent on it.¹²

Switching has real costs too, so a new app has to beat the old one on a written criterion; feeling fresh is not enough. The rule we suggest: money and hours already spent are not reasons to keep a tool, and novelty is not a reason to replace it. Only the problem sentence is.

WiserHours

Choosing your next app

• Write the problem in one sentence, with no product names
• List what I already have that might fix it
• Choose the smallest tool worth trying
• Write my five criteria and which one would rule it out
• Move real tasks in and set an end date for the trial
• Put any renewal date in my calendar
• Test exporting my data once
• Set a review date a few months out

Find this checklist online:
https://wiserhours.com/productivity-apps/how-to-choose-productivity-apps/#checklist-how-to-choose-productivity-apps-steps

Where the research ends and our reasoning begins

The strongest evidence here is on why people keep using tools; the evidence on choosing them rests on a few lab experiments, and the criteria and review schedule are partly our reasoning.

The bottom line

Choose the problem before you choose the app. Write one sentence about what is going wrong, try the smallest tool that could fix it on real work, and judge it on criteria you wrote before the demo impressed you. Then put a date in the calendar to ask whether it still fixes the problem you wrote down, and let money already spent stay out of the answer.