Operational Intelligence With ICM

This is a brain dump turned into a post, summarizing the work I've done with Jake's ICM method. I want to share what I've learned to see how these use cases resonate and what I could do better.

It took me probably two months of reading through the community and using the resources available before this actually clicked. What did it for me was a post

@Curtis Hays

wrote a few months back (https://www.skool.com/cliefnotes/the-folder-system-became-my-agency?p=1e30aba0).

Reading that post is what helped me understand how this actually works, and I'm hoping this post can do the same for someone else. There are a lot of different ways to come at this.

>>>How I wrapped my head around this

I lead development teams, and I also do what I'd call typical project or product management work. So a lot of how I thought about this started with a simple question: what are the most common things I produce or share, at a daily, weekly, or even monthly level? I wrote those things down. From there I asked how they actually get created, where they start, what the process of drafting or iteration looks like, and where they end up.

About 50% of my day is spent on the phone, and most new ideas, action items, and questions come out of those calls. Sometimes it's email, but most of the time it's calls. Before, I'd use AI to help draft or compile something, but I was feeding it context manually every time, sometimes a brain dump on the call itself, sometimes a brain dump afterward. I'd work on the thing, it would spit something out, and I'd save it or send it. What I realized was that I needed a way to take the information from those calls and actually store it, so I could recall it and use it again for whatever needed to happen next.

Here are 4 different use cases of how I use this ICM framework. The first 2 are functional, I use them everyday. The last 2 are more ideas, but only because the opportunity to implement has not presented itself just yet.

>>>1. Meeting intake

I try to record as much as I can, using the existing recording features on Teams or Zoom when I can, because the raw transcript is the most valuable thing to me. When a call isn't on one of those platforms, I use the voice memo app on my iPhone. I didn't want to pay for another tool just for this because we all know these AI tools are just wrappers...

I have a shortcut on my iPhone, I click a button, and it creates an email with a specific subject line tracking system. That's how Claude knows to go find these transcripts in my inbox. I put the transcript in the body of the email and send it to myself. My Gmail is the front door into the whole system.

From there I have a skill, agent instructions, that I still trigger manually (I could automate it, I just don't need to yet). I tell it to go process all the email transcripts in my inbox. It knows not to touch the ones it's already processed. It takes the raw transcripts and runs them through the same structure every time, same file naming, same format. Then, based on a list of my active projects, it decides which project folder the summary belongs in. If I just did a quick brain dump (how I drafted this post) and it's not obvious where it goes, it asks me. That's the human in the loop part.

>>>2. Product management

Once something lands in the right folder, that's where the product management use case picks up. The structure is pretty simple: call logs go into a captures folder, and inside that there are subfolders for where the capture came from: user calls, stakeholder input, and most often internal team meetings. The skill files the summarized call into the right one.

The other outputs I actually produce as part of these products are stakeholder updates, user stories, mockups, and marketing or outreach copy. Because the folder already knows the context of the product (I gave it that context once, and it's kept building on it for months now), I can go in and work on any of these using Claude Code as the interface. If someone mentioned something on a call, I can say let's go deep dive that and structure it into a story.

I have weekly check ins with our core team, and a skill that gives me a prep update before that call: what shipped, what's being discussed, what action items are still open. About every six weeks we also do a larger stakeholder update, a PowerPoint (the worst). I have a folder for that specific update with templates and past decks as reference, and a skill that drafts a steerco update for the date based on what happened over the past six weeks. It's not final by any means, but the value is that the system stays up to date and I'm using it to brainstorm and track things as I go, not starting from a blank page. When I have the actual stakeholder call, I feed that transcript back in too, so the system knows what got covered, and I keep an action item log the same way, with its own skill that drafts what it can of the log.

Two key skills that I use for every session are called 'session-start' and 'session-end'. This is my stenographer and how I keep the context, project_knowledge, global_knowledge markdown all update to date. I found these from another PM, happy to share this out (I cant find the original link to his repo).

Day to day, the upside has been that I don't have to remember where everything is anymore. Not that I was great at that before, but now, as long as I keep it up to date, it's just there, sitting in single markdown files on my Google Drive. The downside is that I don't remember things as well as I used to. That's not necessarily a bad thing, it's just a real shift in how I operate, and I'm still figuring out the balance, how much cognitive load I hand to the system versus keep for myself.

Overall it's been a real change. I feel like I could take on two or three more projects because of this system, and I spend more time on the creative and outreach work, and less time drafting a report or a PowerPoint I didn't actually enjoy putting together anyway.

[VISUAL: pipeline arc] Capture, a call becomes a transcript, leads to route, structured and filed into the right project folder, leads to outputs, stakeholder update, steerco deck, action item log, whatever the actual ask is, and the same line keeps going into the two use cases below.

>>>3. Where I think this goes, part one

Use cases three and four are more aspirational, how I think this could apply, not something fully built yet.

I work in the AEC industry, and we work on large capital programs. The most granular these programs get split up is by subject matter expert (SME), different specialists coming in and working on specific parts of a project. The idea is the same as what I built for product management: if teams and SMEs at minimum update the system of record we already keep, calls with clients, meeting minutes, agendas, submittals, into a subfolder across the whole project, the model could build a log or record of history the same way it does with call notes now. At a project manager level, you could go in and see quickly what the status of something is, or when something was last submitted.

Further out, I think about tracking spend versus what people are actually delivering, a more realistic picture because you're effectively tracking behavior, and you could just ask the model to run that analysis. And if the SMEs themselves used the model and the harness for their own development, creation, or analysis, that history of work product gets retained too, as a byproduct of them just doing the work.

>>>4. Where I think this goes, part two

Use case four is the culmination of all of this. If multiple products or projects used the same kind of folder structure, or at least a similar capture and repository pattern, you could run queries across all of them, insights, updates, problems, concerns. The opportunities there are real, not overstated, but only if people actually keep these systems up to date. That's the key behavior change underneath all of it.

If that's true, the ability to understand where things sit without waiting on someone's response, or without someone being out of town, or someone rolling off a project and needing to get a new person onboarded, becomes easy, because the information is already there. Nobody's digging through emails or reconstructing past decisions with a client from a pile of files. It's just, here's a skill, onboard this person for this part of the project, or for all of it.

That's what I mean when I call this operational intelligence, or organizational memory. It becomes a real asset for these industries and clients, and I think it transfers fairly easily to other industries too, because underneath all of it, these folders are just standard operating procedures that already exists (maybe in someones head or a crap PDF) they just need to be converted into a format that the models ingest (folders and markdown).

[SKILLS LIST GRAPHIC]

Process email transcripts (meeting intake, dedupe, structure, route)
Weekly prep update before core team check ins
Steerco and stakeholder PowerPoint update, roughly every six weeks
Action item log, drafted and kept current on its own
Start and end session skills, keep the folder itself trustworthy

>>>Where I still don't know the answer

I'm still figuring out the balance between what I hand off to the system and what I keep in my own head. And I don't know yet if the cross project rollup in part four is something I actually build next, or a good idea that stays a good idea for a while longer.

What would you put in a folder like this if you started today? And is there a question you're still answering from memory that you shouldn't have to be?

2 comments

Operational Intelligence With ICM