title: "我用 Claude Cowork 搭建了一套让 PM 一天完成一周工作的系统"
source_url: "https://www.youtube.com/watch?v=p2qmX6TM0kw"
author: "How I AI"
excerpt: "公共早报 Daniel Bloom 讲述如何将 Claude Cowork 打造成一套富含上下文的 PM 工作系统，用于规划工作、收集反馈，并逐步学习其决策背后的个人规则。"

Brief Description

Daniel Bloom explains how he built a Claude Cowork-based operating system for product-management work. The system centralizes context, turns scattered work across Notion, Slack, email, calendars, and meeting notes into weekly and daily workflows, and uses feedback loops to improve itself. The conversation covers the system's design principles, its practical routines, the costs of adoption, and how Daniel is turning a personal workflow into a reusable team workstation.

Table of Contents

• Why a PM needs an AI operating system

• The two requirements for a useful Cowork system

• Notion as a managed source of priorities and context

• Building and refreshing a personal context layer

• Weekly preparation and the daily brief

• Learning a user's working patterns

• Compounding productivity and deeper work

• Self-improvement loops for drafts, skills, and friction

• Scaling the system through a team workstation

• What still needs to become autonomous

Why a PM needs an AI operating system

Host: Welcome back to How I AI. Today I'm joined by Daniel Bloom, who is going to show us a Claude Cowork system that he says can self-heal, self-optimize, and go beyond a typical morning brief.

Daniel Bloom: I had already been using AI early, and even simpler tools had helped with important PM jobs such as writing specs and doing research. But the real problem for me was the overhead of being a product manager: coordinating many moving pieces, remembering tasks from Slack and meetings, following action items, and navigating the chaos that arrives every day. That overhead got in the way of focused, in-depth work.

Cowork let me build a system that addresses that problem. I am still surprised by how powerful it is and by how much it has transformed the way I handle my work.

The two requirements for a useful Cowork system

Host: What is in your AI stack, and was Cowork the major unlock?

Daniel Bloom: My company, Melio, largely determined the enterprise tools available to me. We used Gemini Enterprise for a long time, then got Claude Enterprise and Cowork a few months ago. That was when things really changed.

Cowork was the unlock, but the principle is bigger than Cowork itself. Other environments such as Codex or ChatGPT work could support a similar system. What matters is that the system can rewrite its own core files so it keeps improving, and that it has connections and integrations across as much of a person's ecosystem as possible. When both conditions hold, the system can become deeply integrated into daily life and continuously improve.

This can work within the real constraints of an ordinary PM: finite token budgets, company bureaucracy, and a limited approved toolset. You do not need an unconstrained personal lab to make it valuable.

Notion as a managed source of priorities and context

Daniel Bloom: My starting point is a standard PM board in Notion. It has three sections: Top of Mind for larger initiatives, This Week for current priorities, and Inbox for items that arise from Slack, email, and the calendar.

What makes the board useful is not that it exists. Cowork created it from a simple, messy Google document and now manages it on my behalf. I had spent a lot of time contextualizing the system and centralizing work in it, which took some adjustment, but the return has been enormous.

For this recording, I needed to hide real names, projects, and sensitive details. I created a Claude skill called Demo and asked it to replace specific terminology with generic terms. Because it knew my context, a single prompt could replace my manager's name with "your manager" and turn a real initiative into "headline feature." That made it easy to create a usable demo without manually redacting the entire environment.

Host: Is all of the context simply stored in Notion, or is there a more deliberate personal brain behind it?

Daniel Bloom: I wanted a system that could scale, so I researched how to structure Claude Markdown and context files. I maintain context around each topic, work area, goal, and colleague. In the beginning, I invested significant manual effort: linking documents and decks, and dictating everything I could think of. That is a fast way to give the system a great deal of context. Every few weeks, the system updates its knowledge files based on what has changed.

Weekly preparation and the daily brief

Daniel Bloom: The architecture begins with a recurring Weekly Prep task composed of several skills. It pulls information from my Notion workspace, calendar, Slack, and Granola meeting transcripts. It then recommends what should be my focus for the week, whether new top-of-mind items should be added or removed, and which weekly or inbox items should move, be finished, or be removed.

The routine runs on Sunday mornings and gives me a clear, focused list for the start of the week. It also walks through upcoming meetings and asks how I want to prepare: whether an item needs serious preparation and its own weekly task, only a quick reminder, or no preparation. After I confirm the choices, the resulting state is written into Notion.

The system has to work alongside reality, not just create a beautiful weekly plan. A PM has a clean roadmap and priority list on one side, and Slack messages, urgent requests, meetings, and executive asks on the other. I originally felt a large gap between planning and actual work, because so much time was consumed by small tasks. The system learns how I work as well as what I work on. For example, I aim for inbox zero in Slack and email, so when an item is no longer saved in Slack it probably means it is done; when an inbox item disappears, it usually means I read it. Those behavioral rules help the system collaborate with me smoothly.

