That was the whole thing.

Now you have to figure out which remote actually turns the TV on, which one gets you to the right channel or input, and (if you’re in my house) which one runs the sound bar. Three remotes to do one thing: watch something.

I know which remote is which just by the look and the shape of it. That doesn’t stop me from grabbing the wrong one. Constantly.

I mean, if it were up to me you wouldn’t need a remote at all, because the TV would never be on. But that’s not the reality of the house I live in.

Which is why universal remotes exist. Not because I need to understand how they are all wired together in this one remote. I just want to press one button and have it work like it should.

The same thing had been happening with some of the AI processes I was building.

Start the research in ChatGPT. Create the images in Midjourney. Edit and revamp in Claude.

Every one of those is the right tool for that job. I picked them on purpose. But you end up with pieces of the process here, there, and everywhere.

And the friction isn’t that I’m using too many AI tools. It’s that I have to remember where each piece lives and which one I’m supposed to reach for next. Same as the remote basket. I know exactly which one is which, and I’m still standing there holding the wrong one.

The short version: the process now lives in one folder instead of inside any one AI. I change the instructions in one place, and whichever AI I open that morning reads the change. The finished work lands in that same folder, so my dashboard always knows where to look.

I asked for one shared folder and got two AI skills to maintain

The one that “broke the camel’s back” happened in Prepare My Day.

It’s my morning process. What am I actually moving forward today, what needs tending, what happens if there’s room. I wanted to take it out of one AI’s skills and put it into a working folder that Claude, ChatGPT, Codex, or whatever I’m using next could all work from. I said that in the request. Shared by both, or any other AI.

What came back was anything but what I asked for. A folder in Obsidian that held the master copy of the process but it added two more steps:

• Save a packaged copy as a skill in Claude.

• Upload another copy as a skill in ChatGPT.

And from there on: edit the folder, then refresh both installed copies whenever a change matters.

This is not my original ask. I dont understand.

That’s what I typed back. Exactly that, typo and all.

To which I got an explanation wrapped in a recipe analogy. The Obsidian folder is the master recipe. Claude and ChatGPT can’t read the folder on their own so they each need their own directions on their own page. Two one-time setup steps, one per app. Like having two separate recipes in the box. But the ingredients don’t change.

It was a good explanation. Clear in understanding but not exactly what I asked for.

I still don’t understand. I specifically said I don’t want it as a skill that’s installed in each AI because it needs to be AI agnostic, and you’re telling me to save it as a skill.

Because then I have two skills that I have to keep updated if I make any changes.

That was the actual objection. Not the explanation. The arrangement.

And I already had the model I meant sitting right there. Content Lab works from a folder. The WPSS article writing works from a folder. The mentors and the advisors work from a folder. I open the folder, the AI reads what’s in it, and when I change something, I change it once.

I wasn’t confused about how to maintain the copies. I was asking not to have copies to maintain.

Sharing the instructions wasn’t enough. The results needed one place too

So I took the folder to Codex and asked a simpler question. Is this actually set up to work for another model?

Not quite. Everything in the folder was usable. It was just still built to be installed, which was the exact thing I was trying to get rid of. Take that off, don’t put copies anywhere, and the folder becomes the thing every AI works from.

So I typed back three words. fix it please

And that was that. The folder finally became the thing I asked for the first time. One set of instructions, one place to change them, nothing to install anywhere.

Here’s what I hadn’t thought about at all.

Prepare My Day has two halves. The first half is the instructions. How to look at the week, what to weigh, how to land on what actually matters today. The second half is where the answer goes. Every morning that process ends by putting three cards on my Personal Dashboard, a small thing running on my Mac. What I’m moving forward. What needs tending. What happens if there’s room.

I had spent all of this energy on the first half. I never once thought about the second half as part of the thing being shared. It was just where the work ended up.

Then one morning the cards were still sitting on August 4 and it was August 5.

Moving off the skill had broken a small piece of the dashboard. It was reading from the wrong thing. Between me and Codex we found two problems. The local server was down, which explained one of them, and there was a small glitch in the call, which for AI is an easy fix. There was only one place to go looking for either of them, which I didn’t appreciate at the time. Both got sorted. The day got published and I could see the three cards again.

Fine. Done. That’s what I thought.

Then it happened again the next morning.

And this time what came back were two ways to finish it myself. Open Chrome on my Mac and say retry. Or copy a line of code into Terminal and run it.

I’ll paste something into Terminal if I have to. That isn’t the point. The point is that to make it work it needed more manual input steps. Something waiting for me every morning.

The dashboard lives on my Mac at an address only my Mac can reach. A model working in the cloud can read a shared folder just fine. It cannot reach into my machine and set something down there.

Which meant the second half had never been shared at all. It only ever worked because I was sitting at the machine where it lands.

I had shared the instructions. I missed giving the finished work the right place to land.

What an AI-agnostic workflow actually needs

Here’s where my thinking actually changed.

This was never about wanting one AI to do everything. It was about one process. Prepare My Day. I wanted to run it in whichever AI I happened to be sitting in that morning.

Right now it’s Claude. But next week it may be Codex. Next year it might be something that doesn’t exist yet.

The answer was not to give them all their own copies. The answer to the real problem was simplicity and cohesion. Not let’s match copies every time there is a change or adjustment. Because now I have to figure out where are all the places to make those changes. Instead it’s about one place, a single source of truth so that each AI is not quietly doing their own thing.

The two things that have to be shared

What I actually wanted was smaller than that:

• One live place for the instructions. I change them once, and whatever I open that morning reads the change.

• One shared place for the result to land. Whichever AI ran it, the answer goes to the same spot, and my dashboard knows where to look.

That’s the whole ask.

The tools stay different. That’s fine, and that was never the part I was trying to fix. The part I was trying to fix is that there’s one process, and whichever tool I pick should just be able to run it. Picking a different one shouldn’t mean installing something, setting something up, or keeping another copy current.

Finding the glitch in the second part was the icing on the cake. Sure it broke with the first (and second) run but it would have been harder to diagnose and fix if each AI had its own skill.

What the shared folder changed, and what still isn’t automatic

Here’s what my morning looks like now.

I open whichever AI I’m working in. I say prepare my day. It reads the process out of the folder, we go through it, and when I approve the three things, it writes them down in that same folder. The dashboard picks them up on its own. I don’t open Chrome. I don’t paste anything into Terminal. Nothing is waiting for me.

That’s the whole difference.

It took me a minute to believe it, though.

I wasn’t satisfied with taking “it’s working” for the final answer. You need to test, and a few times. Mine was several tests over different checkpoints including running from the cloud instead of the desktop. Then reviewing the actual dashboard to see three cards sitting there on my screen.

Because that was the ultimate pass/fail. Three cards, no blanks.

It’s not an automatic process though. It still needs me to kick it off. But now I choose my AI of choice, connect to the folder and say “prepare my day”. And this was the goal. One process, any AI with the same results.

The prompt to check your own workflow

And now it’s a simple ask for any other process I want to run the same way. Here it is, if you want to point it at yours.

Look at how this workflow is set up. If I change the instructions in one place, will every AI use the updated version, or will I have to update it somewhere else too? Also check where each AI saves the result. Explain anything that is being duplicated and suggest the simplest way for every AI to work from the same folder. Don't change anything until I approve it.

Back to one button: what happens when the tools change

This is one process that I took from scattered to streamlined and I have many others still.

The goal is to take advantage of whichever tech or AI is my tool of choice. Prepare My Day no longer belongs to any one AI. It isn’t sitting inside Claude, or inside Codex. It lives in a folder, and whichever one I open that morning goes and reads it.

Which brings me back to the remotes, because that was the problem I wanted to solve. Not fewer devices. The television, the sound bar, and whatever is back there are all still doing their own separate jobs. I just wanted to press one button and have it work like it should.

Because at the end of the day tech changes. AIs are advancing. The options are increasing. And it’s not which should I choose that is the key decision, but will it break what I have.

And this exercise is where you know something isn’t working, but you can’t quite put your finger on it. For me it was why can’t I use ChatGPT instead of Claude to make this work. For you it may be something else.

I could’ve gone to the store and bought prints. Easy. But I wanted something that was mine. Something I’d put my own blood, sweat, and tears into.

But painting is hard work. It takes time, and it takes talent. So I found my way around it: paint-by-number, with my own flair on top.

At first I felt weird hanging them up. It’s a paint-by-number. What am I doing putting this on my office wall?

Then people saw them, and nobody knew. Everybody assumed I’d painted them from scratch, which was the craziest thing.

There I was, feeling like a painter imposter for taking the easy way, adding my little bit of flair, passing it off as my own art. When that’s exactly what it was. I was just in my own head about it. Hand me and somebody else the same numbered canvas and the two would still come out different. Nobody looking at it ever saw the numbers underneath. They just saw the picture, and either it caught their eye or it didn’t.

The same thing happened when I decided to move my personal website off WordPress. The site is a hub. It points to my two businesses (DigiNav Compass and WP Site Success) and to where I write on Substack. That’s the whole job — one page, three doors.

✳︎ ✳︎ ✳︎

The decision should have taken a week.

It took six months.

Not because the technology was difficult.

Not because the messaging wasn’t ready.

Not because the design was unfinished.

Those were the reasons I kept giving myself, but none of them held up under scrutiny.

I kept telling myself it was the messaging. Then it was the imagery. Then the design. Then whether I should host it on Vercel or Cloudflare. Every time I solved one question, another appeared.

And every time I got close to launching, I’d find another reason to wait.

Something felt wrong.

At least that’s how I described it at the time.

What I know now is that the feeling wasn’t warning me about the project. It was pointing at something I didn’t want to look at.

For eighteen years, I’d been the WordPress person.

I’ve built sites. Maintained sites. Recommended WordPress to clients. Built an entire business around it.

Now I was putting my own website on something that wasn’t WordPress.

That’s what I was resisting. Not the migration. Not GitHub. Not Cloudflare. Not the code.

The story I had about who I was.

The realization didn’t hit until I was decommissioning the WordPress version of the site. Removing the maintenance plugin. Taking it off the server. Closing the chapter.

That’s when I finally understood why it had dragged on for six months.

I wasn’t evaluating a website decision.

I was grieving an identity.

And once I saw that, I knew what to do.

✳︎ ✳︎ ✳︎

If a client came to me stuck like this, I’d start ruling things out. Is it the messaging? The design? The functionality? The audience? What’s actually broken?

So I turned the questions back on myself.

What evidence am I waiting for that I can only get after launch? If someone else showed me this site today, would I tell them to launch it?

What specifically feels unfinished? If I had to launch this Friday, what would I remove from the checklist?

What am I having trouble letting go of? Which parts of the old site represent years of work rather than current value?

Am I stuck because the site isn’t ready, or because launching forces me to admit who I am now?

If you’re stalling on something that should be easy, sit with the last one.

That last question was the one.

The site was ready. I wasn’t. Or more accurately, my feelings hadn’t caught up to a decision I’d already made.

✳︎ ✳︎ ✳︎

Here’s the part nobody puts in the articles or the YouTube videos.

Embrace AI. Vibe-code this. Build an app for that. That’s the easy part. The tools are easier than they’ve ever been. The friction isn’t there anymore. You don’t need permission, you don’t need a developer, you don’t need much of a budget.

What nobody talks about is the part that comes before you touch any of it. The part where you have to come to terms with not doing things the way you’ve always done them. Where the method that built your business isn’t the method that fits this job. Where using the easier tool feels like betraying the harder one you’ve spent years on.

That’s the work. Not the tool. The unlearning of who you were before the tool existed.

And the kicker, for me, was that I’d been telling people this for two years. AI should meet you where you’re at. Match the solution to the need. It’s the line I open conversations with. It’s the line I close them with.

I just hadn’t applied it to myself.

The principle didn’t fail. I almost did, because I was so busy walking the walk for everyone else that I forgot the walk includes me.

✳︎ ✳︎ ✳︎

It made its debut on time. Deadline was set and nothing was going to stop the train from leaving the station.

The site is what I’d pictured. Static HTML, no heavy maintenance, hosted on a server I use regularly, pointing to the places I can be found. A routing page doing the job of a routing page, with my voice and my vibe.

What I didn’t expect was the self-doubt rearing its ugly head for that long. I overlooked the imposter, burn-the-bridges feeling I was sitting with for all those months. If I’d asked myself the hard questions in month one or two, month six would never have rolled around.

And if I’d been my own client, I’d have fired myself for the flippy, floppy indecision. The good news is I gave myself a second chance. The better news is I’ve now got a better diagnostic for the put-this-off, pit-of-my-stomach feeling.

✳︎ ✳︎ ✳︎

If this tension feels familiar, you may want to keep exploring from here.

Related Theme

The Last Mile: The final stretch — where the work is done and the only thing left in the way is you.

Thinking Through Something?

If you’re sitting with a decision, workflow, tool stack, or AI process that technically works but doesn’t feel quite right, I offer limited advisory sessions for solo business owners trying to sort through the noise without adding more complexity.

Think It Through Together →

I’ve never tried any of them.

Who wants to take an ice-cold shower first thing in the morning? Who wants to wake up at 4 or 5 if they don’t have to? But the articles got me thinking about what my morning actually looks like.

I don’t get up with an alarm. Usually 6:15 or 6:30. I work my way into the day. Personal hygiene. First cup of coffee. Brain puzzles — Wordle, the crossword, a few others. Second cup of coffee. Some casual reading — sometimes a Substack, sometimes a newsletter, sometimes a book, depending on the mood. Then the gym.

No email. No client problems. No digging into the day’s productivity.

That part is on purpose. If my day starts chaotic, my whole day is whittled away.

So I protect the quiet before the noise gets in.

✳︎ ✳︎ ✳︎

A method to my madness

That same instinct is what made me notice something was off with the rest of my week.

I’ve been building a lot lately. Daily process. Weekly process. Decisions database. AI is the collaborator on most of it — I lean on Claude the way I’d lean on a smart co-worker who has all my context. The systems are supposed to do for the rest of the day what the morning routine does for the start of it: keep the noise out, surface what matters, let me make the call.

But every single thing I’d built lately had a friction point.

Not one of them. Every one.

Projects were starting and never finishing — sitting on a shelf, not abandoned, just stuck. The kind of stuck where you keep meaning to go back to it and don’t.

My first read was the easy one: I’ve outgrown this.

That was wrong.

But I didn’t know it was wrong yet. What I had was two different systems sending the same kind of static, and the only way I could think to start was to type the static into a chat window and see what came back.

Going outside Claude

My first instinct was to burn one of them down. The experiments database had already been shelved. I hadn’t touched it in weeks. I was ready to add the rest to the pile.

I didn’t.

Instead, I went outside my normal partner. Claude has all my context, which is great most days and a problem on this one. Sometimes you need someone without the history. So I opened ChatGPT, pasted in the instructions I’d written for each of my Claude workflows — the actual prompts that drive what Claude does when I run my daily process or my weekly process — and then pasted in documentation of how my brain operates.

Not personality. Mechanics. The way I produce lists badly and evaluate lists fast. The way storage works fine but retrieval breaks. The way I think differently when I’m given options to react to versus a blank page to fill.

ChatGPT told me the instructions were fighting my flow.

Not the instructions themselves. The instructions, for the way my brain works.

That was the moment the processes changed. And ChatGPT was the partner I worked through the refactors with — the workflow instructions and brain documentation already in the context, different shape of input, different shape of output.

✳︎ ✳︎ ✳︎

The prompts that gave me the diagnosis

Each refactor started with a sentence I typed into ChatGPT. Not a question — a noticing. The kind of sentence you write when you can feel something is off but haven’t decided what to do about it yet.

Daily process.

I started with a simple ask. A question on what I’d noticed, without being specific:

The signal: running the daily rhythm felt like pulling teeth.

The daily was supposed to look at where work actually lives — calendar, client logs, project list, decisions — pull from all of them, and funnel the surfacing into one place where I could make a call. Instead, it was inventing tasks. Asking me what I wanted to do today and then double-checking I had the time and energy to do it.

What’s the point of running this if I’m going to do all the work anyway?

That’s the moment a system stops being collaborative and starts being theater.

The core tension underneath: the system was becoming work instead of supporting the work.

Weekly process.

With the daily process sorted, it was time to tackle the next:

The signal: I was trying to step up a level — from weekly to monthly to quarterly — and the review wasn’t a place to think. It was a place where decisions had already been made.

The weekly was supposed to look at what may actually move the needle, name the growth items, and break them into bite-size chunks for the week ahead. What it was doing was producing a tidy summary that closed loops without leaving room to see anything. By the time I read it, the thinking was over.

The core tension underneath: the review was deciding for me instead of helping me reflect.

A status report, not decision support.

✳︎ ✳︎ ✳︎

Two different leaks. And underneath, the same misread.

Outgrown is not the same as never fit

I’d assumed friction in a system meant I’d outgrown it. The system used to fit, and now it didn’t, so the system had to go.

What was actually happening: I’d never fit any of those systems to me in the first place. I’d built them off what other people were doing, off templates that work for other people’s brains, off whatever the latest article or video or thread suggested. Some of it I was conscious of. Most of it I wasn’t.

The friction wasn’t because I’d outgrown it. It was because I’d never adjusted it to how I think.

The thing is, I’d been watching this same pattern play out somewhere else.

When you feed a model junk context, it gives you junk output. The model isn’t broken. The retrieval isn’t broken. The shape of what you fed it is the problem. The whole conversation drifts because the input was the wrong shape from the start.

I was doing that to myself.

My experiments database was structured like a software change log — every decision, every step, every iteration, every detail. Useful if you’re publishing it. Terrible if you’re trying to reorient yourself a week later. Too much information, too much noise, too much minutia. Junk context.

The system was working exactly as designed. The design was the problem.

The shape of someone else’s template

Stay with me on this part for a minute.

I didn’t sit down one morning and decide to build my daily process on someone else’s template. Nobody does. The templates get absorbed the way background noise gets absorbed. A productivity article here. A YouTube workflow there. A thread that walks through how somebody runs their week. You’re not copying any of it. You’re just exposed to it. Then you sit down to build your own version, and the shape that comes out of you is already half-shaped by what you’ve seen.

The daily was supposed to be mine. But the idea of a daily — what one should do, what it should produce, what it should feel like to run — that came from somewhere else. Same with the weekly. Same with the experiments database. I’d built each of them in response to something I’d read or watched, and I’d done it without noticing the inheritance.

That’s the part I missed the first time.

Friction in a system you built yourself reads like I’ve outgrown this because you assume you knew what you were building. But you were never the only architect. The template was in the room with you. Some of what you built was yours. Some of it was the shape of how everyone else does it. And when the friction shows up, it’s almost always at the seam between the two.

The morning routine works because I built it from nothing. No one handed me a 6:15-coffee-puzzles-gym template. I watched what worked, kept what kept, dropped what didn’t. The reason it doesn’t have friction isn’t that I’m gifted at mornings. It’s that there was no inherited shape to fight.

The workflows had inherited shape everywhere. That’s why every one of them leaked.

Each system has a job to protect

Once I could see the inherited shape for what it was, the refactor got obvious. The morning routine protects quiet before noise gets in. The workflows weren’t protecting anything yet — they were just running.

So I asked the question differently for each one. What is this supposed to protect?

Daily — protects energy and capacity.

Look at the calendar. The client logs. The ticket system. The projects I’m working on in both businesses. And the decisions I’m tracking. Pull from all of those, funnel it into one place, and let me make the call on what’s actually getting done today. The run should help me decide, not hand me a list of made-up tasks. If it feels like one more chore in the day, I’ve built it backwards.

Weekly — protects the growth thread.

