For a while I was running three homes at once: the house we live in, the RV, and wherever my husband and I landed for the winter.

Each one had its own lists, and most were good. The RV opening-and-closing list, which is really the do-not-mess-this-up list. The household list. The winter packing-and-living-away list.

Good lists. Accurate lists. And things still slipped. Not because anything on them was wrong, but because nothing coordinated them.

I'd stand in the kitchen and think, where did I keep that? Not because it was never written down. It almost always was.

What was missing was the handoff between them—a way to see what mattered for the move we were making.

You may have one home and still recognize the business version: email, the calendar, a notes app, two or three project boards, a documents folder, a handful of AI threads you keep meaning to reopen. Every piece can be accurate, and still no single place shows you where the whole thing stands right now.

The same pattern showed up later across two brands and the AI tools I use regularly. Same shape, higher stakes.

✳︎ ✳︎ ✳︎

If you read DigiNav Compass Signal, you’ll stop second-guessing your AI and automation decisions because you’ll have a way to tell what actually fits your business from what’s just noise. The expertise is already yours. You just needed a framework to trust it again.

Subscribe now

✳︎ ✳︎ ✳︎

The business version of three homes

The Decision Toolkit had its own version of the problem. The material was all there: articles, experiment notes, worksheets, prompts, drafts, a string of AI conversations. Nothing was lost. Everything was saved. And starting a work session still meant digging.

A project can be that well documented and still be hard to pick back up.

Your version might not be a toolkit. It might be an offer, a course, a client process, a content series, some internal tool you keep meaning to finish. Plenty of material behind it, and no obvious answer to "where does this actually stand today?"

That can look like:

• An answer you know you got right, sitting three days deep in an AI thread you can't re-find.

• Two or three drafts of the same piece, with no marker for which one is current.

• A card on your dashboard that tells you the project exists, but not where to pick it back up.

Every one of those is saved work. And saving something is not the same as being able to pick it back up without rebuilding it in your head first.

That rebuild is the part that quietly eats the session. Too much of the time I had set aside for the Toolkit went to reconstruction before anything new got made. The project didn't need another beginning. It needed a way back in.

✳︎ ✳︎ ✳︎

The work before the work

Come back to a project like that and the same questions run first, before a word gets written or a single decision gets made:

• Where did I keep this?

• What did we decide?

• Which version are we working on?

• What started this thread?

• What was the next thing I meant to do?

That's the work before the work. On a good day it doesn't even register. It just feels like starting slow.

When it happens often enough, it's easy to decide the problem is you. Maybe you're being inconsistent, or scattered, or bad at follow-through.

But look at what's actually happening. The time set aside to move the project forward goes to reconstruction instead. The session turns into a search party. The friction is in the project, not your character.

An AI collaborator can hit the same wall. It can pick up a thread quickly, but first it needs to know where things stand, what got decided, and which version is current—the same questions again.

Point it at the current state and it continues the project. Leave it guessing and it fills the gaps with its best version of the story, which might not match where things actually are anymore.

Then Kim Doyal, who had offered to put the business through its paces, sent back a Growth Map with one clear instruction: gather what already existed and get it in front of people.

The second part depended on the first. The material was scattered across too many places to pull together on demand. Before the Toolkit could go anywhere, it needed one place to live.

✳︎ ✳︎ ✳︎

One shared home, not one giant list

The fix wasn't a bigger folder. It was giving the Decision Toolkit one place where I could see where it actually stood without reopening its entire history.

The chapters and worksheets live there. So do the AI prompts, the punch list, the decisions we've already made, and a short project status that tells me where to pick back up. When something changes, the current files change with it.

That means I can read through the project myself or ask an AI collaborator for an update based on those files. I'm no longer hoping the right answer is hiding in the right conversation—or reopening a decision because neither of us can find where it landed.

This is closer to what finally worked with our three homes. We didn't stuff the RV list, the household list, and the winter list into one enormous master list. They remained useful for different reasons. What we needed was one place to get our bearings.

A project works the same way. Notes can remain notes. Drafts can remain drafts. The useful part is knowing which ones represent the project now, what has already been decided, and where the work resumes.

For the Toolkit, that was enough to change the work. The written material and AI prompts are complete. Instead of reconstructing those pieces again, I can use them as the foundation for the next stage: a live online version alongside the PDF and AI-guided options.

But giving a project one home only solves part of the problem. Put it down for two weeks and it can still disappear into the noise. It also needs a way to point you back.

✳︎ ✳︎ ✳︎

Make one project resumable

For the Toolkit, the piece that points me back is a short Project Status. It records where things stand and the exact spot to resume. One card on the dashboard points me back to where I left off. Quick reorientation to keep things moving.

You don't need to build any of that to get the same benefit. You can test one project by hand, without redesigning your whole system.

Pick a project that's stalled. Sometimes the problem isn't motivation. If getting oriented costs nearly as much as the next step, the return path may be what needs attention.

Try this with one stalled project. Answer these five questions:

1. Where does the current project live?

2. What has already been decided?

3. Which material is current?

4. Where exactly should the work resume?

5. What's the next move that takes it closer to another person, a customer, or a real-world test?

Want AI to help you get your bearings? Give it the current project files and ask:

Based only on these files, tell me what is current, what has already been decided, what is still open, and where I should pick the work back up. If the files don't answer something, tell me instead of guessing.

If all five have quick answers, orientation probably isn't the main thing stopping you, and that's worth knowing on its own.

If one answer is missing, start there. Repair that part of the return path before you add another tool, another dashboard card, or another AI conversation.

And you don't have to gather everything just because it's related. Keep what helps the project answer those five questions. The rest can stay where it is, available if you need it, without competing to be the current version.

A trustworthy way back in

We don't have three homes anymore. We sold the RV and moved, so three sets of lists became two, each with different needs. What stayed useful was the coordination: each place could keep its own list, while I had one place to get my bearings before shifting from one to the other.

DecisionVerse, the shared home I built for that work, is doing the same job now across two brands, a handful of active projects, and the AI collaborators I work with.

Yours might be far simpler. A single project, a couple of notes, one shared doc. The setup was never the point. The test is whether you—and anyone or any AI helping you—can see where the project stands and keep going from there.

So a stalled project may not need more discipline, and it may not need a fresh start. It may just need a trustworthy way back in.

Which of your projects would get easier to finish if you didn't have to rebuild it every time you came back?

✳︎ ✳︎ ✳︎

Right now I’m running a small beta of the Decision Toolkit — a handful of people testing it on one real decision and telling me what actually happened. It’s open to subscribers. If you’d like a spot, subscribing is the first step.

Subscribe now

And yet the next useful move kept getting harder to see, not easier. Which raised a question I didn’t particularly want to ask:

If all of this access is supposed to make things clearer, why doesn’t it?

A good cheat sheet—and the way each of us needs information to work

I was not always the best student. Not because I couldn’t do the work, but because my mind was usually too busy daydreaming to pay attention to the details of a lecture, or to read a book cover to cover just because the next test would cover it.

What I loved were crib notes. CliffsNotes. Study guides. A good cheat sheet.

I know how that sounds. But I wasn’t trying to get out of the work. I wanted what mattered where I could see it. Give me one page that showed the point, and I could do something with it. Hand me the textbook and three weeks of lecture notes, and everything important dissolved into everything else.

It took me years to understand it wasn’t always me. It wasn’t a character flaw. It was information about how my brain works.

Maybe you did fine with the textbook. Plenty of people do. But I’d bet there’s a version of this in your business right now:

• The course you bought because it worked wonders for the person who made it.

• The planning template you set up in a weekend that you quietly stopped opening by week three.

• The morning routine that fits a person whose mornings look nothing like yours.

None of that failed because you’re undisciplined. It failed the way the textbook failed me. It was built around how someone else needs information to work.

Worth noticing this week: the last time you actually had to decide something, what did you reach for? Not what you’re supposed to reach for. What you reached for.

That’s your cheat sheet. That’s the shape your information needs to be in.

I didn’t connect any of this to my business until Kim handed me a report.

✳︎ ✳︎ ✳︎

If you read DigiNav Compass Signal, you’ll stop second-guessing your AI and automation decisions because you’ll have a way to tell what actually fits your business from what’s just noise.

Subscribe now

The expertise is already yours. You just needed a way to trust it again.

✳︎ ✳︎ ✳︎

The report that moved something—and the pile most of us already have

Last week, put together her Growth Map report for me. She’d dug through my offers, my messaging, my half-built pieces, and there was real analysis behind it. But that’s not what made it useful. What made it useful was the order. Do this first, for this reason. Then this.

A study guide for my own business.

And I moved through it:

• The consulting sessions now have clear pricing.

• The messaging finally says how the two offers fit together instead of leaving people to guess.

• And the Compass Check Toolkit stopped waiting for perfect and started moving toward real testers.

What got my attention was this: not one of those changes came from new information. I already knew all of it. It was sitting in my notes, in old AI conversations, in my own gut. What I was missing was someone saying this matters now, and this can wait.

You have a pile like that too:

• The saved posts.

• The notes app with four versions of the same idea.

• The AI conversation from March where you worked out exactly how to fix your pricing, and then closed the tab.

If someone read through it all, most of what you need is probably already in there.

So the next time you catch yourself researching something you’ve already researched, try a different question.

Instead of: What else do I need to know?

Ask: What do I already know that I haven’t acted on?

For me, acting on the report felt easy. Almost suspiciously easy. And that’s what made the rest of my system look bad.

✳︎ ✳︎ ✳︎

The system I stopped using—and the one you might be maintaining out of habit

I had built myself a daily system called Daily Rhythm. It was designed around my energy instead of a schedule, because that’s how I actually work. It was supposed to be the anti-task-list. Slowly, quietly, it became a task list anyway. One I got very good at ignoring.

So I ran an accidental experiment. I stopped using it. Nothing dramatic. I just didn’t open it one day, and then I didn’t open it the next.

A week went by.

Nothing broke. I didn’t miss it. Client work happened. The pricing changes happened. My days moved fine without it.

That stung a little. I designed the thing. I built it, refined it, maintained it. And the most useful thing it ever told me was what happened when it went silent: I had been updating it more than using it.

The school version of me would have spotted it right away. My system had become the textbook, the lecture, the handouts, and the notes all at once. Everything documented. Nothing distilled.

You may have one of these:

• The weekly review you keep rescheduling.

• The project tracker that’s always one week out of date.

• The journal template with twelve prompts you answer with one word each.

Maintaining it feels responsible. Skipping it feels like a small failure. But notice what actually happens on the weeks you skip it.

If you want to know for sure, borrow my accident and make it on purpose:

1. Pick one recurring ritual.

2. Stop it for a week.

3. Pay attention to what’s genuinely missing. Not what you feel guilty about. What’s missing.

If the answer is nothing, that ritual was maintenance, not support.

Mine never came back. But stopping it opened a messier question: why had I built so many places for everything in the first place?

✳︎ ✳︎ ✳︎

I kept giving everything a place because I hadn’t decided what still deserved one

When I finally looked, the answer wasn’t complicated. The same project was living in three places. A note in Obsidian, a card in Notion, a folder on the hard drive. Not because any of those homes was wrong. Each one made sense when I chose it. But I’d never decided which one was in charge.

And it wasn’t just storage:

• Half-finished experiments sat everywhere, all still technically active.

• Answers I’d worked out completely in an AI conversation months ago were still buried in a thread somewhere.

• Projects that hadn’t earned a minute of attention in weeks kept their active status because parking them would have required deciding about them.

My first instinct was the obvious one: design a better system. I asked Claude for help, and it enthusiastically handed me a five-move replacement process with review cycles. I’d asked for simpler and received a new department.

So I took the whole thing into ChatGPT and made it keep asking me questions until I could say what I actually wanted. Not another planning process. Not a smarter to-do list. Help seeing what mattered now.

Somewhere in that back-and-forth, the real problem showed up in one sentence:

I kept giving everything a place because I hadn’t decided whether it still deserved one.

Every decision I hadn’t finished had quietly acquired real estate. A folder here, a database there, a recurring review, a dashboard panel, an AI thread. My system looked organized. What it was actually doing was faithfully preserving every choice I’d postponed.

Want to test one of yours? Pick a single system, the tracker or template or database you keep tending, and ask it four questions:

1. What were you supposed to help me do?

2. Do I use you, or mostly maintain you?

3. What decision is still sitting open inside you?

4. Can I finish that, stop it, park it on purpose, or pick the one place I’ll look for it from now on?

You don’t have to fix everything those questions turn up. One honest answer closed more for me than any reorganization ever did.

✳︎ ✳︎ ✳︎

What changed—and where you can start without copying me

Once I saw the real problem, the changes stopped feeling like a redesign. They felt like verdicts. The rituals I’d outgrown got retired for real. Not redesigned, not moved to a better app. Retired.

My weekly review stopped being another planning ritual. Now it looks at everything in motion and recommends what deserves movement, in what order, and why. The virtual board of advisors I’d built finally has a job there, but one rule holds it together: the advisors recommend. I decide.

Other decisions became just as plain. An AI conversation isn’t the record; when one ends in a decision, that decision goes where future-me will look. Each project gets one home, with duplicates removed or pointing there. And the dashboard stays local, read-only, and focused on pointing me back to the work instead of becoming more work.

Is it finished? No. I’m proving the weekly process by hand before I automate it. Otherwise, I’d just make the wrong thing faster.

You don’t need my arrangement. Pick one of these instead:

• Mark one stalled project as parked, on purpose, and take it out of your active view. Parked is a decision. Lingering isn’t.

• Pull one decision out of an old AI conversation and put it where future-you will actually look.

• Pick one project that lives in three places, choose the one place it really lives, and delete or redirect the rest.

One is enough. The point isn’t the system you’d be building. It’s the decision you’d finally be closing.

✳︎ ✳︎ ✳︎

Your study guide won’t look like mine

Back in school, a good study guide never learned anything for me. It didn’t replace the thinking, and it didn’t promise the kid next to me the same grade. It did one thing well: it made what mattered visible enough for me to make my own next move.

That’s all I’m really building now. A weekly advisory that distills what’s actually in motion without running my day. A Toolkit heading out to testers before every rough edge is sanded off. A dashboard that’s allowed to stay a simple place to get my bearings.