The Daily Brief is where much of the magic happens. It first reviews recent meetings, summarizes each one, and identifies action items from the Granola transcripts. In the demo, it found a single action item: share a walkthrough, recording, and write-up in the feature channel with go-to-market. It can expand or draft summaries when useful, but it also lets me keep moving.

Then the brief identifies missing context. It scans recent Slack messages, emails, and meeting notes for files, milestones, goals, and internal terms it does not understand. Instead of silently guessing, it asks whether a term or item is important and whether it should read it. In the example, it flagged the term "settlement cap," explained that it had read the relevant thread and understood it as a payments limit being worked through, then asked whether it should save that definition to context. I confirmed it. This is how the system avoids losing track of important company-specific knowledge.

Host: That is sharp because the language inside a company is often not in training data. You are having Claude proactively say that it does not understand a definition, goal, or internal term, define it with you, and save it for later.

Daniel Bloom: Exactly. It is hard to keep context current. Having Claude act as a partner that follows up and insists on filling knowledge gaps is a major unlock.

Working through Cowork rather than around it

Daniel Bloom: Notion is nearly read-only for me. I look at it to regain focus and see my top-of-mind items and weekly priorities. Occasionally I mark something done, but the goal is for Claude to manage the board for me.

Today, I manage roughly 70 to 80 percent of my computer time through Cowork. I try to do more there because work done outside the harness is less likely to be captured in the context. That includes activities involving Jira, Slack, queries, and other applications.

I used Chrome heavily at first and still do in my personal Cowork setup. Connectors and MCPs are increasingly convenient, but the Chrome connector remains critical when an application does not have an appropriate connector or integration. The system can learn from many places, even if it cannot yet treat an open browser tab as a task.

Host: Your system looks very organized. Mine is much more chaotic: I want to ask a bot what is going on at any hour instead of maintaining a table or board.

Daniel Bloom: Reality is still messy for me too. A lot of what I do is business logic in my head. Building the system became ongoing discovery about myself: whenever it has a blind spot, it is much less useful, so I gradually cover more angles. I used to have tasks scattered across Slack, inboxes, and Chrome tabs. Claude learned to look at most of those places in the same way that I do.

Compounding productivity and deeper work

Host: These systems take effort to maintain. What is the practical benefit for a PM?

Daniel Bloom: Not every personal system delivers a strong return. I built one agent whose job is to send memes about my wife to a shared Telegram panel, which is personally valuable but not the core point. For a robust work system, the early return may look weak. Before the system knows your personal business logic and working style, interactions are frictionful. You double-check everything and may lose trust.

The value compounds once you spend the first few weeks contextualizing ruthlessly, sharing relevant information continuously, and centralizing work in Cowork or another harness. Even when it does not feel natural at first, the result becomes extremely powerful.

Personally, I can now do in a day work that used to take a week. That sounds like a hype headline, but I stand behind it. I can often get through a full week's priority list in a good day. More importantly, the work is deeper. I can do more in-depth research, check claims with data rather than hunches, conduct stronger competitive research, and produce more robust documentation. Moving fast no longer has to mean operating without evidence.

Host: At the company level, people need to accept the pain of changing systems. The old way feels faster because it is muscle memory, but reaching the next level gives people a better system and more skills.

Daniel Bloom: That is an important point. A personal productivity system is useful, but its larger benefit is that it forces people to learn how the work can be done differently.

Improving the system through feedback loops

Daniel Bloom: I use a weekly self-improvement loop made of several skills. It is less about an autonomous system improving itself without me and more about Claude helping me improve it without requiring a great deal of separate time.

The first part compares drafts Claude produced with what I eventually sent. When Claude provides a draft and I rewrite it or send a different version, the system looks for the gap. It can infer what changed between the suggested draft and the actual message, then learn from that difference. This helps it better match my writing style.

The second part is a "skills worth building" flow. Claude periodically looks for things I do repeatedly and proposes turning them into skills. Many of my existing skills emerged from that process. For example, while prototyping, it suggested a Claude Design Handoff skill: Cowork handles research and design, while Claude Code acts as the executing arm for implementation.

The third part improves existing skills. My skills and recurring tasks contain instructions to collect feedback and friction from our interactions. I do not need to capture every issue proactively. Whenever I ask for a fix or experience friction, it is gathered; the weekly loop surfaces the most important issues and proposes improvements.