What actually moved this week? What were the growth items? What are the bite-size next steps for next week? The weekly is supposed to help me see what happened so I can decide what’s next. If it’s handing me the answers before I’ve had a chance to look, it’s the wrong tool for the job.

The refactors weren’t replacements. Neither one got burned down. I just rebuilt them to work the way I actually work.

✳︎ ✳︎ ✳︎

The surprise

Then the experiments database — the one I’d shelved, the one I was ready to burn — turned out to be the rescue.

I started looking at it through the same question: what is this supposed to protect?

And the answer wasn’t every detail of every experiment.

It was the decision I made, and the context I’d need to make a similar one next time.

It wasn’t an experiments database. It was a decisions database with the wrong sign on the door. What I actually needed was something I could come back to, get my bearings, pick up the context without having to remember every detail. And on top of that, something I could pull from when I’m sharing what worked or what didn’t — in an article, a video, or a conversation with someone trying to sort through the same thing.

Experiments → Decision Records.

The data I’d already captured wasn’t wrong. The frame around it was. That covered the records of what I’d already decided. The companion to it came from a different place.

Over the past few weeks, I’d been writing down the questions I kept asking myself when I got stuck — the ones I couldn’t quite shake. I had ten of them scattered across notebooks, Notion pages, and the back of receipts. How do I know what’s truly next? How do I know what work fits the energy I have today? How do I make decisions when my brain reacts faster than it retrieves? Those became the Decision Playground. A small Notion database where I can pull up the right question for the kind of decision I’m trying to make — what direction to head, what signals I’m noticing, what my capacity actually is, what I’m watching, what I’m reflecting on.

When I get stuck on what’s next, I have somewhere to start. When I open a conversation with AI for help thinking it through, I have the right context already shaped.

The system I was about to delete was the one I needed most.

I just hadn’t called it the right thing yet.

Replace, refactor, or refine

The hardest part wasn’t realizing something was off. It was figuring out what to do about it.

I had three options on the table for every system I touched. So do you, the next time something feels off.

Replace — burn it down, build something new in its place. This is the option I almost took. It’s also the option most people take, because friction feels like failure, and the response to failure is start over.

Refactor — keep the bones, rebuild the way it works underneath. The system was doing the right work, but the shape was wrong. You’re not throwing the work out. You’re asking the system to do its job differently.

Refine — small adjustments inside the existing design. Tighten a prompt. Move a field. Reword a question. The lens is right. The system just needs a tune.

Most of what I read online treats these as the same thing. They’re not. Picking the wrong one costs you weeks.

Here’s how I tell them apart now. You can use the same test.

Replace when the purpose is wrong. Not the structure, not the output — the underlying job the system was built to do. If you’ve outgrown the need the system was built for, replace. Note: this is actually rare. Most things you think you’ve outgrown, you haven’t.

Refactor when the purpose is right but the frame is wrong. The system was built for the right reason, but the way it’s structured is off. The experiments database belongs here — the purpose (capture what I’m doing) was right. The frame (changelog) was wrong. Renaming and restructuring revealed what was already there. No new work to invent.

Refine when the purpose and frame are right but the execution is rough. A prompt that produces almost-right output. A field that asks the wrong question. A step that’s in the wrong order. These are small. You’d know in a session whether the refine worked.

The trap is treating everything like a refine when it needs a refactor — because refine feels efficient and refactor feels expensive. Just one more tweak is the most expensive sentence in a stuck workflow. If you’ve made three refines in a row and the friction is still there, you don’t have an execution problem. You have a frame problem.

The reverse trap is treating everything like a replace because the friction makes you angry. Replace is the option that costs you the most work and is right the least often. If you’re reaching for it, slow down. Ask first if the purpose is genuinely wrong, or if you’re just frustrated with the shape.

The systems I refactored this week looked, at first, like they needed to be replaced. None of them did. Yours probably won’t either.

✳︎ ✳︎ ✳︎

What I’m watching for

The refactored systems are running now. The honest test isn’t whether they made sense on paper — it’s whether they hold under regular use, or whether new friction shows up that signals the next misfit. I’m not assuming this is solved.

Friction in a system is a signal worth paying attention to — not a verdict, but information.

✳︎ ✳︎ ✳︎

If you’re sitting on a shelf

If you have a system, a workflow, a tool, a habit, a planner, a recurring meeting — something you’ve quietly stopped using but haven’t replaced — that shelf is data. Whether it’s a Notion database or a paper notebook, the question is the same.

Try this. The same thing I did for the systems above.

1. Write the noticing as a sentence.

Not a fix. Not a question for AI yet. The shape of something is off and I haven’t decided what to do about it. Mine looked like “this feels like a chore to run” and “there’s so much reference to everything else.” The sentence is the signal that something’s there worth looking at.

2. Ask what it’s actually doing for you — not what the label says it’s for.

The honest answer sometimes means rebuilding the whole thing. My experiments database wasn’t just mis-labeled — it was holding the wrong shape of data for the job it was actually doing. Once I saw it was a decisions database, the structure had to change too: different fields, different way of capturing the entry, different way of retrieving it later.

Other times the label is fine and the system itself needs to do its job differently. Daily rhythm was a fine name, but the system was generating tasks when it was supposed to be helping me decide. Weekly review was a fine name, but the system was wrapping things up when it was supposed to be opening them up so I could see them.

Asking what something’s actually for doesn’t always end in new vocabulary. Sometimes it ends in a full rebuild.

3. Before you rebuild, ask what it’s supposed to protect.

This is the question I missed the first time around. A system that doesn’t protect anything is just busywork. A system that protects the wrong thing leaks where it matters. The morning protects quiet before noise. The daily protects energy and capacity. The weekly protects the growth thread.

If you don’t know what your system is supposed to protect, you’ll rebuild the same misfit with new paint.

✳︎ ✳︎ ✳︎

Whether it’s a morning or a workflow, it comes back to the same thing.

Protect what’s important.

The noise will find its way in either way.

✳︎ ✳︎ ✳︎

If this tension feels familiar, you may want to keep exploring from here.

Related Theme

Built for Someone Else: Building workflows that fit your actual business and energy instead of someone else’s blueprint.

One thing to sit with: What system have you quietly stopped using — and is it actually outgrown, or was it never built for the way you work?

✳︎ ✳︎ ✳︎

Thinking Through Something?

If you’re sitting with a decision, workflow, tool stack, or AI process that technically works but doesn’t feel quite right, I offer limited advisory sessions for solo business owners trying to sort through the noise without adding more complexity.

Think It Through Together →

My Monday morning starts the way most of my days begin: I open the Chief of Staff dashboard to prepare for what’s ahead.

But last Monday, I opened it and something still felt off. I couldn’t put my finger on it. Not broken-off. Not useless-off. Just off.

The more I sat with it, the more I realized — the last couple of weeks I’d been wrestling with a few friction points in my day-to-day operating system. Or, as I like to call it, the Chief of Staff. The rhythms. The weekly commitments. The reworking of the email triage journey, which you can read about in past articles. All of it feeding into the dashboard, helping me make the most of my energy, not just my time.

And I knew something had to give. What it was, I wasn’t quite sure yet.

Part of the process, and to me the best part, is finding the breaks to create the fixes. But these breaks were personal. Harder to see the forest through the trees.

Because the outcome wasn’t just about what would work or cause friction. It was about whether I was willing to show you the messiest parts of the process to get there. The parts that are sometimes the most difficult to put out in public, because you might look at them and say, “Isn’t this what she tells us not to do?”

Short answer: yes. That would be the very thing I’d tell you not to do.

But taking your own advice isn’t always the easiest pill to swallow.

So this past week, I just took a step back. I stopped following all the things I’d been doing. I stopped running the daily rhythm. I didn’t do any weekly commitments because I just needed to clear my mind of where those friction points were. I didn’t stress about whether I needed to check my emails or not. I just lived in the moment and went through the processes.

And that’s when I realized I was still unconsciously following everyone else’s wins and game plan. The piece bringing it all together — the dashboard I’d built — was the piece I was building based on what I’d seen from everyone else.

Hi, I'm Lee. I help solo business owners get clear on AI and automation decisions before they commit — no hype, no hustle, no borrowed playbooks.

New here? Find the room that fits → No Foundation Yet → Lost In Translation → Built For Someone Else → The Last Mile

Subscribe now

Nothing was broken

Nothing was broken. That’s the part that took me the longest to name.

The daily rhythm worked. The weekly commitments worked. The email triage worked. They were all working. They just weren’t working right. Not 100%. Not for me.

The daily rhythm and the weekly commitments are good processes. I rely on them. But I’d built a dashboard on top of them, beautiful, in Vercel, styled exactly how I wanted, to pull it all together in one place.

And every time I made a change to a Notion space to get the information that mattered most, the dashboard broke. Four version reiterations in. I was using AI to bridge the rhythm builder and the weekly commitments and the end-of-day pulse. Adding tools to fix a tool I’d built to look at the tools I already had.

The email triage I’d built with a Google script and Gemini still had friction. I’d written articles about it. I’d shown people how to set it up. But I was still triaging the triage. The labels weren’t applying right, and I knew CoWork (Anthropic’s desktop agent) could automate it further, but I’d been resisting adding another third-party option to the stack.

Two systems that worked. Two systems that weren’t working right.

Pretty or functional

The dashboard moment is where it cracked open.

I was looking at it, and the question landed: was it pretty, or functional?

It was pretty. It was fun to build. It was the thing everyone was building. But every time I made a change to a Notion database to get the information that mattered most, it broke. And I’d have to fix it. To look at it. In a browser. Signed into a Google account.

Or I could just open Notion.

Here’s the part I was overlooking the whole time: the answer was already in Notion. I just couldn’t see it because I was thinking about design aesthetic instead of usefulness. Notion isn’t as visually appealing as a dashboard I build myself in React and Vercel. I’ll give it that. But Notion has changed. It can do most of what I had the dashboard set up to do. Pull from the same sources, hold the same information, show me the same things.

The dashboard wasn’t solving friction. It was adding a layer on top of the thing that already had my information.

I was doing more work to maintain the watching than I was doing the work itself.

I told you to swap blinders for earphones

Friday I wrote about how to stop feeling like an outsider on AI. About swapping blinders for earphones. Vision wide, volume down. Stop letting the noise drive your decisions.

This week I caught myself with the earphones on and still building the wrong thing.

That’s the part I want to name. Because I think we tell ourselves that if we just fix our inputs, read different people, leave the bubble, stop comparing, we’ll naturally stop engineering for what we’re watching.

We won’t.

You can be in the right bubble, reading the right people, asking the right questions, and still build a dashboard because dashboards are what everyone’s building right now. You can have the earphones on and still hear enough through them to start engineering toward what you’re hearing instead of what you need.

Correcting the inputs isn’t the whole job. It’s the first job. There’s a second job underneath it: catching yourself when you’ve stopped walking your own talk.

When tired is telling you something

I want to be honest about how I got to the recognition, because the version where I just stepped back and saw the truth isn’t accurate.

I stepped back partly because the dashboard kept breaking and I was tired of fixing it. I stepped back partly because triaging the triage was wearing me down. I stepped back because I was tired.

The clarity didn’t come from wisdom. It came from fatigue.

And I think that’s important. Because the reader version of this article would be: Lee took a thoughtful pause and recognized her patterns. The real version is: Lee was tired of maintaining things that weren’t working right, and the tiredness made the question loud enough to hear.

The exhaustion is the signal. If you’re tired of maintaining something that isn’t actually broken, that’s data.

That’s not a personal failing. That’s the gap between what you built and what fits.

What I actually decided

The dashboard: I’m going back to Notion. Not because Notion is better. Because Notion is mine. I’ve been using it for years, I know how to work with it, and it doesn’t break when I change it. The Vercel dashboard was a beautiful experiment. It taught me what I needed to know. I’m not going to keep maintaining it just because I built it. The rhythm and the weekly commitments don’t need a layer on top of them. They just need to keep doing what they already do.

The email triage: I added the third-party tool I’d been resisting. CoWork is now running the triage based on what it knows about me, not on a generic Apple script with stringent rules I was working around. The biggest caveat was setting my MacBook to not sleep, which I solved too. It’s been running for a week. It’s working beautifully.

The pattern shows up in the small calls too. I’ve stuck with Midjourney because it nailed my style, even when everyone was touting Gemini, then ChatGPT, then back again. I use ChatGPT for what it does best, not because someone told me to. And I still second-guess every one of those calls. Was I ahead of the curve, or did I just get lucky by not following the latest craze?

I don’t know. I’m not going to know until later, if ever. The point isn’t being right. The point is making the call from inside my own work instead of from inside the watching.

What isn’t broken but isn’t working right

Here’s what I want to leave you with.

What in your work right now isn’t broken, but isn’t working right either?

Sit with that. Don’t fix it. Don’t optimize it. Just notice it. No big AI prompts or processes. Just you and your gut.

What are you maintaining because you built it, not because it fits?

And then: if you stopped using it for a week, really stopped, would you miss it? Or would you finally see what was actually working, and what you’d just been maintaining?

The first time you correct your inputs, you change what you’re listening to. That’s real work and it matters.

But the second time, and there’s always a second time, you catch yourself building toward what you’re listening to, even when what you’re listening to is good.

I don’t know what you’ll find when you sit with this. I’m not going to tell you what to do with it. The point isn’t to follow my call. It’s to make yours.

That’s the work I’m in right now. Out loud. With the earphones on. Still building the wrong thing sometimes. Still recovering in real time.

If this tension feels familiar, you may want to keep exploring from here.

Related Theme

Built For Someone Else: Building workflows that fit your actual business and energy instead of someone else’s blueprint.

Thinking Through Something?

If you’re sitting with a decision, workflow, tool stack, or AI process that technically works but doesn’t feel quite right, I offer limited advisory sessions for solo business owners trying to sort through the noise without adding more complexity.

Think It Through Together →

Sitting down with my morning coffee, it was time to go through the Action folder so I could set my day. But once I opened it, I could feel a new anxiety building.

This wasn’t supposed to happen anymore. I’d spent weeks getting the email triage dialed in — the cadence, the folders, the rules. I’d written about it. Publicly. The inbox was finally clean. I’d stopped compulsively refreshing Gmail to make sure I hadn’t missed something from a client. For the first time in a long time, email wasn’t running me.

But the Action folder was heavy.

A hefty WordPress migration that needed to go on the schedule, sitting above a two-minute yes-or-no for a different client, sitting above three emails I’d been circling for days, sitting above a vendor follow-up I’d promised on Tuesday. All flat. All the same visual weight. No way to tell at a glance what was a quick reply and what was going to eat two hours.

I sat there with my coffee and the familiar voice started up. Is this actually working, or did I just move the mess?

I tried to shake it off and be practical. Google Tasks was right there — same ecosystem, free, one click. I sent a handful of action items over and watched them land as context-free one-liners. No sender. No subject. No link back to the thread they came from. Just “follow up re: site” sitting next to “approve invoice” with nothing to tell me which was which or which mattered more.

They got stuck there. And I could feel the doubt spreading backward — if the Action folder isn’t working, maybe the triage isn’t working. Maybe the article I’d just written was premature. Maybe I’d built another system that looked clean on the surface and fell apart the second real work hit it.

That was the moment. Not the full folder. The fear that the thing I’d just told everyone was working was about to prove me wrong.

Gemini’s First Three Answers Missed

I opened Gemini.

Normally when I’m thinking through a problem, I go to Claude. That’s where I do most of my work. But this problem lived inside Google Workspace — the email, the folders, the triage rules — and I wanted the answer to live there too. Gemini is built into Workspace. If the answer was a script or a Sheet or some other Google-native piece, Gemini was already standing in the right room. So I went there instead.

I started by explaining what I wanted. A way to see what was in the Action folder at a glance. Enough context on each item to know whether it was a two-minute reply or a two-hour task. Nothing heavy. Nothing that added another login or another platform.

Gemini’s first response pointed me at a third-party ticket system.

Then, when I said no, it offered a lightweight project management setup in a separate app. Then a “productivity ticket system” built on top of something I’d never used. Every suggestion pulled me out of Workspace and into someone else’s ecosystem — another login, another subscription, another tool to learn and maintain for what should have been a small fix.

I pushed back. Told it I wasn’t leaving Google Workspace. The whole point of going to Gemini was that the answer should live where the problem lived.

Then it suggested a form.

The logic on paper wasn’t bad — a form clients could submit requests through, feeding a clean intake pipeline. Except my clients have been emailing me for years. Some of them for over a decade. I’m in the middle of rebuilding half my business right now. The last thing I need is to send a note to a long-term client that says “hey, instead of just emailing me like you always have, can you fill out this form.”

I pushed back again. The email isn’t the problem. The email is what’s working. The problem is what happens after the email hits the Action folder.

Eventually Gemini landed on the right neighborhood — what if we built this in a Google Sheet with a script running in the background?

Yes. That.

So I told it to build the spreadsheet.

What came back was a poor man’s version of what I actually needed. The columns were generic. The structure was thin. The drop-downs were missing context that anyone who’d worked an inbox for a week would know needed to be there. It was the kind of output that looks like a solution until you try to use it.

I stopped it. Told it I’ll build the spreadsheet — I just need the thinking behind it. Tell me what columns, tell me why, tell me what should be a drop-down and what should be free text. I’ll do the rest.

That shift was small but it mattered. I stopped letting Gemini execute and started letting it think with me. The columns got sharper. The drop-down logic got specific. When I mentioned that a single email thread often contains three separate asks — the original request, my clarifying question, the client’s reply — it handled it cleanly by numbering each email within the thread so nothing got lost.

But every useful piece of that system came on the other side of me saying no, not that.

Why AI Keeps Giving Generic Answers

Somewhere between the third pushback and the spreadsheet rewrite, it hit me.

Gemini wasn’t failing. I was expecting it to fail well — to read my mind, to know my business, to understand why I didn’t want a form and why I wasn’t leaving Workspace and why Google Tasks wasn’t enough.

It couldn’t know any of that. I hadn’t told it.

Every answer that missed was an answer built on the context I’d given it, which wasn’t much. “Help me organize the Action folder.” That’s not a brief. That’s a wish. With a brief that thin, of course the first swing was a third-party ticket system — that’s what the internet says to do when someone says “I need to organize tasks.” Gemini was reflecting the average answer to the average version of my question.

The work wasn’t in getting Gemini to be smarter. The work was in getting myself to be clearer.

Once I said it out loud — the triage is working, the email is working, the friction is specifically what happens after an email hits the Action folder, I’m not willing to leave Workspace, I’m not willing to ask clients to change how they contact me — the suggestions got smaller and sharper. Not because Gemini got better. Because the question got better.

I wasn’t waiting for a tool smart enough to figure me out. I was the bottleneck.

That’s the piece I keep forgetting and keep relearning. Every time I’ve had a frustrating conversation with an AI, I’ve gone back and looked at what I actually gave it to work with, and nine times out of ten the answer is not much. A vague goal. No constraints named. No mention of what’s already working, what’s already built, what I’d walk through fire to protect and what I’d happily throw away.

The AI can’t infer any of that. It’s not watching me work. It’s not sitting in my inbox. It doesn’t know I’ve been in the middle of rebuilding my business for months and the last thing I have bandwidth for is retraining my clients on how to reach me. It knows what I type.

So the recognition wasn’t about Gemini. It was about me finally seeing that the friction I kept feeling in AI conversations wasn’t the AI — it was the gap between what I knew about my own work and what I was willing to say out loud.

Staying in the Ecosystem That Already Works

Here’s what I used to believe about solving problems with AI: the goal is to find the right tool, then give it the task, then let it build.

That’s not quite right. The goal is to find the tool that lives closest to where the problem actually is, then bring it into your process instead of asking it to invent one for you.

