I Removed the PM from My Development Loop
Connect NotebookLM via MCP and Claude reads the policy itself. The half-day of Slack waiting became 30 minutes.
Every new feature starts the same way.
You get the spec. You read it. It seems clear at first. Then you go deeper and things get fuzzy. How does this policy apply to that edge case? What's the intent behind this exception? Is there another doc somewhere that explains the background? You send a Slack message to the PM. You wait. An answer comes. You read the spec again.
That loop ran three or four times before I could even start coding.
PMs Are Busy
Asking the PM isn't wrong. It's far worse to go off in the wrong direction without checking. But in practice, PMs are managing multiple sprints at once. Your question isn't always the top priority.
And if your question isn't precise, the answer isn't precise either. "How should I handle this case?" often gets "just follow the existing policy" in return. Now you have to go find the existing policy.
The time before development actually starts keeps growing. Time to gather information. Time to connect the pieces.
NotebookLM Changes the Dynamic
Google NotebookLM lets you upload documents as sources — PDFs, Google Docs, text files — and then ask questions grounded in those documents. Unlike a general-purpose LLM, it answers based on what you uploaded, not its training data. Less hallucination, and it shows you the source.
At first I thought of it as "a smarter way to search documents." The real value turned out to be different.
Upload your spec, policy docs, API references, and team wiki into a NotebookLM notebook, and you have a living knowledge base. When something is unclear, you ask the notebook instead of sending a Slack message.
Q: What happens to comments posted by a user who deletes their account?
A: [Based on Policy Spec v2.3, Section 3.2 — Account Deletion]
Comments are not immediately deleted. They display as "Unknown User."
If an admin processes a personal data deletion request, comment content
is also masked at that point.
Faster and more specific than asking the PM — because the PM would have looked up the same document anyway.
Connect It via MCP and the Workflow Shifts Entirely
This is where it gets interesting. NotebookLM has an MCP (Model Context Protocol) server. Connect it to Claude Code and Claude can query NotebookLM directly while you work.
Before MCP:
Me: read spec
Me: find something unclear
Me: Slack the PM
Me: wait
Me: get answer
Me: back to spec
Me: start coding
After MCP:
Me: give Claude the task
Claude: query NotebookLM for relevant policies (automatic)
Claude: plan based on actual policy
Claude: start implementing
I'm out of the loop. When Claude hits something it needs to understand, it asks NotebookLM directly and uses the answer as context.
What the Workflow Looks Like
When I start a task, I give Claude a prompt like this:
Implement a comment reporting feature.
Before writing any code, check the NotebookLM notebook for:
- Report handling policy (thresholds, auto-blind conditions)
- Feedback shown to the reporting user
- How duplicate reports from the same user are handled
Summarize what you find, share your implementation plan, and wait
for my confirmation before coding.
Claude queries NotebookLM, reads the policy, and comes back with something like:
NotebookLM results:
1. Report handling policy
- 3+ reports on the same content → auto-blind
- Report types: spam / hate / misinformation / other (Policy doc §4.1)
2. Reporter feedback
- Show "Report received" immediately on submission
- No notification of outcome (§4.3 — privacy protection)
3. Duplicate reports
- Same user reporting the same content again → ignored
- Does not count toward the threshold (§4.2)
---
Implementation plan:
- ReportService.createReport(): dedup check → increment count →
trigger blind when threshold exceeded
- Recommend separating blind logic into ContentModerationService
so policy changes don't require touching report logic
...
No digging through the spec. No waiting on Slack. Claude already read the policy before it started planning.
Policy-Grounded Planning Is a Different Class of Output
This matters. Claude writes good code. But good code built on wrong policy is wrong code.
Without the policy context, Claude might count duplicate reports toward the threshold, or send the reporter a notification about the outcome. The code itself is fine — the behavior is wrong. That surfaces in QA, or worse, after deployment.
When Claude reads the policy before planning, these mistakes don't happen. It knows the rules before writing the first line.
Fewer QA cycles. Lower rework cost. Less back-and-forth with the PM.
The Knowledge Base Setup Is the Foundation
For this workflow to run smoothly, the NotebookLM notebook needs to be well-stocked. Here's what I keep in mine:
| Document | Purpose |
|---|---|
| Feature specs | Policy, edge cases, business logic |
| API documentation | Integration contracts and formats |
Just the feature spec and API docs are enough to get started. The rest accumulate over time and make the notebook progressively more useful.
The Takeaway
Running into unclear parts while reading a spec is normal. Even a well-written document can't anticipate every edge case question a developer will have during implementation.
The difference is where you resolve those questions.
The PM Slack → wait → answer loop can be short-circuited with NotebookLM. Go further and connect it to Claude via MCP, and Claude reads the policy itself before planning. Code written with the policy already in context is different from code written without it.
Saying "10x faster" might sound like marketing copy. But when you actually account for the time spent gathering information before development starts — half a day of spec clarification down to 30 minutes is a real number.
Set it up once. Then it just runs.