Daniel Blum's Claude system learns the work around the work

Daniel Blum's Claude system learns the work around the work

Daniel Blum's Claude workflow shows how persistent context, connected tools, and feedback from everyday edits can turn an AI assistant into a practical PM work system.

Daniel Blum, a product manager at Melio, built a Claude- and Cowork-based system that manages a Notion board, reads work context, prepares his week, and reviews its own mistakes. In a conversation with Claire Vo on How I AI, he says the system now handles 70% to 80% of the time he spends at a computer. The important idea is less dramatic than an autonomous employee: the useful part comes from connecting an AI assistant to the routines that surround a task, then giving it a way to learn from the corrections that follow. 12
Loading content card…

The problem is the work around the work

Blum began with the part of product management that keeps interrupting product management: tasks appear in Slack, meetings create action items, email adds more requests, and a PM still has to remember what matters while researching or making a decision. The coordination layer consumes attention before the deeper work begins. 3
His system gives that layer a place to live. A Notion board has sections for large initiatives, this week's priorities, and an inbox for work that arrives through Slack, email, meetings, and other tools. Cowork can update the board on his behalf. Blum describes Notion as almost read-only for him now: he looks at the board to regain focus, while Claude handles much of the sorting and maintenance. 3
The arrangement changes the question a PM should ask about an AI assistant. The relevant test covers the small events that create work: Can the assistant notice them, place them in the right context, and return them when a decision is needed?

Architecture matters more than the model name

Blum reduces the design to two conditions. The system must be able to rewrite its own core files, so the setup can improve over time. The system must also connect to the tools already used at work. Blum says the same pattern could be built with Cowork, Codex, or ChatGPT Work; the product name matters less than whether the assistant can change its operating context and reach the surrounding software. 3
The distinction separates a prompt from a work system. A prompt gives an assistant instructions for one response. Blum's arrangement gives the assistant a place to store operating knowledge, a set of connected inputs, and recurring jobs that move information through the workflow. The Notion board becomes a visible state of the work that the PM can inspect while the assistant handles much of the maintenance.
The design also explains why tool choice alone rarely produces a large productivity gain. A powerful model isolated from a calendar, task list, messages, and company documents still has to be reintroduced to the work at every step. The assistant becomes more useful when those handoffs become part of the architecture.

Context is a maintenance loop

Blum spent months giving Claude voice memos, links, slide decks, and long explanations of his work. He organized that material into context files for topics, goals, colleagues, and other parts of his job. Recurring tasks update those files every few weeks, so the assistant has a way to keep up with changes inside the company. 3
The morning brief adds a second layer. Claude reviews recent Slack messages, email, and meeting notes, then looks for terms or projects that do not fit the context it already has. When the brief encountered "settlement cap," it understood the surrounding thread and still asked Blum to confirm the term before saving it. The assistant was doing two jobs at once: retrieving relevant information and finding the boundary of its own understanding. 3
That pattern gives a workplace system a way to keep its context current. The open questions concern approval and access: who approves new context, where permissions stop, and how the system records the difference between a fact, a temporary decision, and an old assumption.

Improvement comes from the edits people already make

Blum's weekly self-improvement loop looks at the gap between what Claude drafted and what Blum eventually sent. When Blum changes the first draft before delivery, the difference becomes evidence about how he writes and decides. A second part of the loop surfaces recurring tasks that might deserve their own skill. A third collects friction: when Blum asks for a fix, the system records that problem and later proposes changes to the underlying workflow. 3
The mechanism uses behavior that already exists. Blum does not have to stop after every response to write a training label. The final message, the correction, or the repeated request supplies a quieter form of feedback. The system can still make a bad change, so a human approves the proposed update. The loop reduces the cost of noticing patterns while judgment stays with the person using the workflow.
Blum also built an "Improve" skill to examine the stream of advice about AI workflows. He can send a new tip to Claude and ask whether it fits his setup, solves a real problem, or deserves to be built. The skill acts as a filter between an external idea and an internal change. 3

Personalization is the adoption problem

A system that works for one PM can fail when a team adopts it. Blum learned that after building a spec-writing tool around his own working style. Other PMs could see its value, yet the tool assumed they had the same voice, context, and habits. He responded with a Workstation plugin that connects a colleague's tools, maps the relevant people, and learns that person's way of working in about 15 minutes. 3
The lesson is a product lesson as much as an AI lesson. A shared capability needs a shared starting point, while a useful workflow still needs personal context. A blank prompt gives every employee the same surface. A short onboarding flow gives each employee a version that can recognize their work. The system becomes easier to adopt because the first useful result arrives before the employee has to design the whole system alone.

The missing capability is persistence

Blum's estimate of 70% to 80% comes with a clear limit. Claude can manage much of the work while his computer is available, while reliable cloud operation still requires another layer. Blum is preparing for that gap by teaching the system what a closed task looks like. When a drafted Slack message is no longer saved, the system may infer that the message was sent. 3
That detail points to the real test for an AI coworker. Model intelligence is one part. The workflow also needs continuity, controlled access, a feedback path, and a reliable signal that tells the assistant when work is complete. Without those four pieces, a capable model remains a collection of useful sessions.
Blum's system offers a practical way to judge workplace AI claims. Ask what the assistant remembers, which tools it can reach, how it learns from edits, and how it knows that a task has actually ended. The answer will reveal more than the model name on the product page.

References

  1. 1
    How I AI episode page

    lennysnewsletter.com

  2. 2
    Apple Podcasts episode page

    podcasts.apple.com

  3. 3

This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.

Related content

More from this channel