The Action folder problem lived inside Google Workspace. The email, the folders, the triage rules, the clients themselves — all of it was inside Workspace. So the answer needed to stay inside Workspace. Not because I’m loyal to Google. Because every time a solution asks you to leave the room where the problem is happening, you pay a tax. You pay in logins. You pay in subscriptions. You pay in context-switching. You pay in one more place to check, one more system to maintain, one more thing that can break on a Tuesday when you don’t have the energy.

The system you need is the one that fits the process that’s already working. Not the one that replaces it.

Because here’s the other piece — I could have walked this exact problem into Claude Code and built an agent. I could have stood up something in CoWork that watched my inbox and wrote cards to a board. I could have turned an Action-folder problem into a multi-system architecture project and spent the next three weeks getting it just right.

That would have been using somebody else’s system. It would have been me reaching for the most impressive answer instead of the most fitting one. And fitting matters more than impressive. Fitting is what you actually use six months from now.

Staying in Workspace wasn’t a compromise. It was the whole point. The triage already worked there. The clients already lived there. The emails already lived there. Adding a Sheet that talks to Gmail via a small script didn’t add a new system — it extended the one I was already running.

And there’s a quiet bonus waiting at the end of that choice. Everything I’m building in Workspace speaks Google’s API natively. When I’m ready to bring this into the Chief of Staff dashboard I’m building, the data’s already in a format that can be pulled in cleanly. I didn’t have to plan for that. I got it for free by staying in the same neighborhood.

The System: A Sheet, a Script, and What It Actually Does

What I ended up with is almost embarrassingly simple.

A Google Sheet. A script running quietly in the background. That’s it. That’s the whole system.

The Sheet has columns for the things I actually need to see when I look at the Action folder: who’s asking, the subject line (which effectively becomes the ticket name), the priority, the thread number, a link back to the original email, and any links the email itself contained — a Dropbox folder, a Google Doc, a shared asset.

When a thread has multiple back-and-forths, each email in the thread gets its own number, so the context doesn’t collapse into a single flat row. The ask, my clarifying reply, and the client’s response each get their own line.

Drop-downs handle the categories where I was going to type the same thing over and over — priority, status, client. Everything else stays free text so the Sheet doesn’t fight me when a specific email needs a specific note.

The script is what makes it actually work. It watches what hits the Action folder and populates the Sheet in the background. I don’t have to touch it. I don’t have to maintain it. It runs on Google’s infrastructure, inside the same ecosystem where the problem was.

And here’s the quiet payoff I didn’t fully see coming — because every action item is now captured in the Sheet, I can actually archive the email. The folder gets lighter. Nothing gets lost. The ask isn’t waiting in Gmail for me to remember it’s there; it’s already on the list, with context, ready to be worked. The email stops being the holding pen and goes back to being what it was supposed to be — the delivery mechanism.

And because the data lives in a Sheet, I was able to plug it directly into the daily rhythm I run every morning in CoWork. Instead of opening Gmail and scrolling the Action folder to figure out what the day looks like, I open the Sheet view inside my rhythm and see everything at a glance — sorted, prioritized, with context. The Sheet became a feed into a system I was already running, without me having to build any new connective tissue.

The pieces that fit tend to keep fitting. The pieces that don’t, don’t.

What I didn’t end up with matters just as much. I didn’t end up with a ticket system in ClickUp. I didn’t end up with a form for clients to fill out. I didn’t end up with an agent running in the background that I’d have to babysit every time Google changed an API. I didn’t end up with a Notion database that would have been beautiful and unused by month two.

I ended up with the smallest thing that does the job. And the smallest thing that does the job is the thing I’ll still be using a year from now.

None of this is to say the system is finished. It isn’t. I’ll tweak the columns as I notice what I’m actually using and what I’m ignoring. I’ll adjust the drop-downs when I realize a category is too broad or too narrow. I’ll probably find a piece of context I keep wanting that isn’t captured yet, and I’ll add a column for it. That’s how any process improves — the same way you refine an SOP, the same way you tighten up any part of the business.

What the automation piece gives me isn’t a finished product. It gives me a way to remove the friction of sorting and prioritizing so I can actually see what the next refinement should be. The system is version one. The point is that it works now — and because it fits, I can keep making it better without starting over.

The Skill Is the Pushback

All of this started because Gemini tried to send me somewhere else — another platform, another form, another system — and I said no.

The pushback is the part I want you to keep.

Not the spreadsheet. Not the script. Not the Google Workspace ecosystem. Those are mine. Yours might look nothing like this. Yours might live in Notion, in Airtable, in a stack I’ve never used. The specific tools are almost beside the point.

What matters is the posture. The willingness to interrupt the AI’s first answer and say no, not that — and then take the extra minute to explain why. The willingness to stay in the ecosystem that’s already working for you, even when the suggestion is to leave it. The willingness to describe your actual process out loud, including the parts that are messy and the parts you’re not willing to change, so the AI has something real to work with.

Most of the time, the friction I feel in an AI conversation isn’t the AI. It’s that I haven’t made the gap between what I know about my work and what I’m willing to say out loud small enough yet.

So here’s the question I want to leave you with:

When was the last time you pushed back on a solution that was recommended?

Sit with it for a minute. Not to answer it for me. Not to reply. Just to notice.

If this tension feels familiar, you may want to keep exploring from here.

Related Theme

Built For Someone Else: Building workflows that fit your actual business and energy instead of someone else’s blueprint.

Thinking Through Something?

If you’re sitting with a decision, workflow, tool stack, or AI process that technically works but doesn’t feel quite right, I offer limited advisory sessions for solo business owners trying to sort through the noise without adding more complexity.

Think It Through Together →

For years I believed the template was the answer.

Use a structure. Follow the framework. Pick the writers you admire and reverse-engineer how they do it. The advice made sense — consistency, clarity, repeatability. So I built templates. Then I found better templates. Then I borrowed frameworks from writers whose work I admired and mapped my ideas onto their shapes.

And the information wasn’t bad. It was boring and incomplete.

I love to paint but a trained painter I am not. And for years I would use those paint by numbers kits. You know the ones — printed canvas, numbered sections, every color pre-assigned. They even give you brushes. Generic ones, but brushes.

At first it’s frustrating. Staying inside all those tiny little spaces. Then it gets efficient. Then it gets robotic. You’re not being creative — you’re just the person following the numbers.

That’s what the template was doing to my writing process.

The real problem wasn’t that the ideas were bad or the content was weak. It was that my articles were missing the best parts — the lessons, the snafus, the messy parts.

Most writing advice lives at the endpoints. Here’s the problem. Here’s the output. A to D, clean and straight.

Nobody shows you B and C.

What Happened When I Handed AI the Blueprint

Every week I would sit down to “write” the article.

I’d hand AI the brain dump — the build log, the experiment notes, some random thoughts I’d captured through the week. And from that pile of raw material, it would outline and draft the article. Based on the template.

Here’s what I didn’t notice for a while: the information was getting pared down to fit the tidy little spaces. The riffs didn’t make it in. The creative insights got smoothed over. The “oops, here’s where it went sideways and here’s how I adjusted” moments — gone. And the real failures? The ones rooted in my own mindset? Those definitely didn’t survive the template.

It wasn’t robotic. It wasn’t sloppy. You couldn’t look at it and say “an AI wrote this.”

But it was missing the only thing that made it worth reading — the experiences that only someone going through it could articulate. The part where I second-guessed myself at step three. The detour that turned out to matter more than the destination. The small realization that only shows up when you’re in the middle of something messy and paying attention.

The template didn’t know those parts existed. So it left them out.

The Better Template That Still Didn’t Work

So I did what made sense. I went looking for a better template.

I pulled some of my favorite writers. The ones whose articles felt effortless to read, whose structure seemed to carry you forward without you noticing. I asked AI to help me analyze what they were doing and build something better. Maybe it was a flow problem. Maybe the gaps just needed different sections.

Same thing happened.

I’d finish a draft and find myself rewriting large chunks of it. Not because the words were wrong exactly — but because they weren’t landing on the things that actually happened. The real texture of the experiment. What I was actually feeling at step three when it wasn’t working the way I expected. The adjustment I made that wasn’t in any plan but turned out to matter.

The words were there. They just weren’t making the cut.

And that’s when I finally looked at the right problem.

It wasn’t the structure of the template. It wasn’t the writers I was borrowing from. Templates don’t work for the way my creative process works — and more importantly, they don’t have room for the things that happen between step one, step two, and step three. The pivot that only makes sense if you were there. The failure that wasn’t a failure, it was information. The moment where the whole direction shifted because of something small that a template would never think to ask for.

That’s not a gap you can restructure your way out of.

Structure Isn’t a Template — Here’s the Difference

So I ditched the templates.

And then I just sat there.

Because the templates weren’t just a writing problem — they were also my process. Without them I had a pile of raw material and no clear path through it. I still needed to get from the brain dump to a published article without spending three times as long rewriting everything. I still wanted AI in the mix. I just needed it to stop making decisions that weren’t its to make.

That’s when I realized I’d been confusing two things that aren’t the same.

Templates and structure. I’d been using them as interchangeable words for the same idea.

They’re not.

A template tells you what goes where. Section one is this. Section two is that. Hit these beats in this order at roughly this length. It’s a paint by numbers canvas — the decisions are already made before you sit down.

Structure is different. Structure is just a flow of information. A guide, not a cage. You still know where you’re going. You just get to find your own way there.

The messy middle — the detours, the pivots, the things that only make sense because you were in them — those fit inside structure. They never fit inside a template.

And if you’ve ever handed a process over to a framework and wondered why the result didn’t feel like you — you already know what I’m talking about.

You’re Not Doing It Wrong. You’re Using Someone Else’s Process.

For as long as most of us can remember, we’ve been taught to follow the blueprint.

Funnels. Frameworks. Content templates. Launch sequences. There’s a proven path for almost everything in business — and following it is how you get results. Do X, then Y, then Z. Hit these steps in this order. Success is a system.

And for a lot of people, it works. The map gets them where they’re going.

But what about the ones whose minds need to work through things differently? What about the off-roads — the detours that don’t show up on the map but turn out to matter? What about the person who learns by going sideways first, or needs to feel their way through the middle before the beginning makes sense?

The map still gets everyone to the same place, technically.

It just doesn’t account for how some of us actually travel.

And borrowed confidence — following someone else’s proven path — looks exactly like best practice right up until the moment you notice what it cost you to get there.

How to Know When a Template Is Working Against You

So how do you know when a template is working for you — and when it’s working against you?

Start here. These aren’t a framework. They’re just honest questions worth sitting with (and a few simple one-line prompts) to help you think it through.

Does finishing the draft feel like something you would say or do? If it’s not reflecting the whole story, you need to ask yourself why it feels off and if it helps or confuses the audience.

Are you rewriting large sections after the draft is done? Not polishing. Rewriting. If you’re regularly putting back parts that got cut to fit the template, the template is editing your voice. And your audience will see that.

Does the output sound like you — or like a version of you that cleaned everything up? There’s a difference between clear and sanitized. If you read the draft out loud and it doesn’t feel like you, chances are it’s not.

If any of those land, you’re not doing it wrong. You’re just working with a tool that was built for someone else’s process.

The next step isn’t finding a better template. It’s figuring out what structure actually fits how your mind works — and that looks different for everyone.

My brain has always run at full speed. Some people call it ADHD tendencies. I prefer to think of it as superdrive.

For as long as I can remember, someone was telling me to focus, slow down, do one thing at a time. Teachers. Managers. Myself, on a good day.

Now I use AI daily, and honestly? It can be just as scattered. There’s no one to rein me in when a session goes sideways — when I’ve asked four different questions, chased three tangents, and somehow ended up somewhere completely unrelated to where I started.

Until I built myself a mirror.

It started with an article from Mia at . Her framework is smart — she breaks down what’s actually hiding inside every AI session and makes a compelling case that most of us save the wrong thing. We file the polished draft and lose the moment our thinking actually shifted.

She’s right. But I was sitting here building something slightly different, and I think it’s worth naming why.

Mia’s framework asks: what did the session produce worth keeping?

The thing I kept bumping into was a different question: was I clear, honest, and focused going in?

Those are not the same problem.

I spent a session this week designing a debrief process. It started as “let me capture AI breakthroughs” and wandered through Mia’s hierarchy, through knowledge systems, through Obsidian structures — until I stopped and said out loud: we’re thinking about this all wrong.

What I actually wanted wasn’t a knowledge capture system. It was a mirror.

Something that would show me, at the end of a thinking session, how I showed up. Did I have too many asks going at once? Did I drift off on a tangent that went nowhere useful? Was I actually thinking something through — or was I using the conversation to avoid deciding?

That’s not a breakthrough journal. That’s a coaching log.

Here’s the distinction that crystallized for me:

Mia’s framework is output-oriented — it helps you extract what the session produced.

What I built is input-oriented — it helps me evaluate how I used the session.

Both matter. They’re just solving different problems.

The output framework catches the breakthrough after it happens. The input framework catches the bad habit before it becomes a pattern. And for those of us who use AI daily as a thinking partner, the input side is where a lot of invisible time gets lost — not to bad tools, but to unfocused sessions, validation loops, and scope creep that looks like productivity.

The debrief I landed on is simple. At the end of a general thinking session, Claude observes five things: how focused the session was, whether tangents were useful or distracting, whether I was thinking or seeking validation, whether it reached a real conclusion, and whether the complexity matched the actual size of the problem.

Then I react. Then we write one or two sentences — the honest version — and I log it in Obsidian.

No elaborate capture system. No tagging taxonomy. Just a running record of how I think, so the patterns can eventually show themselves.

I won’t know what my patterns are for a few weeks. That’s kind of the point.

If you’re a daily AI user, you probably already have some version of Mia’s problem — great sessions that evaporate because you didn’t catch what shifted. Her debrief prompt is worth using.

But if you’ve also had that feeling of closing a tab and realizing you can’t quite account for the last 45 minutes — that’s the other side of the same issue. Not what you failed to save. How you showed up in the first place.

That’s worth paying attention to too.

If this resonates, here’s a short prompt to start your own end-of-session habit:

“Look back at this conversation and tell me: how focused was I, did I go on any tangents, and was I actually thinking or just seeking validation?”

Paste it at the end of any session that felt a little sideways. See what comes back.

And if you’re finding your AI sessions are doing more wandering than working, that’s exactly what I help with. Book a session today.

P.S. If you haven't read Mia Kiraki's original piece on catching AI breakthroughs, it's worth your time. Her framework is what sparked this one. Read it here.

If you missed the first two parts of this series, here’s the short version: I built a Google Apps Script to triage my inbox into three folders — Action Items, Read Later, and Noise — so I could stop treating email sorting like a productivity win and start dealing with the thing underneath it: the compulsive checking, the constant context switching. Part one covers the concept. Part two covers the build. This one is about what happened during testing — and what I kept getting wrong.

The script was running. Emails were moving. And I was still opening my inbox every hour or so to check on it.

Not to take action. Not because something felt urgent. Just to watch. To make sure it was doing what I told it to do.

That’s the moment I should have caught myself. I’d handed off the job — and then immediately started looking over its shoulder.

When Two Tools Are Running and Neither Is Enough

When the script wasn’t sorting things right, my first instinct was to run the same instructions through CoWork and see if it could do better. It could, in a way. CoWork read context well. It pulled from my Stripe customer list, identified who actually needed a response, and — this was the part that surprised me — it could explain why it was categorizing something the way it was.

But it couldn’t label. Couldn’t archive. Couldn’t do the actual mechanical job the script was built to do.

So for a stretch, I had both running. CoWork doing the reasoning. Google Script doing the moving. Two tools covering for each other’s gaps.

That’s not a solution. That’s a workaround.

And it told me something: the script wasn’t the problem. The instructions were.

The Brief Was the Problem, Not the Script

I’ve been hired as a consultant with ambiguous instructions. More than once.

It doesn’t just frustrate you — it makes it impossible to do the job well. You deliver something, and it’s wrong, but not because you’re bad at the work. The brief was bad. You built exactly what you were asked to build. It just wasn’t what they actually needed.

That’s what I did to my script.

I gave it instructions that were clear enough to get started but not specific enough to get it right.

When emails landed in the wrong folder, my instinct was to pull everything back and handle it myself. What I should have done was look at the instructions and figure out where they weren’t clear enough.

The other side of that analogy matters too. When you hire someone — or something — for their expertise, you have to trust that the expertise can do the work. Hovering doesn’t improve the output. It just signals that you didn’t actually hand off the job.

What I Actually Fixed

So I stopped looking at what the script was doing and started looking at what I’d told it to do.

I took CoWork’s reasoning — how it was categorizing, why it was making the calls it made — and fed that back into Gemini alongside the current script. Here’s what this tool understands about context. Here’s what it’s getting right. Now fix the script to match.

I added the Stripe customer list so the script had the context it was missing. Names and email addresses it could recognize, not just patterns it was guessing at.

I dropped the hourly recap entirely. It felt like a safety net — proof the system was working — but it was just noise. Subject lines and folder names with no explanation of the decision behind them. Once the script had better instructions, I didn’t need a report. I needed to trust the output.

And I changed the frequency. Every hour was recreating the exact problem I was trying to solve — constant interruption, constant context switching, just automated instead of manual. Four times a day:

• 8:00 am

• 12:00 pm

• 4:00 pm

• 9:00 pm

Enough to stay current. Not enough to give myself permission to check in between.

Before You Check the Output, Check the Instructions

The script is still running. Still working through the occasional sorting quirk. Triggers needed resetting at one point — a minor fix, easy to solve, and Gemini walked me through it clearly enough that someone with no coding experience could have handled it too.

But it’s working. Not because I found a better tool. Because I finally gave the tool I had instructions good enough to succeed.

Before you check whether the automation is working, check your gut — and check the instructions. Were they clear enough for the agent to actually do what you needed? If the output is wrong, that’s the first place to look. Not the inbox. Not the tool. The brief.

It’s the same question worth asking before you automate anything: have you defined the job clearly enough for someone else to do it?

Think about it the same way you would hiring a consultant or a contractor. You bring them in for their expertise. You give them the direction. And then you trust them to do the work — because hovering over their shoulder doesn’t make the output better. It just means you never actually handed off the job.

Your automation works the same way. Give it clear enough instructions, then let it run. If you haven’t, no tool is going to fix that for you.

If you’re working through something similar — an automation that’s half-working, instructions that aren’t landing, or just the general discomfort of letting a system do something you’ve always done yourself — that’s exactly the kind of decision DigiNav is built to help you think through. Start here.

Habits are hard to break. Whether it’s over-checking your email inbox or overindulging in your favorite dessert, it’s something you know isn’t doing you any good but you do it anyway.

I’ve been building a Chief of Staff dashboard for the past few weeks — using AI to pull information into one location so I can concentrate on what needs my attention.

The goal was to not have 10+ tabs open trying to figure out where that one piece of information is or was. I’m making progress, but the email section was the weak link.

Three boxes showing unread counts — inbox, WPSS, read later — and a link to go triage, which was basically a link right to the main inbox. Displayed as just numbers. No intelligence behind them.

I could see how much was waiting. I couldn’t see what kind of waiting. Action items looked the same as plugin update notifications. A client question sat next to a Substack digest.

To actually do anything useful, I still had to open Gmail and sort through everything myself. Which meant I was checking email to figure out if I needed to check email.

That’s the problem I needed to solve before the dashboard could do its job.

Before the Script: Cleaning Up 18 Years of Gmail Labels

It didn’t just start with an automation of my inbox. I had to start with the folder system that was 18 years in the making. 50+ Gmail labels accumulated over many years of running a WordPress agency and building a consulting business. All part of the chaos.

