Building an Automation: The Method That Overcomplicated Everything
Your method isn't broken—it's placed too early in your workflow. Here's how to find where it actually works.
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:
Brainstorm content ideas
Choose a topic
Find a story that matched that topic
Extract the components that served that specific piece
Write the article
Publish
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:
Brainstorm content ideas (what topics matter?)
Choose a topic (what am I writing this week?)
Match story + lesson to that topic (which story serves this specific piece?)
Write the article
Publish
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:
Brainstorm content ideas
Choose a topic
→ Use Story Refiner to extract components that match THIS topic
Write the article
Publish
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.