Yours won’t look like this, and it shouldn’t. You learn differently than I do. You decide differently. Your cheat sheet might be a single page you rewrite every Monday, a voice memo, a whiteboard, one honest question you ask before you open a single app. The shape doesn’t matter. What it helps you do does.

Because the clearest system may not be the one that remembers and displays everything. It may be the one that helps you use what you already know, and lets the rest stop asking for your attention.

Is there something in your setup that still exists because you’ve never made a firm decision about it?

✳︎ ✳︎ ✳︎

Want a first look at the Compass Check Toolkit?

I’m looking for a few beta testers. It’s still rough in places, and that’s on purpose: I’d rather have real eyes on it now than polish it in a vacuum. Message me if you’d like to be one of the first through it.

Paper. Pencil. Spreadsheets. Atomic Habits. Notion databases that took me a full weekend to build. Productivity systems borrowed from people whose businesses looked nothing like mine. Every few years a new tool, a new framework, a new promise that this would be the one that finally stuck.

None of them did.

When AI showed up, I thought maybe this was different. I started building what everybody else was building, a chief of staff dashboard modeled on someone else’s flow. I was a few hours in when I caught myself telling Claude, for the third or fourth time, this is not a productivity system.

Claude called me out.

I was piecemealing every impressive build I’d seen on Substack and YouTube and stitching them into exactly the thing I said I didn’t want. A productivity system. A nicer-looking version of every system that hadn’t worked for me before.

So I stopped.

I closed the tabs. I stepped away from the dashboard. And I sat with the question I’d been avoiding for eighteen years: why has none of this ever worked for me?

I wasn’t failing the systems. The systems were built for someone who wasn’t me.

The list wasn’t built for me

The list I’d been chasing wasn’t built for me.

Time blocking. Theme days. Morning routines optimized down to the fifteen-minute increment. Frameworks designed for people who ship the same kind of work every day, content creators, vibe coders, anyone whose output looks roughly the same on Tuesday as it does on Friday.

My work doesn’t look like that. It never has.

Some days I disappear into an experiment for six hours. Some days are quick. Answering clients, clearing the inbox, moving small things forward. Some days my brain wants to think and refuses to do anything else. Some days I need to be outside before I can sit down at all.

But every productivity system I tried assumed I’d show up the same way every morning. So I kept trying to become that person. I’d follow the routine for two weeks, and then something would shift, a rough night, a heavy stretch of client work, a week where I needed to think more than do, and the system would collapse.

Then I’d blame myself. Start over. Try again.

The piece I missed for years: I wasn’t failing the systems. The systems were built for someone who wasn’t me.

The AI version of this is louder. Automate this. Schedule that. Hand off the things that waste your time. The list got longer and the assumption stayed the same. Your day is a stack of repeatable tasks waiting to be optimized. What you need is more output, faster.

I kept trying to map myself onto it anyway. Because that’s what trying every system teaches you to do. You assume the next one will work if you just follow it correctly.

Why productivity systems don’t work for me (and maybe you)

I went back to the question I’d been avoiding: why has none of this ever worked for me?

The answer wasn’t you haven’t found the right system.

The answer was you’ve been asking the wrong question every time you sit down.

Every system I’d tried started in the same place: what do I need to get done today? Open the list. Pick the next thing. Move it forward. Check it off. Repeat.

The question sounds productive. It feels productive. But it assumes something that isn’t true. That today is interchangeable with yesterday, and that what I’m capable of right now is the same as what I was capable of when I built the list.

Some days I sit down with a list of seven things and I’m clearheaded enough to move through five of them before lunch. Other days I sit down with the same list and the first item takes me three hours because my brain is somewhere else and I won’t admit it.

The list doesn’t know the difference. The list never knew the difference.

What I actually needed to ask, before I touched the list at all, was a different question:

What kind of day is this?

Not what’s on the calendar. Not what’s overdue. What’s the shape of the day in front of me. What’s my energy, what’s my capacity, what’s pulling at my attention before I’ve even started.

That’s a decision question, not an output question. And no productivity system I’d ever tried had asked it.

Building a decision system instead of a productivity system

So I started building something different.

Not a productivity system. A decision system. Something that started with the question I’d been skipping, what kind of day is this, before it asked me anything about what to do.

I called it the Daily Pulse.

The first thing it asks isn’t what’s on the list. It’s an inner check. How am I feeling. What’s my energy. Did I sleep. What’s already pulling at my attention before I’ve sat down. Then it asks what’s on the calendar. What commitments are non-negotiable today, what’s flexible, what could move if the day calls for it.

Only then does it look at the work.

The order matters. Because if you ask the work first, the work always wins. Every list I’d ever built worked that way. Open the list. Pick the next thing. Don’t think about whether you have it in you to do that thing, just do it. By the end of the day, half the items would be checked off and I’d feel like I’d been hit by a truck and not be able to tell you why.

The Daily Pulse reads the day before it touches the work.

That’s the part AI can’t do for me. Claude can build the dashboard. Claude can pull from my calendar, my notes, my Notion databases. Claude can do almost every part of this faster than I can. But Claude cannot tell me what kind of day I’m having. Only I can answer that. And until that question is answered, every other question downstream of it is the wrong question.

That was the reframe.

Use AI for the work you can outsource. Don’t outsource the read.

Five flags, not a grid

The Daily Pulse needed a way to know what was getting starved.

Not a productivity grid. Not a list of tasks sorted by priority. A way to see, across a week, where I was pouring everything in and where I’d gone quiet. Because I already knew what happened when I didn’t watch for that. I’d disappear into a stretch of heavy client work and come up three weeks later having not read a book, not gone outside, not talked to anyone outside of a deliverable thread.

So I gave it five categories.

Build, Think, Learn, Grow, Live.

Build is the work. Experiments, client deliverables, anything I’m shipping. Think is thinking on my own, without AI in the room. Learn is consumption that gets tested and applied, not just stockpiled. Grow is the relationships, the people I work for myself partly so I can show up for. Live is the body, the outside, the rest, the things that aren’t work and aren’t trying to become work.

The categories aren’t a schedule. They’re flags.

If a week is heavy in Build and Learn and Grow has gone untouched, the system says so. Not here’s what to do about it. Just, hey, you haven’t touched this in five days, are you good with that? Sometimes the answer is yes. Sometimes the answer is no, that’s why I feel like garbage and don’t know why.

That distinction was the whole point. I didn’t want a system that picked my work for me. I wanted a system that called me out when I was about to repeat a pattern I already know costs me.

That’s the part most productivity systems get backwards. They optimize for what you do. The Daily Pulse optimizes for what you’d otherwise miss.

If you want to test what this feels like before you build anything, here’s a prompt you can paste into Claude or ChatGPT to try it once:

I want you to help me read my day before I plan it. Ask me four questions, one at a time, waiting for my answer before moving on:
1. How am I feeling today, physically, mentally, emotionally?
2. What's already on my calendar that I can't move?
3. What's pulling at my attention before I've even started?
4. Looking at the work I could do today, which of it actually matches the day I just described?
Don't suggest a schedule. Don't optimize anything. Just help me see the day clearly before I decide what to do with it.

Run it once. See if the answer to question four surprises you.

If it does, you’ve already learned the thing the Daily Pulse took me weeks to figure out: the read comes before the plan, every time.

Just because you can build it

I spent eighteen years trying to find the system that would finally work for me.

What I needed wasn’t a better system. It was a better question.

The Daily Pulse isn’t the point of this article. It works for me because it was built around the way I read a day, the categories that keep my week balanced, the inner check that matches my energy patterns. If you copied it move for move, it would feel like wearing somebody else’s shoes.

But the question I had to ask before I could build it, that one’s worth borrowing.

Every list you’re staring at right now, the AI playbook, the productivity stack, the chief of staff dashboard, the framework that promises to finally get you organized, every one of those was built by someone else for the way they work. That’s not a flaw. That’s just what it is.

The question isn’t whether you can build it. You probably can. AI has made it easier than ever to clone someone else’s system in an afternoon.

The question is the one I should have asked a long time ago:

Just because you can build it, does it apply to you?

Sit with that for five minutes before you build the next thing. Before you automate the next task. Before you copy the next dashboard from a tutorial.

If the answer is no, you’ve just saved yourself another two weeks of trying to fit into someone else’s shape.

If the answer is yes, build it. But build it from your own questions, not theirs.

If you’re stuck between I should be doing more with AI and I don’t know what’s mine to build, that’s the gap I help close. Book a call and we’ll get clear on what’s worth building for you specifically, and what’s just somebody else’s good idea.

I’m big on organization especially when it comes to AI use and conversations. So her guides are always well-organized and specific in a way that makes you slow down and take note even when the technical details aren’t directly relevant to what you’re doing.

I read this one because Cowork is where I’m spending more of my time this quarter, and Karo has a way of laying things out that makes you look at your own setup and think: wait, am I being sloppy about something that matters?

The article covers a lot of ground — connector architecture, permissions, using Notion as persistent memory. Good stuff, worth reading on its own.

But the thing that I got the most out of wasn’t the technical setup of CoWork. It was something simpler underneath it: the names you give your folders are instructions to Claude, not just labels for yourself.

The names you give your folders are instructions to Claude, not just labels for yourself.

Karo’s folder structure is deliberate. Each name signals what Claude should do with what’s inside it. Easy to skim past when you’re looking for the architecture details.

The kind of thing that’s obvious in hindsight and invisible until someone makes it explicit.

Two things I took from Karo’s setup that didn’t require me to build anything new:

Sub-folders beat a flat root. Before reading this, everything except outputs lived in my root folder. One folder. Everything dumped in. It works until it doesn’t — and when it doesn’t, it usually means Claude is filling in gaps you didn’t know you left.

The rename that clarified something I hadn’t noticed. When I ran the article through a conversation with Claude, it flagged one specific thing: my folder called references should probably be called context. I didn’t push back. It made sense immediately.

Here’s why it matters.

References, to me, means sources: supporting documents, things I cite, external material. Context means something different: what Claude needs to understand my world. My voice. My audience. How I think about problems. Those two things were living under the same name, and that name was doing the wrong job.

The practical move is simple: look at your Cowork folder setup and ask whether the names mean what you think they mean to Claude — not just to you. That’s a five-minute audit. It won’t overhaul your system. It might just make it work the way you thought it already did.

If you’re using Cowork and have any kind of folder structure in place, this is worth 20 minutes now. Not to rebuild from scratch — just to look at what you named things, how you’re set up — and whether those names are doing the right job.

If you’re not in Cowork yet, this type of thinking works with other file management best practices. Starting with intentional folder names is a better foundation than cleaning them up later. Either way, go read Karo’s full article. The Notion memory setup alone is worth the time.

Karo’s full article is here:

Product with Attitude

Claude Cowork Guide for Power Users: 50+ Tested Tips on Plugins, Skills, Sub-Agents, and Memory

Read more

5 months ago · 128 likes · 15 comments · Karo (Product with Attitude)

One question to sit with:

In your current Cowork setup, is there a folder named something that made sense to you when you created it — but might mean something different to Claude? That’s your starting point.

A friend of mine loves to bake. Cakes, cookies, those little things she drops off that nobody ever turns down. But somewhere between the job, the side gig, the family and everything else life stacks on top — she was running out of time to do it. The baking wasn’t the problem. The process around it was eating the hours she didn’t have.

So I asked her: why not get ahead of it? Do the prep work in bulk when you have a window. Handle the time-consuming parts in advance, so when the hour finally appears, you’re not starting from scratch — you’re just baking.

She looked at me like I’d said something obvious. And maybe I had.

That conversation stuck. Because I’d been having the same one about my own business — just without the baking. Moving information from one place to another. Updating the same record in two tools. Copying what Claude produced into Notion, over and over.

The baking was fine. The prep work was the problem.

And the fix wasn’t somewhere else. It was already in the room.

The problem wasn’t what I had. It was what was missing between them.

The terminology was never built for you

You’ve probably heard this by now: connect your tools. Automate the repetitive stuff. Let AI handle it. Or maybe it comes with a list — MCPs, APIs, automation workflows. Someone making it sound like the logical next step.

And if you’ve ever looked at those words and thought, that’s not for me, you weren’t wrong to think it. For a long time, connecting apps required reading through developer documentation, understanding architecture, building the integration yourself. The barrier was genuinely technical. The conclusion — this isn’t in my lane — was a reasonable read of the situation.

But here’s what changed: everything around those terms did. The terms are the same. What they require from you isn’t.

MCPs. APIs. Skills. Plugins. These aren’t going away — if anything, you’re going to hear them more. But they’re no longer instructions for developers. They’re descriptions of how a system works. And once you understand what each one actually does, in plain language, the next question stops being can I even do this?

It becomes: where does this fit in what I’m already doing?

That’s a completely different question. And it starts with four definitions.

When Claude does the work... sort of

I had Claude do some of it. Updating records in Notion, pulling information across, and handling the pieces I didn’t want to do manually. And sometimes it was great — exactly what I needed.

Other times, it was inconsistent. Spotty results. Updates that half-landed. A process that worked well enough on a good run and let me down on the next.

The fix existed. I knew that. The problem was getting it to work reliably — and that meant setting things up properly, with the right connections in place.

And here’s why that matters for you — especially if you don’t have a technical background.

The path to fixing it runs through terms like MCPs, APIs, Skills, and Plugins. And for most people, that’s exactly where the conversation ends. Not because the concepts are complicated. Because the words signal: this requires a developer. This is not your lane.

That signal is wrong.

The terminology was built for a technical audience. It wasn’t built to keep you out — it just was never translated for someone who runs a business without a coding background. So you keep copying and pasting. You keep doing the manual steps. Not because you can’t use these tools, but because nobody handed you the plain-language version of what they actually mean.

That’s what this is.

Here’s what happens when the terms click.

You stop asking “can AI do this?” and you start asking “which piece handles this?” That’s a completely different question — and it opens up a completely different set of possibilities.

For me, that looked like setting up CoWork, not Claude Code. Most of the conversation has gone in that direction — it’s the more technical option. CoWork is the everyday version. The one built for exactly this: connecting Claude to the apps and spaces you’re already using, without needing a development background.

