Why He Built It Instead of Buying It

Michael's starting complaint is that the PM-for-AI market does not have a product that actually solves the problem he has. He is a senior product manager at Showpad. He owns six large product areas, each with multiple sub-features. He has at least ten systems where product signal lives: Pendo for analytics, Salesforce for pipeline, the internal data lake for raw behavior, Gong for customer conversations, Slack for team escalations, Confluence for documentation, Jira for engineering tickets, and a few more. None of the AI tools on the market speak to all of them, and the ones that claim to speak to any of them do so generically, not in the way he needs.

The concrete trigger for building his own agent was a product request a few months ago that required him to pull insights across most of those systems. He asked himself what the best way to go deeper than skimming would look like. The answer, he said with a deadpan shrug, was to build an agent.

“So I built an agent. Surprise.”
- Michael van Rantwijk

Claude Code as the Substrate

The foundation of Michael's agent is Claude Code, Anthropic's coding CLI, running in his terminal. He acknowledged this was an unusual choice for a product manager. Most PMs would expect an agent to come with a user interface. Michael has chosen the opposite on purpose. His argument is that engineering tools are where the state of the art of AI actually lives. Engineers get the fastest models, the best harnesses, and the richest tool ecosystems first, because they are the users who will most aggressively complain when things break.

Using the engineering tool, he said, forces him to feel the capabilities and the failure modes of current AI directly. You see where it hallucinates. You see which reasoning steps break. You see which tasks it is shockingly good at and which it still cannot touch. He described this as foundational for product intuition, not a detour from it.

“I was an engineer before this, so I love living in the terminal. But the real reason I use Claude Code is that engineering tools are the state of the art. You get a direct sense of what AI can do today, rather than expectations.”
- Michael van Rantwijk

The 500-Line Skills File

The core of the agent is not the model or the tools. It is a single text document Michael calls a skill. His current skill is roughly 500 lines long, written by hand over several months as he encountered the specific failure modes of processing customer data at scale. It started small. Every time the agent did something wrong, he added a rule. Every time he noticed the output was sloppy, he encoded what good looked like. The skill has grown organically into a dense specification of how he wants product work done.

infoWhat the Skill Actually Encodes

Michael's skill is the encoding of his own product judgment for the agent. It covers the kinds of quotes he considers meaningful, how he wants transcripts processed, what he means by verbatim, how he wants artifacts named on the filesystem, and his house style for reports. He is Dutch, he said with a smile, and he hates fluff, which means a lot of the skill is about stripping out the kinds of diplomatic filler that Claude would otherwise generate by default.

Sub-Agents, Artifacts, and Auditability

The hardest problem Michael solved for himself was context management. There is no version of listening to a hundred hours of customer calls in one day. There are not a hundred hours in a day. Instead, he has the main agent spawn sub-agents, one per transcript, that run in parallel and do first-pass processing independently. Each sub-agent strips the non-relevant parts of the call, surfaces candidate quotes, and writes them to artifacts on the filesystem.

The main agent then reads those artifacts, groups quotes by theme, and assembles a report. Every step produces a file on disk. The design choice sounds mundane but it is load-bearing. Because every intermediate output is a plain text file, every step is auditable by another agent, by Michael, or by him at a later date. When the agent gets something wrong, he can go back and see exactly which sub-agent produced which claim from which call.

Honest About the Failure Mode

An audience member pushed on this directly. How do you know you are capturing the right signals, the ones that actually matter to you? Michael's answer was refreshingly unguarded. I do not, he said. I hope. He acknowledged the process is probabilistic, that he will miss things, and that he has almost certainly made mistakes. But, he said, I would have made mistakes listening to the calls myself, probably more. The agent makes him faster, not infallible.

Signal, Not Summary

The most important design principle Michael built into his skill is the refusal of summarization. Early in his experimentation, he noticed that the narratives the agent produced were being nicely summarised. Everything was framed, qualified, softened. The rough edges of what customers actually said got smoothed away, and he was left with something that sounded confident and told him nothing new.

