Context

Daniel Blum is a product manager at Melio, a B2B payments company, and an early AI adopter working inside the normal limits of a corporate stack: fixed tools, capped tokens, and a budget. On How I AI, host Claire Vo has him screen-share the actual Claude "co-work" system he uses to run most of his day. The episode is not about a clever prompt. It is about the operational overhead that quietly eats a PM's week, the endless Slack threads, meetings, and action items, and how Daniel built a system that absorbs that coordination load so he can spend his real hours on deep work. It matters because the setup is deliberately built within constraints most PMs actually face, not a researcher's unlimited playground.

The Big Idea

The unlock is not a single tool or prompt. It is a system that can rewrite its own instruction files and is deeply wired into your whole work ecosystem, so it keeps getting better and closer to how you actually work with almost no ongoing effort from you.

Once those two properties are in place, the assistant stops being a smart autocomplete and becomes a partner that manages your task board, catches things you would have dropped, and improves itself weekly. Daniel says the payoff is real: he now does in a day what used to take a week, and does deeper, more data-backed work than before.

Key Insights

1. Two rules make a system self-improving

Daniel argues the specific tool matters less than two properties. First, the system must be able to rewrite its own core instruction files, so it keeps improving instead of staying frozen at day one. Second, it needs connections and integrations into as much of your ecosystem as possible (Slack, email, calendar, docs, meeting notes). He uses Claude co-work, but says Codex or ChatGPT could work too. Gemini Gems could improve specs and research, but lacked this self-rewriting, deeply-integrated quality, which is what turns a helper into a system.

2. Notion as a read-only source of truth

His Notion board has three sections: Top of Mind (large initiatives), This Week (current priorities), and Inbox (items pulled from Slack, email, and calendar). The point is not the board itself. Co-work built it (it "got tired of" his messy Google Doc and made this on its own) and it manages the board on his behalf. Daniel treats Notion as almost read-only: he looks at it to get his focus and occasionally marks something done, while Claude does the updating. The clean planning surface is an output of the agent, not another thing he has to maintain.

3. Contextualize ruthlessly before the ROI shows

The system knows him well only because he front-loaded a lot of context. He built a separate context file for every topic, work area, goal, and colleague, feeding it links and decks and dictating long streams of thought with Whisper. The system then updates those knowledge files itself every few weeks. How well it knows him showed when prepping this episode: with one prompt to a "demo" skill, it swapped every real name and initiative for generic terms (his manager became "your manager," his top initiative became "headline feature") because it already understood what each thing was.

4. An agent that audits its own context

The standout idea, which Claire noted she had not seen on the show before, is proactive gap-detection. In the daily brief, co-work scans recent Slack messages, emails, and Granola meeting notes and looks for things it does not understand: an unfamiliar file, a milestone, a goal, a term. It then asks him about them. On the live demo it flagged "settlement cap," a payments term, read the thread, inferred the meaning, and offered to save it to context. Most company-specific language is not in a model's training data, so having the agent insist on filling its own blind spots is what keeps it useful over time.

5. Learn from the draft-to-sent gap

Normally Claude drafts something, Daniel edits it, and sends it, and the model never learns what changed. His weekly loop closes that gap: it finds drafts it wrote that he did not reply to, checks whether he sent a different version, and learns from the difference between its draft and his final text. This uses an indirect signal (the rewrite itself) rather than asking him to grade outputs, so the writing style improves passively. Claire compared it to a "write-like-me" loop but noted this version is sharper because it mines behavior he was already producing.

6. Clean plans versus messy reality

Daniel names a tension every PM feels: the beautiful, organized world of a roadmap or weekly plan, and the real world of Slack pings, urgent asks, and executive requests flowing in all day. Early on he felt a gap between what he planned and what actually happened. He fixed it by teaching the system his real working conventions, so it operates in the mess with him rather than only maintaining the tidy version. Example: he is inbox-zero, so the system infers that a Slack item no longer saved is probably done, and an email no longer in his inbox is probably read.

Mental Models & Frameworks

The two anchor automations

Daniel runs two scheduled co-work tasks that bookend his time.

• Weekly prep (Sunday): a composition of several skills that pulls from Notion, calendar, Slack, and Granola meeting transcripts, then recommends what to focus on, what to add or drop from Top of Mind and This Week, and how to prep for each upcoming meeting (serious prep that becomes its own task, a quick reminder, or nothing needed). It writes the result into Notion.
• Morning brief (daily): recaps yesterday's meetings from Granola transcripts as one-liners with any action items, then runs the context gap-detection pass described above.

Use this as a template: one weekly task to set direction, one daily task to catch up and stay current.

The self-improvement loop

A weekly scheduled task made of four skills that improve the system with little dedicated effort:

• Draft learning: compares its drafts against what he actually sent, and learns the gap.
• Skills worth building: watches for things he does repeatedly and suggests turning them into reusable skills. Many of his skills originated here.
• Friction fixes: every skill and task has lines instructing it to log feedback and friction during use; the loop surfaces the top frictions each week and proposes fixes.
• The Improve auditor: a critical reviewer for the flood of AI tips from X, LinkedIn, and newsletters. He forwards a post to a Slack channel and asks whether it is real, whether it is powerful, whether it fits his current setup, and whether it is needed, so he adopts what is useful without drowning in hype.

Onboarding UX as the scaling mechanism