What I built was a simple connection. My experiment notes on my hard drive. My Notion workspace. My dashboard. My articles. CoWork became the layer that linked them, so Claude could reach across those spaces without me manually carrying the information between them.

Before CoWork, I had something similar running in regular Claude. And it was inconsistent in a specific way — sometimes it would create or update the Notion records exactly right. Other times, it would stop short and hand me code or text to copy and paste myself.

Which, if you think about it, is just the copy-paste tax wearing a different outfit. The connection between Claude and Notion was missing the piece that makes it reliable — the MCP, the API link. Without that, Claude was doing its best with what it had. Which wasn’t always enough.

The copy-paste process didn’t disappear because I found a smarter workaround. It disappeared because I had the right structure in place. Four terms. Four jobs. Each one handles a specific part of how the system works.

That’s what this understanding makes possible for you. Not a complicated build. Just a clear picture of what each piece does — and suddenly, the question isn’t whether you can do this.

It’s where do you want to start?

The four terms, in plain language

So let’s get into the four terms. Not the developer version. The version that actually makes sense for how you run your business.

MCPs — the hallway.

Your business doesn’t live in one room. It lives in Notion, in your inbox, in your calendar, in the documents on your hard drive. MCP is what builds the hallway between them. Without it, you’re the one carrying information from room to room. With it, the information moves on its own.

APIs — the smart lock.

You’re not handing anyone a key to your house. You’re giving controlled access — a code that works for a specific door, for a specific reason, and can be revoked whenever you want. The house stays yours. You just decided who gets through which door.

Skills — the recipe adapted for who’s cooking.

Same kitchen, same base. But a home cook improvises differently than a baker, who measures everything, because the chemistry matters. Skills are how Claude’s instructions get calibrated for the task at hand. What works for syncing documents is set up differently from what works for writing. Same foundation. Different precision depending on what’s actually being made.

Plugins — the meal kit.

Someone has already figured out the ingredients, the sequence, the portion sizes for a specific dish. You’re not building the recipe from scratch — you’re getting a pre-assembled package designed for one job. A sales plugin is a meal kit for prospecting. A marketing plugin is a meal kit for content.

Skills teach Claude how to cook. Plugins tell it what to make and for whom.

MCPs connect the rooms. APIs control who gets through which door. Skills are the recipe adapted for who’s cooking. Plugins are the meal kit — pre-assembled, one job, ready to go.

The companion piece walks through building each of these layers — what setup looks like, what to do with an API key, and how to build a Skill for a specific task. That’s where the how-to lives.

Here’s what staying manual actually costs.

Not in a dramatic way. Just in the quiet, steady way of doing the same task twice because the tools don’t talk to each other yet. Copying what’s in one place into another. Updating the record. Doing it again next week.

It’s not broken. It just never stops being your job.

The other cost is harder to see. It’s the possibilities that don’t show up because the vocabulary hasn’t landed yet. You can’t ask for a connection you don’t have a word for. You can’t build a system around terms that feel like they belong to someone else’s world.

The copy-paste tax is the visible one. The vocabulary gap is the invisible one. And they compound — the longer the terms feel inaccessible, the longer the manual process continues.

Noticing that friction isn’t weakness. It means you’re paying attention to where your time is actually going — and asking whether it has to.

It doesn’t.

Five things worth taking with you

If you only take away five things from this:

1. MCPs connect your tools. Without the connection layer, you’re the one carrying information between rooms. That’s the copy-paste tax — and it’s optional.

2. APIs are access keys, not developer tools. You give controlled access for a specific purpose. The house stays yours. Access is yours to grant and revoke.

3. Skills are how Claude’s instructions get calibrated for the task. Same base, different precision depending on what’s actually being made. A sync task and a writing task don’t run on the same settings.

4. Plugins are the meal kit. Someone already figured out the ingredients and sequence for a specific job. You’re not building from scratch — you’re deploying something pre-assembled for one purpose.

5. The barrier was never a technical skill. It was unfamiliar language. Once the terms land, the question changes from “can I do this?” to “where do I want to start?”

You’re allowed to find this hard.

Not because the technology is complicated. Because the language around it was built for a different audience — and nobody handed you the translation. So you watched the tutorials, heard the terms, and quietly concluded that this level of setup wasn’t for you.

That conclusion made sense with the information you had.

It’s just not accurate anymore.

The tools are there. The connections are possible. What changes first isn’t your setup — it’s the question you’re asking. And the question changes the moment the terms stop feeling foreign.

So here’s what I want to leave you with: what’s one process in your business where you’re still the one carrying the information? Not a general category — a specific thing. The task you do every week that moves the same data from one place to another, because the rooms aren’t connected yet.

That’s your starting point.

And once the terms land, the next question becomes which tool is the right fit for the job you’re trying to do. That’s a different conversation — and one worth having.

If you want to go further, the companion piece walks through building each of these layers, from what to do with an API key to how to build a Skill for a specific task. That’s where the how-to lives.

Every session started the same way.

Open a new conversation, load the three docs, explain what I was working on, explain how I worked, and explain what I would and wouldn’t do. AI would take it in, do something reasonable with it, and we’d move forward. Then I’d close the tab.

Next session: start over.

This was early, before AI tools had real memory, or right at the edge of it. All three foundation docs were in place by then. The Business Snapshot, the Audience Profile, the Voice DNA. Loaded together, they gave me better output than I’d gotten before. I thought that was the fix.

The problem showed up when I’d ask for help thinking through a decision. The answer would come back technically right, sensible on paper, but wrong in ways I couldn’t always name immediately. Suggestions that ignored a second business I was running. Directions that assumed a work style I don’t have. Boundaries none of the docs had any way of knowing existed. I’d add the missing context manually. The session would improve. I’d close the tab. Next session: start over.

Business, audience, voice: the three docs tell AI about the operation. They say nothing about the person behind it.

Why This Is Harder Than It Looks

The standard advice is to build the three foundation docs and call it done. Business Snapshot. Audience Profile. Voice DNA. It makes sense. You’ve given AI the business context, the audience context, and the communication style. The logic is the same one we use when laying a building foundation: pour it once, get it right, then build on top of it.

The advice isn’t wrong. The three docs do what they’re supposed to do.

What they don’t do is tell AI how you work. Your decision-making style. What drains you. When you do your best thinking. What you’d never agree to, regardless of how sound it looks on paper. The reality of running a second business alongside the first. None of that is in a Business Snapshot. None of it belongs in a Voice DNA doc. It doesn’t have a home yet. The conventional wisdom skips the part nobody talks about: the person behind the operation.

A foundation without the framing that goes on top of it is still just concrete. It’s a starting point, not a finished structure.

What I Tried That Didn’t Work

So I tried the obvious thing first. I went back into the Business Snapshot and added a section. A few lines about how I work best: the hours I protect, the second business, the things I wouldn’t do regardless of what the numbers said. The logic was solid. The Business Snapshot was already the doc I loaded first. If I put the missing context there, it would be there.

It helped for about two sessions. Then the same drift came back. The Business Snapshot was built to describe the operation — the model, the audience, the positioning. When I added personal operating notes to the bottom of it, the doc did what docs do: it held everything without prioritizing any of it. AI would take in the full thing and give more weight to the business description than the three lines about how I work.

I’d patched a doc that wasn’t broken to solve a problem it was never built to solve. And I nearly convinced myself it was working. The sessions weren’t obviously broken. The output was still reasonable. But reasonable isn’t the same as right, and I was still adding the same context manually, session after session, the same way I had been before I touched the Business Snapshot at all.

Half-right output is harder to catch than wrong output. Wrong output is obvious. Half-right looks reasonable until you try to act on it and realize it was built for a version of you that doesn’t quite exist. I had documented the business, the audience and the voice. I hadn’t documented myself. And I’d spent time patching a doc instead of building the one that was actually missing.

What Actually Shifted

What finally changed wasn’t adding more to the three docs. It was realizing the three docs were never built to answer those questions.

Each one was doing its job. The Business Snapshot covered the business. The Audience Profile covered who I was talking to. The Voice DNA covered how I sound. Together they did what they were designed to do, and still left a gap I kept filling manually every single session.

Two things were missing that had names once I looked at them directly. The first: Personal Context. Not communication style (that’s what Voice DNA covers). Operating style. When I do my best thinking. What drains me. My non-negotiables. The behind-the-scenes reality of running two businesses at once. How I actually make decisions, not how I’d describe my decision-making process if someone asked. The difference between those two things is larger than it sounds.

The second: Product/Offer Context. What I’m building toward, whether the offers are fully formed or not. What I’d never build, even if it made sense on paper. What success looks like in 12 months. Without it, every planning session defaulted to what had worked for everyone else before, solutions built on hustle-culture assumptions that had nothing to do with how I wanted to work or what I was actually building toward.

Once both existed, the sessions changed. AI stopped suggesting strategies that required energy I don’t have at the time of day I do most of my work. The rules I’d built around energy and recovery stopped being invisible constraints I had to re-explain every time. Planning had somewhere to land.

I had documented the business. I hadn’t documented myself. Those are two different documents.

The change from here doesn’t arrive all at once.

Build is where you are after the docs are in place. The foundation is real. That’s the table stakes.

Refine is the first few weeks of use. You notice something’s still off, open the doc, update a line. The next session is better. This is the system working, not failing.

The compound is harder to see from inside it. Sessions get easier. You stop re-explaining yourself. The output starts fitting in ways that accumulate quietly.

Operating differently isn’t a destination. It’s what’s already happening if you’ve made it to compound.

Here’s What This Looks Like in Practice

You now know what two docs are missing. While you’re building them, the foundation you already have can handle four plays. Each one pressures a different part of your context so you can see what’s holding and what’s missing. Run them with three docs. Run them again with five. The difference between those two sessions is where the remaining gap shows up.

Play 1: Decision Testing. Run it before committing to anything, new tool, new offer, new direction. It tests a decision against your actual business context instead of general reasoning. Why it matters: a decision that fits your business on paper might not fit how you work or what you’re building toward. Upload: Business Snapshot. Add Personal Context and Product/Offer Context when you have them.

Play 2: Map What You Actually Need. Use it when you know what you’re working toward but can’t see clearly what’s between you and it. It skips the 90-day roadmap and gets to the smallest useful next step. Why it matters: Personal Context shows whether the path forward actually fits how you work; Product/Offer Context gives the mapping somewhere real to land. Upload: Business Snapshot and Audience Profile. Add the two context docs when you have them.

Play 3: Blind Spot Recognition. Use it when the audience feels right on paper but the content isn’t landing the way you expect. It surfaces the gap between your interpretation of their problem and what they’re actually dealing with. Why it matters: knowing what you’re building toward changes which audience blind spots matter most. Upload: Audience Profile. Add Product/Offer Context when you have it.

Play 4: Strategic Reflection. Run it at the end of a month or a project cycle. It finds the patterns in your own work before you build more: what’s emerging, what’s stalling, what question you should actually be sitting with. Why it matters: this play does the most work with the full five docs loaded. Patterns that look like business problems often turn out to be operating problems, and that only surfaces when Personal Context is in the room. Upload: all three docs. Add Personal Context and Product/Offer Context when you have them.

When I run these, what surprises me is how quickly the misfit shows up. The plays don’t need the two extra docs to run. They need them to stop giving you answers that are half right. The companion piece walks through each play in practice: the prompts, the process, and what done looks like. Same format as the starter kit, with interview prompts, synthesis prompts, and what a finished doc actually looks like for Personal Context and Product/Offer Context.

What It Costs to Stay Stuck

Running without these two docs doesn’t stop the work. It just means some of your time and energy go toward compensating for what isn’t documented yet.

Bad output is easy to spot. You see it, you fix it, you move on. Misfit output is different. It looks reasonable. It fits the business. It passes the first read. The problem surfaces when you try to act on it and realize it was built for a version of you that doesn’t quite exist, someone with different hours, different constraints, a different sense of where this is heading. So you correct it manually. Add the context that’s missing. Get a better answer. Close the tab. Next session: same thing.

The energy drain isn’t the bad sessions. It’s what you’re doing in the good ones. Every time you re-explain your working hours, your boundaries, your direction, that’s a doc that doesn’t exist yet doing its work anyway, through you, one session at a time. The work gets done. It just takes more out of you than it should. Without Product/Offer Context, AI defaults to what’s worked before for someone else, in a different kind of business, with different values about how work should feel. The answers point in a direction that isn’t quite yours, and you spend energy steering back each time.

Noticing this friction isn’t a sign that something’s broken. It’s pointing directly at what’s missing.

Key Takeaways

If you take away only four things from this, make them these.

1. Business, audience, voice, and then you. The three foundation docs cover the operation. They say nothing about the person behind it. For a solo business owner, those aren’t the same thing.

2. Half-right output isn’t a prompting problem. It’s a missing-docs problem. If AI keeps coming back with answers that look reasonable but don’t quite fit, the gap is in what hasn’t been documented yet, not in how you’re asking.

3. Two docs fill what the first three can’t. Personal Context captures how you work, not just how you sound. Product/Offer Context gives AI a direction to orient around, rather than defaulting to someone else’s playbook. Both answer questions the foundation docs were never built to answer.

4. The plays work now. They’ll work better with five docs loaded. Run them with what you have. Pay attention to where the answers still feel slightly off. That friction is showing you exactly what to build next.

You’re Allowed to Find This Hard

Building the first three docs is hard in a specific way. You’re answering questions about the business: what it is, who it serves, how it sounds. Those questions have answers, even if they take work to surface.

Personal Context and Product/Offer Context are harder in a different way. They ask you to document how you actually work, not how you’d like to work. To articulate a direction that might not be fully formed yet. To be honest about constraints and non-negotiables that feel uncomfortable to put in writing because putting them in writing makes them real. That’s worth naming. I still catch myself skipping the personal docs when I’m in a hurry, loading three instead of five and then wondering halfway through the session why the output keeps needing correction.

A half-formed direction doc is more useful than no doc. You don’t need certainty to build either of them. You just need enough honesty to give AI something real to work with instead of letting it fill the gap with someone else’s assumptions about how a business like yours should run. Start with one line that’s true. Update it when something shifts. That’s the whole process.