There were emails from clients who hadn’t been active in years. Others were duplicates with slightly different names. A few were things I couldn’t even remember creating, and some folders had zero messages in them.

You can’t automate a mess. If a script is going to sort emails into useful buckets, those buckets need to exist first and they need to make sense.

Knowing that I would be overwhelmed trying to organize all of that folder mess, I went to Claude AI and asked it to help me make heads or tails of the folder structure and how I could streamline it. I also took into account that now, with AI, it’s easier to find emails just by asking the AI to sort for you or by using the search function in Workspace.

And here’s where the reorganization ended:

• WPSS/ — agency wind-down, all client-related threads in one place

• DigiNav/ — consulting, content, audience conversations

• Life/ — personal, receipts, subscriptions, tax stuff

• Utility labels (underscore-prefixed so they sort to the top of the sidebar):

  • _Action Item — needs a response or decision

  • _Read Later — worth reading when there’s time

  • _Processed — the script’s audit trail

This is the non-glamorous work that people don’t talk about. It took a full session with Claude to sort through the chaos. But the upside was that it only took a few hours of conversation, as opposed to weeks of trying to figure out what was where and how to reorganize it.

Why I Used Gemini and Google Apps Script

So I moved the conversation from Claude to Gemini. The AI piece — sorting emails by judgment, not just pattern matching — wasn’t going to happen with Gmail filters or manual checking. But making that sorting automatic wasn’t clear until I started working inside Google’s ecosystem.

The reason for Gemini was simple: it lives inside Google Workspace. And there were some non-negotiables I wanted to make part of the process:

• Read Gmail natively

• Write a script that would automatically trigger

• Set those triggers to be time-based

• Not add another app that wasn’t already in the flow of tools I use

Gemini suggested the Apps Script approach. A script that runs on a timer, reads unread emails, uses AI to classify them, and applies the right labels. I set it to run every hour.

From there, the script would sort emails into three buckets:

• Action Items — anything that needs a response or a human decision

• Read Later — content worth reading when I have time

• Noise — notifications, plugin updates, form submissions, system alerts with zero human attention value

And the best part — Gemini correctly wrote the script based on best practices. It also gave me step-by-step instructions to not only install the script but to run the tests. I already knew how to do that, but if that’s not something you’re familiar with, Gemini can walk you through the whole process too.

Testing the Email Triage Script

The first test run put everything into Action Items. Every email. The rules weren’t specific enough about what counted as noise or read-later, so the script defaulted to the safest bucket. If you don’t tell AI what noise looks like, it assumes everything matters.

So I tightened the rules. Got very specific about what counts as noise:

• WordPress plugin update notifications

• Automated form submissions

• System alerts with no required action

And what counts as read-later:

• Newsletters and articles

• Informational updates with no response needed

The pendulum swung the other way. Everything landed in Read Later. Noise got a few scraps. Action Items was nearly empty.

Then there was the archiving problem. The script was archiving emails before the labels fully applied. Emails were disappearing — no inbox, no folder, just buried in Gmail’s archive. The fix was the same one from my earlier manual triage: label first, pause, then archive.

The _Processed folder became the safety net I didn’t know I needed. Every email that went through the script got tagged. When the counts didn’t add up or a category felt light, I could open that folder and see exactly what the script had done. It wasn’t just a label — it was the audit trail that let me refine the rules without losing anything and without reverting to checking the inbox myself.

The Anxiety of Letting Go

The system was working. The rules were dialed in. Emails were sorting into the right buckets every hour. And I still felt anxious about it.

The inbox was nearly empty, and my brain read that as something’s broken.

It wasn’t. It was working. The script was processing every hour, which meant email never had a chance to pile up the way it did when I was checking three or four times a day.

I was so used to seeing a wall of unread messages — and sorting through it as a kind of productivity ritual — that an empty inbox felt like a system failure.

I was getting in my own way. I’d second-guess how the script sorted things because I wasn’t the one making the call. I’d peek at the inbox to see if something got missed.

The whole behavior I was trying to automate away, I was recreating in a different form.

After a few more test runs, I looked at the Processed folder, confirmed the sorting was accurate, and made a conscious decision: stop opening the inbox. Go to the folders. Work from there.

That sounds simple. It was the hardest part of the entire build.

What the Email Triage Dashboard Looks Like Now

With the triage script running and the folder structure in place, the Today tab on my dashboard finally had what it needed.

Before: Generic unread counts. How much is piling up.

Now: Three intentional boxes:

• Action Items (red) — what needs a response

• Read Later (blue) — what’s worth reading when I have time

• Substack (purple) — engagement and reading, on its own schedule

Each box links directly to the Gmail label view. I go to the bucket that matches the energy and time I have.

Fifteen minutes between tasks? Check Action Items, knock out quick replies. Slower afternoon? Open Read Later and catch up on content. Ready to engage? Head to Substack and spend time on the conversations that matter.

The email section went from the weakest part of the dashboard to the piece that makes the rest of it work. Because now I’m not spending the first twenty minutes of my day sorting. I’m spending it deciding what to act on.

And with the triage running, the obvious next question was whether AI should handle the responses too.

The Line I Chose to Keep

I considered having AI draft responses. That’s the natural next step, right? Triage the email, then generate a reply so all you do is review and send.

I pulled back. Not because I think there’s anything wrong with it — plenty of people use AI for email drafting and it works for them.

But for the way my brain operates, I need to be fully present in the ask. When someone emails me a question, I need to read it, understand the context, figure out whether it’s technical or logistical or relational. That’s where I serve my clients and colleagues. If AI drafts the response, I’m reviewing words instead of understanding the need.

The triage handles sorting. The responding stays human.

That’s not a limitation of the system. It’s a design decision about where AI helps and where I need to stay in the loop.

What Automating Email Triage Actually Taught Me

Making the most of the tools that were already in my ecosystem was the gold of this whole experiment. Google Workspace, Gemini, and Apps Script were all sitting there waiting to just be connected and used. I didn’t need a new platform or another paid automation tool or the added expense of another AI platform.

But really the tools were secondary. Before any of that mattered, I had to organize what I was automating. 18 years of folders and labels wasn’t a system. It was sediment. Cleaning that up was the unglamorous foundation that made everything else possible.

And through all of this, the hardest part wasn’t the technical build. It was the behavioral changes:

• Trusting the system

• Trusting it enough to stop checking email

• Recognizing that an empty inbox means the automation is working, not that something’s broken

• Knowing where to draw the line between what AI handles and what stays mine

The script is still in testing mode. I need to give it time to work out any of the other kinks. I’m letting it run and watching how it’s sorting and adjusting based on the edge cases that come up. That’s how it should work. Not a launch-and-forget deployment, but building trust — with the system and with myself.

If you’re thinking about automating email triage, start here:

1. Figure out your buckets. What are the three folders that would cover 90% of your inbox?

2. Clean up the mess first. You can’t automate labels that don’t make sense.

3. Use what you already have. If you’re in Google’s ecosystem, the tools are already there.

4. Give yourself permission to feel uncomfortable. An empty inbox will feel wrong at first. That’s the system working, not failing.

The script is the easy part. Changing how you interact with your inbox is the real work.

This is part of an ongoing series documenting the build of a Chief of Staff dashboard — a personal command center for managing two businesses. The email triage was the missing piece that unlocked the Today tab.

Previous in this series:

What are the three folders that would cover 90% of your inbox? Reply and tell me — I’m curious how different they are from mine.

I was halfway through an article about Claude Code when I caught myself nodding along to advice about git workflows and terminal commands. Things that have nothing to do with how I actually use AI day-to-day.

Not because the developer stuff was interesting. Because buried underneath all of it was something I’d been wrestling with in my own work. The why behind AI going sideways on me.

This week, I read two genuinely excellent articles. Both about Claude Code, which is a developer tool that lets programmers use Claude directly from their terminal instead of the chat interface most of us use. One is even trying to bridge the gap for non-developers. But even that one assumes you’re writing code, managing files, and running commands.

The ideas underneath all of that? They’re not about code at all. They’re about how to work with AI better. And they apply whether you’re a developer or a business owner typing into Claude’s chat window.

So I dug them out. Here’s what I found.

(The articles, if you want the originals: Practice Makes Claude Perfect by Julia Diez, and Claude Code Skills, Commands, Hooks & Agents Guide by Dheeraj Sharma. Both worth reading if you’re technically inclined.)

It’s not a magic box. It’s a contractor.

Julia Diez opens with a reframe that I keep coming back to: Claude isn’t an assistant. It’s “a brilliant contractor who has no memory between work sessions and can only hold a certain number of things in their head at once.”

“A brilliant contractor who has no memory between work sessions and can only hold a certain number of things in their head at once.”

— Julia Diez

In the developer world, this means creating special files that brief Claude Code on the project before every session. Developers literally write a briefing document that loads automatically so Claude knows what it’s working on, what matters, and what the rules are.

You and I don’t have that automatic setup. But we need the same habit.

Why does AI keep missing the mark even when you’ve used it for months? You’re not briefing each session. Yes, Claude has memory now, and it might remember your name and some preferences.

But that’s not the same thing.

Memory is like knowing your contractor’s phone number. A briefing is sitting down with them Monday morning and saying: here’s what we’re working on this week, here’s what matters, here’s what done looks like.

Why does it drift on longer tasks? You handed over a big job without scoping it. Why do results get worse the longer a conversation goes? The job site got cluttered, and nobody cleaned it up.

I’ve done every one of those things. Still do, when I’m rushing.

The developer fix is a special file. Your fix is simpler: at the start of any significant AI task, take thirty seconds to tell Claude what you’re working on, what matters, what the constraints are, and what “done” looks like. Not a novel. A few sentences of context. The kind of thing you’d tell a smart freelancer on day one.

More instructions actually make AI worse.

This one surprised me.

Developers spend a lot of time writing rules and instructions for Claude Code to follow. Sharma’s article gets into the specifics of how to organize them, where to put them, what format to use. But the insight underneath all that structure is simple and it applies to everyone:

If you’ve ever given AI a detailed set of instructions and watched it nail the first few tasks but get progressively sloppier, there’s a reason. AI can only hold so many rules in its head at once. Add too many and quality doesn’t just drop on the extra ones. It drops across all of them.

Developers discovered this the hard way. They’d write hundreds of lines of instructions and wonder why Claude started ignoring the important ones. The fix was cutting back to only what actually mattered for the task at hand.

Same thing applies when you’re setting up a Claude Project or writing a system prompt. Every vague, redundant, or low-priority instruction isn’t just noise. It’s competing with the things that actually matter.

I’ve been guilty of this. Long system prompts full of “nice to have” preferences that I never pruned. If you’ve noticed your detailed instructions working less well over time, this might be why. Short, specific, high-stakes rules outperform long lists of preferences every time.

Plan before you produce.

Julie writes about a Claude Code feature called “plan mode” that forces Claude to map out its approach before it writes any code. Developers use it because building the wrong thing wastes hours.

You don’t need plan mode. You just need to ask.

Her prompt translates directly: “Before you start, walk me through your approach and flag any assumptions you’re making.”

I’ve started using this in almost every session. The reason it matters isn’t technical. AI, like most of us, defaults to action over thinking. Give it a task and it starts producing. That feels like progress. Often it isn’t.

When you ask AI to plan first, you get two things. It thinks through what it’s about to do. And you get a chance to catch misunderstandings before they become a finished draft heading in the wrong direction.

Diez puts it simply: changing direction during planning costs seconds. Changing direction after the fact costs everything.

Worth trying once before you dismiss it. Next time you have a real AI task, start with “before you begin, walk me through how you’d approach this.” See what comes back. Redirect if needed. Then let it go.

One conversation shouldn’t do everything.

Both articles land in the same place: a general AI loaded up with everything you’ve ever needed performs worse than a focused AI given only what it needs for the task at hand.

Developers solve this by building separate configurations for different types of work. They create specialized setups that load only the rules and context relevant to a specific job.

For the rest of us, it’s simpler than that. Stop asking one conversation to do everything.

I see this with my own work. I’ll start a session doing email drafts, pivot to client research, then ask for a proposal outline. All in the same thread. And then wonder why the proposal feels off.

The fix is almost boring. Start fresh conversations for different kinds of work. If you use Claude Projects, give different types of work their own project instead of loading one up with everything.

Smaller scope, sharper results. That’s it.

What I’m actually taking away

The problems both articles tackle are ones you’ve probably had too. AI that forgets, drifts, underperforms, and goes sideways. Developers just got to the solutions first because their tools forced them to think about it.

Brief it like a contractor. Keep your instructions tight. Ask it to plan before it produces. Stop asking one conversation to hold everything.

Not a technology problem. A workflow problem. And it’s one you can start fixing today.

If any of this shifted how you’re thinking about your own AI use, I’d love to hear what clicked. Hit reply and tell me.

DigiNav Compass is for business owners navigating AI decisions on their own terms. If this helped, forward it to someone who’s been frustrated with their AI results lately.

Inspired by information in: Practice Makes Claude Perfect by and Claude Code Skills, Commands, Hooks & Agents Guide by

Five Tabs, Three Failed Dashboards, and One Decision

I had five tabs open every morning. Gmail for personal. Gmail for the business. Google Calendar. Google Tasks. And a Notion dashboard I’d built three different times — each version more organized than the last, each one quietly abandoned within weeks.

The data organization in Notion was solid. I’d give it that. But the UI never worked for me, and “organized” doesn’t matter if you stop opening it. Some days it was a forgotten wasteland.

Meanwhile, the real work — triaging two inboxes, checking what’s on the calendar, figuring out what actually matters today — was scattered across tabs I had to manually stitch together every morning. That daily stitching was bogging me down and stressing me out.

Before: five tabs, Notion ignored.
After: one dashboard, one rhythm.

I didn’t need another productivity system. I’d tried that. What I needed was something tailored. Built around how I actually work, pulling from the tools I was already using, structured around my energy and my priorities. Not someone else’s template.

So I built it. Using Claude, Claude Code, and Cursor, I built an AI Chief of Staff dashboard that does what no off-the-shelf tool could: sees everything in one place and helps me structure my day around it.

I’m a developer. I could have mapped this out the traditional way — architecture docs, wireframes, weeks of planning before writing a line of code. But that’s exactly the cycle I wanted to break.

What an AI Productivity Dashboard Actually Does

It connects to the tools I’m already using — two Google Workspace accounts, Google Tasks, Google Drive and eventually Notion — and pulls everything into one screen. Email counts from three sources. Today’s calendar. Tasks. Brain dump notes I’ve captured throughout the day.

Then the AI does the part I used to do manually: it builds my rhythm.

“Build My Rhythm” looks at all of that context — commitments, emails, tasks, my top five priorities for the week, appointments, brain dump notations. Then it generates time-blocked working sessions for the day. Not a task list. Not a project plan. Rhythm blocks. Each one has a purpose, a start time, and an end time. Mode-based, not checklist-based.

Think of it like a chief of staff who reviewed your calendar, scanned your inboxes, checked your priorities and handed you a structured day before your first cup of coffee. Except it costs pennies a day and runs on Claude’s API (an API is just a way for one app to talk to another — in this case, the dashboard asks Claude to think through your day and send back the plan).

The goal wasn’t another task list that would fade away. It was to use my best work times and workflows to structure my day.

Why Generic Productivity Tools Keep Failing

Here’s the pattern I keep seeing — in my own attempts and in conversations with other creators.

You find a tool that’s almost right. Notion’s data organization is genuinely good. Google Workspace handles email and calendar well enough. So you try to make them work together.

You build a Notion dashboard. You set up filters. You create views and databases. And for a while, it feels like progress.

Then you stop opening it.

Not because the system was bad. Because it wasn’t yours. It was someone else’s structure, with your data poured into it. The friction was just high enough that on a busy morning, you’d skip it. And once you skip it twice, it’s over.

My friend hit the same wall. She liked Notion’s organization — same as me — but not the UI or the usability. Someone else’s system almost worked. So she built her own dashboard to solve it.

That’s the part most people miss. The problem isn’t discipline. It’s fit. Generic tools assume a single inbox, a single calendar, and a single way of working. I have two email accounts, newsletter folders, weekly priorities that live in a different system and brain dumps that need to feed into how I plan my day. No off-the-shelf tool handles that — because it wasn’t designed for my workflow.

The problem isn’t discipline. It’s fit.

How I Built a Custom AI Dashboard in Days

I didn’t follow a roadmap. I followed a pattern that kept repeating: figure out what I need, keep what’s already working, and let AI handle the parts I don’t want to spend weeks on.

Step 1: Define what your day actually needs.

Before I touched any code, I mapped out what was stressing me out. Three email sources that needed triaging every morning. A task list of must-dos. The five things I want to accomplish each week to move my business forward. My calendar commitments. And a place to capture ideas throughout the day without breaking flow.

That’s it. Not a feature list — a friction list. What’s slowing me down? What am I forgetting to check? What keeps falling through the cracks?

Step 2: Keep what works. Replace what doesn’t.

Google Workspace was working: email, tasks, docs, calendar. I wasn’t going to replace those. Notion’s data organization was working. I wasn’t going to abandon that either. What wasn’t working was the layer on top: the thing that pulls it all together and makes it usable.

So the dashboard became a lens, not a replacement. It connects to Google’s APIs and shows me unread counts across all three email sources with “Triage →” links that open the right Gmail label. It pulls calendar events from both accounts. It reads my tasks.

Quick Capture writes brain dumps straight to Google Drive with auto date headers and a “Captured Today” count.

The tools stay. The view changes.

Step 3: Let AI build it — and design it.

This is where it got interesting. I saw Kim Doyal’s dashboard and loved the layout— clean and easy to navigate. That was my missing visual reference. So I uploaded a screenshot to Claude and asked it to help me write the proper prompt for how it should be coded.

Claude handled the reasoning and planning. Claude Code wrote the application code. Cursor kept everything in one workspace while I worked. The Claude API powers the daily rhythm generation: “Build My Rhythm” sends all my dashboard data to Claude and returns a structured day, color-coded by category.

Here’s what it actually took: a code editor, a hosting platform, and API access. That’s the infrastructure. The thinking is the part only you can do. What do I need? What’s already working? What should the day look like?

The AI handles the technical translation. You bring clarity to your own workflow.

I went from concept to a working dashboard in days, not weeks. Not because I skipped the hard parts — because the hard part was knowing what I needed. And I already knew that.

Tailored means yours. Your dashboard won’t look like Kim’s or mine. It shouldn’t.

What Building Your Own Dashboard Actually Takes

If you’ve ever written a brief for a contractor — “here’s what I need, here’s how I work, here’s what matters” — you have the skills this takes.

Building a tailored dashboard isn’t a coding exercise. It’s a clarity exercise. Once you know what you need — your inputs, your workflow, your priorities — AI walks you through the build. Step by step. Clear instructions. Each piece connects to the next. Think of it less like programming and more like following an SOP that gets written for you as you go.

Claude, Claude Code and Cursor handle the technical translation. You follow the steps.

What they can’t do is tell you what your morning needs to look like. They can’t decide that you need to triage three email sources before your first creative block. They can’t know that your best thinking happens before noon, or that your weekly priorities need to be visible while you plan your day.

That’s the work. And it’s work you’ve already done — you just haven’t written it down in a way that becomes a system.

The scary part isn’t the technology. The scary part is admitting that the tools you’ve been using aren’t working and committing to something built around how you actually operate. Once you make that decision, the build is the easy part.

Key Takeaways

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

1. The problem isn’t discipline — it’s fit. If your productivity system keeps becoming a forgotten wasteland, it’s not because you’re lazy. It’s because it wasn’t designed around how you actually work.