“The only way to get out of that was to force the agent to produce attributable quotes with links to the minute of the call. If I want to build a strategy on something a customer said, I want to hear the customer say it. I am not going to listen to the AI.”
- Michael van Rantwijk

The skill now requires verbatim quotes, speaker attribution, and a timestamped link back to the Gong recording. The agent extracts. The thinking, the pattern matching, and the product decisions stay with Michael. Summaries are comfortable and mostly useless, he said, because the PM job is not to consume summaries. It is to develop judgment from raw material.

The Gong MCP Server He Vibe Coded Himself

One of the most telling moments in the talk was when Michael almost apologized for a piece of infrastructure he had built. The off-the-shelf MCP server for Gong, which lets the agent query call transcripts, was too slow for the number of calls he was processing. So he built his own. A caching layer in front of the Gong API, written in an afternoon, entirely vibe coded.

The first time the agent fetches a transcript, his custom server saves it to disk. The next time any sub-agent asks for that transcript, it comes from the local cache instead of round-tripping to Gong. The solution is, as Michael put it, a dumb way to do it. But it is what works, and it is what let him run hundreds of transcript fetches without making Gong's API angry.

lightbulbThe Meta-Point

Michael was not showing off the caching layer for its own sake. The point was that when you are the user and the builder and the domain expert at the same time, you can patch the infrastructure underneath your own agent in ways a SaaS vendor never will. The cost of fixing that one slow tool call was one afternoon. The payback has been months.

Three to Five Agents Running in Every Meeting

The question that got the most nervous laughter in the Q&A was about how Michael actually uses the agent day to day. His answer was that he runs three to five of them in parallel during almost every meeting he is in. One is processing the question someone asked five minutes ago. Another is preparing for the meeting he is walking into next. A third might be pulling adoption numbers for a feature he is about to be asked about.

The example he gave was mundane and exactly right. Someone in a meeting says, I wonder what the adoption rate of that feature is. In the pre-agent world, that sentence sits in the air. Nobody actually answers it. In the post-agent world, Michael writes the question into his terminal, keeps listening to the meeting, and twenty minutes later gets back an answer with a Pendo link attached. The difference is not speed. The difference is that the question gets answered at all.

Why It Compounds

Michael closed the second half of his talk with the argument he seemed most emotionally invested in. The reason he thinks every PM should build their own agent is not that the productivity gains are large. It is that the learning compounds, and it compounds in the same direction as product intuition. Every hour spent on the agent teaches him something about how agentic systems actually behave, which makes him a better reviewer of what his team is building into Showpad.

“This compounds. I have been doing this for a year. That is the same way it often works with your customers. You learn something, you build your model. You learn more, you build it more. You end up with a very good understanding. The same thing is happening here with the models themselves.”
- Michael van Rantwijk

The closing line of the second act mirrored the first. Ship less, kill more, build your own tools. That is the job now. The rest, he said, is slop. The room applauded, and a row of people visibly opened their laptops during the Q&A to install Claude Code.

Scale Yourself: How a PM Stopped Waiting for the Tools and Built His Own Agent in Claude Code

Download the Slides

Why He Built It Instead of Buying It

Claude Code as the Substrate

The 500-Line Skills File

infoWhat the Skill Actually Encodes

Sub-Agents, Artifacts, and Auditability

Honest About the Failure Mode

Signal, Not Summary

The Gong MCP Server He Vibe Coded Himself

lightbulbThe Meta-Point

Three to Five Agents Running in Every Meeting

Why It Compounds

This article is for Consortium members

Key Takeaways

Related Editorials

Dashboard-Poor, Customer-Rich: How Mbrella Built World-Class Product Without Analytics

Chat Bolted on Legacy: Why Slapping a Chatbot on Professional Software Is Product Slop

One Agent Became Two: How Donna Split Conversation from Execution to Survive Enterprise Scale