The companion piece covers how to build them: same format as the starter kit, with interview prompts, synthesis prompts, and what a finished doc actually looks like.

Subscribe now

What’s one thing you find yourself re-explaining to AI session after session? Not a business detail. Something about you: how you work, what you need, what you’d never do. Drop it in the comments.

Missed the article? Read the companion piece to “The Workshop I Built Was Wrong.”

Before you start: what your AI context foundation looks like when it’s done

Most people build context docs the wrong way because they don’t know what they’re building toward. So let’s show you the destination before you start packing.

A working AI context foundation isn’t one long document. It’s a folder structure with specific files doing specific jobs. Here’s what that looks like:

Read more

Why your AI output keeps coming back flat

Feedback and interactions were off. Not wrong, just flat.

You know the feeling. Something doesn’t feel right, but you can’t quite put your finger on it. Like making your favorite chocolate cake, following the recipe to a tee, using all your favorite ingredients, and it’s still a little off. Nobody sends it back. They still eat the cake. But it’s not the one they talked about the next day.

That’s what was happening to my writing. One week I had the perfect three layers and everyone raved. The next time, nobody said a word but they still showed up. Comments that circled around something without landing. Shares that were quieter than expected.

So I did the reasonable thing. I opened my Voice and Tone doc and started tightening it. Added more examples of what I didn’t want. Made the language more specific. Documented a few phrases that kept creeping into drafts I didn’t like.

I closed the doc feeling like I’d fixed the recipe. The next article came back the same way.

It took longer than I’d like to admit to figure out what I was actually doing. The voice wasn’t the problem. The structure was. The way I was presenting information (the flow, the sequence, the shape of an argument) wasn’t in my Voice and Tone doc. It wasn’t in any of my docs.

I had a full set of context docs. Business Snapshot. Audience Overview. Product Strategy. Storytelling Guide. All the right ingredients.

None of it answered the question my articles were actually asking.

The docs weren’t wrong. They were answering the wrong questions entirely.

Why “more context” is enterprise advice for a small business problem

The standard advice makes sense. Document your context. Give AI your voice, your audience, and your business background. The more it knows, the better it performs. Most of us have heard this, tried this, and watched it work, at least partially.

The advice isn’t wrong. It was just written for a different version of the tools and for a different scale of operation.

The frameworks most of us are following came from developers and prompting experts building large systems. Complex pipelines. Processes that needed every variable documented because the cost of getting it wrong was high. Their rules made sense for what they were doing.

When you apply that logic to a small business, it doesn’t tighten your output. It just gives you more to maintain. The docs grow, the updates pile up, and before long, you’re working on your context docs instead of the thing they were supposed to support.

I was spending more time updating my context docs than actually using them.

The goal was never to document everything. It was to remove the guesswork. Those are not the same job.

The over-documentation trap (and the template spiral that followed)

The problem wasn’t that I needed better docs. It was that I was building the wrong kind.

The original approach made sense. AI needed everything handed to it. It couldn’t hold context between sessions, couldn’t infer what you meant, and couldn’t reason about your business without explicit instruction. So you gave it everything. Voice down to specific phrases you’d never use. Audience down to what kept them up at 3 am. Background detailed enough to onboard a new hire.

I was still following those rules when I built my Content Lab (where all my content work lives) and started laying out my LifeOS dashboard (a personal productivity system I was building in Notion). And for a while, it felt like the right call.

When I finally identified the structural problem with my articles, I did the right thing. I started building writing templates. Specific ones for the actual use cases I was working with: experiments I was running, tools I was testing, and prompts I was stress-testing. Each one had its own shape and flow.

And then I kept adding more.

More templates, more use cases, more variations. No core set to anchor them. So the supporting docs (tone, audience, what to stay away from) got muddy. AI couldn’t figure out which flow to follow, so it defaulted to whatever pattern felt closest. The output got inconsistent in a whole new way.

I still catch myself doing this. Starting a new use case and reaching for a new template instead of asking whether one I already have could do the job.

I had graduated from the wrong foundation to the wrong working layer. Different problem, same root cause: building more instead of building better.

The three-layer AI context foundation that fixed it

What finally changed wasn’t the documents themselves. It was the question I was asking about them.

I had been asking “what’s missing from this doc?” every time something went wrong. Which meant every problem sent me back into the same pile of files, adding more to the docs that didn’t need more.

The better question turned out to be: which layer is this problem actually in?

That’s a different question. And it changes where you look.

A living context foundation isn’t one long document or even a tight set of core files. It’s built in layers, each one doing a different job:

The foundation is who you are, how you sound, and who you’re talking to. Most people have this, at least partially. It’s table stakes, not the finish line.

The working pieces are how you structure and present information. Templates, offer documents, and the shape of how you think through a problem. This is the layer most people skip entirely. It’s also the one that changed my output quality more than anything in the foundation layer.

Your running record is what you’ve tested, what worked, what didn’t, and what you learned. It’s the layer that lets AI push back rather than just execute. Without it, you have a capable partner with no history of how your business actually works.

The foundation tells AI who you are. The working pieces teach it how you think. The running record gives it something to measure against.

When I stopped patching the foundation and started building the missing layer, the output settled. The articles found their shape. The foundation stopped being something I was constantly fixing and started being something I was building on.

How to audit and update your AI context docs

Three shifts worth making, in order:

1. Build in layers, not in length.
Start with your foundation if you don’t have one. If you do have one, look at what’s next. Do you have a writing template, or a document that captures how you structure information? Do you have anything that tracks what you’ve tried and what you learned?

Each layer lives in its own document. Not one long file that keeps growing. A connected set you can open, update, and put back without touching the rest.

2. Review on a rhythm, update only what drifted.
Every few months, unless something significant changes. Open the relevant document, ask AI to review it against what’s new. Sometimes nothing needs updating — and that’s the system working, not the system failing. You’re not looking for what’s wrong. You’re checking whether it still reflects where you actually are.

3. Let AI do the seeing you can’t.
This one surprised me. When I started adding experiment notes to my context — what I was building, testing, learning — AI flagged something I hadn’t noticed myself. I had been telling my agents to break everything down into plain language, no jargon, keep it accessible. But when I wrote those experiment notes, I was writing like I was back in a developer meeting. Project briefs. Technical shorthand. The language of someone deep inside the work.

AI couldn’t reconcile the instruction with the example. And just like that, I couldn’t pretend I didn’t know. My content had been talking at my audience instead of with them — and no amount of audience profiling would have caught it. The problem wasn’t in the profile. It was in how I was showing up in my own docs.

Here’s a prompt you can use to audit a document you already have:

I'm going to share one of my context documents with you.