Finally, I use a skill called Improve to handle the endless stream of setup advice from X, LinkedIn, newsletters, and blogs. I send items into a Slack channel, often from my phone, and ask Claude: is this real, is it powerful, does it fit what we have now, and is it actually needed? It acts as a critical auditor rather than letting me drown in advice or blindly follow hype. For example, it evaluated a How I AI episode on designing loops and concluded that scheduled tasks already cover many loops, while goal loops were a potentially relevant addition.

Host: The indirect learning from drafts you rewrote is especially interesting. Building feedback or telemetry into skills, then reviewing it weekly, is also unusually thoughtful. Teams can learn from direct and indirect feedback instead of treating every interaction as disposable.

From a personal setup to a team workstation

Host: You have turned a large personal system across Notion, Claude, and improvement loops into something that can scale across the organization. How does the workstation work?

Daniel Bloom: We debated building it with Claude Code, which is more powerful, or Cowork. We chose Cowork for what we call the Workstation: an operating system that began for PMs at Melio and expanded to more employees. I built it with talented colleagues, and we placed a great deal of emphasis on onboarding and UX.

When we asked PMs to set up the workflow through Claude Code and the terminal, installation and dependencies could take three days. That taught us that the system had to be simple. The Workstation is a chat-based UX that guides a person through the entire flow. Apart from a few confirmations and questions, it gets them up to speed: connects tools, confirms roles, maps colleagues and management relationships, examines the calendar and Slack, helps establish a personal voice, captures goals, and lets the person start quickly.

The goal is for someone to write in a way that sounds like themselves from day one, rather than like a stranger. A guided setup is more likely to be adopted when the value is clear and the process is accessible.

Host: Instead of teaching every team member a long list of steps, a skill can ask whether their connectors are set up, whether their voice has been captured, and whether the system understands them. Then everyone starts from a useful baseline and customizes from there.

Daniel Bloom: The Workstation is shared as a plugin in our library, so anyone can access it. Colleagues have already taken it further in impressive ways. A lesson came from an earlier spec-writing gem I built. I thought it was complete and well suited to my own workflow, but when I watched other PMs use it from zero, they struggled because it was tailored to how I worked. I added a guided UX that explains the assistant, recommends a starting path, and makes the tool accessible. Good UX and simplicity are critical even for internal teams, PMs, and technical users.

The remaining gap to autonomy

Host: You operate around 70 to 80 percent through Claude and Cowork. What is in the remaining portion, and can the system reach full coverage?

Daniel Bloom: The missing piece is the ability to operate in the cloud independently of whether my computer is open and running. That feels close. A cloud capability would let Claude continue operating while I am away, though I have heard it can be expensive. Systems such as OpenClaw or Hermes point toward the same idea: agents that can run on their own rather than only while the user is present.

I have a workaround through a Slack channel that Claude polls. When I am away from the computer, I can send information there for it to read later. But it still needs an online session. The bigger future step is an agent that can coordinate and act while I am away.

I am preparing for that by teaching the system not only to capture tasks but also to recognize what completion looks like. If someone asks a question in Slack and the thread receives a reply that is no longer saved, the system can infer that it is done. It observes how I resolve tasks so that, eventually, simple but annoying work such as finding a file, answering a request, or scheduling a meeting can happen on its own.

Where PMs should spend the reclaimed time

Host: If AI creates more capacity, which product tasks deserve more attention?

Daniel Bloom: The answer is not surprising: in-depth work, talking to customers and users, and research. Those remain essential. A newer priority is improving the system itself. When the foundations are right, the system can grow and improve week over week.

I dedicate time to learning about AI, following how the tools are progressing, and implementing useful changes. My Improve skill receives posts, tweets, and articles with recommendations. We review them together to decide whether they actually fit my system or are merely LinkedIn hype. Maintaining that ability to learn and improve is now a critical skill in its own right.

Closing reflections

Host: When Claude is not doing what you want, are you polite or do you get frustrated?

Daniel Bloom: After watching many episodes, my answer is probably like everyone else's. When I use voice input, I can raise my voice. I do not get road rage, but I get Claude rage. The funny part is that voice transcription does not always capture the intensity, so the transcript fails to reflect my exasperation. That is my feature request: make the exclamations feel more felt.

Host: I have a theory that someone could tell which model I am using from how agitated I sound. Maybe that becomes a future How I AI benchmark: how furious an agent or AI makes me.

Daniel Bloom: This was a lot of fun. People can find me on LinkedIn under Daniel Bloom and at DanielBloom.com. Some of the resources behind this system are available to download.

Host: To recap: Notion acts as a read-only source of truth for context and priorities; two anchor automations handle weekly setup and the daily brief; and a shared Workstation helps scale the approach across the organization. The productivity gains are real, but the deeper lesson is to build a system that understands context, collects feedback, improves over time, and gives people more room for the work that requires human judgment.