What I learned trying to delegate my job to Claude Code

What does a Product Marketing Manager (PMM) actually do?

I've been a PMM. I've managed PMMs. I've hired PMMs. And if you asked me to write down exactly what the job is, the actual process, the actual judgment calls, it would take me a while. A job description might say: "Own positioning and messaging. Lead content production. Drive executive storytelling. Support field marketing. Build sales enablement. Conduct competitive research."

True but also in my opinion, completely useless. You could follow that job description perfectly and still have no idea if you're doing the job well.

That was fine when I was the one doing the job, or managing the team that did the job. I'd internalized what "good" looked like. I knew when messaging landed and when it fell flat. I knew which battles to pick with Sales and Product and which to let go. The knowing was in my head, validated by my years of experience in SaaS Marketing, but never written down.

Now that I am a bootstrapped entrepreneur pushing the boundaries of AI, it's a problem. Not just in Product Marketing land, but across every function I am managing with AI.

Knowledge work is poorly defined

When I started using Claude Code in earnest for more than just development, I did what everyone does. Write a prompt, get an output. Ask the model to improve the prompt, get a better output. Chain prompts together into workflows. It worked, with carefully controlled context and lots of back and forth. But I kept hitting the same ceiling: no matter how much prompt tuning I did, the output would still be off. I couldn't explain why. It just felt off.

Surely there's a better way, I thought. Surely someone has defined "knowledge work" or "judgment" in a way I could actually use. If I could find a rigorous framework, I could build my workflows and prompts around it.

I literally couldn't find anything usable.

The term "knowledge work" has been around since Peter Drucker coined it in 1959, in his book, The Landmarks of Tomorrow, but after sixty-five years of use, one researcher called the concept "theoretically and empirically weak." We use it constantly without agreeing on what it means. The definitions I found were either tautological ("work that requires thinking") or listed examples without cleanly defining the category.

"Judgment" was worse. The Harvard Business Review published a piece, The Elements of Good Judgment, that concluded good judgment is "the core of exemplary leadership" and comes from "a learning process." That's not a definition. It's a placeholder. Michael Polanyi argued expert knowledge is fundamentally unknowable: "we know more than we can tell." True, but defeatist if you're trying to teach it. Other frameworks described how judgment develops or fails, but none told me what "good" actually looks like.

Towards the end of my research, I realized all of these definitions just point at each other without ever landing on something concrete. And guess what, you can't teach anyone to "use good judgment" if you can't define it. Let alone teach AI.

Try it yourself. What does a PMM actually do? You might break it down like this: there's domain knowledge (the market landscape, competitor positioning, customer segments, product capabilities). There's process (launch planning, messaging development, sales enablement, competitive analysis). There's judgment (which features to emphasize, what resonates with this audience, when messaging is "done").

The problem: every one of those elements still requires judgment to execute.

Knowing the market landscape doesn't tell you which competitor to position against in a specific situation. Having a launch planning process doesn't tell you whether this counts as a Tier 1 or Tier 2 launch. Even "sales enablement" requires judgment about what Sales actually needs to know versus what will just create noise. Tell that to every Product Manager who's tried to train Sales on a new feature.

The judgment bucket? That's where things collapse entirely. "Which features to emphasize" assumes you can articulate why you emphasize some over others. "What resonates with this audience" assumes you've externalized the pattern-matching that lets you predict resonance. "When messaging is done" is the worst offender, because the real answer is usually "when it feels right." Judgment calling itself done.

This is why, in Pavilion's CMO School, one of the most-cited pitfalls for PMMs is "becoming an order-taker for Sales or a content-jockey." When you can't define the judgment layer, the role collapses into whatever's most tangible: decks delivered, emails sent, requests fulfilled.

This is also why product marketing talent stays scarce even though the job has been around for decades. We're not looking for rare skills. We're looking for people who've developed tacit frameworks through years of pattern-matching, then hoping they can adapt those frameworks to our context. We can't transfer the judgment directly, so we hire for the ability to rebuild it from scratch.

That worked when you were hiring humans. It doesn't work when you're trying to "hire" AI.

Humans can build on imprecise definitions

We've operated on these undefined terms for decades. It worked because humans calibrate.

With human hires, you'd screen for competencies that correlated with success. You'd give feedback, they'd calibrate, they'd internalize your standards over time. You never had to define your judgment. Just react to their attempts. A manager says "this isn't right." The person figures out what "right" means through iteration.

With AI, that doesn't work. There's no intuition to calibrate. No background that helps the AI read between the lines. You have to transfer both process and judgment explicitly. The difference in one sentence: a manager says "this isn't right." A teacher has to say why it isn't right, what right looks like, and how to get there.

We've spent careers learning to do, then learning to manage doers. Teaching is different. Most of us have never learned to teach. So not only do we have to learn to be managers, we also have to learn how to be teachers.

I think we're woefully underprepared.

A better construct for knowledge work

Here's what I discovered: for every kind of "knowledge work" I had to document three things: the process I followed, the judgments I applied along the way, and the conventions I operated under. It's the combination of all three that led to consistently good outputs.

The turning point came at 11pm, staring at the third version of a draft for this blog. Claude had followed everything. The output was still wrong. I couldn't explain why. I just knew. That's when I realized: I'd never actually defined what I do. Twenty years of knowledge work, and I'd never externalized the process, the judgment, and the conventions in sufficient and excruciating detail.

I'd just been doing it.

The new job: write down what you actually do

Each version of my process doc revealed something I hadn't articulated. The first showed I'd documented mechanics without judgment. The second showed my principles were too high-level to act on. The third showed I'd never written down the conventions. No em dashes. Blog paragraphs, not LinkedIn staccato. Endings with texture, not mic-drops. The patterns that make something feel "right" even when the content is correct. Every failure showed me what I still hadn't externalized.

So here's my question: Can you write down what you actually do? Not the job description. Not the competencies. The actual process, the actual judgment calls, the actual conventions that separate great work from mediocre work in your domain.

Pick one thing you do regularly: a pricing review, a campaign brief, a competitive positioning doc. Write down exactly how you do it, and how you judge it along the way.

See how much you can get out of your head.

Next week: the framework I wish I’d had six months ago.