Once I share it, tell me:
1. Which layer does this belong in — foundation (who I am, voice, audience),
   working pieces (how I structure information, templates, offers), or
   running record (what I've tested and learned)?
2. What's in here that still feels current and accurate?
3. What feels like it was written for an older version of my business?
4. What's missing that would help you act as a real partner, not just a generator?

Don't tell me what to fix yet. Just tell me what you see.

The companion piece walks through building each layer from scratch — what goes in each document, the prompts for creating them, and what they actually look like.

The hidden cost of outdated context docs

Every session where AI guesses wrong, you’re editing. Every month a doc ages unreviewed, you’re re-explaining. Every output that’s almost right but not quite — that’s not a prompt problem. That’s a foundation problem.

The harder cost to see: you can stay busy tweaking docs and feel like you’re making progress. But if the missing layer never gets built, nothing changes. You’re not stuck because you stopped trying. You’re stuck while trying the wrong thing.

That friction you keep feeling isn’t weakness. It’s pointing at exactly what needs attention.

Key takeaways

If you only take away four things from this, make it these.

1. The docs aren’t wrong — they’re answering the wrong questions. More context doesn’t necessarily lead to better results. The goal was never to document everything. It was to remove the guesswork. Those aren’t the same job.

2. You can’t fix a structure problem in a voice document. When output is off, identify which layer the problem is actually in before you touch anything.

3. A living foundation is built in layers, not in length. The foundation tells AI who you are. The working pieces teach it how you think. Your running record gives it something to measure against. Each one is a different document doing a different job.

4. AI can surface contradictions you can’t see from inside. When your instructions and your examples don’t match, AI will find it. Add your experiment notes, your test results, your real work — and let it show you what you’re missing.

Start here: find the layer you’re missing

Most people built their context docs once and moved on. Going back to revisit them feels like admitting they weren’t enough.

They were enough. For then. The tools changed, and the job changed with them. That’s not a failure — it’s just where we are.

The shift that’s actually hard isn’t the tactical one. It’s accepting that something you built carefully and deliberately might need a new layer — not because you did it wrong, but because you’ve outgrown what it was designed for.

You’re allowed to find that hard.

What’s one document or template you built a while back that still makes sense on paper — but you’re starting to suspect isn’t working for where you are now? Not a general category. A specific thing. Drop it in the comments and I’ll tell you which layer I’d look at first.

If you want to build the layers from scratch, the companion piece walks through all three — what goes in each document, the prompts to create them, and what done looks like.

Three Projects, Zero Code, One Week

I kept running into permission issues on my Mac. Folders I couldn’t access, files that wouldn’t move. The kind of thing that makes you realize you’ve been kicking the can on how you organize your digital life for... a while.

After fixing the permissions problem (another AI project, another story), I was already in cleanup mode. And everyone’s been talking about AI agents and tools that do the work for you, specifically Claude’s new CoWork feature. Me being me, I needed some real projects to throw at it.

The criteria were simple: tackle something that would take more of my time than I wanted to give, have it solve a real problem, and factor in more use cases for the future.

So I picked three.

• A MacBook hard drive stuffed with files migrated from multiple machines over the years.

• A Dropbox folder holding 10+ years of documents spanning several brands.

• And hundreds of Midjourney image files with names like `leedrozak_A_woman_seated_at_a_cluttered_desk_covered_in_scatt_f928b109-0e14-4709-a6d0-a1e3bb3632b6_1.png.`.

No code. No terminal. No developer skills for any of them.

And here’s the part that surprised me: the tool wasn’t the hard part. The thinking before I opened it was the hard part.

Every article I’ve read about CoWork tells you to point it at a folder and watch it go. That’s like telling someone to hire an employee and just let them figure it out.

The people getting frustrated with CoWork are skipping the planning. The people getting value from it are doing what good managers do: defining the what before they unleash the how.

So What Is CoWork, Actually?

Let me skip the jargon for a minute.

You already know how to use Claude in a chat. You type a question, and Claude answers. That’s a conversation. CoWork is different. Instead of asking Claude for advice, you’re handing Claude a task and letting it do the work.

Think of it this way. Regular Claude is like calling a smart friend and asking, “How would you organize this mess?” CoWork is like that friend coming over, rolling up their sleeves, and actually sorting through the pile with you.

The technical term is “agentic AI,” which means Claude can take actions on its own, step by step, checking in with you along the way. It can read your files, move them, rename them, create new documents, and build spreadsheets. All on your actual computer. You choose which folders it can see, and it asks before taking big actions.

Here’s the part that matters for people who don’t write code: CoWork was built specifically so you don’t need a terminal. It lives inside the Claude desktop app, same place you already chat. You describe what you want done in plain language, point it at a folder, and it gets to work.

That’s it. That’s what it is.

The question isn’t whether the technology works. It does. The question is whether you give it enough to work with.

If you want to see CoWork in action before diving into the how, here's a quick walkthrough.

Why Most First Experiences Disappoint

Here’s the thing about CoWork that nobody is writing about.

Most people’s first experience goes like this: They open it, type something vague like “organize my Downloads folder,” point it at 200 files, and wait. CoWork does... something. It creates folders. It moves files around. And the result is... fine. Maybe. Or maybe it sorted your tax documents into a folder called “Miscellaneous PDFs” and put your client contracts next to your takeout menus.

Then they close it and think, “Well, that was underwhelming.”

I almost had that experience myself. The first time I sat down with my MacBook drive cleanup, my instinct was to just point CoWork at the whole drive and say, “fix this.” But I’ve been around long enough to know that when you hand a capable person a vague task, you get a vague result.

The pattern I keep seeing, in my own work and with clients, is the same one: people jump to the tool before they’ve done the thinking.

They skip planning because it feels like the boring part. But planning isn’t busywork here. Planning is the entire job. CoWork handles the execution. You handle the strategy.

And that distinction? That’s the plot twist nobody’s talking about.

CoWork doesn’t need your technical skills. It needs your management skills.

The Framework: Specs, Blueprint, Roadmap

Here’s what actually worked for me this week. Before I opened CoWork for any of these three projects, I worked through the same three questions in the same order.

Step 1: The Specs (What do I actually want?)

This is where most people stop too early. “Organize my files” is not a spec. That’s a wish.

A spec answers: What does the finished version look like? What are the categories? What are the rules? What should be kept, trashed, or flagged for me to decide?

For my MacBook drive, the spec was straightforward: I had files migrated from several old machines. I needed duplicates identified, old system files flagged for removal, and everything else sorted into folders that matched how I actually work (not how my old computers were organized).

For my Dropbox, the spec was more complex: 10+ years of documents across multiple brand iterations. I needed files sorted by which brand they belonged to, with anything outdated moved to an archive folder, and current working files surfaced to the top.

For my Midjourney images, the spec was creative: rename every file so the name tells me what the image is about (subject) and how it feels (vibe). Instead of that AI-generated string of characters, I wanted filenames like woman-desk-thinking-contemplation-decisions-papers.png.

Here’s the kicker about the Midjourney project. The original filenames already contained the prompt I’d used to generate each image. Words like “cluttered desk” and “half-open window” and “focused expression” were buried in those long, ugly filenames. So CoWork wasn’t guessing from scratch. It had context to work with. I gave it something to build on.

That’s what a good spec does. It gives the worker enough context to make smart decisions.

Step 2: The Blueprint (How should it approach this?)

The blueprint is where you anticipate the decisions CoWork will have to make, and give it your preferences before it starts.

For the MacBook drive: “When you find duplicates, keep the most recent version. If a file hasn’t been opened in 3+ years and isn’t a legal or financial document, flag it for review but don’t delete it.”

For the Dropbox folder: “Documents with ‘DigiNav’ in the filename or content belong to the current brand. Anything referencing [old brand names] goes to archive. If you’re unsure, put it in a ‘Review’ folder and I’ll decide.”

For the Midjourney images: “Rename using this pattern: subject-descriptors-mood-vibe.png. Keep it lowercase, use hyphens between words, and focus on what’s visually happening in the image plus the emotional tone.”

See the difference? The spec says what you want. The blueprint says how to handle the judgment calls. Without a blueprint, CoWork makes those calls for you. Sometimes that’s fine. Sometimes you end up with your client proposals filed under “Miscellaneous.”

Step 3: The Roadmap (What order, and where do you check in?)

The roadmap is your sequence. It’s especially important for bigger projects.

For the MacBook drive, the roadmap was simple: scan first, show me a summary of what you found, then sort. I wanted to see the lay of the land before anything moved.

For the Dropbox folder (the biggest project), I broke it into phases: start with just the top-level folders. Show me what you’d do before you do it. Then go deeper one folder at a time. I didn’t want CoWork tearing through a decade of files without checkpoints.

For the Midjourney images, the roadmap was: rename a batch of 10 first. Let me see if the naming pattern works. Then do the rest.

That last one turned out to be smart. After the first batch, I adjusted a few of my naming preferences before letting CoWork finish the other hundreds of files. Ten minutes of review saved me from renaming everything twice.

What This Really Requires (Hint: Not Technical Skills)

Here’s what I want my not-so-technical friends to hear, because this part matters.

Nothing I did this week required coding. Nothing required a terminal or command line. Nothing required understanding APIs or scripts or any of the vocabulary that makes people’s eyes glaze over.

What it did require:

Knowing what you actually want. Not “organize this” but “here’s what organized looks like for my situation.” That’s not a tech skill. That’s a management skill. It’s the same skill you use when you brief a contractor, or explain a project to a virtual assistant, or onboard a new team member.

Thinking about edge cases before they happen. What should CoWork do when it finds a file it can’t categorize? When there are duplicates? When something could belong in two places? You don’t need to catch everything. But anticipating the obvious judgment calls saves you from cleaning up the cleanup.

Starting small and iterating. Every single project went better because I didn’t hand CoWork the whole thing at once. I tested on a small batch, reviewed the result, adjusted my instructions, and then scaled up. That’s not caution. That’s how good project management works.

If you’ve ever managed a person, delegated a task, or written instructions for someone covering your work while you’re on vacation, you have the skills CoWork needs. The barrier isn’t technical. It’s the willingness to do the thinking first.

If You Only Remember This

If you only take away five things from this entire post, make it these.

1. CoWork is Claude with its sleeves rolled up. Instead of giving you advice in a chat window, it actually does the work on your computer. Same Claude, different mode.

2. The tool isn’t the hard part. The brief is. Vague instructions get vague results. Clear specs, a blueprint for judgment calls, and a phased roadmap make the difference between “meh” and “wow, that just saved me an entire weekend.”

3. You don’t need technical skills. You need management skills. If you can explain a task to a capable human, you can use CoWork. The skills that matter are knowing what you want, anticipating decisions, and reviewing in stages.

4. Start small. Always. Test on a batch of 10 files before you unleash it on 1,000. Review the first pass before trusting the rest. This isn’t being timid. This is being strategic.

5. Context is your superpower. My Midjourney renaming project worked because the original filenames already contained prompt information. CoWork wasn’t working blind. Give it something to build on and it builds well.

The Real Cost of Skipping the Thinking

I know what you might be thinking: “That planning sounds like a lot of work. Can’t I just... try it and see what happens?”

You can. And you might get lucky.

But here’s what “trying it and seeing what happens” actually costs. You spend 45 minutes watching CoWork do something you didn’t quite want. Then you spend another hour undoing what it did. Then you try again with slightly better instructions. Then you tweak again. And again.

Three hours later, you’ve “saved time” by spending more time than it would have taken to do it manually.

I know because that’s exactly the pattern I see with every new tool, not just CoWork. The tool gets blamed for the result. But the result was set the moment you skipped the thinking.

The 15 minutes I spent writing specs and a blueprint for each project? That wasn’t overhead. That was the entire reason the projects worked. It’s the same reason you’d never hand a contractor your house keys and say “renovate something.” You’d give them a plan first.

That friction you feel about slowing down to think before acting? That’s not weakness. That’s 17 years of business experience telling you something important: tools work when the thinking is done. Not before.

What Are You Putting Off?

Here’s what I’d love to know.

What’s the project on your computer that you keep putting off because the manual version feels overwhelming? The folder you haven’t touched in years. The files with names that mean nothing. The digital junk drawer you close as soon as you open it.

That’s probably a CoWork project. And the first step isn’t opening CoWork. It’s answering this: What does “done” look like, specifically, for you?

If you can answer that, you have your spec. And you’re already further than most people get.

Your turn…tell me what that project is. I’m genuinely curious.

And if you want help thinking through the specs-blueprint-roadmap for your specific situation, let’s talk. That’s exactly the kind of thinking work I do. Not pushing buttons for you. Helping you name what “done” looks like, because that’s harder than it sounds.

I thought I was ahead of the curve. I’d built Claude Skills—voice guidelines, content repurposing workflows, the works. Felt pretty good about it. Then put out a call last week asking people to share what they’d built. And to say people delivered is an understatement.

Writers maintaining voice across months of content. Consultants with context libraries that eliminate the “let me explain my business again” dance. Systems that work across any project, not just the one they were built for.

I looked at my setup. What I’d built was solid—but it was trapped. Locked inside specific projects as instructions. Every time I started something new, I was rebuilding context instead of deploying it. I’d been building rooms when I should’ve been building infrastructure.

The Real Gap Nobody Talks About

Most people think the problem with Claude is consistency. The AI gives you gold one day, garbage the next. So you save the prompts that worked. You build custom instructions for your projects. Maybe you create a Skill or two. You’re doing the right things.

But here’s what I discovered looking at what others had built: the real issue isn’t whether you’ve set things up. It’s whether you’re thinking big enough about what that setup could do.

I had good stuff. Voice guidelines that actually captured how I write. Content workflows that saved me hours. But they lived inside specific projects as instructions. My Substack project had one setup. My client's work project had another. My brainstorming space had... nothing, really. Just me re-explaining the context every time.

The people getting genuinely consistent results? They weren’t just building for individual projects. They were building for their whole process—voice that deployed whether they were writing a newsletter, drafting a client proposal, or outlining a workshop. Context that didn’t need to be copy-pasted or recreated. It just existed, ready to use wherever they were.

Here’s what that gap was costing me:

• Duplicate effort rebuilding context across projects

• Inconsistent outputs because each project had slightly different instructions

• The mental load of remembering which project had which setup

• Useful things I’d built that sat unused because they weren’t accessible elsewhere

The fix wasn’t building more. It was rethinking what I was building for. Not project-specific instructions. Something you set up once and stop thinking about—because it just works wherever you are.

So what does that actually look like?

How I Rebuilt My Approach

The Creative QA Skill by Mariam Vossough stopped me cold.

Mariam had built something specifically for catching weak spots in drafts—not grammar or typos, but the structural stuff. Unclear transitions. Arguments that don’t land. Sections that drag. The kind of feedback you need after you’ve reworked something three times and can’t see it clearly anymore.

I’d been missing that. I thought my content process was solid, but I didn’t have anything that checked for weak spots after the drafting and redrafting were done. That was gap number one.

But then I started thinking bigger. A Creative QA check shouldn’t just work on Substack articles. What about YouTube scripts? Content repurposing? Website copy? The underlying need—catching weak spots in something I’ve already worked and reworked—shows up everywhere. Why would I build something that only works in one place?

That’s when the real pattern clicked.

I looked at what I’d already created. Voice guidelines, content workflows, repurposing frameworks. All solid. All trapped inside specific projects. My Substack project had context my YouTube project couldn’t access. My content repurposing project duplicated half of what lived in my drafting project. I’d built useful things, but they didn’t talk to each other.

Here’s what I tried:

1. Audited what I actually had. Listed every project and its instructions. Asked: is this specific to one use case, or is the underlying need something I hit repeatedly?

2. Identified the core that applied everywhere. My voice guidelines? Needed everywhere. My content pillar definitions? Same. A QA checklist? Definitely not a one-off.

3. Rebuilt as account-level tools. Pulled what I’d created out of individual projects and rebuilt them as standalone pieces that could be accessed from anywhere.

4. Tested across contexts. Took the rebuilt voice setup and used it for a Substack draft, a YouTube outline, and a landing page. Same foundation, three different outputs. It worked.

The surprising part wasn’t that this approach was better. It was how much mental overhead I’d been carrying without realizing it. Remembering which project had which instructions. Recreating context I’d already built. Wondering if my Substack voice guidelines matched what I’d set up for client work.

When I stopped building for single projects and started building for my whole process, that overhead disappeared.

Here’s what I finally understood: the question isn’t “what does this project need?” It’s “what’s a problem I solve over and over—and how do I build something once that handles it everywhere?”

How to Build for Your Whole Process

Why Project-Locked Instructions Were Costing Me

Every time I started a new project, I was rebuilding context. Copy-pasting instructions from one project to another. Wondering if my voice guidelines here matched my voice guidelines there. What I’d built was useful—but only in the single place I’d built it.

Which meant I was doing the same setup work repeatedly, just in different containers.

Here’s What Changed: Building at the Account Level

The shift was moving what I’d created out of individual projects and into account-level custom setups—where they’re available everywhere, triggered automatically based on what I’m working on.

You’ll find this under Settings > Profile > Settings > Capabilities > Skills in Claude. That’s where Skills live at the account level, separate from any individual project.

Now, when I ask Claude to help with DigiNav content, my voice setup activates. Not because I remembered to paste instructions. Because I built triggers that recognize the context.

The Structure That Makes It Work

I let Claude handle the formatting, but everything I build now has three parts:

• Metadata: What this is for and when to use it

• The Core: The actual instructions, guidelines, or framework

• Supporting Resources: Any documents it needs to reference

The Trigger Setup

This is the part I was missing. What you build needs to know when to activate. My voice setup triggers on:

• Requests to write DigiNav content

• Mentions of “Lee’s voice” or “DigiNav style”

• Content about AI/automation for thoughtful business owners

• Keywords like “clarity before automation” or “thinking partner”

No manual activation. No remembering which project has which instructions. It just shows up when it’s relevant.

The Question That Filters Everything

Before building anything now, I ask one question:

Am I using this in more than one project—or is this a one-off use case?

If it’s one project, it stays as project instructions. If it shows up across multiple contexts, it becomes something I build once and use everywhere.

Try This: Audit Your Current Setup (15 minutes)

1. List every project you’ve created in Claude—OR think about the threads you find yourself starting over and over again

2. Look at the custom instructions in your projects, or notice what context you keep re-explaining in those repeated threads

3. Ask: what’s duplicated? What do I rebuild or re-explain because I couldn’t access it elsewhere?

4. Those duplications are your first candidates for building bigger

What Others Are Actually Building

When AI Blew My Mind put out that call, the responses didn’t just show me what was possible. They showed me how differently people were thinking about the problem.

The article organized submissions into categories, and each one revealed a different angle on thinking bigger.

Writers and Content Creators built for voice consistency, editorial feedback, and content repurposing. Not "here's how to write a blog post"—but "here's how to maintain my voice whether I'm drafting a newsletter, scripting a video, or writing a sales page." One setup, multiple outputs.

Marketers built for audience analysis, campaign planning, and messaging frameworks. The pattern: instead of rebuilding their brand positioning every time they started a new project, they created something that carried that context forward automatically.

Business Ops built for process documentation, meeting summaries, and decision frameworks. These weren't tied to a single workflow—they were designed to plug into whatever came up.

The thread that connected all of them: nobody was building for one use case. They were building for repeated problems that showed up across their work.

That’s the shift I’d been missing. I was asking “what does this project need?” They were asking “what problem do I keep solving—and how do I stop solving it manually every time?”

Looking at what others built didn’t just give me new ideas; it also inspired me. It gave me a different question to start from.

The Shift

I started this thinking I was ahead. I’d built things. I was using Claude more intentionally than most people I know.

Then I saw what others were building, and realized the gap wasn’t effort—it was approach. I was building for projects. They were building for problems that repeat.

The shift isn’t complicated. It’s just a different question to start from:

What do I keep solving manually that I could solve once?

You don’t need to rebuild everything. Start with one thing—the context you’re most tired of re-explaining. Build it bigger. See what changes.

And if you want to see what sparked this whole rethink, check out the 6 Claude Skills examples from the AI Blew My Mind community. The examples might make you realize you’ve been thinking too small, too.

It worked for me.

We’re moving again. At this point, I think we’ve crossed the eight-moves-in-twelve-years threshold, though who’s really counting anymore? You’d think with that kind of track record, it might get easier. Nope: it doesn’t. Utility setups still require precision timing, address changes still hide in every digital corner, and closing companies have their own unforeseen challenges.

The one saving grace this time?

We’re moving locally. And we finally hired movers instead of bribing family with pizza and promises. It’s just the hubs and me now, living minimally enough that the process shouldn’t feel overwhelming—and yet it somehow still does.

December already has its own natural chaos: holidays, year-end projects, and a business (or two) to run. That elusive “pre-retirement enjoyment” everyone talks about? I’m convinced it’s a myth.

Especially when you’re the kind of person who still lights up over tech shifts and the ways even the smallest businesses can be reshaped by what’s coming next. Passion doesn’t clock out just because the calendar says you’re approaching the “easy years.”

But somewhere in the middle of all the lists, the boxes, and the swirling mental tabs, I stumbled across something that shifted everything: an article on the hierarchy of needs. I expected a psychology refresher. I got something closer to a deep breath.

Because, for all the noise around me, one idea hit hard: even in chaos, priorities have an order. And when you honor that order, things stop feeling impossible.

Why Your Schedule Isn’t the Problem (Hierarchy Is)

Most people think the problem with overwhelm is that they need better time blocking, more discipline, or a stricter schedule. So they buy the planner. They try to force every week into the same structure, assuming Monday through Friday will look identical across four weeks of December when, in reality, closing week looks nothing like holiday week.

But here’s what I discovered: the real problem isn’t your schedule. It’s that traditional planning assumes your capacity stays constant when it never actually does.

For me, the math was brutal. Week one (closing): almost zero business time available. Week two (moving week): logistically heavy but slightly more flexible. Week three (early holidays): shifting again. Week four (actual holidays): completely different. A rigid weekly template would fail by day four.

I needed something that adapted by the week. Something that permitted me to say:

“In survival mode, these three things are non-negotiable. Everything else waits.”

Something I could actually reference instead of losing in a Google Doc.

Here’s what costs you if you keep forcing traditional balance:

• You abandon momentum on things that matter (content, client relationships, building something new)

• You create guilt—either you’re shirking business or sacrificing presence at home

• You burn out trying to maintain “equal weight” on unequal weeks

• You make reactive decisions instead of strategic ones because you’re constantly behind

If you keep thinking balance means equal distribution, you’ll end up scattered across all of it instead of clear on any of it. You’ll feel like you’re dropping balls everywhere, even when you’re actually just dealing with reality.

So what actually works is permission to rank your chaos. To say: this week, these three things matter most. Next week, that shifts. And having a system that reflects that shift, rather than punishing you for it.

How Three Different AIs Solved My December Chaos—And Why One Got It Right

So I did what I always do when I’m stuck between what I know I need and what I can actually execute: I turned to AI.

Not for motivation. Not for one more productivity hack. I needed my bots to help me translate the hierarchy concept into a real, week-by-week game plan that worked with December chaos rather than against it.

Here’s what I realized immediately: I had no idea what my actual capacity was.

I started with ChatGPT.

I said: here’s December, here’s what’s happening (closing, moving, holidays, business commitments), here’s the framework I want (hierarchy of needs), so let’s build a plan. It came back with a five-tier system, which had good intentions but fell apart on the math. It said I had 10 hours available when I actually had 5.

Perfect logic, completely disconnected from reality.

So I threw everything into Gemini. Same context, same request. This time, it gave me a time-blocking system—very structured, very confident. “High energy times, low energy times, block accordingly.” Clean concept. Totally wrong for me because it assumed every week had the same structure. It didn’t account for my moving days or the logistical chaos underneath the calendar.

That’s when I realized the problem: neither AI was asking me enough clarifying questions. They were just solving based on assumptions.

I turned to Claude next, but this time I did something different. I uploaded everything from the first two conversations and said, “Tell me where the gaps are.”

And that’s when it actually started thinking.

It said: “Here’s what’s working—you get the life-first hierarchy concept. You understand energy levels matter. But here’s where it’s off the mark: your business baseline is probably 10-12 hours, your actual available time is 20-25 hours this month, the math doesn’t work, and you’re treating this like a rigid time-blocking problem when it’s actually a permission problem.”

That was the breakthrough. Permission problem, not planning problem.

It asked clarifying questions: What’s your energy pattern on specific days? What are your true minimums—what absolutely has to happen weekly? What weeks are actually different? It didn’t assume—it clarified.

Then it built a traffic light system.

Red weeks were survival mode (just keep the business alive, don’t crash anything). Yellow weeks were maintenance (the things you need to do if you have energy, the things that keep momentum). Green weeks were a bonus (and it literally gave me zero green weeks in December, which was refreshing).

That’s when I understood: I wasn’t scattered because I had too many tools or not enough discipline. I was scattered because I was trying to apply a one-size-fits-all framework to a month where no two weeks looked the same.

The system Claude built wasn’t just a plan. It was permission. Permission to survive some weeks instead of thrive in all of them. Permission to keep business alive without burning out, trying to also manage a move and holidays at full capacity.

The Red-Yellow-Green System That Replaced My Rigid Planning

Here’s what changed everything. Instead of fighting December with a rigid schedule, I built three layers: clarity on capacity, permission by week, and one visual system I could actually reference.

Why Traditional Planning Was Costing You:

Forcing “equal balance” across unequal weeks meant you were either lying about your capacity or burning out trying to maintain it. Real cost: momentum loss on what matters, guilt, and decision fatigue. The system wasn’t wrong—your situation was just too variable for it.

Here’s What I Built Instead:

I created a simple framework that asked Claude to do something most planning tools don’t: help me get realistic about what’s actually possible this month, and then build the plan around that reality instead of theory.

Here’s a Claude (or any AI) prompt for you to try:

I’m overwhelmed about [month] and need a realistic game plan. Here’s what’s happening:

[List: major life events, business commitments, energy drains, critical dates]

Here’s what I need:
- Permission to prioritize (not everything gets equal weight)
- Honesty about my actual capacity (not what I wish I had)
- A week-by-week system that adapts (because not every week is the same)
- Clear minimums (what actually has to happen)

Questions for you before we build the plan:
1. What am I getting wrong about my own capacity?
2. What are my real minimums—what can’t be dropped?
3. Which weeks are actually different, and how?
4. What counts as “good enough” vs. what needs to be excellent?

What makes this work for me: Claude doesn’t just build a plan. It asked clarifying questions first. It validated the concept (hierarchy matters) while poking holes in the assumptions (your capacity math is off). Then it built something that actually fit.

Here’s what the system looked like:

Three tiers, color-coded:

• RED weeks (survival mode): 3-5 hours of business time. Just keep things alive. Non-negotiables only.

• YELLOW weeks (maintenance): 10-15 hours. The things that matter, the momentum keepers. Do these if energy allows.

• GREEN weeks (bonus): Everything else. (Pro tip: I had zero green in December, and that was honest.)

Then I automated it into Notion:

Here’s where Claude took it a step further. Instead of building the system myself, I said, “Can you turn this plan into a Notion page I can actually use?”

It created a full Notion page with sections for each week, color-coded headers (red/yellow/green), and checkboxes for every task. Then it delivered it directly to Notion for me.

I didn’t have to build a database. I didn’t have to structure anything. I just opened Notion, and the plan was already there—organized, visual, and ready to use. All I had to do was check boxes as I moved through December.

That’s the difference between a plan that sits in a document and a plan that becomes part of your workflow. Claude didn’t just think through my problem. It solved it in a format I’d actually reference.

If you want to see how this unfolded in real time—including the moment I realized Claude’s approach was fundamentally different from ChatGPT and Gemini—here’s the full walkthrough.

When People Stop Measuring Themselves Against the Wrong Week

When people talk about December overwhelm, they’re usually not actually overwhelmed by the tasks. They’re overwhelmed by the gap between what they’re doing and what they think they should be doing. The guilt comes from measuring an unequal week against an equal-week standard.

It’s not “I have too much to do.” It’s “I’m not doing my normal routine while also dealing with [move/holidays/family crisis/business pivot].” And then they feel like they’re failing at everything because they’re comparing survival mode to normal mode.

That’s what the hierarchy of needs actually does: it permits you to measure yourself against this week’s capacity, not last week’s or some hypothetical perfect week. It’s not about being less ambitious. It’s about being realistic about when you have the energy and capacity for ambition.

The shift isn’t magic. It’s just permission. Permission to say: “This week, these three things matter. That’s enough. Everything else waits.” And then actually believing that’s strategic instead of seeing it as a failure.

The universal principle underneath all this: You don’t need better balance. You need permission to be strategic about what deserves full attention in each phase.

Build a Week-by-Week Planning System (That Actually Works)

The Old Way: Rigid weekly templates. “Monday through Friday will look the same all month.” Force every task into time blocks. Treat capacity as constant, even when your life clearly isn’t.

The Smarter Way: Build a framework that adapts by week. Get honest about your real capacity. Create permission tiers (survival, maintenance, bonus) instead of pretending everything is equally important.

Here’s exactly how:

Step 1: Get Real About Capacity (10 minutes) Write down: How many hours do you actually have available this [month]? Not what you wish. What you actually have. Factor in the moving days, the closed office dates, and the holiday disruptions. Ask Claude to poke holes in your math.

Step 2: Define Your True Minimums (5 minutes) What absolutely has to happen every week, no matter what? For me: one Substack article, weekly Substack notes, one YouTube video. Everything else is secondary.

Step 3: Color-Code by Capacity (10 minutes) RED: Survival weeks. Only minimums. Everything else pauses. YELLOW: Maintenance weeks. Minimums plus the momentum keepers. GREEN: Bonus weeks. Everything else if energy allows.

Step 4: Put It Somewhere You’ll Actually Check (10 minutes) Notion database. Google Sheets. Wherever you look, when you’re wondering what to do next. Make it visual so you don’t have to think.

Why this works: You’re not fighting reality anymore. You’re building a plan with reality. Which means you’ll actually follow it because it doesn’t ask more than you have.

Permission Over Perfection: Your December (and Every Month) Game Plan

This whole exercise with the AI comparisons taught me this: the system doesn’t have to be perfect. It just has to be honest.

Honest about your actual capacity. Honest about which weeks are actually different. Honest about what counts as good enough when you’re in survival mode. That kind of honesty doesn’t feel like failure. It feels like permission.

So here’s the thing: you probably don’t need a new planner or more discipline or a stricter schedule. You need permission to look at December (or April, or August, or whenever your chaos hits) and say: “These are the realities. Here’s what’s actually possible. Here’s what I’m protecting. Here’s what waits.”

That’s not a weakness. That’s strategy.

The real breakthrough wasn’t the red-yellow-green system. It was what Claude did before building it: ask clarifying questions. Instead of assuming my capacity, it asked. Instead of guessing my priorities, it clarified. That conversation—the one where context actually gets named—is what made every decision after it make sense.

That’s why I’m creating the SHIFT Your Context Workshop launching in January.

It’s built on the same principle: get your context clear first, then build your plan around reality instead of theory. Whether you’re managing a chaotic season, scaling a business, or building something new, the conversation works because you’re not making decisions on assumptions anymore.

If you want to be part of that workshop and actually get the clarity piece sorted before 2025 picks up speed, I’ll have details soon. But for now, I want to hear from you.

So here’s what I want to know: What’s one season or phase in your business where you’re forcing traditional “balance” when you actually need survival mode permission?

In middle and high school, I struggled. Lectures blurred together, and pages of dense text left me restless. I wasn't "bad" at school, but I looked like I was, because my brain simply couldn't lock in through that format.

But when I had the chance to learn by doing, something flipped.

In music class, home economics, or science labs, I thrived. Give me trial and error, let me touch and test and fail and try again—that's when my mind lit up.

College was a little better. Different styles of learning meant I could find my way through. But I still hit the same wall in lecture-heavy courses. My focus drifted, my grades showed it, and underneath it all was a constant thought: maybe something's wrong with me.

That belief stuck for a long time—until recently.

What I've come to realize is that this story isn't unique to me. It's the story of every entrepreneur, creator, or business owner who's ever felt like traditional learning methods don't fit their brain. We've been carrying around this belief that we're somehow deficient when really, we're just different.

What Your Learning Struggles Really Mean (It's Not What You Think)

Here's what I realized was actually happening: the issue wasn't my capacity to learn. It was the assumption that there's only one "right" way to absorb information.

Traditional education systems are built around passive consumption:

• Sit still and listen quietly

• Read lengthy texts without interaction

• Absorb information in predetermined formats

• Hope your brain magically retains everything

"But here's the thing about that approach: it only works for a specific type of learner."

The rest of us get labeled as distracted, difficult, or simply not smart enough. We internalize that message and carry it into our adult lives, where we continue to force ourselves through learning methods that drain our energy instead of amplifying our natural abilities.

The real problem isn't that some of us can't learn—it's that we've been trying to force our square-peg brains into round-hole systems.

In a world where staying current with industry knowledge, new tools, and evolving strategies is essential for business success, this mismatch isn't just frustrating. It's actively limiting our potential in ways we don't even realize.

Most people are fighting the wrong battle entirely. They're trying to fix themselves instead of finding the right tools.

How I Used AI to Transform My Learning Process (Step-by-Step)

Now, with AI in the mix, I've realized it wasn't me that was broken. It was the one-size-fits-all way I'd been taught to learn.

When I face a 20-minute lecture or a long article, I don't have to force myself through it anymore. I can drop it into an AI tool and ask for the key takeaways. From there, I can build: asking follow-up questions, creating quizzes, and testing myself in ways that feel active.

Watch me demonstrate exactly how I use ChatGPT to transform complex content into formats that match different learning styles - from visual diagrams to interactive quizzes to hands-on exercises. You'll see the actual prompts and responses that turn passive content into active learning.

Instead of battling my way through dense material, I realized I already had everything I needed—curiosity, the ability to ask good questions, and a preference for interactive learning. The missing piece was simply a bridge between how information was presented and how my brain wanted to process it.

I started with one small experiment: taking a business article I'd been avoiding and feeding it to ChatGPT with a simple prompt. What worked was immediate—I understood the content better in two minutes than I had in twenty minutes of forcing myself to read.

Here's what surprised me: this approach actually deepened my understanding. Because I could ask follow-up questions and test my comprehension in real-time, I retained more than I ever had with passive reading.

The breakthrough moment came when I stopped seeing AI as a shortcut and started seeing it as a translator—converting information from formats that drain me into formats that energize me.

My next move was to stop apologizing for how my brain works and start designing my learning around it, rather than against it.

AI Learning Prompts That Work for Every Learning Style

Here's the exact prompt I use when I'm stuck with dense content:

"I learn best through interaction and application. Please break this [article/video/concept] down into: 
1) The core idea in one sentence
2) Three key points with real-world examples  
3) Two questions I should ask myself to apply this"