2. Start with your friction list, not a feature list. What’s slowing you down? What are you forgetting to check? What keeps falling through the cracks? That’s your blueprint.

3. Keep what works. Replace what doesn’t. You don’t need to abandon Google Workspace or Notion. You need a better layer on top — a lens that pulls it all together.

4. AI makes the build accessible — but only you can define the need. The technical parts are handled. The hard part is knowing what your morning, your workflow, and your priorities actually require.

5. Tailored isn’t one-and-done. Your solution keeps evolving because your work does. Phase 1 ships. Phase 2 fixes and automates. The system grows with you.

The Cost of Staying Scattered

Here’s what staying in the cobbled-together setup actually costs you.

Every morning you spend stitching tabs together is a morning you’re not doing the work that moves things forward. Five minutes here, ten minutes there — checking this inbox, switching to that calendar, opening a Notion page you haven’t touched in a week. It adds up.

Not just in time, but in mental load. By the time you’ve assembled the picture of your day, you’ve already burned through your best energy figuring out what to do instead of doing it.

And every system you’ve abandoned? That wasn’t a failure of discipline. That was a signal. The tool didn’t fit, so you moved on rather than forcing it. The problem is that “moving on” usually means moving to another generic option that will hit the same wall.

That’s the real cost. Not the wasted setup time.

The slow bleed of mornings that never quite start right. The weekly priorities that drift because they weren’t visible when you were planning. The brain dump ideas that never fed back into your rhythm because they lived in a different tool.

You already know what you need. The question is whether you keep adapting to tools that weren’t built for you — or build something that was.

Start With Your Friction List

When nothing fits, build it.

That’s not a slogan. It’s what I did when three versions of Notion dashboards failed. It’s what Kim did when she hit the same wall. And it’s what the tools — Claude, Claude Code, Cursor — are making possible for anyone willing to start with one question: What does my day actually need?

My dashboard pulls from two email accounts, Google Tasks, Google Calendar, Google Drive and soon Notion. It generates rhythm blocks based on my energy, my priorities, and my commitments. Yours won’t look anything like that. It shouldn’t.

Maybe yours needs to surface client deadlines alongside your content calendar. Maybe it needs to track invoices and project status in one view. Maybe it’s simpler — just your top three priorities and today’s calendar, visible the moment you open your browser.

Whatever it is, it starts with your friction list. What’s not working? What are you stitching together every morning? What keeps getting ignored?

I’m still building. Now that Phase 1 is shipped, it’s time to test and find the parts that aren’t quite right. I can already see a few tiny adjustments before I move on to Phase 2, the automation layer that will make it a true chief of staff. Tailored isn’t one-and-done. It evolves because the work does.

If you’re sitting on a version of this problem — tools that almost work, systems you keep rebuilding, mornings that start scattered — I’d love to hear what your friction list looks like. Reply and tell me what’s not working. That’s where it starts.

And if you want help figuring out what your tailored solution could look like, book a quick session and we’ll cut through the noise together.

I saw someone’s Claude Code content system and thought I’d found the answer. Run a command, AI generates an article, done. Automation. Structure. Efficiency. Exactly what I needed.

So I started rebuilding my workspace to work like theirs. I copied their automation scripts into my content workspace. I mapped out their workflow: brief the AI, let it research and draft, and review the output. Clean. Systematic. Impressive.

(Quick note: Claude Code is terminal-based, Cursor is visual interface-based. Both use Claude AI, with different execution styles. More on that in a minute.)

Halfway through the rebuild, I realized what I was actually doing: automating myself *out* of the creative process.

Their system was brilliant—and it worked perfectly for their workflow. But here’s what I missed: even though I can build and code, when I’m creating content, I need to think *creatively*, not *technically*. I need to be part of the process throughout—asking questions, making judgment calls, shaping direction as ideas emerge.

I was building a vending machine—insert prompt, receive content—when what I actually needed was someone to think alongside me.

The tool wasn’t the problem. My approach to using it was.

Understanding AI Tools: Agents, Rules, and Skills

Before I explain what went wrong, here’s what these tools actually are—because the terminology gets confusing fast.

Agents (in Claude Code) are automation scripts. You give them a job in the terminal; they do it and return output. Think of them like hiring someone to complete a task while you’re away. You brief them; they execute; you review the results.

Rules (in Cursor) are IDE guidance. They tell the AI how to behave when you’re working together in real-time. Think of them as giving someone your preferences before you collaborate. “When I’m writing marketing copy, use this voice. When I’m coding, follow these conventions.”

Skills (in Cursor) are interactive workflows. You and the AI work through a process together, step by step. Think of them like having a structured conversation with someone—you’re both present, making decisions, shaping the outcome as you go.

Same AI. Different execution models. Different levels of participation are required from you.

The question isn’t “which tool is better?” The question is: which execution model fits the kind of work you’re doing?

Why Automation Fails for Creative Work

Here’s what I almost did (and what I see a lot of people do): I approached content creation from a *technical* mindset instead of a *creative* one.

The technical mindset says: “How do I make this efficient? How do I build a system that runs a process and produces output?” It’s the same thinking you’d use to set up email filters or schedule social media posts in advance. Figure out what repeats, build the system once, and let it run.

That works beautifully for repetitive tasks. But creativity isn’t repetitive. You can’t automate taste. You can’t script insight. You can’t batch-produce your voice.

What I realized halfway through rebuilding my workspace: I was trying to factor myself into the process “in big chunks”—at the beginning (write the brief) and at the end (edit the output). Everything in the middle? Hand it to the machine.

That’s not collaboration. That’s a production line.

And here’s what that actually costs you: the work feels hollow. All those little moments where you’d normally ask a follow-up question, and the whole direction shifts? You miss them.

The judgment calls that make it sound like *you*? They’re not there. You end up managing AI output instead of actually creating something.

It’s not the tool’s fault. It’s what happens when you try to completely remove yourself from the creative process.

So I stopped trying to copy their system and started rebuilding for how I actually work. Not “how do I make this more efficient,” but “how do I stay in the conversation while still getting structure and support?”

Three decisions changed everything.

How to Structure AI Collaboration (Not Automation)

Step 1: Separate Workspaces by How You Think, Not What You Build

I used to have everything in one workspace: code projects, content drafts, someone else’s automation setup, and my positioning docs. Every time I opened Cursor, the AI loaded context for *all of it*—coding guidelines when I was writing, editorial voice when I was debugging.

The fix wasn’t organizing by file type. It was organized by *workflow type*.

What I did:

• Created a “Builds” folder — All code projects (where automation makes sense)

• Created a “Lees-Space” folder — All content work (where collaboration makes sense)

• Created a “Client-Workspace” folder — Future client projects

Inside Lees-Space, I created another separation: a content-lab subfolder for editorial work and a marketing-assets subfolder for conversion copy. Each has its own rules folder, so the AI loads the right context for the right job.

Why this matters: When you’re creating, the AI should load your voice guide and editorial process—not your coding configs and debugging tools. Separation isn’t about organization. It’s about focus.

Step 2: Build Roles for the AI, Not Scripts

Instead of building automation scripts that “go do the work and come back,” I built rules that define how the AI collaborates with me during different phases of content creation.

What rules are: Think of them as instruction files that live in your workspace. When you’re working in Cursor (the visual editor), the AI reads these rules and adapts its behavior to match. They’re like giving someone your collaboration preferences before you start working together.

What I actually created:

• 800-article-ceo — The strategic interview role. I answer questions, the AI structures my brain dump into a blueprint.

• 810-article-write — The drafting partner role. The AI suggests how to frame sections, I write and edit to match my voice.

• 820-qa-voice — The voice checker role. I review, the AI spots where I’m drifting from my positioning.

• 830-seo-optimizer — The visibility role. I approve decisions, the AI helps optimize for search without killing the voice.

The numbers ensure they load in order—content strategy first, then drafting, then refinement, then optimization. The .mdc file extension just means “markdown with cursor rules”—nothing fancy.

These aren’t scripts. They’re collaboration agreements. The AI knows what role to play, and I’m in the conversation the entire time.

The moment this clicked: I was about to convert someone else’s SEO automation script into my system. Then I realized—I don’t want the AI to do SEO for me. I want it to help me think through SEO decisions. Same job. Different execution model. I built a rule instead of a script, and suddenly I was part of the decision-making process, not just reviewing the output.

Step 3: Keep Yourself in the Conversation

This is the part that’s easy to miss: collaboration requires real-time participation. You can’t batch it.

What this looks like in practice:

• When I’m blueprinting, the AI asks me three strategic questions and waits for my answers before building the outline. I’m not feeding it a brief and walking away—I’m answering in the moment, and my answers shape what gets built.

• When I’m drafting, we move through the sections section by section. The AI suggests how to frame a section; I write it in my own words, we review it together, and adjust before moving forward. I’m not editing a completed piece—I’m shaping it as it emerges.

• When I’m optimizing for search, the AI proposes changes, and I approve or reject them one by one. I’m not reviewing a batch of edits—I’m making judgment calls in real time.

The transferable principle: If you can’t be part of the conversation during the work, you’re not collaborating—you’re delegating. And delegation works great for tasks that don’t require your taste, but terrible for work that does.

What This Really Requires

Here’s what this approach doesn’t require:

• You don’t need to be a developer

• You don’t need to understand how AI models work under the hood

• You don’t need to write code or live in the terminal

Here’s what it does require: knowing how you think when you’re creating something.

Do you need to be part of the conversation as ideas take shape, or are you comfortable handing off a brief and reviewing the result? Do you think in back-and-forth dialogue, or do you think in structured plans you execute alone? Do you make your best decisions in the moment, or after you’ve seen the full picture?

There’s no right answer. But there is a fit question.

Some people can hand off creative work and edit the result. Others lose their voice that way. Some people think best when they’re reacting to something in real time. Others need space to process alone first.

Neither is better. But if you’ve ever felt like something was “technically fine but not quite right,” and you couldn’t figure out why until you realized you weren’t part of shaping it—that’s the signal. You don’t need better tools. You need a process that fits how you actually think.

TL:DR

If you only take away 4 things from this post, make it these:

Automation and collaboration are different execution models. Agents automate (you brief, they execute, you review). Rules guide (the AI adapts to you in real time). Skills collaborate (you work through it together, step by step). Same AI, different levels of participation.

You can’t automate creativity. The technical mindset (make it efficient, eliminate manual work) works for repetitive tasks. But creativity requires taste, judgment, and your voice—and those can’t be scripted. You can structure collaboration, but you can’t automate insight.

Separate your workspace by how you think, not what you build. Code projects and content creation require different workflows. When they share the same workspace, the AI loads irrelevant context every time. Separate them so the AI focuses on what matters for the job at hand.

If you’re not in the conversation during the work, you’re delegating, not collaborating. Delegation works for tasks that don’t require your taste. Collaboration is required when the work needs your voice, your judgment, your real-time decisions. Know which one you’re doing.

The Real Cost of Automating Creativity

Here’s what happens if you keep trying to automate creativity:

You’ll spend weeks building the perfect system. You’ll set up agents, write detailed briefs, and refine your prompts. The AI will produce content. You’ll edit it. And something will feel off.

The work will be fine. Technically correct. But it won’t sound like you. The little moments where your perspective comes through—the turns of phrase, the judgment calls, the tangents that actually make the point land—they’ll be missing. You’ll read it back and think, “This is almost right, but not quite.”

And here’s the part that’s hard to spot until you’re in it: you’ll start adjusting yourself to fit the system. You’ll write briefs that produce better output. You’ll edit in a way that preserves what the AI generated. You’ll optimize for the tool rather than the idea. You’ll become a prompt engineer managing a production line instead of a creator making something that matters.

Let’s do the math: You spend 2 hours building the brief, the AI works for 30 minutes, and you spend 3 hours editing the output to sound like you. That’s 5.5 hours. You could have written it yourself in 4 and actually enjoyed the process.

The efficiency promise is a trap. You’re not saving time. You’re spending it differently—and losing your voice in the process.

Ready to Rebuild Your Process?

So here’s my question for you: What’s one piece of content you’ve been trying to create, and what’s stopping you from just sitting down and making it?

Is it that you don’t have a system? Or is it that the system you’re trying to build is getting in the way of actually creating?

Because here’s what I help people with: figuring out how to use AI as a thinking partner instead of a replacement for thinking. Not “here’s the tool,” but “here’s how to structure collaboration so you stay in the driver’s seat.” If that sounds like the kind of conversation you need to have, let’s talk.

Want the actual files I built for this? I’m sharing the full breakdown—the .mdc rule files, the workspace structure, the conversion process from agents to rules, plus screen recordings of how it all works in practice—as a companion piece for paid subscribers.

Inspiration & Credit:

This article was inspired by the excellent work of on Claude Skills, ’s Claude Code writing system, and ’s Cursor-based workshop on The Hub Workshop.

Their approaches to AI collaboration helped me see what was possible—and gave me the language to articulate what I was building.

Last week, I was updating a client's course content. New lessons, revised material, the usual.

The old me would have opened both documents side by side. Gone line by line. Compared, edited, revised. Checked my work. Revised again. It’s how I’ve done content updates for years... because that’s how you do it right.

I caught myself reaching for that familiar process. And then I stopped.

Instead, I uploaded both versions to Claude and asked it to compare them and suggest changes. Ten minutes later, I had a clear summary of what needed updating. But here’s where it got interesting. I grabbed the code from the existing page and asked Claude to make the adjustments directly.

What would have taken me half a day took less than an hour. Same quality. Fraction of the time. Saved my sanity and saved the client money.

That moment stuck with me. Not because of the time saved (though that was nice). Because I almost didn’t do it. My old rules were pulling me back toward the line-by-line approach, even though I knew a better way existed.

“The hardest part of working with AI isn’t learning the new stuff. It’s unlearning the rules I spent years acquiring.”

That line came out of my mouth during a conversation with Kim Doyal. She paused, said it was quite the aha moment, and told me I should share it.

So here I am.

Your experience is the problem.

Here’s what nobody tells you about being good at what you do.

The principles that made you successful? The hard-won knowledge from years of trial and error? The instincts you’ve built through thousands of hours of practice?

They can become the exact things holding you back.

Not because they were wrong. They weren’t. They worked beautifully... in the context where you learned them.

The problem is, context has changed. Dramatically. And we’re still running old programs in a new operating system.

I’ve been in this game for over seventeen years. I remember hand-coding HTML in a text editor. Building databases from scratch. Debugging systems line by line. Every one of those experiences taught me something valuable. Every one of them created a rule in my head about “how things work.”

Rules like:

• Research thoroughly before you start anything

• Build it yourself if you want to understand it

• Follow the established process because that’s how professionals work

These weren’t just habits. They were principles I’d earned. The kind of hard-won knowledge that becomes automatic.

And automatic is exactly the problem.

Here’s what unlearning actually looks like in practice.

You sit down to work. You know there’s a faster, smarter way to approach the problem. You’ve seen it. Maybe even used it once or twice. But something in your brain keeps pulling you back to the familiar path.

That pull isn’t ignorance. It’s experience.

And that’s what makes it so hard to override.

I catch myself doing this constantly. I’ll start a project with every intention of using AI tools to move faster. Halfway through, I’m back in my old patterns. Researching for hours before taking action. Following processes designed for a world that no longer exists.

The wheel spins, but the cart doesn’t move.

What’s actually happening is a conflict between two kinds of knowledge. There’s what I know intellectually (AI can handle certain tasks faster and often better). And there’s what I know in my bones (the accumulated instincts from thousands of hours of doing things a certain way).

When those two conflict? Bone-deep knowledge usually wins. Not because it’s right. Because it’s automatic.

The difference between people who adapt quickly and those who struggle isn’t intelligence or technical skill. It’s having clear context for what you’re actually trying to accomplish.

The breakthrough wasn’t forcing myself to use new tools.

It was building a foundation that made the shift feel natural.

When you know your business deeply (what makes it work, what makes it unique, what problems you’re actually solving), you can evaluate new approaches without losing yourself in them. You can ask, “Does this serve what I’m already doing well?” instead of “Should I do what everyone else is doing?”

That foundation becomes a filter. It helps you decide what to keep from your old playbook and what to let go of. Without it, you’re just grabbing at tactics with no way to evaluate whether they fit.

I’ve been building what I call a context library. A collection of documents that capture the essential context about my business, my approach, and my thinking. Sounds almost too simple to matter.

But here’s what I noticed: When I start a conversation with Claude using that context, the results are dramatically different. Not because the AI is smarter. Because it’s working with material that reflects my actual situation.

The irony?

Building that context library required me to unlearn one of my deepest habits. The assumption that context lives in my head and doesn’t need to be articulated.

For years, I operated with implicit knowledge. Things I understood so well I never bothered to write them down. That worked fine when I was the only one doing the work.

But AI can’t read your mind. It can only work with what you give it.

Catching old patterns is the key.

If you want to start noticing where your old rules might be creating friction, here’s something you can try this week.

Next time you sit down to work on something and feel that familiar pull toward your usual approach, pause. Ask yourself three questions:

1. What rule am I following right now?

Name it out loud. “I need to research this thoroughly before I start.” “I should figure this out myself before asking for help.” “I need to have all the information before I can make a decision.”

Just making the rule visible is half the battle.

2. Was this rule built for this situation?

Most of our rules were built in a different context. The rule might have been perfect for 2015. The question is whether it still fits in 2025.

3. What would I try if I loosened this rule for one hour?

You’re not abandoning the rule forever. You’re experimenting with holding it lightly. What would you do differently if you gave yourself permission to try another way?

Here’s what this looks like in practice.

Say you’re working on a proposal and catch yourself deep in research mode. Gathering information, reading articles, compiling notes.

Pause and name the rule: “I need to understand everything before I can write anything.”

Ask if it fits: “This rule helped me avoid embarrassing mistakes early in my career. But right now, I’m not writing a dissertation. I’m drafting a proposal I’ll revise anyway.”

Try loosening it: “What if I spent 20 minutes talking through my initial thinking with Claude, let it surface questions I haven’t considered, and then did targeted research on the gaps?”

Here’s a prompt you can copy and paste:

I'm working on [describe the task]. Before I dive into research, help me think through this:

1. What are the key questions I should be able to answer?
2. What assumptions am I probably making that I should check?
3. What's the minimum I need to know before I can start a rough draft?

Push back if you think I'm overcomplicating this.

That’s the shift. Not from careful to careless. From automatic to intentional.

Here’s what staying stuck in old patterns actually costs you.

• Time you can’t get back. Every hour spent on the line-by-line approach when a smarter method exists is an hour you could have spent on work that actually requires your judgment.

• Money (yours or your client’s). That course update I mentioned? The old approach would have cost my client significantly more. Not because I was padding hours. Because the process itself was inefficient.

• Mental energy for the wrong things. The cognitive load of grinding through tasks the hard way leaves you depleted for the work that matters. The strategic thinking, the creative problem-solving, the relationship building.

• Falling behind while feeling busy. This is the sneaky one. You’re working hard. Putting in the hours. But the people who’ve loosened their grip on old rules are moving faster with less effort. And the gap widens.

The friction you feel isn’t a sign that you’re behind or not getting it. It’s a sign that you’ve invested deeply in your craft.

The question isn’t whether you’ll feel resistance. It’s whether you’ll let that resistance make your decisions for you.

The weight of experience.

I want to say something that might sound obvious, but needs to be said anyway.

You’re allowed to find this hard.

If you’ve built a career doing things a certain way, and now the landscape is shifting, it’s completely reasonable to feel friction. That friction is evidence that you’ve invested deeply in your craft. That’s not a weakness. That’s the weight of experience.

The goal isn’t to become someone who never hesitates. It’s about becoming someone who can sit with the discomfort of not knowing, try a different approach, and honestly evaluate whether it worked.

