Start with the Job, Not the Brand

A community event needs a workable timetable, not another AI subscription. Before comparing products, it helps to work out which parts of the job need thinking, current information and an actual editable file.

Imagine you're responsible for organising a small community event. You have notes from six volunteers, an old timetable and a few possible venues. Someone recommends a new AI product that promises to do everything. Before you sign up, it's worth asking a less exciting question: what exactly needs doing? You might need to turn disorganised notes into decisions, check up-to-date venue information and produce a timetable other volunteers can edit. Those are three different jobs, even though they all belong to one project.

That distinction is called thinking in capabilities rather than brands. A product is a package of capabilities: it might write and summarise, search the web, interpret an uploaded document, create an editable file or connect to a calendar. Some products do several of these well; others do one particularly well. What matters is the gap between the information you have now and the result somebody can actually use. A persuasive paragraph about a timetable isn't the same thing as an editable timetable.

Start with the deliverable. If you need ideas to discuss, an ordinary conversation with a general assistant may be enough. If volunteers need to rearrange dates, your deliverable is probably a spreadsheet or shared calendar. If the council asks for evidence of your venue comparison, you'll need sources you can inspect, not just a confident recommendation. Working backwards from the deliverable reveals the operations the system must perform: read, compare, calculate, retrieve, create, share or update.

Next, separate information the assistant can reason over from information it must obtain. It can organise the notes you provide without contacting anybody. It cannot reliably know whether a venue is available next Thursday unless that information is checked against a current source. A tool that can search the web may find published opening hours, but published opening hours are not a booking confirmation. The capability you need might actually be access to a live booking system, or a hand-off to a human who can telephone the venue.

Consider permissions as part of the job, not a nuisance to deal with afterwards. A connected tool might read files, send messages or change records. Each permission expands what the system can do and what a mistake might affect. If you only need a draft invitation, don't grant access to send emails. Ask for a draft you can check. If private contact details are involved, use an approved environment and share only what's necessary. A more powerful tool isn't automatically the better choice.

Now test the smallest approach that could work. Give one assistant a short, realistic sample of your event notes and ask for a timetable with the constraints made explicit. Check whether it catches overlapping commitments and admits when a venue detail needs verification. If it produces the right structure, you've learned something useful without migrating your entire project. If you still need an editable file, test whether the product can genuinely create one. Don't mistake instructions for making a file for the file itself.

Only add a specialist tool when you can name the improvement. Perhaps it saves manual copying, handles a format your main assistant can't, or gives controlled access to a source you must use. Then count the extra costs: a subscription, another login, learning an unfamiliar interface, data permissions and the effort of moving outputs between services. A tool that wins an impressive demo may lose once those practical costs are included.

You can make the choice visible in a simple three-column comparison: required result, essential capability and how you'll verify it. For example: 'shared timetable' needs an editable calendar or spreadsheet, verified by opening and changing an entry; 'venue recommendation' needs current evidence, verified at the original source; 'invitation' needs clear writing, verified by reading it before sending. You don't need to score twenty products. You need a defensible reason to use the one you chose.

This is particularly important as AI products change. A capability that's unavailable today may appear next month; a feature included in one plan may require payment in another. By describing the job rather than memorising a league table of brands, you keep the skill when the market changes. The goal isn't to become an expert shopper for AI subscriptions. It's to become someone who can recognise what a task needs, select the simplest capable setup and check that the result really works.