This aligns with what Tiago Forte writes about in Building a Second Brain—that our minds are designed to connect new information to existing knowledge through active engagement, not passive absorption.

For your specific learning style, try these variations:

• Visual learners: "Create a simple diagram, flowchart, or visual representation of this concept"

• Kinesthetic learners: "Give me three hands-on exercises or activities to practice this skill"

• Auditory learners: "Rewrite this as a conversation or dialogue between two people discussing the topic"

• Reading/writing learners: "Create a structured summary with headers, bullet points, and action items"

My Complete Learning Toolkit:

• Information Processing: Paste dense content + ask for breakdown in my preferred format

• Comprehension Testing: "Quiz me on this material" or "Give me a scenario to apply this concept"

• Retention Building: "Help me create analogies for this concept using [topic I'm already familiar with]"

• Application Focus: "What are three ways I could apply this in my business this week?"

• Visual Creation: "Turn this into a simple infographic or step-by-step visual guide"

The tool that made the difference: ChatGPT as a learning translator. Instead of fighting the original format, I use AI to convert information into the style my brain actually craves.

Key insight: These aren't crutches. They're amplifiers. I'm not avoiding learning—I'm optimizing it.

Why Learning Style Adaptation Matters for Business Success

This isn't just about individual learning struggles—it's about recognizing that adaptation is a strength, not a weakness.