I still catch myself spinning my wheels. I still default to old patterns more often than I’d like. But I’m getting better at noticing when it’s happening.

And that noticing? That’s the skill.

Sometimes you have to unlearn to relearn. That’s not failure. That’s growth with more layers.

I’m curious about your experience with this.

What’s one rule or process you learned years ago that you suspect might be holding you back now?

Not a general category. A specific thing. The way you research. How do you start projects? What do you think you need to know before you can begin?

One thing I’m working on:

I’ve been developing a Context Library Workshop. A structured exercise to help you build three cornerstone context pieces for your business. These are the documents that capture what makes your work valuable, how you approach problems, and what you’re actually trying to accomplish.

I’m looking for two people to work through this with me. Whether you’re just starting to explore AI tools or you see the opportunities and want to move more intentionally, getting this foundation in place changes how you work with AI.

If that sounds useful, mention it in your reply or send a DM. Tell me where you are in your AI journey, and I’ll follow up with details.

Last week, I got a prompt from The Neuron that looked genuinely useful. Instead of saving it, I tested it. Took ten minutes. Refined it for my actual workflow. Used it twice that day. Deleted the original.

That’s when it hit me: the prompt that works is the one you test today. The one you save for someday? That’s just a different kind of hoarding.

I didn’t always think this way. For months, I did what most people do. Subscribed to newsletters specifically for their prompts. Copied the good ones into a Notion database. Tagged them. Told myself I’d circle back when I had time.

My prompt library grew. My actual prompt usage didn’t.

Sound familiar?

We spent years accumulating free PDFs, swipe files, and courses we never finished. We told ourselves it was research. Preparation. Building a toolkit for someday.

Then AI showed up, and we started doing the exact same thing with prompts. Different medium. Same pattern. Same graveyard.

The database gets bigger. The “someday” pile grows. And the gap between collecting and actually using widens every week.

Why Your Prompt Organization System Isn’t the Problem

Most people think the problem is organization. They believe if they just had a better system... better tags, better folders, a smarter way to categorize prompts... they’d actually use them.

But here’s what I discovered: the system isn’t the problem. The collecting is.

Every time you save a prompt “for later,” you’re making a tiny decision to not engage with it now. And that decision compounds. One saved prompt becomes ten. Ten becomes fifty. And somewhere along the way, the act of collecting starts to feel like progress.

It’s not. It’s a preparation theater.

I know this because I lived it. My Notion database had prompts organized by category, use case, and even AI model. Beautiful system. I opened it maybe once a month.

Meanwhile, the prompts I actually used? They never made it into the database at all. I tested them in the moment, refined them, and moved on.

The library was a monument to good intentions. The real work happened outside of it.

If you keep building the collection, here’s what happens:

• You spend more time organizing prompts than testing them

• You forget why you saved half of them in the first place

• You feel behind even though your database is full

• You mistake the size of your library for readiness

The uncomfortable truth? A smaller prompt habit that you actually use beats a massive library you admire from a distance.

What I Learned When I Stopped Saving Prompts

I realized my prompt library wasn’t helping me when I went looking for something I knew I’d saved. Took me fifteen minutes to find it. Then another ten to remember why I thought it was useful. By the time I actually tested it, I’d burned almost half an hour on a prompt that didn’t even work for my situation.

That was my wake-up call.

The system I built to save time was costing me more than it saved.

This is the part when I realized.

I already had everything I needed to use prompts effectively. I just had it backwards. I was treating prompts like collectibles when they’re actually disposable tools. You don’t save a sticky note forever. You use it, then throw it away.

What if I treated prompts the same way?

Put this to the test.

Instead of randomly saving prompts gained for others, I put it to the test first:

1. No more saving by default. When I saw a promising prompt, I tested it immediately or let it go.

2. 10-minute rule. If I couldn’t test and evaluate a prompt in 10 minutes, it wasn’t worth my time right now.

3. Refine or delete. After testing, I either adapted it for my specific workflow or deleted it entirely. No “maybe later” pile.

4. One active prompt per category. Instead of fifty options for summarization, I kept one that actually worked.

What surprised me was how little I missed. The prompts I let go? I never thought about them again. The ones I tested and refined? I used them repeatedly.

After a few weeks, something shifted.

“The value of a prompt isn’t in the saving. It’s in the testing.”

I stopped being beholden to new prompts. I stopped opening newsletters with the thought of “I should save this.” Instead, I read them with a simple filter: Is this useful to me right now? If yes, test it. If no, move on.

My prompt “library” shrank to maybe a dozen. My actual prompt usage doubled.

This pattern applies beyond prompts

It’s the same trap with tools, templates, frameworks, and tactics. We collect because collecting feels safe. Testing feels risky. What if we pick wrong? What if there’s a better one?

But here’s what I learned the hard way: the prompt you tested and refined for your workflow will always outperform the “perfect” prompt you saved but never touched.

The gap isn’t between good prompts and bad prompts. It’s between tested and untested.

The 10-Minute Framework That Replaced My Prompt Database

Why “Save for Later” Was Costing You

Every prompt you saved without testing created a small decision debt. You told yourself you’d evaluate it eventually. But eventually never came, and now you have a database full of untested possibilities and no clear sense of which ones actually work.

Which means you’re no closer to using AI effectively than you were before you started collecting.

Here’s what changed for me: I stopped asking “Is this worth saving?” and started asking “Is this worth ten minutes right now?”

The 10-Minute Prompt Test

When you encounter a new prompt, run it through this filter before you do anything else:

1. Test it raw. Copy the prompt exactly as written. Run it with a real task you’re working on today. Not a hypothetical. Something actual.

2. Note what breaks. Where did the output miss? Too generic? Wrong format? Missing context about your situation?

3. Refine once. Make one adjustment based on what broke. Add your context, change the output format, and narrow the scope. Run it again.

4. Decide: use, adapt, or delete.

   • If it worked after one refinement, save your version (not the original)

   • If it needs heavy modification, it’s not the right prompt for you right now. Delete it.

   • If it flopped completely, delete it without guilt.

Total time: 10 minutes. You now know more about that prompt than you would after six months in a database.

Two Prompts Worth Testing Today

Here are two from The Neuron that passed my filter. Don’t save them. Test them.

The “Compare and Decide” Prompt:

Compare [Option A] vs [Option B] for [my situation]. 
Output a table with: features, tradeoffs, risks, cost/time, best-fit. 
Then give a recommendation with clear reasoning and "if X, choose A; if Y, choose B."
Research and show any hidden costs.
Include a short 'What would make me regret this?' section for each option, and end with a 3-step next action plan (trial, pilot, or due diligence).
Give a confidence level regarding how likely it is to be the right choice given what you know about my needs today and me as a person.

Best for: Tool decisions, vendor comparisons, build vs. buy choices.

Downside: Requires clear context about your situation upfront or the output stays generic.

The “Give Me Options” Prompt:

Generate 10 distinct approaches to solve [problem]. 
For each: give a one-line summary, best use case, and one downside. 
Then recommend the top 2 based on [my priority: speed / cost / quality / risk].

Best for: When you’re stuck on approach and need to see the landscape quickly.

Downside: Can feel overwhelming without a clear priority filter.

The Prompt You Keep

After testing, your saved prompts should meet one criteria: you’ve used them at least twice on real work.

Not “this looks useful.” Not “I might need this.” You’ve tested it, refined it, and it delivered.

Everything else is decoration.

The Real Reason Most Prompts Fail (It’s Not the Prompt)

When I talk about using AI and LLMs, my clients often feel frustrated because their results are usually… off.

They believe the problem is finding (copying) the right prompt. The magic combination of someone else's ideas that unlocks useful output.

But here’s what I’ve noticed: the prompts aren’t the issue. The context is.

That “Compare and Decide” prompt above? It works beautifully when AI knows your situation, your priorities, and your constraints. Run it cold, with no context? You get generic output that requires heavy editing.

This is why prompt collecting fails. You’re gathering tools without giving them anything to work with. It’s like collecting recipes but never stocking your kitchen.

The shift happens when you stop hunting for better prompts and start giving AI better context. A clear description of their business. Their audience. Their voice. Their constraints.

Suddenly, even simple prompts work harder.

My prompt library got smaller. But my context documents got richer. That’s what actually moved the needle.

How to Evaluate Any Prompt in 10 Minutes

Here’s the smarter approach, step by step.

The Old Way: Save prompt. Tag it. Tell yourself you’ll test it later. Open your database in three months and wonder why you saved half of what’s there.

The Smarter Way: Test immediately. Refine once. Decide now.

The Exact Process

Step 1: Grab a real task (2 minutes)

Don’t test prompts with hypotheticals. Find something you’re actually working on today. An email you need to write. A decision you’re weighing. A document you’re drafting.

Step 2: Run the prompt raw (3 minutes)

Copy it exactly. Paste it into your AI tool with your real task. See what happens without modification.

Step 3: Identify the gap (2 minutes)

Where did the output miss? Usually it’s one of three things:

• Too generic (needs your specific context)

• Wrong format (needs output structure specified)

• Wrong scope (needs narrower focus)

Step 4: Refine and rerun (3 minutes)

Make one adjustment. Add context about your business. Specify the format you need. Narrow the scope. Run it again.

Step 5: Make the call

• Works after one refinement? Save your refined version.

• Needs heavy rework? Not the right prompt for you right now. Delete it.

• Flopped entirely? Delete without guilt.

You just learned more in 10 minutes than you would in six months of saving.

TLDR Version

• Collecting prompts feels productive, but creates the same “someday” pile as PDFs and courses

• The value of a prompt is in the testing, not the saving

• 10 minutes of real testing beats six months in a database

• Prompts fail because of missing context, not because they’re the “wrong” prompt

• Keep only what you’ve used twice on real work. Delete everything else.

You don’t need a bigger prompt library.

You need a clearer filter for what’s worth your time and a better context to make any prompt work harder.

The prompts you test today will always outperform the collection you admire from a distance.

So here’s my question: What’s one prompt you’ve been “saving for later” that you could test in the next 10 minutes?

One More Thing

If you noticed the real issue here... that prompts fail because of missing context, not missing prompts... you’re ready for the next step.

Next week, I’m running a workshop: Teach AI Your Business Once.

In this working session, you’ll build a simple Context Library for your business. Core Identity, Voice & Tone, and Audience documents you can drop into any AI tool.

Instead of starting from scratch every time, you’ll leave with infrastructure that makes AI sound more like you and need far less editing.

No more prompt hunting. No more “someday” piles. Just context that makes everything work better.

Two lightweight experiments that solved a problem I didn't know I had.

My son’s birthday is New Year’s Eve.

For the last 30+ years, the week between Christmas and New Year’s isn’t about wrapping up and relaxing. Between birthday logistics and the last week of the current year, I usually don’t take my breather before January hits.

The “new year, new me” energy doesn’t land for me until January 3rd at the earliest.

By then, everyone else is already running.

I used to fight that timing. Now I work with it.

These last few weeks, I’ve been running lightweight experiments... not to overhaul anything, just enough to keep my head in the game.

Two of those experiments connected in a way I didn’t expect.

A Simple Weekly Planning System (Built in Claude)

I created a simple planning system called the Weekly 5.

The idea: Pick five things each week that advance DigiNav. Not necessarily revenue-generating, just forward motion.

Sometimes it’s a new experiment. Sometimes it’s cleanup and organization. Sometimes it’s learning something I’ve been putting off.

I built it as a Claude project to handle three things:

• Weekly reflection on what got done

• Planning the next week’s five priorities

• Checking my calendar for actual time available

It wasn’t difficult to create since Claude helped me write the instructions.

Here’s the core prompt (cleaned up so you can adapt it):

You are assisting with a Weekly Reset.

Context:

The week is the unit of commitment.
Exactly five items define success.
Everyday/maintenance work must NOT be included.
This is a light-capacity week unless stated otherwise.
Items must be finishable in one sitting or two short sessions.
You may make strong suggestions, but I make final decisions.

Inputs you will receive:
Brain dump list
Weekly items candidates
Calendar constraints (if provided)

Your tasks:
- Identify which candidate items are actually everyday/maintenance work.
- Identify which items are too vague or too large as written.
- Propose shrunk, finishable versions of those items.
- Recommend a final set of exactly five items that fit the week’s capacity.
- Wait for explicit confirmation before writing anything to {{your database}}.

Do not optimize for productivity. Optimize for clarity, calm, and finishability.

Once the five items are locked in, they get written to a Notion database with the week’s date. Simple view: what’s due between Monday and Sunday.

What I learned:

• Simplified the review and planning process significantly

• Got too granular at first, which made the whole thing cumbersome

• The sweet spot: Claude does the sorting, I do the input

It was working.

But there was a problem. The system writes to Notion... except when it doesn’t. The connection wasn’t reliable, which meant I was still manually copying things over.

Creating a Custom AI Agent in Notion

Separately, I’d been experimenting with Notion AI.

I came across an article on Solopreneur Code by @anferneeck about creating a custom AI agent in Notion. The approach clicked for me... a structured prompt that gives the AI agent clear modes and context.

I already had a mascot named VITA. She’d been sitting in my brand assets without a real job. This felt like a good use for her.

I loaded in the context documents I’d already built:

• Audience profiles

• Tone and voice guidelines

• Content themes

• Content workflow

• Product strategies

• And more

The setup took about 20 minutes. A good use of time for the clarity it would save me in the long run.

The modes I settled on:

• Foundation: Brainstorming, Project Planning, Strategy

• Execution: Content, Marketing, Sales, Email Communications

• Support: Decision Making, Research & Learning

What started as trying the prompt turned into a game plan to streamline Notion and use the space better.

And VITA worked well. Really well.

For tasks that involved writing to Notion databases, having the AI agent live inside Notion made the whole process smoother.

Why the Weekly 5 Belonged in Notion All Along

Here’s where the two experiments collided.

The Weekly 5 writes to a Notion database. That’s the whole point... tracking what I commit to, what I complete, what sits in limbo.

The reflection and planning process generates entries that need to be updated in that very database.

I’d built it in Claude because that’s where I was already working and Claude is able to write to Notion.

But the output connection sometimes worked and other times not.

Which meant I was constantly copying things over, creating friction I didn’t need.

The realization: The Weekly 5 should live where the database lives. Not where I happened to be comfortable. Not where I’d already started. Where the work actually belongs.

The Feature I Didn't Know Notion Had

One reason I’d kept the Weekly 5 in Claude: calendar integration.

Part of the Friday planning process involves looking at my upcoming week... what commitments are already locked in, whether I’m overloading myself before I even start.

Claude can connect to Google Calendar. Notion couldn’t.

Or so I thought.

Turns out Notion added Google Calendar integration recently. It can’t write or push notifications, but it can read. It can pull my commitments into the planning view.

That was the last barrier. Gone.

Stop Asking "Which Tool Is Best"

This wasn’t a dramatic pivot.

It was a small adjustment that removed friction I’d been tolerating.

But the underlying principle matters:

Sometimes the right tool choice reveals itself when you stop asking “which tool is best” and start asking “where does this work actually live?”

I didn’t need a better planning system.

I needed to stop fighting against my actual workflow.

The Foundation That Made Both Experiments Easy

Both experiments moved quickly because I had context documents ready.

Business positioning. Voice. Audience profiles. Frameworks... all documented and portable.

When I created VITA, I didn’t have to explain my business from scratch.

When I moved the Weekly 5 to Notion, the context came with it.

That portability is the thing I keep coming back to.

Your AI tools are only as useful as the context you give them. And the context you’ve already documented is usable anywhere.

I’m running a Context Library workshop in January focused on exactly this: building the foundation that makes every AI tool work harder.

More details coming soon.

I read the tip in some organizing blog: turn all your hangers backward, then flip them forward as you wear each piece. After a few months, you’ll see exactly what you actually wear versus what’s just taking up space.

Simple. Clean. Done.

So I did it. Hung up all my clothes, flipped the hangers backward. And honestly? It worked for the first part of the purge.

Until it didn’t: half my closet isn’t hung up at all.

I have jeans folded in a drawer. Sweaters stacked on a shelf. Casual pieces in a separate section. Then there are the pieces that aren’t regular wear—the wedding outfit, the funeral dress, the timeless blazer I wear twice a year but absolutely need. The shoes, belts, scarves, and accessories that live in their own ecosystem.

The hanger method solved for some of my clothes, but it completely ignored the complexity that actually mattered. I could turn hangers backward all day and still have half my wardrobe making its own decisions in drawers and shelves I wasn’t tracking.

That’s when I realized something that changed how I approach everything—systems, frameworks, processes, even how I build things with AI.

Simple systems fail when you ignore what’s actually real.

Most people think the problem is that they need a simpler system.

They see elegant solutions that work for others and try to force them into their own situation. The hanger trick looks beautiful because it’s reductive. One rule. One action. One outcome. But the second you acknowledge what’s actually real about your situation, that elegant solution breaks.

But here’s what I discovered: the problem isn’t the system. The problem is pretending the complexity doesn’t exist.

I wasn’t being indecisive about my closet. I wasn’t hoarding. My clothes actually lived in different places for different reasons. The hanger trick was brilliant for one piece of the puzzle, but it was built on the assumption that all my clothes worked the same way. They didn’t.

And I see this pattern everywhere now—in how solo builders try to force one automation framework into a messy reality, in how we attempt to apply one template to processes that actually need multiple logic systems, in how we ignore the complexity that matters and then wonder why elegant solutions fall apart.

If you keep forcing simple systems over actual complexity, here’s what happens:

• You waste energy trying to make reality fit the system instead of building a system around reality

• The elegant solution actually costs you more time than it saves because you’re constantly working around exceptions

• You give up on the system entirely instead of acknowledging what’s actually real

• You lose authenticity because you’re overriding what you know to be true about your situation

The closet still got purged. But not because of the hanger trick. Because I finally mapped out the actual reality: what gets worn regularly (hung in rotation), what’s seasonal (rotated storage), what’s occasion-specific (accessible but separate), what’s accessory support (its own system).

Four different logic systems. Not one.

The False Start

Initially, I thought the fix was just better organization. The hanger method looked elegant enough, and organizing blogs swear by it. So I committed. Turned every hanger backward, checked the calendar to see how long I should wait, and felt productive about having a clear system.

For exactly two weeks, it felt like it was working. Then I hit the wall: all my seasonal pieces, all my occasion-wear, all my accessories—they lived outside this system entirely. I was tracking hangers on 40% of my wardrobe and completely ignoring the other 60%.

The Turning Point

The moment it clicked was when I stopped pretending the complexity wasn’t there. I sat down and actually mapped out how my clothes actually lived, not how they’re supposed to live in organizing blog theory.

Regularly worn pieces need one system (rotation). Seasonal storage needs another (accessibility + visibility). Occasion-specific needs a third (separate but accessible, because I wear that wedding dress every few years and I need to know where it is). Accessories need their own ecosystem entirely (because scarves don’t follow closet logic, they follow “what matches the outfit” logic).

None of these pieces worked with the same system. Forcing them into one hanger method would have meant ignoring what made each piece actually valuable to keep.

The Experiment

I built a hybrid system instead. The pieces I wear regularly? Hangers in rotation. The seasonal pieces? Labeled storage with visibility. The occasion-wear? Its own section where I know exactly where to find it without opening a drawer. Accessories? Organized by type and accessibility, not by “wear frequency.”

Suddenly, the system worked because it honored what was actually real instead of pretending reality didn’t exist.

The Connection

This same pattern showed up later when I was building a video creation system with Claude. I started by asking AI to write my scripts for me. Seemed simple. Elegant. Efficient. One tool does the thinking, I do the recording.

