3 Types of People Use AI. Only ONE is the Right Choice.

Picture two people using the same Claude subscription. Same model, same features, same price.

One keeps getting work they have to redo, the other gets results they can actually use.

If you’re the first person, it’s frustrating. 

You’ve learned how to prompt. You’re using the tool.

But you’re still wondering what everyone else seems to have figured out.

Having the same access doesn’t explain the difference. We need to look at what each person is doing with it.

McKinsey describes 3 approaches companies take to AI: Takers, Makers, and Shapers.

And it’s a useful framework for thinking about your OWN relationship with AI.

Each describes different decisions about what to buy and what to build.

Understanding that choice helps you put your effort into something that actually improves the way you work.

Takers use AI the way the vendor built it

Takers rent AI. Claude or ChatGPT exactly as the vendor built it (maybe with a few settings changed and some favorite prompts).

They get powerful technology immediately, without the hassle of developing or maintaining it.

For plenty of tasks, that’s the right call.

There’s no prize for rebuilding something you could have bought.

But the tradeoff is fit.

A general-purpose product serves a wide variety of people doing completely different work.

Its research tools don’t come with the standards you have for credible sources.

Its document analysis doesn’t include your project history or commitments.

You can supply that missing context in the conversation, but you’re still responsible for telling Claude what matters and checking whether it used that information correctly.

And being a Taker doesn’t mean being BAD at AI.

You’re relying on the standard product and directing how it gets applied.

With time, the more you prompt, the better you get at prompting. 

To go beyond that takes some building. But building the AI itself is a different job from customizing how you use it.

Makers build the model

OpenAI, Anthropic, and Meta build the underlying models.
That’s the Maker’s job in this framework.

They invest in research, training data, computing infrastructure, and specialized people.

Then they keep developing and operating that technology.

The REWARD is control over the model.

The COST is taking responsibility for technology the rest of us access through our subscriptions.

That only makes sense when developing AI models IS your business.

But even a model you owned would still need the information and process for your particular job.

Let the Makers focus on improving the model.

Your only focus should be building your knowledge and process into how the model does YOUR work.

Shapers build the harness

A Shaper takes an existing model and builds a setup around it for specific work.

That setup is called a HARNESS.

It includes the information, instructions, tools, and workflow that determine how the model does the job.

Claude already supplies part of that setup.
You build the part specific to your work.

For instance, say you want to build a weekly project brief.

You need to know which commitments are at risk and what needs a decision.

In the Takers world, they’d prompt Claude with the request, give it a list of their to-do’s, and Claude would provide them a basic high-level summary.

But that summary of updates doesn’t necessarily answer which commitments are at risk OR what needs a decision.

So the setup needs the commitments AND the updates, with instructions to compare them, flag missing information, and show the evidence behind each finding.

For my content, that means things like previous scripts, a voice file, and a research skill.

Those provide examples of how I explain things, writing standards, and a sourcing process.

That’s where I’d put my effort.

Use the model someone else built. Build the setup for your own work.

But before building it, you need to be able to tell whether it’s doing the job properly.

Start with work you know how to judge

Imagine the weekly brief says a launch is ready because every task is complete.

Except it still needs approval.

You catch that because you’ve done the work and are familiar with the process. You understand that “tasks complete” and “ready to launch” mean two different things.

Now you have something specific to build into the harness: check approval requirements before calling a project ready.

Give it the record of who needs to approve what, then check whether the next brief catches outstanding approvals.

That’s how your experience makes the setup better. You recognize what’s missing, explain the requirement, and test whether it’s been addressed.

Without that experience, you might accept the first report.

You’d have a tool producing convincing answers, with no reliable way to tell whether they’re useful.

So start with a recurring task you already do. Something where you can look at the result and say, “This missed something, and here’s why.”

And keep the first version specific to YOUR work. 

A company building project-management software has to serve thousands of organizations. You only need to account for YOUR projects, YOUR approval process, and the decisions YOU need to make.

Use your experience to define what good looks like. That gives you a clear job to build the harness around.

But what should you shape and what should you…take?

Build the missing parts, not the whole thing

Take what Claude already does well: reading documents, comparing information, drafting responses. Let Anthropic keep improving those capabilities.

Shape the parts specific to YOUR work: the information it needs, the process it follows, and the standards you judge it against.

For the weekly brief, that means project commitments, current updates, and instructions to flag risks, blocked decisions, and outstanding approvals—with evidence for each finding.

Put the materials and an example brief in a folder on your computer. Open Claude Code, select that folder, and paste this:

Run it against a real week. Did it catch the issues you would have raised? Can you verify its findings?

Make it something you’ll actually use

If checking the brief means digging through six documents, you’re still doing the detective work.

Have it put each finding beside its supporting evidence and the decision needed. A simple document might be enough.

That’s part of Shaping, too: deciding how the work reaches you so you can actually use it.

And when a finding is wrong, the evidence gives you somewhere to start.

The corrections are part of the build

Say the brief flags a decision that’s already been made. Deleting it fixes today’s brief. It doesn’t fix next week’s.

Check the cause. If the decision is missing from the source material, add it. If Claude relied on an older update, clarify how it should handle conflicting records.

Save the correction where the skill will use it, then rerun the brief to check that it worked.

Now your review improves the process, instead of fixing the same answer every week.

Your subscription is the starting point

That’s why I’d choose Shaping. You get the technology the Makers keep improving, with a process built around how YOU work.

This week, pick ONE recurring task you understand well enough to judge.

Give Claude the materials and standards it’s missing.

Run it, review it, and save the corrections.

You’ve moved from directing another conversation to building a process you can use again.

Now If you’re a business owner or operator who wants help building your own harness,

I’m opening a few spots to join the 10+ business owners I’m working with directly, helping build theirs. Apply to join us → HERE

Cheers, see y’all next newsletter.