According to research from the National Center for Education Statistics, over 40% of adults struggle with traditional learning formats, yet most business education still relies on lecture-heavy, passive consumption models. This explains why so many capable entrepreneurs and creators feel behind when it comes to staying current with industry knowledge.

The same principle applies to:

• Staying current with industry trends without information overwhelm

• Learning new tools and technologies at your own pace

• Processing client feedback and market research in actionable ways

• Absorbing business education that actually sticks

• Onboarding team members with different learning preferences

"In a rapidly changing business landscape, the ability to quickly translate new information into actionable insights isn't just helpful—it's essential."

Many successful entrepreneurs I know have similar stories. They struggled in traditional educational settings but excel when they can customize their approach to match their thinking style. The difference now is that technology has democratized this customization.

Consider how this applies to your business growth. Instead of forcing yourself through every industry report or sitting through webinars that don't match your learning style, you can use AI to transform that information into formats that actually stick.

The broader pattern here: when we stop trying to fit into systems and start building systems that fit us, everything changes.

30-Minute AI Learning Experiment You Can Try Today

Pick one piece of content you've been avoiding—maybe it's an industry report, a training video, or even a book chapter that's been sitting in your "someday" pile.

Here's your 30-minute experiment:

1. Identify your learning preference (visual, auditory, kinesthetic, or reading/writing)

2. Open ChatGPT and paste your content with this prompt: "I learn best through [your preference]. Please help me understand this material by [specific request: creating examples, breaking it into questions and answers, making it actionable, etc.]"

3. Spend 15 minutes engaging with the AI's response—ask follow-up questions, request clarification, or have it quiz you on the material

4. Create one actionable item from what you learned to implement in your business this week

5. Notice the difference in your comprehension and retention compared to your usual approach

Pay attention to:

• How engaged your brain feels during the process

• How much you retain without forcing yourself to focus

• Whether you feel energized or drained by the experience

• How quickly you can move from understanding to application

This isn't about replacing deep thinking with shortcuts—it's about removing barriers so your natural thinking can happen.

From Learning Struggle to Learning Success: Your Next Steps

That constant thought that maybe something was wrong with me? It's gone.

Not because I changed how my brain works, but because I stopped trying to force it into systems that never fit.

The real shift isn't just about technology—it's about permission. Permission to learn the way that actually works for you, rather than the way you think you should. Permission to see your learning differences as strengths, not deficits.

Here's what I'm curious about: what would change in your work or business if you stopped fighting your natural learning style and started designing around it instead?

The tools are here. The question is whether we're ready to let go of the idea that there's only one "right" way to absorb and apply new information.

If this resonates and you're ready to stop fighting your brain's natural learning style, let's explore what's possible when you start working with it instead of against it.

The cover story was that we were headed to the horse races, dinner, and a full night out. On the way, we "had to stop" at a local club to pick up a friend. That stop, of course, was the real destination: a surprise party with everyone waiting inside.

But when he walked in, instead of delight, I saw him freeze. Shock, disappointment, maybe even irritation flashed across his face. He's never been a big fan of surprise parties, and to make matters worse, we had been talking with friends about a road trip for months. He thought that night was finally it. In one moment, all my careful plotting collided with his unspoken hopes.

Here's what I realized was actually happening. The party itself wasn't the problem—the people, the venue, even the surprise element could have worked. My real mistake was context. I had built a story that fit my imagination of "perfect," not his reality. I gave him the wrong setup for the experience I wanted him to have.

The irony is, it wasn't the element of surprise that failed. It was how I framed the evening. If I'd simply said, "We're meeting a friend at the club," the reveal would have landed completely differently. Same party, same people—but the path into it mattered everything.

That lesson has stayed with me for twenty years: context shapes meaning. Whether you're planning a milestone celebration or giving instructions to an AI, the framing determines whether you get magic or disappointment. You can't just drop someone—or something—into a role and expect the outcome to align with your world.

Why AI Gives You Generic Answers Instead of Useful Advice

Most solopreneurs and creators I work with struggle with the same issue I had at that party: they're asking for what they want without providing the context for how to deliver it.

With AI, this shows up as generic, surface-level responses that feel like they came from a manual instead of a thinking partner. You ask for marketing advice and get textbook strategies. You request help with a business decision and receive one-size-fits-all frameworks.

The real problem isn't that AI can't help you—it's that you're giving it a role without defining how to act within that role. Just like I gave my husband the role of "party guest" without the context that would make him comfortable in that role.

What I've learned the hard way: There's a massive difference between telling AI "be an expert" and telling it "act as an expert who's speaking to someone in my specific situation." That distinction changes everything.

How Role vs Acting As Completely Changes AI Responses

After my birthday party disaster, I started paying attention to how context shapes every interaction. In my business, when a client would ask for website advice, I learned to ask: "Are you trying to impress your industry peers, or connect with customers who've never heard of you?" Same expertise, completely different approach.

When I started working with AI tools, the same pattern emerged. I'd ask for help with content strategy and get generic social media tips. But when I started experimenting with more specific framing, everything changed.

I realized AI has two levels of instruction, just like people do. There's the overarching role—the expertise and personality it brings to the conversation. Then there's the specific lens or function within that role—how it should apply that expertise for your particular situation.

Here's the breakthrough that changed how I prompt: Instead of just saying "act as a marketing expert," I started saying "your role is a marketing expert, and you're acting as a strategist helping a solopreneur who's overwhelmed by all the conflicting advice online." Suddenly, the responses became specific, actionable, and actually useful.

The same way my husband needed the right context to enjoy his party, AI needs the right context to give you advice that actually fits your world.

Let me show you exactly how this works. I created a simple test using something everyone can relate to: preparing an onion for cooking. Watch this short video where I demonstrate three different ways to ask the same question and get three completely different levels of advice.

First, I simply asked: "Your role is a chef. Tell me the best way to prepare an onion for sautéing." The response was generic—choose the onion, cut it, and follow the basic steps.

Then I added context: "Your role is a chef, and you're acting as a teacher for a home cook who's just beginning cooking lessons." Now the response started with knife safety and broke down every step in beginner-friendly language.

Finally, I shifted the context again: "Your role is a chef, and you're acting as someone training restaurant staff." The response immediately focused on speed, consistency, and volume—completely different priorities for the same basic task.

Same expertise, three different applications. The chef's knowledge didn't change, but the context determined which part of that knowledge was most relevant.

The Exact Prompting Framework That Gets Specific Results

Here's the exact framework I use now for every AI interaction:

The Two-Layer Prompt Structure:

• Layer 1 (Role): "Your role is [expertise/personality]"

• Layer 2 (Acting As): "You're acting as [specific function] for [specific audience/situation]"

Copy-paste examples you can use immediately:

For business strategy:

"Your role is a business consultant. You're acting as a thinking partner for a solopreneur who's feeling stuck between too many good ideas and needs help prioritizing."

For content creation:

"Your role is a content strategist. You're acting as an editor helping someone who has great ideas but struggles to organize them into clear, actionable posts."

For technical help:

"Your role is a web developer. You're acting as a patient teacher explaining to someone who's comfortable with basics but gets overwhelmed by advanced tutorials."

The Context Multiplier: Once you get a response, you can instantly shift the context without starting over. Just say: "Now act as [new specific function]" and watch how the same information gets reframed for a different need.

Pro tip: Save your best role + acting combinations in a simple document. I keep mine in Notion and simply copy and paste the setup that works for different types of questions.

Why Context Matters More for Solopreneurs Than Anyone Else

This isn't just about getting better AI responses—it's about getting help that actually fits your reality as a solopreneur or creator.

Most business advice assumes you have a team, a big budget, or endless time to implement complex strategies. But when you give AI the right context about your actual situation, it adapts its expertise to your constraints and advantages.

Just as I needed to plan the party around my husband's personality, not my own preferences, you need AI advice that takes into account your business model, available time, and specific challenges.

This approach works because it mirrors how the best human advisors operate. They don't just share what they know—they filter their knowledge through an understanding of who you are and what you're trying to accomplish.

Try This 15-Minute AI Context Experiment Today

Pick one area where you've been getting generic advice—whether from AI, online articles, or even well-meaning friends.

Instead of asking "How do I improve my marketing?" try this specific approach:

Step 1: Define the role: "Your role is a marketing strategist with experience helping service-based solopreneurs."

Step 2: Add the acting context: "You're acting as a consultant helping someone who has a solid reputation locally but wants to expand their reach without losing the personal touch that makes their business special."

Step 3: Spend 15 minutes asking follow-up questions within that same context setup.

Notice: How different the advice feels when it's filtered through your specific situation instead of generic best practices.

From Generic AI Responses to Personalized Business Guidance

That birthday party taught me something I use every single day: the difference between what you want to give and what someone needs to receive often comes down to context.

Twenty years later, my husband still brings up that party—not as a disaster, but as the night he learned how much thought I put into making him happy, even when I got the delivery wrong. The intention was right; the framing just needed work.

The same is true with AI. The capability is already there. The knowledge exists. What's missing is the bridge between generic expertise and your specific world.

When you start treating AI like a thinking partner who needs context rather than a search engine that should magically understand your situation, everything changes. You stop getting advice that sounds impressive but doesn't fit your life, and start getting the kind of guidance that actually helps you move forward.

What's your version of my party planning mistake? Where are you asking for help without providing the context that would make that help actually useful?

Growing up in Pittsburgh, we have our own dialect or words for things that make absolutely no sense to anyone else who isn't familiar with how we talk. Instead of saying "you all," we say "yinz." Instead of saying "soda," we say "pop." Over-easy eggs are dippy eggs.

I remember when I was a young teen, vacationing in Virginia Beach with family and some family friends. We stopped at this corner deli sub shop while taking a break from a day at the beach. I kept trying to order a sandwich, but I kept calling it a hoagie instead of a sub. The person behind the counter seemed confused, which was frustrating me because it seemed like we were never on the same page.

How hard should it have been to order a sandwich?

The Real Cost of Confusion: Why Simple Tasks Feel Impossible

I must have said "hoagie" ten times (or what I remember as a million times), and she kept saying "you want a sub." The confusion was mutual. She looked at me like I was speaking another language. I looked at her as if she were being deliberately difficult.

Finally, I pointed to a picture and said, "I want a sandwich with meat, cheese, and heated." That's when she said, "Yes, you want a sub." Young me felt embarrassed that I didn't know the proper term. Current me finds it fascinating that there was such a divide over such a simple thing.

We both wanted the exact same outcome. We just didn't have the shared vocabulary to get there efficiently.

The Problem Isn't the Technology—It's the Translation

But here's the kicker...

Words matter.
Terms matter.
The way you describe something matters.

It's not about being right or wrong—it's about being understood.

When Business Owners and Tech Experts Speak Different Languages

That deli moment taught me something I use every single day now: when people don't understand each other, it's usually not about intelligence or capability. It's about language.

And it's the same with artificial intelligence. Coming from a coding background, I understand some of the terms that are being used to describe certain parts of the AI infrastructure.

But when I'm talking to clients about AI, we're often speaking different languages just like that day at the deli.

They want to "make their business smarter," and I'm thinking about context windows and token limits. They ask, "Can it learn?" and I explain the difference between training data and memory.

