Stop prompting. Give Claude work.

In almost every training session I give, I see the same thing. People open Claude and think: "What should I ask Claude?"

That's a perfectly fine question if you have a chatbot in front of you. But Cowork is not a chatbot. Cowork can read your files, walk through folders, operate your apps, run code, deliver finished output and start at nine in the morning without you being there. If you use that tool to ask questions, you're using maybe ten percent of what's there.

The question to ask in Cowork is a different one: "What work can I hand over here?" It sounds like a small difference in wording. It's a big difference in results.

The difference between a question and an assignment

Put two versions of the same intention side by side.

As a question: "What's the best way to create a monthly report from my website statistics?"

What you get back is an explanation. Useful, maybe. But you still don't have a report, and next month you start all over again.

As an assignment: "The folder /reports contains the monthly exports of the past twelve months. Turn the most recent export into a report of at most two pages: first the five most important changes compared to last month, then the numbers in a table, then one paragraph on what should catch my attention. Use the structure of report-june.docx. Don't ask anything in between, but list at the end which numbers you couldn't trace."

What you get back is a report. And because the assignment is written down, it can run again next month.

The difference isn't length. It's that the second version describes work instead of a topic. Look at what it contains: where the material lives, what the end product is, how it should be structured, which example is leading, and what to do with loose ends. That's exactly how you'd explain a task to a new colleague.

The five parts of a good work assignment

You don't need to be a prompt engineer to delegate work well. You just need to do what every good manager does when handing over a task. A good work assignment has five parts.

1. The location. Where is the material? Name the folder, the file or the source. "The folder /reports contains the monthly exports" is concrete; "my numbers" is not. Cowork can read your files, but it needs to know where.

2. The end product. What do you want to have in your hands when it's done? A two-page document, a table, a filled-in presentation, a tidy folder. Describe the result, not the activity. "Analyze my numbers" is an activity; "a report of at most two pages" is a result.

3. The structure. In what order, with which parts? "First the five most important changes, then the table, then one paragraph on what should catch my attention." This way you decide the structure, and Claude doesn't have to guess it.

4. The example. Point to a document that shows what it should look like: "use the structure of report-june.docx." One good example replaces ten lines of explanation about style, tone and formatting.

5. The handling of loose ends. Say what should happen when something is unclear. "Don't ask anything in between, but list at the end which numbers you couldn't trace." That way the work can run through in one go, and you still keep sight of the doubtful cases.

Whoever puts these five parts on paper holds something else of value: a reusable assignment. Next month you change one file name and the work runs again. That's the moment a prompt becomes a process.

Three tasks to start with this week

You don't have to overhaul your entire work week. Pick one task you had to do anyway and phrase it as a work assignment. Three candidates that exist in almost every job:

1. The recurring report. Monthly numbers, a week overview, a team update. It's the perfect first task: the source files exist, last month's version is your example, and the assignment repeats itself. Write it once, run it every month.

2. The overdue clean-up job. A folder full of files named final-v3-REALLY.docx, a downloads folder spanning three years, an archive nobody dares to touch. Have Cowork walk through the folder, propose a logical order, and rename or file the pieces. Exactly the kind of work that's never urgent enough to do yourself, and perfect to hand over.

3. The first draft. A proposal, a job posting, a project plan. Don't hand Claude an empty page but your material: previous versions, notes from the meeting, the client's email. Ask for a first version following the structure of a document you were happy with. You spend your time improving instead of starting.

Where you stay at the wheel

Handing over work is not the same as handing over responsibility. Three boundaries I keep in every training session, and at my own desk just the same.

Decisions stay yours. Claude can prepare options, line up pros and cons, calculate scenarios. But the choice of which offer goes out the door, who gets which message, which direction the plan takes, that's yours. Have the decision prepared, never taken.

Everything that leaves the building passes you first. An email to a customer, a quote, a publication: Claude drafts, you send. Not because it will go wrong, but because your name is on it.

You remain the final editor. Check numbers, names and claims before the result travels on. That check takes a fraction of what the work itself would have cost you. That's precisely the deal: Claude puts in the hours, you provide the judgment.

Start with one task

Don't start big. Pick the report, the clean-up job or the first draft this week. Write down the five parts. See what comes back. And notice what changes in your head: you stop coming up with questions and start seeing work everywhere that you can hand over. That switch, from asking to delegating, is the real upgrade. Not the model. You.