Daniel's org-wide version, the "workstation," is an operating system built in co-work (chosen over Claude code specifically for simpler UX). Its key feature is a guided in-chat onboarding: it connects your tools, confirms your role, maps your colleagues and management, reads your calendar and Slack, builds your writing voice, and captures your goals, in about 15 minutes. It started for PMs at Melio and spread to all employees. The lesson underneath it: a system that works for one person does not transfer until it can set itself up for someone new.

Decision Principles

Principle: Wait for the tool that fits

• When: a powerful tool exists but is built for a different user than the one who has to adopt it.
• Why: Daniel deliberately sat out the Cursor and Codex hype because those felt too technical for a PM, and waited for co-work, which won on UX and simplicity. For broad adoption, an accessible tool with clear value beats a more powerful tool people struggle to use.

Principle: Do the work where context is captured

• When: choosing whether to do a task inside your agent or in another app (Jira, a Slack query, a browser tab).
• Why: Daniel routes 70 to 80% of his computer time through co-work because anything done elsewhere is context the system does not capture as well, which weakens every future interaction.

Trade-offs & Nuance

Upfront friction versus compounding ROI

Early on the return looks bad. Before the system knows your business logic and working style, it is friction-full, its outputs are slightly off, you lose trust, and you double-check everything. Daniel's claim is that the value compounds sharply if you power through the first few weeks of ruthless contextualizing and centralizing, even when it does not feel natural. The trade-off is real: this approach is a poor fit if you cannot invest that early, low-payoff stretch.

Switching cost versus muscle memory

At a company level, Daniel tells people the old way will genuinely be faster at first because it is muscle memory, and the new system will be less efficient during the switch. He still argues for pushing through, because the endpoint is both a better system and a team that has leveled up its AI skills. The honest framing is that you are trading near-term speed for a higher ceiling, not getting a free upgrade.

Common Mistakes

Mistake: Building only for yourself

Daniel built a spec-writing gem ("spectacular") tuned perfectly to how he worked, then watched other PMs struggle with it in live demos because it assumed his habits. The fix was adding a guided, hand-in-hand UX that tells a new user how to work with it. The mistake is assuming a tool that is complete for you is ready for anyone else.

Mistake: Chasing every AI tip

The constant stream of "you must build this" advice from social feeds and newsletters is overwhelming, and blindly acting on it leads to a bloated, incoherent setup. Daniel's Improve skill exists precisely to resist this: it critically evaluates each tip against what he already has before he builds anything. He even ran it against Claire's own episode on designing loops, and it pointed out that loops are essentially scheduled tasks he already runs, while flagging the parts genuinely worth adopting.

Practical Application

Build a context file per area

Create one context file for each topic, goal, and key colleague, and seed it aggressively: paste in links and decks, and dictate long, unstructured brain-dumps with a voice tool rather than typing polished notes. Then instruct the system to refresh these files on a recurring schedule so the context does not go stale.

Add a gap-check to a daily brief

Set up a scheduled task that scans your recent Slack, email, and meeting notes for terms, files, or goals the assistant does not recognize, and has it ask you to explain them and save your answer to context. This steadily closes the assistant's blind spots on company-specific language without you having to anticipate them.

Capture friction inside your skills

Add a line to each skill or automation instructing it to log feedback and friction whenever you interact with it, then run a weekly review that surfaces the top friction points and proposes fixes. This turns everyday annoyance into a maintenance backlog you did not have to write down.

Make a team onboarding skill

Instead of teaching teammates your AI setup step by step, build a shared skill that sets it up for them: connect their tools, confirm their role, map their org, capture their writing voice from their Slack and email, and record their goals in one guided flow. Let your most AI-fluent people extend it, and give everyone shared ownership.

Questions to Consider

• Which parts of your current AI setup are frozen the day you build them, and could you give the system permission to rewrite its own instruction files instead?
• Where is the gap widest between your tidy roadmap or weekly plan and the actual Slack-and-meetings chaos of your day, and could an assistant operate in that mess with you rather than only maintaining the clean version?
• What company-specific terms, files, and goals live only in your head, and how would an assistant ever learn them unless it actively asked?
• When your AI drafts something and you rewrite it before sending, is that correction being captured anywhere, or is the same edit lost every time?
• Is your personal AI system transferable to a new teammate in 15 minutes, or does it silently assume all of your habits?

Bottom Line

A genuinely useful PM assistant is not the smartest single prompt, it is a system you have wired into your whole workflow and allowed to rewrite itself, so it manages your priorities, audits its own blind spots, and improves weekly. The upfront cost of contextualizing it is real and the early payoff is poor, but Daniel's experience is that it compounds into doing in a day what used to take a week.

Tools & Products

People to Follow

Daniel Blum

A product manager at Melio and an early, pragmatic AI adopter who builds within real corporate constraints (fixed tools, limited tokens). Worth following for concrete, reproducible PM automation systems rather than abstract AI takes. He shares resources and part of this system on his site, DanielBloom.com, and posts on LinkedIn.

Claire Vo

Host of How I AI and a product leader focused on practical AI workflows. Her episodes consistently pull working operators into screen-sharing their exact setups, including the "designing loops" episode referenced here.

Notable Quotes

"I'm really able to do in a day now what used to take me a week." (Daniel Blum)

"So many of us work inside companies where the things that we say are not in the training data. And so actually proactively prompting Claude to say, I don't understand what you're talking about here, can we define it together, is really, really sharp." (Claire Vo)