Why AI Sounds Complicated (But Doesn't Have to Be)

The real problem isn't that AI is complicated—it's that we're using insider language to describe everyday tools.

Think about it: you don't need to understand internal combustion engines to drive a car. You don't need to know how electricity works to flip a light switch. But somehow, we've convinced ourselves that you need a computer science degree to use AI effectively.

That's nonsense.

What you need is a shared vocabulary. The same way I needed to know that "sub" and "hoagie" meant the same sandwich, you need to know what people mean when they say "LLM," "prompt," or "agent."

Not because the technical details matter for most of what you're trying to do, but because understanding the language helps you ask better questions and get better results.

Someone Who Gets It

– Visual AI Creator: Heather gets it. She started out just as confused by AI jargon as anyone else. "I'm not a traditional technologist," she says, which is exactly why I love following her work. When she first stumbled into AI tools, she found them overwhelming and hard to understand.

But here's what she figured out that most people miss—she doesn't get caught up trying to master every new tool that comes out. Instead, she digs into the nuts and bolts of how to use this stuff better. She'll give you the exact prompt she used, show you her real workflow, and explain it all. No fancy terminology, no showing off—just "here's what worked and here's how you do it."

The Simple Truth About AI Terminology

Here's what nobody tells you about AI terminology: most of it describes things you already understand.

You've been "prompting" people your whole life—it's called giving clear instructions. You understand "memory"—it's just remembering previous conversations. You know what "tools" are—they're the apps and websites that help you get work done.

The only difference is that now we have fancy names for familiar concepts.

Stop Learning AI—Start Speaking Human

This isn't about dumbing down AI—it's about speaking human.

When you strip away the jargon, AI tools become what they actually are: really sophisticated assistants that can help you write, research, organize, and think through problems. They're not magic, they're not going to replace your judgment, and they're definitely not as complicated as the terminology makes them sound.

The goal isn't to become an AI expert. The goal is to become fluent enough in the language that you can order your digital sandwich without pointing at pictures.

Your First Step: Learning to Order Your Digital Sandwich

So here's what I wish someone would talk about for AI terms—the same thing I wish that deli server had told teenage me about regional sandwich names:

We're all talking about the same thing. We just need to agree on what to call it.

What if learning AI wasn't about mastering complex technology, but simply learning to translate between what you want to accomplish and how these tools actually work?

How to Become AI-Fluent in 4 Simple Steps

Your AI Vocabulary Starter Kit:

1. Save this simple translation guide – bookmark the definitions below for when you encounter AI jargon in articles or conversations

2. Practice the language – next time you use ChatGPT or Claude, notice you're writing a "prompt" and getting a response from an "LLM"

3. Ask better questions – instead of "Can AI help my business?" try "Which AI tools handle the specific tasks I need to automate?"

4. Join the conversation – now that you speak the language, you can participate in AI discussions without feeling lost.

Your AI Terms Translation Guide

Large Language Model (LLM)
What it is: An AI program that's read lots of text, learned how language works, and can now answer questions or write content—like ChatGPT or Claude. Why it matters: These are the "brains" behind most modern chatbots and writing AI tools.

Agent
What it is: An AI that doesn't just answer questions—it can make decisions and take actions on its own. Real-life example: An AI that checks your calendar, finds a free slot, and schedules a meeting automatically.

Model
What it is: The core technology (like GPT-4 or Claude) that powers an AI system. Each model has different strengths. Why it matters: Some models are better at images, some at language, some at reasoning.

Prompt
What it is: The instruction or question you give an AI (like "Write a thank-you email to my boss"). Why it matters: Better prompts get you better answers from AI.

Memory
What it is: The ability of AI to remember previous inputs and use that info in future responses. Real-life example: An agent that remembers your favorite coffee order or your business priorities.

Hallucination
What it is: When AI gives a convincing but made-up answer (not based on real facts). Why it matters: Always double-check important information from AI.

Token
What it is: AI splits sentences into chunks called tokens for processing. About 1,000 tokens equals 750 words. Why it matters: Helps you avoid overloading the AI with too much text at once.

Context Window
What it is: The amount of text an AI can "remember" at once in a single conversation. Real-life example: If your conversation gets very long, earlier messages might be forgotten.

The Real Landing (Call to Action)

Ready to speak AI fluently?

Stop letting jargon intimidate you out of using tools that could transform how you work. These terms aren't barriers—they're just vocabulary words waiting to be learned.

What AI task have you been putting off because the language felt too complicated? Hit reply and tell me—I'll help you translate it into plain English.

Not because I didn't know where I was going—I could see the direction clearly. But something was missing, something I couldn't quite put my finger on. The frustration of knowing your concepts are solid, but watching them turn fuzzy the moment you try to explain them to someone else.

You know that feeling when you're trying to describe a color to someone who's never seen it?

The Spiral Started With Words

Those niggly details that should be simple but somehow aren't.

"Community"—I know exactly what I mean when I say it, but it lands completely differently with my audience. "Thinking partner"—crystal clear in my head, sounds impossibly vague when I say it out loud. When words don't land right, your brain immediately jumps to "I must be doing something wrong."

Maybe I should pivot. Maybe this direction isn't right. Maybe I'm missing something fundamental.

But here's the thing—the direction felt solid. The concepts made sense. It was just the language that wasn't cooperating. Yet instead of trusting that and working on the clarity, I started questioning everything.

Dropoffs and Meltdowns

But then I remembered the times I dropped my daughter at her day care.

It took me back to those mornings dropping my daughter off at her child development center. She loved it there—I was right up the road, she knew the staff, had little friends waiting for her. But there were still those days when the first few moments were her own WTF moments.

The clinging. The tears. The "why can't I spend the day with you" look.

Beyond The Tears

On those tough mornings when she'd wrap around my leg, the teacher would always say the same thing: "Don't worry Mom, as soon as the door closes, the tears stop and she goes about her merry way."

And she was right. Every time.

My daughter struggled to articulate her needs and why she needed time before I left. She knew she wanted something—comfort, connection, understanding—but the words weren't there. The clarity wasn't there. Just the raw feeling that something was off.

Sound familiar?

The Right Words

The breakthrough wasn't about changing direction—it was about finding the right language for where I was already going.

Here's what I realized: My daughter and I were in the same boat. We both knew what we meant, but we couldn't make others understand. The temporary discomfort wasn't proof we were in the wrong place—it was proof we needed better clarity on the details.

Not the big picture. That was clear—the translation between what we knew and what others could grasp.

Most of us abandon ship when the words don't work. We think if we can't explain it clearly, the concept must be flawed. But what if the concept is solid and we just need to find our language?

What if the problem isn't what we're building, but how we're describing it?

Someone Who Gets It

– Marketing Strategist built her entire "Smarter Solopreneurs" newsletter around the precision of language. She took the fuzzy concept of "anti-hustle entrepreneurship" and made it crystal clear through consistent, specific messaging.

She doesn't chase trends—she finds the exact language that helps thoughtful solopreneurs understand what they're building. Her success comes from clarity, not complexity.

The Words Hitting Differently

The tears stop as soon as the door closes.

Those words hit differently now. It wasn't about my daughter being in the wrong place—it was about the temporary discomfort of not being able to see what came next.

The same way my business direction is right, but I'm still in that moment before the door closes. Still finding the words that will make everything click.

• • •

This wasn't about my concepts being wrong—it was about needing the right language to make them clear.

"Community" needs to become something more specific. The term "Thinking partner" needs context to be concrete rather than vague. Context Library needs examples that show rather than tell.

The direction is solid. The foundation is there. I just need to trust the process of finding words that match the clarity I already have inside.

What Would You Change

What would change if you stopped questioning your direction every time the words didn't work?

Instead of scrapping concepts that feel solid but sound fuzzy, what if you trusted the adjustment process? The minor tweaks that help others see what you already know clearly.

Sometimes the problem isn't your vision—it's finding the language that lets others into it.

Here's how to trust the process while you find your words:

1. Document what you actually mean - Write out the clear version that lives in your head, even if it's messy

2. Test small pieces - Share one concept at a time instead of trying to explain everything

3. Collect the confusion - When people look lost, ask "What part doesn't make sense?"

4. Build your translation bridge - Create a Context Library of language that actually lands

• • •

Ready to Build Your Context Library?

I'm putting together an on-demand workshop that walks through creating your own Context Library—the foundation that helps you find the right language for the right concepts at the right time.

If you're tired of having brilliant ideas that sound fuzzy when you explain them, this is for you. I'll keep you posted when it's ready.

P.S. The tears do stop. Trust me on this one.

When I opened the box, I realized there were no instructions; this was not good.

This wasn’t my first assembly project, nor will it be my last, but I like instructions (and guidance). I wasn’t just disappointed—I was irritated. I wanted a clear path. I expected the direction to be laid out for me. Instead, I had a pile of parts and an invitation to wing it.

That’s not how I work.

Sometimes, clarity isn’t given to us. We go get it.

The Mindset That Builds What Hacks Can’t

Forget shortcuts. This is the path to sustainable success.

A common belief or misconception

In business, the loudest messages tell us to move faster, be more efficient, and hack our way to the top.

You’ll hear it everywhere: Just follow this formula. Just use this tool. Just mimic this 6-figure tactic.

While these strategies might work for someone, they often lead to more confusion than clarity, especially when you’re building something that needs to feel personal, aligned, and sustainable.

The truth is, most solopreneurs aren’t failing because they lack information.

They’re stuck because they’ve never slowed down long enough to figure out how they actually work best.

The missing instructions (and what they revealed)

I expected a clean path forward when I opened that porch furniture box.

I didn’t get one.

Most people would either dive in blind or give up until someone else comes along.

I opened Google. YouTube. Asked ChatGPT. Cross-checked model numbers. I needed insights before I started, and I knew how to approach the task to make it feel easy to understand the concept behind the build.

That’s when I realized this is exactly what I do in my business.

I don’t guess my way through big projects. I research, plan, adjust, and then take action with full alignment.

It took me less time to look up the instructions than it would’ve taken to unassemble and start over again.

Clarity always saves more time than shortcuts do.

How to think differently about progress

Here’s what this moment reinforced for me—and what I now teach others:

1. Your natural instincts are part of the process.

Not everyone works the same way. Some people need structure. Others need space. Trust what energizes you.

2. Slowing down isn’t stalling out.

It’s easy to confuse pause with procrastination. But thoughtful planning prevents rework.

3. You don’t need more tools. You need more context.

A hammer is useless if you’re building the wrong thing. Stop downloading and start clarifying.

4. Action without direction is expensive.

It costs energy, time, and confidence. It’s okay to stop and check the map.

5. Alignment is faster than hustle.

When your path makes sense to you, you move with less resistance.

The shortcut trap (and a softer truth)

I understand the appeal of a fast win or the ultimate hack.

At one point, I believed every new framework or trending method would solve the problem. However, most of them made me feel like I was failing harder.

Now? I believe in frameworks that flex. In systems that start with you.

You don’t need to ditch every tactic. You just need to stop assuming someone else’s roadmap will work with your terrain.

When the strategy honors your instincts, it actually sticks.

Try this instead

The next time you feel stuck, ask:

• Am I trying to act before I’m clear?

• Do I need a new tool or a new way of thinking?

• What do I actually want from this outcome?

Then, give yourself space to explore. Research. Rethink. Make a sketch. Ask a question.

You’re not wasting time. You’re navigating with intention.

Taking it forward

I built the chairs. I sat on the porch. The hummingbirds came.

And then, I reflected on the fact that success often feels stagnant and still before you feel the momentum.

Let yourself pause and breathe.

Let clarity be enough to move you forward.

Would you be ready to navigate with more clarity?

If you’re tired of chasing one-size-fits-all strategies and want support finding your way, I can help.

Inside Digital Navigator HQ, get on-demand support that meets you where you are. There is no scheduling or pressure, just real, grounded help that flexes with your energy and goals.

Whether you’re developing your next offer, setting up sustainable systems, or simply getting out of your own head, I’m here to help you move forward.

You've spent years mastering your craft. As your brain accumulates knowledge, it creates shortcuts—big-picture thinking. So, while you're seeing the completed puzzle, the person in front of you struggles to figure out where the corner pieces go.

This gap leads to misunderstanding. Maybe you are speaking jargon they don't get, making your audience feel like they are drowning in minutia and technicalities.

Why You Need to Step into Their Shoes

Effective communication isn't just about being clear; it's about being empathetic. It would help if you met people where they are. You won't be able to break the wall of not understanding without understanding how they are feeling.

Before explaining something, could you take a moment to step into their shoes? What do they already know? What might be confusing to them? Instead of launching into a lecture, ask them questions. See where they're starting from.

My daughter wanted to make my meatballs. I gave her a list of ingredients and a step-by-step guide, assuming she knew what to grab from the store. Days later, she told me they were "okay," but they didn't taste like mine. It turns out that when I told her to buy "meatloaf mix," she thought I meant a spice packet—not a mix of beef, pork, and veal. I had forgotten that they had never done the shopping before.

See how simple questions could have avoided the misunderstanding. "Do you know what meatloaf mix is?" would have made all the difference. Please take a minute to figure out whether they already know the steps.

Making the Complex Simple

Here's another trick: analogies. They're like a secret for breaking down complex ideas when done right.

Think of an analogy as a mental shortcut. It takes something abstract and turns it into something relatable. You're giving your audience something they can understand and connect with what you're trying to teach.

Take the house analogy we often use for web design. I was trying to explain hosting and domain terminology to a potential client, and it was not clicking. I could see it. That's when I knew I needed to give her something familiar.

I switched gears and said, "Think of the houses in your community. Some are single-family and have the space all to themselves, while others are apartments with private and common elements. That helps explain the server space. And regardless of the type of home, each has its unique address; this is the domain." This is where it usually starts to click.

The meatloaf mix example works the same way. Think of the mix like pre-mixed clay—you could make it yourself, but buying it all ready to go is more effortless. Boom. Now, it makes sense.

Analogies are designed to take the unfamiliar and make it familiar. To try to find ones that make sense. It makes explaining concepts that much easier for the other person to grasp.

Don't Assume, Clarify

When we communicate, we often assume people know what we're discussing. But assumptions can lead to disaster. Instead, ask questions to check their understanding. Think of it as laying down stepping stones for a conversation.

The best way to do this is to ask simple, clarifying questions. Before explaining your meatball recipe (or whatever else), ask something like, "Have you ever used meatloaf mix before?" or "What's your experience with this?" This immediately helps you gauge what they know and what they don't.

This shift was huge for me. I used to assume everyone was on the same page. Now, I ask qualifying questions right from the start. And the difference? It gives the conversation a jumping-off point, and it's no longer one-sided.

Why do they suggest you begin an article, video, or audio with a hook or a question? Because it gives context to what they are about to learn.

Embrace Your Own Learning Vulnerabilities

What is the one thing most overlook? Vulnerability. Admitting that you have struggled, too, makes a difference.

You're not just an expert on a pedestal when you show vulnerability. You're human. You've been where they are. You've made mistakes. This opens the door for others to ask questions and engage more fully.

I remember when I first started learning to code. In the first month, I broke my program at least five times. I would crash it, patch it up, and break it again. Admitting that it wasn't a win right off the bat helps others feel less intimidated about making a mistake. It also enables you to understand that fails are part of the process of winning.

When you show your audience that you've been right where they are and that they need to go through the trial and error phase, you create a safe space for learning.

Bringing It All Together

So, how do we overcome the curse of knowledge and communicate better? Here's a quick roadmap:

1. Ask where they're starting: Ask the qualifiers to see what they know before you jump right in.

2. Use simple language: Strip out the jargon. Use the words your audience uses; if you must use technical terms, explain them with analogies.

3. Share your stories: Use relatable stories and metaphors so they can make mental comparisons.

4. Check for understanding: Ask clarifying questions as you go along. This will quickly bring them into the conversation.

5. Share your struggles: Show that you've been where they are. Adding vulnerability allows you to build better connections.

The next time you're trying to explain something, try these steps. You'll be surprised at how much smoother the path to "aha" happens. You (and your audience) will walk away feeling better.

Empowering Your Audience

Ultimately, it's not about how much you know; it's about building the bridge between your skill set and your willingness to learn. It's about getting them near the space you are now in.

So, the next time you need to explain something, remember to meet your people where they are, add some stories, and show a bit of vulnerability. Take them on a journey of discovery to allow them to build alongside you.