Productivity

What productivity apps are worth building?

Productivity tools are crowded with general-purpose planners, so the ones worth building tend to be specific. They put a number on a cost people feel but rarely measure, or they perform one recurring chore that people keep postponing. A meeting cost ticker turns attendance into a running total. A weekly review drafts itself from the calendar and the task list. A hold assistant stays in a phone queue for the user and calls back when a person answers. Each has a single clear job, which is what makes it possible to test.

Three shapes recur. Measures turn a hidden cost into a figure. Routines do a chore such as a review, a log or a planning step. Handled interruptions take a waiting or repetitive task off the user’s hands. Measures are the easiest to test, because the figure either surprises people or it does not. Routines are where most ideas fail, because people abandon a chore that takes longer than the chore itself. Interruptions depend on the telephone or messaging systems people already use, which a first version should rely on rather than rebuild.

A planner that opens to an empty list is usually a planner. The test is what the main screen contains. If it contains a number, a draft or a waiting state, the idea is doing something.

Who uses productivity apps, and how do you reach them?

Knowledge workers who run their own calendar, team leads who run recurring meetings, freelancers who bill by the hour, and people who have already tried several planners and given up are the clearest groups. The last group is often the most useful to talk to. They know which tools they tried, what they expected, and the exact point where they stopped, which is more specific than a general survey answer.

Reach people with the measure or the routine itself, not with a general promise to save time. A shared screenshot of what a particular meeting costs is a more concrete hook than any feature list. Test whether people who try the tool come back in a second week, since productivity tools are often opened once and then forgotten. Returning use is the signal that matters, and an install count is not.

What makes a productivity idea good?

• It names the cost or chore in one sentence, with the thing it saves or shows. “Meetings cost money” is a feeling. “A team’s weekly meetings, priced by the people in them” is an idea.
• The input is data the user already produces: a calendar, a task list, a phone call, a typing session. A tool that asks for new data every day is asking for a new chore.
• The output is one number or one page. A dashboard with eight panels is a second job for the user.
• It removes a step rather than adding a habit. A tool that needs a daily check-in to work has made the problem worse for the people who forget.
• It can be switched off in a day. A productivity tool that is hard to leave creates its own cost, and users notice it.

Write the figure or the page the user should see at the end. If you cannot describe it, the idea has no output yet.

What does a first version look like? A worked example

Hypothetical meeting cost ticker for one team. The user enters the number of attendees in each role and an hourly cost for each role, then starts the timer. A running total shows while the meeting is on screen, and a final figure appears when it ends. The rates are typed by the user, so the first version needs no calendar login and no access to anyone’s pay.

Build a single-page app. Inputs: a list of roles, each with a count and an hourly cost typed by the user, in one currency. Store the rates only in the browser. Controls: start, pause and stop. While running, show a large running total from zero, updated every second, and the elapsed time. After stop, show the final total and a plain line stating how many minutes of the meeting the total was made of. Include a visible note: “This is an estimate from the rates entered, not a figure from any employer.” Store nothing on a server and send nothing to anyone.

Test it on three real meetings the team already has. Ask whether the figure changed what anyone did in the next meeting, such as cutting the attendee list or shortening the agenda. If it did not, the cost is not the thing people act on, and the idea needs a different measure, such as the number of agenda items decided per hour.

What goes wrong with productivity apps?

• Monitoring dressed as productivity. Tools that log keystrokes, screen time or message counts for someone else’s view turn people into the metric. Keep the data with the person who generated it, and do not build a manager’s view of an individual’s activity.
• Figures that look precise. A cost ticker built on guessed hourly rates shows false precision. Label the estimate and show how it was calculated.
• Another planner. The category has many, so a generic task list will be compared with products people already use. Pick one measure or one routine and build that.
• Streaks and penalties. Streak counters and lost-progress messages keep some people going for a while and make others quit. Avoid designs that punish a missed day.
• Promised savings. A claim about the hours a tool will save cannot be tested before users exist. Describe the measure itself, and let users work out what it is worth to them.

Where to start: live ideas and the next post

Four ideas that were on the board when this page was written map onto the measures and routines above. Meeting cost ticker is the measure described in the worked example. It waits on hold for you and calls when a human answers is a handled interruption, and its hard part is the telephone system, which a first version can avoid by relying on the user’s own phone. The weekly review that writes itself is a routine, and its test is whether anyone reads the draft. Clak, a typing test that feels and sounds like a mechanical keyboard is a different kind of tool, where the test is whether people return to it.

Pricing some other hidden cost? Post it as three things: the cost, the data the user already has, and the one number or page that comes out. A builder can test the claim with how to validate an app idea, and weekend project ideas shows how small a first build can be and still finish.