Start with the Job, Not the Tool

A colleague asks you to organise feedback from a community event, and a blank document is open on your screen. Before choosing a template or app, decide what the work needs to produce: a set of recurring themes, a record of each comment, or a short list of issues to discuss. Starting with the job, not the tool, helps connect the task with the kind of support it actually needs.

A tool can shape how work gets done, but it cannot decide what the work is for. Naming the task, its limits and the intended result helps you identify whether you need a shared document, a form, a physical tool or a conversation.

Describe the job as an observable change

Start with a verb and an object: sort incoming requests, record a room’s condition, draft a reply or hand over a piece of work. A broad label such as “manage projects” bundles distinct activities together and makes it harder to identify useful support.

Then describe what should be different when the task is complete. A request might be ready for a decision; a room might have a usable inventory; a reply might answer a customer’s specific question. The intended result should be recognisable to another person without guesswork.

Say you have been asked to organise feedback from a community event. You begin with comment cards and a request to prepare material for a planning meeting. First, you read the cards and mark recurring subjects, keeping each comment attached to its wording; next, you put the subjects and relevant comments in a shared document. The resulting document lets the group see both recurring concerns and individual remarks, rather than presenting a count that loses the original context.

Write one plain sentence describing the change the work should produce. If it contains several verbs joined by “and”, check whether it combines separate tasks that need different support.

Separate firm constraints from preferences

Constraints are conditions the work must respect. They may concern who can see the material, where the work happens, what equipment is available, how much detail is needed or whether other people must contribute. These conditions narrow the useful approaches before product names enter the conversation.

Some constraints are firm. Private information may need to stay in an approved system; a task away from a desk may call for paper or an appropriate mobile method. Other conditions are preferences, such as wanting a familiar interface. Keep the two distinct: a preference can often bend, while a firm constraint may rule out an approach.

It also helps to name what must not happen. A feedback process might need to keep names from being visible to the whole group. A repair record might need to preserve an observer’s wording rather than turn an observation into an unsupported conclusion.

List the conditions and mark each as essential or preferred. If an approach conflicts with an essential condition, set it aside; if it conflicts only with a preference, consider whether another part of its fit makes the trade-off worthwhile.

Identify the kind of support the task needs

Many jobs do not need a new app. The useful distinction is often between kinds of support: capturing information, organising it, calculating or transforming it, communicating it, or coordinating people. A notebook can capture observations; a spreadsheet can organise rows and apply formulas; a shared document can support joint editing; a conversation can resolve an ambiguity that a form would only record.

These functions can overlap. A spreadsheet may also help people coordinate, and a paper form may make information easier to capture in a busy setting. Naming the main function keeps attention on the work rather than on a tool’s more prominent features.

Consider a team collecting equipment faults from several rooms. If the immediate need is consistent records, a form with the same fields for each report can help. If the team must decide which fault needs attention first, a shared, sortable list and a way to discuss urgency may be more useful. One approach captures information; the other helps people act on it.

Ask what the work needs help doing, then choose a format that supports that function.

Make the intended result easy to recognise

A desired result becomes practical when someone can tell whether it has been reached. “Make the handover better” is hard to judge; “leave the next person with the current status, the unresolved question and the relevant file” is clearer. The second description also points to what the format must make easy to record.

Decide what information belongs in the output and what can stay out. A handover note may need a “next action” field, while a long account of every earlier discussion could bury the detail its reader needs. Too little structure invites gaps; too much can make routine work cumbersome.

Imagine you need to leave a colleague with a draft to continue. The starting materials are a current document, a source file and one unresolved editorial choice. You put the latest version, the choice still to be made and the source file in a shared document, then add a brief status note. The colleague can find the material and understand what remains; a task board alone might show ownership without preserving the reasoning.

Read the blank fields from the recipient’s point of view. If a field supports no decision or action, leave it out.

Match the method to the people involved

Some tasks are individual; others depend on review, approval or a hand-off. If another person must respond, identify what they need to receive and what they are expected to do. That may call for comments in a document, a direct message or a record that keeps decisions beside the relevant material.

Several people being involved does not automatically mean everyone needs access to the same tool. One person may supply information while another owns the decision. Matching the method to those roles keeps participation proportionate and makes it easier to see where the work stands.

For sensitive material, access and sharing conditions matter as much as convenience. Clarify the intended audience and use approved arrangements where applicable.

Questions that help identify the right support?

Use a selection note to keep the task in view

Before browsing products or methods, write a brief selection note covering the task, the intended result, essential conditions and the kind of support needed. Add who must use or receive the result if that affects access, format or timing. The note keeps the decision connected to the work without prescribing a brand or interface.

For example, “record each visit, keep names private and make unresolved issues easy to locate” describes needs that could be met in different ways. “Use a particular app with a particular layout” commits to a method before its suitability is clear.

When you compare approaches, use the note to check whether each supports the task, respects its essential conditions and leaves the intended result in a usable form. If the work changes, update the note first; a different task may call for different support, even when the existing tool still suits the old one.