Issue No. 05 - July 7, 2026

Last week I was telling a friend about the GA4 (Google Analytics) setup I'd been working on. The containers, the custom channel groups, the UTMs. I wasn't showing off. I was just recapping what I'd done.

She stopped me and said she never would have guessed I'd been scared to touch any of it.

That stopped me for a second. Because I had been. For years, I'd heard about Google Analytics the way you hear about something that's clearly not for you. Developers used it. People who understood what "firing a tag" meant used it. Not me. I was certain that if I got anywhere near the code that ran our website, I'd break something that couldn't be undone.

So I avoided it entirely. Which is exactly how you end up with a gym membership you haven't actually used.

What changed wasn't that I got less scared. It's that I had a specific thing I needed to find out, and I couldn't find it out without getting into the tool. So I walked through the setup with Claude, question by question. Not "explain GA4 to me" as an opening prompt. More specific than that. I needed to see whether AEO was driving traffic, and that meant understanding what was standing between me and that answer. So I asked about that. What is a container and why does it need to be there? What does a UTM actually do to the data? Why would AI traffic show up under "referral" instead of its own bucket?

Each answer gave me enough to take the next step. I wasn't learning GA4. I was learning what I needed to know in order to get a specific thing done. Those aren't the same thing.

My friend's reaction made me think about why that distinction matters. She assumed I'd learned the tool. I hadn't. I'd learned what I was trying to accomplish well enough to ask useful questions about it, and then asked them in the right order. The result looked like expertise from the outside. From the inside it felt like a very productive conversation.

I keep coming back to a phrase that I think describes what I've been doing for the past few months across all of this. Dangerous enough to ask the right questions. Not expert enough to build it from scratch. Not confused enough to not know where to start. Just enough conceptual understanding of what I'm trying to do that I can get real, specific, useful answers instead of generic ones.

That's the zone I'm trying to stay in. And I think it's available to most non-technical operators who are willing to do one thing first: be honest with themselves about what outcome they actually need, before they worry about how to get there technically.

You don't have to understand the tool. You have to understand what you're trying to find out. Once you know that clearly, the questions write themselves.

Where this lands in the three buckets

Immediately actionable: The next time you're staring at a tool that feels too technical to touch, don't ask it to explain itself to you. Ask one specific question about the thing you're trying to accomplish. "I need to see whether traffic from ChatGPT shows up differently than traffic from Google. Where do I look?" is a better starting point than "explain Google Analytics to me."

Start thinking about: There's a difference between technical understanding and conceptual understanding, and you need more of the second than you think. You don't have to know how to build the channel group. You do have to know why you'd want one. That conceptual layer is what makes your questions useful and your answers actionable.

Next phase: If you've been using AI tools mostly to get answers to factual questions, try using them to walk you through technical setup processes instead. Not as a replacement for expertise, but as a way to move through unfamiliar tools with someone explaining what's happening and why it matters as you go.

Meghan Brenner is COO at JB Sales and founder of The Operator's Notebook. The Muddy Middle publishes every Tuesday.