His AI does 80% of his job, he says. His colleagues struggled with the one piece he shared.

Daniel Blum, a product manager at Melio, estimates that his Claude setup now handles 70% to 80% of his workday. It runs his Notion board, prepares him for the week, and reads Slack and email for context he would otherwise have to find himself. He says he can now do in one focused day what used to take him a week.

Then he gave one piece of it to his colleagues, and they struggled with it.

That piece was Spectacular, his spec-writing tool, handed to other product managers at Melio. The tool was not broken. It had been built entirely around his own working style, and they were not him.

That is the part of this story worth your time. Almost every account of a personal AI system stops at the productivity number. This one kept going and hit the wall on the other side.

The thing he built was never the prompts

Blum is direct that the model was not the variable. He says the same system could have been built in Cowork, Codex or ChatGPT, and that he used only tools Melio had already licensed. Two properties of the architecture made it work.

First, the system can rewrite its own core files. Context is not written once and left to rot; recurring tasks refresh it every few weeks. That keeps the gap small between what the assistant knows and what is actually true inside the company.

Second, it learns from behaviour rather than feedback. A weekly job compares what the assistant drafted against what he actually sent, then treats the difference as the lesson. He never has to file a complaint or write a correction. It watches the small edits he makes instinctively, the ones nobody would ever bother reporting.

Which means the asset he built is not a set of prompts. It is a body of accumulated context about one specific person doing one specific job. That changes the transfer problem completely. He was not handing a colleague a tool. He was handing them a tool shaped like him.

What it cost to get there

The build took months of feeding it voice memos, links, decks and verbal brain dumps. All of that became detailed context files covering every area of his work.

He is candid about how that period felt. The first few weeks are frustrating. The system does not know enough yet, its output is slightly off, and nearly everything needs a second look. You are paying full price and getting a worse version of doing it yourself.

That ordering is why most attempts die. The value curve is inverted against the effort curve, and the gap is measured in weeks. Anyone who judges the system while it is still in that window concludes it does not work — and on the evidence in front of them, they are right.

The morning brief that admits what it doesn't know

The most copyable piece of the morning brief is a design decision, not a prompt.

Each day, the brief reviews his Slack, email and notes for unfamiliar terms, projects or goals that do not appear anywhere in its context files. It then asks him targeted questions to close those gaps.

When it hit the phrase "settlement cap," it had already read the relevant thread and worked out the general idea. It only needed him to confirm the meaning before saving it.

An ordinary assistant writes around an unfamiliar term convincingly. This brief does something else. Its useful output is not the summary. It is the short list of things it noticed it could not account for.

He applies the same principle across the whole system as telemetry. Every skill logs moments of friction. If he says something is not working, or asks for a correction mid-session, that gets recorded. Once a week an improvement loop surfaces the most common problems and recommends updates. It amounts to analytics for his internal tools.

The onboarding flow is the actual product

His answer to the Spectacular failure was not to make the tool more generic. Generic was the disease.

He built an onboarding flow that connects each employee's tools, maps their colleagues, and learns their voice in about fifteen minutes, he says. Every Melio employee now starts from his architecture, personalised to them, rather than from a blank page or a system tuned to someone else's habits.

Fifteen minutes against his own months. That ratio is the whole argument. He spent the months discovering which context mattered. The fifteen minutes are for collecting it from a new person. Once you know the shape of the questions, filling them in is fast.

If you have built one of these for yourself, the test is not whether it saves you time. It is whether a colleague can reach the same place in one sitting. If the answer is no, you have a personal habit with good tooling. It is valuable to exactly one person and worth nothing to the company the day you leave.

What he is still waiting for

Blum names the remaining limitation as persistence, not intelligence. The system cannot keep working in the cloud while his computer is off.

So he is preparing for that in advance by teaching it to recognise the closed state of a task. If a drafted Slack message is no longer saved, the system can infer it was probably sent.

That is a strange thing to build for a capability you do not have yet. It follows the same approach as everything else here: do the boring definitional work early, so the system already knows what finished looks like when the constraint lifts.

The productivity number will be quoted. The fifteen-minute onboarding flow is the part that turns one person's habit into something a company owns.

Full write-up: Claude Cowork for PMs: My Self-Improving Productivity System, published by ChatPRD.