Then I realized: I was asking Claude to replace the part of me that actually matters—my thinking, my voice, my authenticity. The elegance came from ignoring the complexity that defines what I do.

So I pivoted. Instead of “write my script,” I asked Claude to structure my thinking. Instead of “create a finished product,” I asked for “talking points that reflect my actual approach.” Instead of replacement, amplification.

That’s when the system worked. Because it honored the complexity—that I need structure AND authenticity, efficiency AND my voice, systems AND staying personally involved.

The Breakthrough

Here’s what I finally understood: simple systems look good on paper because they’re built on the assumption that everything works the same way. But the moment you acknowledge what’s actually real—that some parts of your business need hands-on attention, that some content needs your specific thinking, that some decisions only you should make—elegance has to make room for complexity.

My Story Refiner Bank process clicked into place the same way. I kept trying to force stories into a single framework until I stopped pretending they worked the same way. Some stories teach through vulnerability. Some teach through systems. Some teach through real-world failure. Different logic. Different extraction process. Different downstream use.

The system only works when you build it around what’s actually real.

Why Oversimplified Systems Were Costing Me

Using one-size-fits-all approaches meant I spent energy forcing a fit instead of building systems. I wasted time working around exceptions instead of accounting for them. And I started losing authenticity because I was overriding what I actually knew to be true.

With the closet: I’d turn the hangers backward all week, then realize I still had no system for 60% of my wardrobe. With the Claude project: I’d get beautiful scripts that weren’t in my voice, then have to rewrite them anyway—which defeated the efficiency purpose entirely.

The cost wasn’t time saved. It was time wasted on a system that ignored reality.

Building Systems Around Complexity

Here’s exactly how I built systems that honored what’s actually real:

Step 1: Map Your Actual Reality (15 minutes)

Don’t imagine how things should work. Document how they actually work right now.

For closet: How do your clothes physically live? What gets worn how often? What needs a different logic?

For video creation: What do you actually need from AI? What thinking do you need to keep? What parts feel efficient vs. what parts feel like replacement?

For your business: Which processes involve decision-making that only you should do? Which are pure busywork? Which needs your authentic voice?

Step 2: Identify Your Logic Systems (10 minutes)

Not everything in your process follows the same logic. Name them explicitly.

Example from closet:

• Logic System 1: Daily rotation (hangers forward/backward tracking)

• Logic System 2: Seasonal storage (labeled, accessible, rotated quarterly)

• Logic System 3: Occasion-specific (separate, easily findable, worn rarely)

• Logic System 4: Accessories (organized by type and matching logic, not wear frequency)

Example from video creation:

• Logic System 1: Structure and talking points (AI collaboration)

• Logic System 2: Authentic voice and delivery (my thinking, live recording)

• Logic System 3: Visual flow and transitions (predetermined based on my teaching style)

• Logic System 4: Final refinement (testing if it feels like me, not if it’s perfect)

Step 3: Build a Different System for Each Logic (20 minutes)

Trying to force one elegant system means ignoring which pieces actually need different treatment.

For the closet: hangers for daily rotation, labeled bins for seasonal items, an accessible drawer for occasion wear, and an organized shelf for accessories.

For video: Claude collaboration for structure, my natural speaking for delivery, predetermined visual framework, refinement loop that asks “does this honor my voice?”

For your business: Automation for repetitive busywork, collaboration for thinking work, systematic tracking for decision-making, and authentic interaction for client relationships.

Step 4: Test and Adjust (Ongoing)

The system only works if it honors reality. If you find yourself working around the system constantly, it means you’re ignoring a piece of actual complexity.

Ask: Is this system honoring what’s actually real, or am I pretending complexity doesn’t exist?

If you’re constantly making exceptions, the system isn’t elegant. It’s ignoring you.

The Claude AI Video Script System (That Preserved My Authenticity) - Watch me walk through the 6-step collaboration loop I created with Claude, from first iteration through final refinement

When solo builders come to me with scattered processes and overwhelm, the conversation usually goes like this:

They say: “I need a simpler system.”

What they actually mean: “Everything I do feels complicated, and I want one elegant solution to fix it.”

But then we start mapping what’s actually real. And it always looks different.

One client thought she needed to automate her entire client intake process. Seemed simple. Elegant. Efficient. Until she realized: the first conversation with a client is where they decide if she understands their business. That conversation needs her thinking. Automation would have replaced the part that makes her valuable.

Here’s the pattern: people don’t actually need simpler systems. They need systems that honor the complexity that’s actually real.

The shift happens when they stop asking “How do I make this more efficient?” and start asking “What’s the actual logic underneath each piece of what I do?”

That’s when they see it. Some parts of the business should be automated (the busywork that doesn’t define them). Some parts should stay personal (the thinking that does). Some parts need AI collaboration (structure + thinking together). Some parts need their authentic voice (delivery, client relationships, final decisions).

Different logic systems. Not one elegant solution.

The Smarter Approach

The Old Way: Force Elegance Over Complexity

Apply one system to everything. Pretend reality will bend to fit theory. Work constantly around exceptions. Eventually, abandon the system because it keeps failing.

The Smarter Way: Build Systems Around Actual Complexity

Map what’s real, identify your logic systems, build differently for each one, test if it honors what you actually do.

Here’s exactly how:

Step 1: Closet Audit for Your Business (10 minutes)

List everything you do. Next to each item, write:

• How often do I do this?

• Does it require my thinking, or is it busywork?

• Is this part of what makes me valuable?

• What logic does this actually follow?

Don’t overthink it. Just dump it.

Step 2: Group by Logic (5 minutes)

You’ll start seeing patterns. Some things all follow the same logic. Others are completely different.

Example:

• Group A: Daily repetitive work (busywork, same logic, automate-friendly)

• Group B: Client-facing decisions (requires your thinking, different logic, keep personal)

• Group C: Creative process (needs your voice, different logic, amplify, don’t replace)

• Group D: Seasonal or occasional (different rhythm, different logic, separate system)

Step 3: Build or Adjust Systems One Logic at a Time (15 minutes)

For each logic system, ask: What would actually work here?

For busywork automation, use Make or Zapier to eliminate repetitive tasks.

For client-facing decisions: Use AI collaboration (Claude structures options, you decide).

For the creative process: Use frameworks that guide but keep you in the thinking.

For seasonal/occasional: Build visibility and accessibility, not forced into daily logic.

Step 4: Ask the Question (Ongoing)

Before you implement anything: Is this system honoring what’s actually real, or is it ignoring the complexity that matters?

If you’re constantly working around the system, it’s not elegant. It’s incomplete.

If the system makes you feel less authentic, it’s replacing something it should be amplifying.

The right system should feel like it works for you, not like you’re working for it.

Pretending The Solution Works

I could have kept turning hangers backward and pretending that an elegant solution would somehow solve the part of my closet that lives in drawers.

I could have let Claude write my scripts and convinced myself that efficiency was worth losing my voice.

I didn’t. Because the moment I acknowledged what was actually real, everything changed.

Simple systems look beautiful on paper. But they break the second you stop pretending complexity doesn’t exist.

The question that matters isn’t: How do I make this simpler?

The question is: Does this system honor what’s actually real about how I work?

When you start building around actual complexity instead of forcing reality to fit elegance, something shifts. The system starts working. Your energy goes into creating, not constantly working around exceptions. You stay authentically you instead of overriding what you know.

That’s not more complicated. That’s smarter.

My vision is usually close. It’s just never quite right.

Enter my husband. I’ll pick out a paint color that looks like it fits, and he’ll take one look and say something like, “This gray looks good in a small swatch but in this big room with three windows it will be ugly and bland.” Then he’ll add some white, remix the color, and suddenly the color works. Not the version in my head—a better version that actually functions in reality.

The running joke in our family: I’ve never picked a paint color that made a wall untouched.

Here’s what I didn’t realize for years: he’s not correcting me. He’s testing my theory against reality and adjusting it based on what he discovers. He treats iteration as part of design, not a sign design failed.

I was treating iteration like a dirty word.

Where Content Planning Becomes the Problem

I learned the hard way that this pattern shows up everywhere—not just in paint colors, but in systems I build.

Most people think the problem with content strategy is that you haven’t planned far enough ahead. So they plan more. They create detailed spreadsheets, map quarterly themes, anticipate every pillar and angle. They let AI generate topics based on business strategy. Then they sit down to execute.

But here’s what I discovered: the problem isn’t that planning is bad. The problem is confusing a complete mental picture with a complete design.

I spent hours mapping out 12 weeks of content for DigiNav. I had the whole thing visualized: brainstorm topics → map to refined stories → pick or create supporting video → write the article. Clean. Systematic. Complete.

I created a spreadsheet with topics, themes, which content pillar each one served, video descriptions—the whole thing. It looked perfect on screen. Organized. Strategic. Like if I just executed this plan exactly, 12 weeks of content would flow out seamlessly.

Then I opened the database in Notion and felt it immediately: this is generic fluff.

Not because the topics were wrong. Not because the framework was broken. But because I was looking at a list of content ideas that could work for anyone. They didn’t spark anything. They didn’t feel like me. They felt like exactly what AI generates when you ask it to plan content from strategy—structurally sound, contextually hollow.

Here’s where most people get stuck: They interpret that disconnect as a planning failure. They should have thought it through more. They need better strategy. So they go back and replan, hoping that more detail will create alignment.

But that’s not what was happening. And that’s not what fixes it.

When the Plan Met Reality

I looked at my beautiful 12-week plan and realized something: I’d planned the content without testing whether the planning process itself actually worked.

I’d done exactly what I do when I visualize a room. I’d created a complete picture in my head and assumed executing it would be the same as building it. Except it wasn’t. Because the moment I started executing, reality showed up.

So I stopped trying to execute the plan and started asking a different question: Why does this feel wrong?

I created a new Claude thread. I added my business context, my content pillars, my framework. And then I said: “Look at this 12-week plan I created. Something feels off. Help me diagnose what it is. This isn’t implementation—let’s talk about it. Ask me questions to clarify and call me out on my stuck points.”

Here’s what Claude came back with: “I find a disconnect. It’s structurally correct, but contextually hollow.”

That sentence stopped me. Because that was exactly it. The plan was structurally correct. It hit all my pillars. It was organized by theme. It showed strategy. But it wasn’t connected to anything I was actually building or thinking about.

Then Claude asked: “What are you actually building and navigating right now? What’s the real difference between a topic that feels generic and a topic that says, ‘Oh, I have something to say about that’?”

And finally: “Should the planner generate topics based on your real-time work rather than a pre-planned calendar?”

That’s when it clicked. The problem wasn’t that I needed to plan better. The problem was that I was treating the plan as a blueprint rather than a hypothesis. I was confusing “I’ve thought this through” with “I’ve tested this and know it works.”

From Generic Topics to Real Angles

The False Start: More Detailed Planning

My first instinct was to fix it by planning better.

So I went back to the original prompt. Made it more detailed. Added more context about my voice and approach. Specified exactly which framework should appear in which piece. Added more specificity about tone, structure, engagement hooks.

That made things worse. More planning didn’t produce better content. It produced more overthought, more constrained content that felt even further from what I actually wanted to say.

I was writing to the system instead of writing to discover what I actually thought, which is exactly the opposite of staying authentically me.

The Turning Point: The Diagnostic Question

Then something shifted. When I asked Claude to help me diagnose instead of fix, it asked me: “What are you actually building, learning, navigating right now?”

And I realized: I am building something. I’m actively working on refining my content automation process. I’m discovering what works and what doesn’t. I’m navigating the tension between planning and executing. I’m building in public, showing the messy middle. That’s real work. That’s material.

But my 12-week content plan didn’t reflect any of that. It was theoretical topics, not real work.

That’s when I understood. I wasn’t generating content topics from thin air—I was trying to. Which meant everything was generic.

My husband doesn’t visualize room color better than I do. He relies on his experience as a commercial painter to test the theory against reality. He observes what actually happens, then adjusts based on data. He treats iteration as part of design.

I was treating my planning the same way I treat visualizing rooms: as if the first picture were the final answer.

The Experiments: Testing Different Approaches

1. Tried: Let Claude generate 12 weeks of topics upfront based on my business pillars and strategy .
   Result: Organized spreadsheet. Generic topics. Nothing sparked. Felt hollow.

2. Tried: Abandon the plan entirely and write intuitively whenever I felt inspired.
   Result: Some alive pieces. No coherent strategy across them. Scattered and chaotic.

3. Tried: Identify real work I’m doing, then ask Claude to extract 5-7 different angles from that one project.
   Result: Content ideas that felt alive. Grounded in actual work. Strategic without feeling generic. Each angle sparked something.

Number three changed everything.

Angle Extraction Instead of Topic Planning

Here’s what finally clicked: I don’t need a content planner that generates topics from strategy. I need a content angle extractor that takes work I’m already doing and shows me all the different ways I can present it.

Claude said it perfectly: “What you’re actually doing is not talking about planning content. You’re talking about extracting content angles. And that’s different than planning content.”

Think about the difference:

Content Planning: “Based on your business strategy, here are topics you should cover this quarter”

Angle Extraction: “You’re working on X right now. Here are 5-7 different angles you could pull from that work that would matter to different parts of your audience”

They sound similar. They’re completely different.

Content planning starts from nothing. It generates ideas from strategy, which defaults to generic. Angle extraction starts from real work and multiplies it. It takes something alive and shows you all the ways it connects.

When I stopped asking Claude “what should I write about?” and started asking “I’m working on this—what angles can I pull from it?”—everything shifted. The content felt true. It felt grounded. It felt like mine.

Why This Looks Different When You Understand It

When I work with clients building content systems, the conversation usually starts the same way: “I need better content strategy.”

But when I dig deeper, I find they’re doing what I was doing. They’re asking AI to generate topics from strategy rather than extracting angles from the work.

One client told me: “I have plenty of content ideas when I’m working with clients. But when I sit down to plan content, nothing comes to me.”

That’s not a planning problem. That’s a sourcing problem. When you’re in the middle of real work—solving a client problem, building a system, discovering something—you see multiple angles naturally. You see how it connects to different parts of your business. You see how different audiences would relate to it.

But when you sit down to plan content in the abstract, you have nothing to extract angles from. You’re generating from strategy, which always feels generic because it’s not grounded in anything real.

Here’s the principle that applies: Generic content comes from planning without material. Grounded content comes from extracting angles from real work.

How to Actually Plan Without Overplanning

This is where most people trip up. They hear “extract angles from real work” and think it means abandoning planning. That’s wrong. It means planning differently.

The Old Way: Generate topics upfront → organize them → execute them

The Smarter Way: Do real work → extract multiple angles → organize by pillar → execute the angles

Here’s exactly how:

Step 1: Identify Real Work You’re Actually Doing (No Time Limit)

Don’t try to think of content ideas. Instead, notice what you’re actively building or navigating right now.

Examples:

• You’re refining a process in your business

• You’re working through a client problem

• You’re discovering something that changes how you think

• You’re building a system or framework

• You’re navigating a tension or challenge

Write it down: “I’m currently working on: [specific real thing]”

Step 2: Ask Claude to Extract Multiple Angles (15 minutes)

Now ask Claude: “I’m working on this [real thing]. Here are the different audiences I serve: [list them]. What are 5-7 different angles I could pull from this work that would matter to each of them?”

You’re not asking it to generate topics. You’re asking it to help you see all the ways your real work connects to different problems people are facing.

Step 3: Evaluate Which Angles Spark Something (5 minutes)

Read through the angles. Notice which ones make you think “oh yeah, I have something to say about that” vs. which ones feel obligatory.

The ones that spark you are the ones grounded in your real thinking. Those are the ones worth writing.

Step 4: Organize Angles by Pillar and Timing (10 minutes)

Take the angles that sparked you and map them:

• Which content pillar does this serve?

• When does this fit in your business cycle?

• What order makes sense?

This is the only planning you need. Not “what should I write about this quarter” but “of the angles I’ve identified from real work, how do I organize them?”

Step 5: Execute One Angle (Time Varies)

Write the piece. Don’t try to work ahead on all seven angles. Just do the next one.

While you’re writing, notice what else you’re discovering. Let that inform what comes next.

Step 6: Repeat With Your Next Real Project

Once you’ve extracted and executed the angles from the first project, move on to the next real work you’re doing. Extract angles from that. Repeat.

Why This Works:

You’re never scrambling for content ideas because you’re mining them from work you’re already doing. You’re never starting from nothing (which is how generic happens). The content stays grounded because it’s anchored in real problems and real building. And you maintain strategy without forcing ideas to fit a predetermined plan.

You’re not abandoning planning—you’re sourcing from reality instead of strategy alone.

The Stakes of Staying in Topic-Planning Mode

If you keep thinking perfect planning comes before real work, here’s what happens:

• You generate topics from strategy that feel generic because they’re not grounded in anything

• You sit down to write and feel uninspired because there’s no material to extract from

• You force yourself to write to the plan instead of writing what you actually think

• Your content feels obligated, not owned

• Meanwhile, builders who extract angles from real work are creating content that feels alive, specific, and grounded

The real cost of planning topics upfront isn’t the time spent planning. It’s the authenticity lost by generating from strategy instead of extracting from work. It’s the weekly scrambling because you have no material to pull from. It’s the generic feeling that follows you through every piece.

The Permission You Need Right Now

Here’s what I’ve learned about staying authentically you while building strategically: Grounded content doesn’t come from better planning. It comes from extracting angles from real work.

My husband didn’t paint the wall untouched because he had a better mental picture than I did. He painted it untouched because he tested the theory against reality and adjusted based on what he discovered.

Taking time to identify real work before extracting angles isn’t indecision. It’s strategy.

Launching content that comes from actual work rather than forcing it through a predetermined plan isn’t a weakness. It’s how strategic builders actually work.

The content works better because we adjusted based on real material. The system works better because we iterated based on work, not theory.

Not because we planned better the second time.

Because we let reality inform the decision.

One Final Thought

The shift from “generate content topics from strategy” to “extract angles from real work” isn’t a small change in process. It’s a fundamental change in where your ideas come from and why they land.

Your real work is abundant with content angles. You’re just not extracting them yet. You’re trying to generate from thin air instead.

Stop planning your content in the abstract. Start mining it from work you’re actually doing.

Your first piece doesn’t need to be perfect. It needs to be grounded in something real. Everything else follows from there.

Start there.

Here’s what actually happened.

The Part That Was Working

The StoryRefiner is my custom Claude project that takes rough story drafts and extracts key components for my content system

Story Refiner was solid. It took my rough stories and turned them into polished assets with all the components I needed: emotional arc, key details, lesson anchors, SHIFT stages, and headlines.

Beautiful output. Everything formatted. Ready to use.

Then I had to copy each piece into Notion manually.

Split screen. Copy from Claude. Paste into the Notion field. Back to Claude. Copy the next piece. Back to Notion. Repeat.

It worked. But every time I switched screens, I lost momentum.

So I asked Claude: “I’m looking to build a skill that sends my refined stories to my Notion database Master: Story_Components”

The Conversation That Changed Everything

Claude needed to see my database structure first. I sent the link. It fetched everything and saw all my fields: Story Snapshot, Headlines, Scene Snapshots, Emotional Beats, Lesson Anchors, Key Details, my SHIFT framework stages, and YouTube URL.

Claude noticed something: the StoryRefiner output included a Refined Core Story section, but my Notion database didn’t have a property for it. Two options—add a field or work around it.

I explained that the refined story should go in the page body due to its length. The components go in the properties.

Then Claude asked the question that set the automation into play: “For the Name property, what should it be?”

Options included using the first headline, theme keywords, manual entry, or auto-generating from content pillars.

Pause for thinking here...

I’d been thinking about automating this part of the step next. But this question made me realize something.

I manually create a short 3-5 word title for each story.

That title—that’s where I decide what this story is about, a memory jogger if you will. It helps me remember, and it was the most energy-intensive part of the process.

Until I realized that in the refiner, the AI names the thread (three to five words). Problem solved. I’ll just copy and paste that part.

That became the unlock. The “let’s kick this thing off” moment.

So now I just needed to figure out how to kick off the skill at this point.

And that is where the first “aha” automation moment came into play. How would it (it being Claude) know which database to put the story into?

Because in my mind, I’m working from one database at a time, but Claude thinks differently, at least from a Skills perspective.

After some back-and-forth, we landed on adding Notion integration instructions (Option 3) at the end of the StoryRefiner system prompt.

Option 1: Skill (Cross-Project)

Works anywhere in Claude (any project, any chat)
You copy StoryRefiner output, paste in any conversation, say “send to Notion”
Flexible but requires copy/paste between projects

Option 2: Direct Integration in StoryRefiner Project

Add instructions directly to StoryRefiner’s system prompt
After refining, you just say “send to Notion” in same conversation
No copy/paste needed
Lives only in that project

Option 3: Notion Connector in StoryRefiner Project

Use Claude’s built-in Notion integration
StoryRefiner can directly create pages without skills
Simplest approach if you ONLY do this in one project

When It Broke (Repeatedly)

I added the instructions to the StoryRefiner project and started testing.

“Tool execution failed.”

We adjusted. It worked.

By the next morning, it broke again.

Over three days, we cycled through fixes:

• disconnected and reconnected the Notion integration (worked temporarily),

• removed the MCP connection Claude said I didn’t need (same results)1

• tweaked the project instructions (temporary success)

• switched from browser to desktop app for stability (helped, but issues continued)2.

Each fix worked. Then broke.

And each time it broke, Claude wanted me to use manual entry.

Me: “I DO NOT WANT MANUAL ENTRY. We had this working before, so it’s doable unless you can’t continue to handle the workload or automation.”

We were chasing the wrong problem—focusing on MCP connections. I fed Claude screenshots from both API setups.

Then I tried the desktop app again and got a specific error:

Response [{”type”: “text”, “text”: “Tool execution failed”, “uuid”: “8a7011eb-672b-49bd-bb94-21f6c811ab46”}]

Claude saw it immediately:

“I see the problem now! Look at the JSON - all the property names and values are wrapped in backticks (`) instead of double quotes (”).”

Invalid JSON. That’s why it kept failing.

The automation was breaking because of an invisible formatting error in the instructions—like using tablespoons instead of teaspoons in a recipe, where everything looks fine until nothing works.

We fixed the instructions. Reran the tests.

Everything worked.

What This Actually Taught Me

The questions that moved things forward weren’t about building better automation. They were about clarifying what I was protecting.

“For the title, what should it be?” Revealed the title is strategic—it frames the story. That’s mine to decide.

“Should we add a Secondary SHIFT field?” Revealed I was trying to capture too much. The primary stage is enough.

“Look at the JSON - see the backticks?” Revealed a formatting issue I couldn’t see just by looking at the output.

“Try the desktop app instead of the browser.” Revealed the problem wasn’t the logic—it was platform stability.

The Stuff That Happened Along the Way

The backtick bug: One wrong character took the whole process down. I asked for fully rewritten instructions after each change, but I didn’t ask for proper formatting.

The auth instability: Using the browser app isn’t the same as using the desktop app.

The oversimplified instructions: When I fixed the backtick issue, I removed the property mappings. I should have asked for the fully corrected and formatted fix.

None of these were complicated. They were just stuff that happens when you’re building something real.

What to Check When Your Automation Breaks

Is your trigger clear? The 3-5 word title became my trigger. One manual input triggers the automation.

Are you automating strategy or logistics? The title frames the story—that’s strategic. Extracting components—that’s logistics.

Is the formatting actually valid? Backticks vs. quotes. One character. Check your JSON or ask if the instructions are properly formatted.

Is your connection stable? Sometimes it is the connection, so test different scenarios—browser versus desktop.

Did fixing one thing break another? Simplifying the fix of the backtick bug removed the property mappings. Keep a log of the changes you are making.

The Actual Lesson

The clean demo shows what works. The messy conversation teaches you what to protect.

I protected the strategic decision—the title that frames the story.

I automated the logistics—extracting and recording components.

The automation that works isn’t the one that does everything. It’s the one that handles the tedious stuff so you can focus on the decisions that actually matter.

That’s what the video doesn’t show. And that’s what actually matters.

I read the tip in an organizing blog: turn all your hangers backward, then flip them forward as you wear each piece. After a few months, you’ll see exactly what you actually wear versus what’s just taking up space. Simple, clean, done.

So I did it. Hung up all my clothes, flipped the hangers backward. And honestly? It worked for the first part of the purge.

But what they don’t consider: half my closet isn’t hung up at all.

I have jeans folded in a drawer. Sweaters stacked on a shelf. Tees in a separate section. Then there are the pieces that aren’t regular wear—the wedding outfit, the funeral dress, the timeless blazer I wear twice a year but absolutely need. The shoes, belts, accessories that live in their own ecosystem.

The hanger method solved for some of my clothes, but it completely ignored the complexity that actually mattered. I could turn hangers backward all day and still have half my wardrobe making its own decisions in drawers and shelves I wasn’t tracking.

Simple systems look good on paper. But they break the second you acknowledge what’s actually real.

That’s when I realized: the method wasn’t wrong. It was just in the wrong place.

And that’s exactly what happened with my Story Bank.

The Workflow Problem I Didn’t See

I wanted to systematize story extraction. So I built the Story Refiner to pull notes and the start of a personal experience and create ONE comprehensive entry: emotional arc, key details, lesson anchor, best SHIFT stage, story snapshot.

Then I built a complicated Notion database to hold it all. Multiple fields. Nested properties. Filters. Related databases.

It was comprehensive. Strategic. On paper, it seemed perfect.

But here’s what I actually needed to do to create content:

1. Brainstorm content ideas

2. Choose a topic

3. Find a story that matched that topic

4. Extract the components that served that specific piece

5. Write the article

6. Publish

7. Repurpose

I had Story Refiner extracting and storing stories before I knew what topic I was writing about. The database was full of pre-refined stories with pre-determined uses. But I wasn’t using them during content creation—I was creating content first, then trying to force stories into topics they didn’t naturally fit.

The method wasn’t broken. It was just in the wrong place in my workflow.

You Can’t Extract Before You Know What You’re Extracting For

Most people think when a system isn’t working, they didn’t execute it well enough. Need to refine it. Tweak it. Make it work better.

But here’s what I discovered: sometimes the problem isn’t the method. It’s when you’re trying to use it.

If you try to solve a decision before you have the information you need, here’s what happens: you build something comprehensive that attempts to anticipate every possibility. You end up with options that feel like they could work but don’t actually serve your current need. You skip the system during real work because you already know what you need. You eventually abandon it because it’s trying to solve a problem you don’t actually have yet.

That’s not poor execution. That’s a method placed too early in your workflow.

Here’s what I was missing: I thought Story Refiner should extract five possible uses for every story. But I didn’t have a topic yet. I was trying to extract for theoretical uses instead of extracting for actual needs.

The database was trying to solve “what could this story be used for?” before I’d answered “what do I actually need to write about today?”

Different questions. Different information available. Wrong point in the process.

How I Realized the Workflow Was the Problem

The moment I really understood something was wrong was when I sat down to create content.

I’d choose a topic. Open the Notion database. Look for stories that matched. Find pre-refined stories with their five suggested uses. None of them felt right because they were refined for theoretical possibilities, not this specific piece I was writing.

So I’d skip the database and just write from memory.

The system I’d built wasn’t getting used during the actual work. That’s data. The method wasn’t in the right place.

So I asked a different question: when do I actually have enough information to decide which story components matter?

Answer: after I’ve chosen the topic.

Not before. After.

That’s when I understand what this piece needs. That’s when I can ask “what emotional arc serves this topic?” That’s when I can extract components that actually fit.

So I moved the entire process.

Instead of: Brainstorm → Extract stories → Choose topic → Write

I rebuilt it as: Brainstorm → Choose topic → Extract components for this topic → Write

Story Refiner didn’t move. The timing did.

Now the database wasn’t holding five pre-refined uses. It was holding the raw stories. When I chose a topic, I used Story Refiner in that moment to extract the components that served that specific piece.

Same tools. Same process. Different place in the workflow.

Everything changed.

The Smarter Approach: Map Your Workflow, Then Place Your Method

Here’s how to recognize when your method is placed too early—and how to move it to where it actually works.

Step 1: Map Your Entire Actual Workflow (10 minutes)

Don’t think about what should happen. Map what actually happens.

Ask: from idea to completion, what are my actual steps?

For content creation, mine is:

1. Brainstorm content ideas (what topics matter?)

2. Choose a topic (what am I writing this week?)

3. Match story + lesson to that topic (which story serves this specific piece?)

4. Write the article

5. Publish

6. Repurpose

Write yours down. Step by step. What you actually do.

Step 2: Identify Where Your Method Is Placed Right Now (5 minutes)

Look at your workflow and ask: at which step am I currently trying to use my method?

For me: I was trying to use Story Refiner at Step 1 (brainstorm). I was extracting and storing before I knew what I’d need.

Where is yours placed?

Step 3: Ask: Do I Have Enough Information Here? (5 minutes)

This is critical. At the step where your method is placed, do you have enough information to make the decision your method is supposed to help with?

For me: at the brainstorm step, I don’t know what topic I’m writing about. So I can’t extract components that serve a specific topic. I don’t have enough information.

At Step 3 (after choosing topic), I do. That’s when I can say “this topic needs this emotional arc” or “this needs this key detail.”

Where do you have enough information to use your method? That’s where it belongs.

Step 4: Move Your Method to the Right Point (10 minutes)

Take your method and place it at the step where you actually have the information you need.

For me: move Story Refiner from Step 1 (before topic choice) to Step 3 (after topic choice).

New workflow:

1. Brainstorm content ideas

2. Choose a topic

3. → Use Story Refiner to extract components that match THIS topic

4. Write the article

5. Publish

6. Repurpose

Same method. Different place. Now it serves an actual decision.

Step 5: Test During Real Work (1 week)

Use the method at its new place in your workflow during actual content creation.

Do you use it? Does it give you what you need? Does it make the work smoother?

For me: yes, yes, and yes. When I choose a topic and immediately extract components for that topic, the method becomes essential instead of optional.

Why this works: you’re not forcing a method into a step before you have the information you need. You’re placing it where it actually serves a decision you’re making. Which means you use it.

Here’s the Prompt You Can Use for Your Own Workflow

Use this with Claude or your AI tool to find where your method should actually be placed:

I’m trying to streamline my [specific process: content creation, client onboarding, project management, etc.].

Here’s my current workflow from start to finish:
[Describe each step of what you actually do]

I built a system/method to [describe what you’re trying to do].

But I’m trying to use it at this point in my workflow: [describe when]

And I’m not actually using it because [describe the friction].

Help me:
1. Map out where this system/method is currently placed in my workflow
2. Identify what information I have at that point vs. what information I actually need to make this decision
3. Find the actual point in my workflow where I’d have enough information to use this method effectively
4. Redesign the workflow to place the method at that point instead

Show me step-by-step what my workflow should look like with the method in the right place.

What Other Creators Miss About Method Placement

When creators get stuck with systems that don’t work, they usually think it’s an execution problem. But sometimes the problem is simpler: the method is trying to solve something before you have enough information.

One creator built a client intake form that asked 20 detailed questions about their needs, budget, timeline, and past experiences.

Comprehensive. But she was using it before the initial conversation.

The prospect didn’t know enough about what she offered to answer accurately. She moved it to after the first call, when they both understood what they were looking for.

Same form. Different place. Suddenly it worked.

Another built a decision framework with five criteria for evaluating opportunities. Good framework. But she was evaluating opportunities before she understood what her business actually needed. She moved the framework to after she’d clarified her strategy. Same framework. Suddenly it made sense.

Here’s what they had in common: they placed their methods too early in their workflow, before they had enough information. The methods weren’t wrong. The timing was.

The shift happens when you ask: at what point do I actually have enough information to use this method? And then move it there.

For me, it was realizing Story Refiner needed to be used after topic choice, not before. Once I moved it, everything worked.

Where in your workflow is your method placed too early?

The Real Cost of Methods Placed Too Early

If you keep trying to use a method before you have enough information, here’s what happens:

You build the method carefully. You prepare comprehensive inputs. You try to use it during real work and realize you don’t have what you need yet. You skip it and solve the problem manually. You feel like the method failed. You eventually abandon it because it’s creating friction instead of removing it.

That’s not failure. That’s misplacement.

But here’s what changes when you move your method to where you have enough information:

You build the method for actual use. You place it at the decision point where you need it. You use it immediately during real work because it serves what you’re actually deciding. You get the efficiency you hoped for because the method is doing what it’s supposed to do at the right time.

That’s when methods actually work.

From Early to Right-Timed

I didn’t move Story Refiner GPT. Story Refiner stays exactly where it is—as the first step, extracting everything from every story.

Here’s what actually changed: I started recording the components in Story Bank itself.

Before, Story Refiner extracted emotional arc, key details, lesson anchor, best SHIFT stage, story snapshot. But those components lived nowhere accessible. They weren’t in the database. They were just in my head or scattered in notes.

So when I got to Step 3 (choosing a topic and matching a story), I couldn’t actually search the components. I couldn’t filter by “stories with vulnerability arcs” or “stories that teach Filter-stage lessons.” The components existed but weren’t recorded in a way I could use them.

Now, every component Story Refiner extracts gets recorded directly in Story Bank. Emotional arc as a field. Key details as a field. Lesson anchor. Best SHIFT stage. All searchable. All filterable.

That’s the only change. Story Refiner still runs first. Still refines. But now those components live in the database where I can actually automate the matching.

Now automation can help me find which story serves which topic because the components are recorded and searchable in Story Bank.

Same Story Refiner. Same extraction power. But the components being recorded in the database is what makes the whole system work—because it enables automation to match stories with topics during the actual content planning step.

The backward hanger trick works if you record which hangers got flipped. Without that record, you can’t see the pattern. Story Refiner works. But without the components recorded in Story Bank, you can’t automate the matching. Recording them in the database is what made everything automatable.

Watch me walk you through my journey of building the Story Refiner, a powerful and highly-refined content story workflow that hit a snag when automating the process.

Here’s What You Should Actually Be Doing

Look at one system or method you built that isn’t getting used during real work.

Ask yourself: at what point in my workflow am I trying to use this? Do I have enough information here to make this decision?

Be honest. Most unused systems are placed too early, before you have what you need.

If yours is, don’t rebuild it. Just move it to where you actually have the information.

The backward hanger trick didn’t fail because the method was wrong. It failed because you can’t track what you wear while you’re getting dressed. The complicated Story Bank didn’t fail because the method was wrong. It failed because you can’t extract for a specific topic before you’ve chosen one.

What method are you placing too early in your workflow? Reply and tell me what you’re maintaining at the wrong point in your process.

Right until I squeezed the brake handles and nothing happened.

You know that feeling when you're committed to something and suddenly realize you're completely unprepared? That stomach-drop moment when the thing you thought would work... doesn't?

When the Obvious Comes Too Late

Growing up, I was fearless and curious, so I was always getting myself into predicaments, as my mom would say. Some led to broken bones or groundings, others to pats on the back or an "atta girl." This particular one included a bike ride down a steep hill after a heavy rainstorm.

The hill was slick with fresh rain, and I was picking up speed fast. The obvious kicked in too late—wet roads, steep hill, broken brakes. Classic recipe for disaster.

Which led to a hospital visit and an arm cast for the summer. The lesson seemed crystal clear: check your brakes before riding a bike down a hill, especially when the roads are wet.

The Lesson That Wasn’t the Lesson

But here's what I wasn't prepared for.

The funny thing about lessons is they're not learned until after the fact. Should I have ridden the bike without brakes? That's a big no. Should I have done things differently, like check the brakes first? Yes, why yes, I should have.

But the real question dawned on me later: should I have even been on the bike in the first place?

That answer was no—not because of the weather or the brakes, but because I was not supposed to be on the bike in the first place.

What We Miss When We Only Analyze the Crash

What hit me years later wasn't about better safety checks or improved decision-making skills.

"I was looking at the outcomes and not the parameters of what got me here," I realized, deep into running my own business.

It wasn't so much that the bike was forbidden. However, sometimes we analyze the crash without questioning whether we should have been on that particular path at that moment, given everything else that was happening.

I'd spent years thinking about checking the brakes when I should have been questioning the entire scenario.

Stop Fixing the Wrong Thing

Here's what drives me crazy about most business advice: we're obsessed with fixing our execution when we should be questioning our parameters.

Every week, I talk to others doing exactly what young me did. They're analyzing their "brake failures"—why their launch flopped, why their marketing didn't convert, why their strategy felt so hard to implement.

But they're asking the wrong questions:

• "How can I improve my email open rates?" instead of "Should I even be focusing on email right now, given my current situation?"

• "What's wrong with my sales process?" instead of "Are the parameters of my business supporting this approach?"

• "Why didn't this strategy work for me?" instead of "Should I have been pursuing this strategy in the first place?"

The most successful business owners I know aren't better at execution. They're better at reading their parameters before they commit to the hill.

Someone Who Asked a Better Question

from The Business Within: Kim could have continued to perfect her WordPress expertise and doubled down on what she was "supposed" to do as an established business owner.

Instead, she stepped back and asked a different question: what actually energizes me now? The answer led her to embrace AI and pivot to "vibe coding"—not because the old way was broken, but because the parameters of what fulfills her had shifted.

Even as GenXers, we don't have to follow the playbook of playing it safe. Sometimes the real change isn't about better execution—it's about bucking the norm for what lights you up.

The Real Lesson

The best business decisions aren't about having better brakes—they're about recognizing when you shouldn't be on the bike.

Sometimes the real lesson isn't about doing things differently. It's about questioning whether you should be doing them at all.

The Reframe That Changes Everything

This isn't about being more cautious or overthinking every decision. It's about looking at outcomes and parameters, not just tactics and execution.

Instead of: "How can I do this better?"
Ask: "Should I even be doing this given my current parameters?"

Instead of: "What went wrong with my approach?"
Ask: "Was I supposed to be on this path in the first place?"

What I Wish I’d Known Sooner

Here's what I wish someone had taught me earlier: most business struggles aren't execution problems—they're parameter problems.

What if your biggest challenge isn't that you need better tactics, but that you need to identify where you're actually stuck in the decision-making process?

Think about your last business "failure." Were you fixing the brakes or questioning whether you belonged on that bike?

A Better Way to Find Your Stuck Point

Stop guessing where you're stuck. I created the Problem Spotter specifically for this—it uses the proven SHIFT framework to help you identify exactly where you're hitting resistance in just 5 minutes.

Because here's what I've learned: you can't fix a problem you haven't properly identified.

1. Take the Problem Spotter Quiz - Find out if you're stuck at See, Harness, Implement, Focus and Filter, or Take Stock. Take the quiz.

2. Get your specific next steps based on your actual stuck point, not where you think you should be

3. Stop wasting time on solutions that don't match your real challenge

Don’t Just Work Harder. Think Smarter.

Ready to stop fixing the wrong things?

Make your next business move with confidence. I provide 'thinking partners' that help you filter out the hype and focus on the simple, right-for-you actions to grow your business.

Curious what a 'thinking partner' is? Try my free customGPT and experience one for yourself. It's a simple, guided chat that will give you clarity on your biggest challenge in the next few minutes.

Because sometimes the best lesson isn't about better execution—it's about better questions.