Elezea — essays

Two small new things on the blog

Rian van der Merwe — Sun, 19 Apr 2026 20:29:02 GMT

Now that the site is off WordPress, I can finally start doing a bunch of things I've wanted to do for years. Here are the first two:

1. Auto-posting side-project releases

When I tag a GitHub release on one of my side projects — tldl, listentomore, discogs-mcp, and others — a post now appears on this site automatically. Title, tagline, release notes, and a link back to the GitHub release.

I ship a lot of small improvements, and historically none of that work was visible anywhere except the GitHub tab nobody reads. Now it shows up on the blog as a first-class content type.

2. Per-content-type RSS feeds

If you only want the long essays and not my link posts or quotes about other people's writing (or the release notes, for that matter), you can now subscribe to just those. There are six feeds:

Everything — the full firehose
Essays only
Link posts
Quotes
Releases
Summary — titles and descriptions only

I've also updated /subscribe with the full list. And a reminder that RSS is very much alive and well. Get started with What is a Feed?.

Thanks for still believing in RSS! Feel free to get in touch.

What actually changed about being a PM

Rian van der Merwe — Sat, 18 Apr 2026 14:54:37 GMT

I have decided that in this new AI era I will be practicing FDD. Fear-Driven Development. Every time I send a pull request, which happens a lot now, I'm terrified of an engineer sending it back to me and asking me to please stay in my lane and stop sending them slop. So I plan, write specs and implementation plans, test thoroughly, and I don't trust the agent's inevitable confidence.

I'll come back to that, but let me first frame what this post is about. The loudest take on PM work right now is that AI is collapsing the role — that we're one product cycle away from redundancy, or being reduced to prompt jockeys. That hasn't been my experience at all. The job got more hands-on, harder (brain fry is real), but also a lot more fun. What follows is what actually shifted for me over the last 5 months at Cloudflare, what didn't, and a couple of things I got wrong.

What changed

We all ship now. The biggest shift in my day-to-day is that my team and I write code. Not as a vanity exercise or to replace engineers — there is no universe in which I'm touching our data pipeline code. But for prototypes, internal tools, small features, and live bugs or UX improvements that are safe for us to do, we just go ahead and make a PR instead of adding things to the backlog. This quote from one of our EMs sums it up well:

I like these dashboard revamps. Far better if PMs can express their visions for the product directly to Opencode, avoids a lot of back and forth.

This is where FDD comes in. The terror of shipping slop is the thing that keeps me responsible. Telling Claude "hey, build me X" is a fast road to code that doesn't work the way it should, or worse, works but introduces ten regressions along the way. So the pattern I run now is: brainstorm first, usually with a skill that forces me to articulate what I'm actually trying to do; write a spec; turn the spec into an implementation plan; and only then start generating code.

Counterintuitively, the planning is what makes the whole thing faster (and better!). Skip the brainstorm and you'll spend ten rounds of PR review untangling code the model wrote confidently and incorrectly. Plan properly and the build itself is usually the fast part.

Context is the product, and evals are the new PRD. The second change is arguably even more consequential: I spend real time maintaining a context layer. A CLAUDE.md, a library of skills, stakeholder memory, agent routing, a second brain that feeds all of it. None of this was part of my job a year ago, and treating AI as a chat window means missing most of what it can do. My own PM rubrics live inside this layer too. My /okr and /prd commands load the problem-first frameworks and antipattern checklists I'd apply myself, so the first pass on any draft or review is already done before I open the doc.

The same shift is showing up in specs and PRDs. When a document has two audiences (the team building the product and the agent helping them) the writing changes. Ambiguity gets expensive. Rhetorical flourishes don't survive the first load into context. A good spec is one that loads cleanly as context and runs as a plan — that's a different job than writing a memo for stakeholders. Ornella at Braintrust has a good post on how evals are the new PRDs:

An eval is a structured, repeatable test that answers one question. Does my AI system do the right thing? Think of it as a unit test for AI behavior.

Her argument is that in AI-native products the eval suite is what actually defines the product. A PRD says what you want; an eval tells you whether you got it. For PMs, the artifact that matters is the one you can run.

We take more load off engineering. CUSTESCs (our customer escalations) used to take hours and hours of PM and engineering capacity. Someone would dig through Jira, read code across a dozen repos, chase down the relevant ClickHouse tables, check the docs against what the customer expected, and go back and forth for days before anyone had a useful working hypothesis.

Our team now has a /custesc command that does most of that in parallel. It pulls the ticket, runs three agents at once across code, Jira, and the wiki, generates and runs ClickHouse queries to check the leading hypothesis, and passes the draft through a blind validator and challenger before it lands as a classified analysis. Ticket ID to root cause in about 20 minutes, most of the time.

This moves where the investigation work sits. A CUSTESC used to be a tax on engineering. Now I can run the full investigation myself and come to engineering with a classified issue and a working hypothesis, instead of a vague "can someone take a look at this?" One enormous side benefit: I've learned more about our products in the past couple of months than I have in the 1.5 years before that.

What didn't change

Figuring out what to bet on. What to say yes/no to is still the hardest part of the job. AI can lay out the tradeoffs; it can't tell you which user/business opportunities to prioritize this quarter. The roadmap is still a set of bets you own. (What "roadmap" even means in this new world deserves a post on its own, but suffice to say we have fully adopted Now/Next/Later)

Trust with engineers. There is no AI shortcut for being useful to your team over time. Showing up and owning the ambiguous stuff is still the job. The calls no one wants to make are still yours. If anything, PMs being able to prototype makes the line between helping and stepping on toes harder to hold. It's a human line, and it gets redrawn every week.

Owning outcomes when things go wrong. AI doesn't absorb accountability. It won't take the hit in a postmortem, and it won't rebuild trust with a customer after an incident — you will. The hardest moments in the job haven't changed.

What I got wrong

I underestimated the context layer. For the first year I treated AI as a chat tool: ask good questions, get good answers. I thought prompt engineering was the skill. The thing I missed is that skills, memory, agent routing, and the specs you load in are the product. Prompts sit downstream.

I thought adoption would be gradual. I assumed PMs would pick this up on a normal curve: some fast, some slow, most in the middle. What I'm seeing industry-wide is a widening gap between PMs who are willing to change how they work and PMs who aren't. You can see the gap in how fast they investigate a problem, how concretely they argue about a design, and how useful they are to other teams.

Getting started is easy and the early wins are obvious. The hard part is being open to changing your job. I was talking to my wife the other day about what I'm doing, and she asked the obvious question: "Why are you automating your job away?" My answer: the people who automate their own jobs away are the ones who become more valuable, because the craft is now in orchestration — setting up the layers so the AI does the right thing.

Where this leaves us

I don't know what this job looks like in another year. The pattern of the last few months has been that the ground shifts faster than the opinions written about it, and most of the stable-sounding takes age badly within a quarter. What I'm trying to do is pay attention to what's getting easier, what's getting harder, and what's making me uncomfortable. And reminding myself that "uncomfortable" is usually where the real learning happens.

Thanks for still believing in RSS! Feel free to get in touch.

I am finally — FINALLY — off WordPress

Rian van der Merwe — Thu, 16 Apr 2026 02:24:03 GMT

A quick meta-post incoming! This site has been running on WordPress and Dreamhost for 18 years. It worked fine, but the overhead was really starting to get to me: a MySQL database, monthly hosting costs, plugin updates that arrive every other week, and embarrassing page load times...

I've wanted to move to a static site for years, but it felt impossible. Every time I started to think about it I just gave up. How do I migrate 1,700 posts without breaking almost 20 years of URLs? What do I do about search? The Last.fm widget? Email routing? The existing CSS? There were too many things I didn't know I didn't know, so I never got very far.

A few months ago I started working on a fresh migration plan with Claude Code, using the obra/superpowers skill set. Not to write code yet, but to think through the plan. What's the best long-term architecture for a move like this? What's the actual order of operations? Where are the traps?

We iterated on it many times over several weeks. Each pass surfaced something I hadn't thought about: redirect strategy, shortcode handling, whether my existing CSS depended on WordPress-specific class names, email routing before cancelling the old host, rollback options if something went wrong... The plan got longer and more detailed, but it also got clearer. What had felt like an insurmountable thing gradually became something with known phases, concrete steps, and tradeoffs I could actually evaluate.

By the end of the planning process, the migration had a 1,300-line plan covering everything from exporting WordPress content to the DNS cutover runbook. And then Claude and I did the actual migration... in a single weekend.

So WordPress and Dreamhost are both gone. What you see here now is Astro, deployed to Cloudflare Workers, with no database and no server-side runtime. Content lives as Markdown files in a git repo. Search runs entirely client-side via Pagefind. And of course, it's also the fastest the site has ever been.

A lot of people I know have a project like this — something they've wanted to do for years, have started and abandoned, and have filed away under "someday." It stays there because the project doesn't feel possible. You can't begin to think of all the complexities involved, so you just don't start.

I think we've learned now that AI is pretty good at making work legible. If you iterate on a plan long enough the project stops being a vague, scary thing and becomes a checklist you can actually run through. So hey, find your "I'm free" thing. It might be more doable than it looks.

Thanks for still believing in RSS! Feel free to get in touch.

From Assistant to Collaborator: How My AI Second Brain Grew Up

Rian van der Merwe — Sat, 14 Mar 2026 15:13:36 GMT

Over the past few months I’ve been writing about how I use AI for product work. The first post covered the philosophy: context files, opinionated prompts, and how to compose the right inputs for each task. The second added slash commands and daily summaries. The third was a hands-on setup guide. And the fourth introduced project brains for keeping complex initiatives organized.

This post covers a different kind of change. The earlier additions were incremental: more commands, better context, smoother workflows. What changed recently feels more like a threshold. The system graduated from a tool I invoke for specific tasks to something closer to a collaborator I dispatch to do real work. Three capabilities drove that shift: multi-agent orchestration, cross-session memory, and the encoding of domain expertise into the system itself.

Multi-Agent Workflows

The clearest example is customer escalation investigations. As a PM for data products, I regularly investigate customer-reported issues: logging gaps, data discrepancies, behavior that doesn’t match expectations. These investigations require pulling information from multiple sources and cross-referencing it all into an analysis that engineering can act on.

I built a slash command that handles this as a multi-phase workflow. When I run it with a ticket ID, here’s what happens:

The system reads the customer ticket, extracts the core problem, identifies which product area is involved, and classifies the issue type.
Three specialist agents launch simultaneously, each focused on a different data source. One searches the codebase for the relevant logic and recent changes. Another searches for related tickets and prior incidents across projects. A third checks documentation and internal wiki pages for relevant operational context.
A fourth agent receives the combined findings and produces database queries that can confirm or refute the working hypothesis.
The system combines everything into a structured analysis: issue classification, root cause anchored in code where possible, customer impact, and recommended next steps.
A blind validator independently re-fetches every source cited in the draft to verify the claims hold up. Then an adversarial challenger looks for alternative explanations and tests whether the classification is correct.

The output is a document I can review with an engineering colleague or paste into a chat thread. It includes a confidence assessment and a data collection status table showing what was checked and what was unavailable, along with how the analysis compensated for gaps.

The command file that orchestrates all of this isn’t prompting in the traditional sense. It defines which agents to dispatch, what information each one needs, when to wait for results before proceeding, and how to handle failures gracefully. Writing this felt more like designing a workflow than writing a prompt.

I’ve applied the same pattern to other tasks. A “fix feasibility” command evaluates whether a ticket describes a code change simple enough for a PM to implement with AI coding assistance, and produces an implementation brief if the answer is yes. The specific use cases differ, but the architecture is the same: break the problem into specialist tasks that run in parallel, then synthesize and validate the results.

Cross-Session Memory

AI conversations are stateless by default. Every new session starts from zero, which means re-explaining context that should already be established. Over a few weeks of working on the same projects, this friction adds up.

I addressed this with a four-layer memory system:

The first layer is stable facts: a compact file that captures the current state of all active work, including project status, recent decisions, and environment constraints. This is the primary orientation file. When I start a session, the AI reads it and immediately knows what’s in flight.
The second is a session log: a reverse-chronological list of handoff notes. Each entry records what happened in a session and what threads remain open. The last three entries give enough context to pick up where I left off.
Third, a corrections file. This holds behavioral fixes for things the AI consistently gets wrong. It’s a staging area that should shrink over time as fixes get promoted elsewhere.
And finally, a decisions log: a cross-cutting record of decisions that don’t belong to a specific project. Each entry captures context and rationale so I don’t relitigate settled questions.

Two commands manage this. /session-start loads all four files and presents a brief summary of current state and recent sessions. /session-end reviews the conversation, writes a handoff note, and then checks whether any learnings should be promoted to infrastructure.

“Promote to infrastructure” means taking something learned during a session and baking it into the files the agent actually reads. A correction about how to handle a specific edge case in escalation investigations might start in the corrections file, then get promoted into the escalation command or a domain skill once it’s validated. The corrections file shrinks over time as knowledge graduates into the right places.

This creates a loop where the system improves its own instructions. I approve every change, so it’s not self-modifying in a creepy way. But in practice each work session can make the next one slightly better, and the compound effect over weeks is noticeable.

Domain Expertise

The earlier posts described skills like pm-thinking, which applies product methodology (problem-first thinking, measurable outcomes) to any PM-related conversation. That’s useful, but generic. It works the same way regardless of what product you’re building.

The bigger shift was building skills that encode institutional knowledge about specific products. I now have skills for each major product area my team owns: log delivery, analytics, audit logs, alerting, and data pipelines. Each skill contains the product’s architecture and common failure modes, along with which code repositories to search and which database tables hold relevant data.

This is what makes the multi-agent workflows genuinely useful. When the code investigator agent examines an escalation about missing logs, the domain skill tells it which service handles job state and which repository contains the delivery pipeline. It also flags recent architectural changes that might be relevant. Without that context, the agent produces plausible-sounding analysis that misses the specific details engineering needs.

Now every investigation that uses a skill validates or extends the knowledge it contains, and /session-end catches insights that should be added back.

How The Work Changes

A few practical observations from working this way:

The role has shifted from “write the right prompt” to “design the right process.” The escalation command is a workflow with phases, dependencies, and validation steps. Thinking about it that way produces better results than trying to pack everything into a single conversation.
Validation has to be built in. The blind validator exists because agents make mistakes. They cite files that don’t exist, mischaracterize what code does, or draw conclusions the evidence doesn’t support. Catching those issues before they reach anyone else is the whole point.
Cross-session memory requires discipline. The system only works if I run /session-end after substantive sessions and keep stable facts current. When I skip it, the next session starts cold and I lose the compounding benefit. Automation helps, but the commitment to maintain the memory is mine.
And domain skills need regular maintenance. Products change. Code gets refactored, pipelines get rearchitected. Skills that aren’t periodically updated drift from reality. I haven’t solved this well yet. It’s still a manual process of noticing when a skill’s knowledge is stale and updating it.

The system still makes mistakes. Multi-agent workflows are more thorough than single-prompt conversations, but they’re not infallible. The confidence assessment in the escalation output exists because sometimes the answer is “medium confidence, we couldn’t confirm this from the available data.” That honesty about limitations is more useful than false certainty.

Where This Is Going

I’m sure the specific commands and skills will look different in six months as I learn what works and what doesn’t. But the underlying pattern feels durable: compose specialist agents with deep domain context, validate their output, and feed learnings back into the system.

I’ve published updated files to the Product AI Public repo, including the session memory commands and a generalized version of the multi-agent escalation workflow. If you’re building something similar, those might be useful starting points.

The value of this system is in how the pieces reinforce each other. Domain skills make agents useful for real investigations. Session memory means the system gets smarter over time. And the promote-to-infrastructure loop ties it together, so each piece of work has a chance to make the next one better.

Thanks for still believing in RSS! Feel free to get in touch.

Project Brains: Organizing Complex Initiatives for AI-Assisted Work

Rian van der Merwe — Tue, 24 Feb 2026 01:46:50 GMT

I’ve written before about how I use AI for product work and how that workflow evolved with slash commands and skills. This post focuses on how to maintain context for complex, long-running projects.

The Problem: Context Fragmentation

When I’m working on a major initiative, relevant information ends up scattered everywhere: PRDs in one tool, tickets in another, meeting notes in a third, plus emails and chat threads. Every time I return to a project after a few days, I spend time reconstructing where things stand.

AI assistants can make this worse because each conversation starts fresh. I can reference files, but the model doesn’t know which files matter for this project, what decisions we’ve already made, or what questions remain open. I end up re-explaining context that should be obvious.

Project brains solve this by creating a dedicated folder for each major initiative with a standard structure that both humans and AI can navigate.

What a Project Brain Looks Like

The structure looks like this:

projects/[project-name]/
├── CONTEXT.md        # The hub: status, stakeholders, decisions, open questions
├── artifacts/        # PRDs, specs, designs, one-pagers
├── decisions/        # Decision logs with rationale and alternatives
├── research/         # Customer feedback, data analysis, technical investigation
└── meetings/         # Meeting notes related to this project

The CONTEXT.md file is a living document that answers the questions I’d need to answer every time I pick up a project:

What’s the current status?
Who are the stakeholders and what do they care about?
What decisions have we made and why?
What questions are still open?
Where are the relevant artifacts?

When I start a conversation about a project, I point the AI to the project folder. It reads CONTEXT.md first, then can drill into specific artifacts as needed. The model immediately knows the project state without me explaining it.

A Real Example

Say I’m working on adding observability to an internal platform—something that needs coordination across multiple teams over several months. The CONTEXT.md includes:

Quick reference table: Status, PM, engineering lead, target dates, links to the PRD and relevant tickets. Everything I’d need to orient myself.
Problem statement: A clear articulation of the user pain. In this case: “Platform incidents go undetected until users report them, and debugging takes hours due to lack of visibility.”
Success metrics with baselines and targets: Things like uptime targets, reduction in mean time to resolution, and alert accuracy. These anchor every conversation about scope.
Key decisions made: A table showing what was decided, when, why, and what alternatives we considered. When someone asks “why aren’t we including component X in v1?”, the answer is already documented.
Open questions: A checklist of unresolved issues. This prevents the AI from assuming things are settled when they’re not.
Links: Direct paths to the PRD, spec, analysis docs, and related pages.

The decisions/ folder contains detailed decision logs for significant choices. The research/ folder holds whatever analysis informed the project direction. The meetings/ folder captures sync notes that would otherwise disappear into Gemini notes in a Google Drive… somewhere.

When to Create a Project Brain

Not every task needs this treatment. I create a project brain when:

The work spans multiple weeks or months. Short-term tasks don’t need the overhead.
Multiple stakeholders are involved. If I need to coordinate with other teams, having a single source of context helps.
Decisions require documented rationale. If someone might ask “why did you do it this way?” later, a decision log is worth the investment.
The project crosses team boundaries. Cross-functional initiatives benefit from dedicated context that doesn’t live in any one team’s space.

For simpler work, I use a flatter folder structure with documents organized by type. Project brains are for the complex initiatives where context fragmentation is a real cost.

How AI Uses Project Brains

The payoff comes when I’m working with AI on project-specific tasks. A few examples:

Preparing for a meeting: “Read the CONTEXT.md in the [project] folder. I have a spec review meeting tomorrow. What are the open questions I should raise?”
Drafting an update: “Based on the project context, draft a status update for leadership. Focus on progress since the start of the month and remaining blockers.”
Decision analysis: “We need to decide whether to include [component] in scope. Read the research folder and the current CONTEXT.md. What would you recommend and why?”

The AI knows the project history, the stakeholders, the constraints. Its recommendations are grounded in documented context rather than generic best practices.

Maintaining the Project Brain

The value depends on keeping CONTEXT.md current. I’ve found a few practices help:

Update after significant events. When a decision is made, a meeting happens, or the status changes, update the file immediately. “I’ll do it later” means it won’t happen. LLMs are great at making these updates, so you can simply say “update relevant files based on the session we just concluded.”
Move open questions to resolved. When a question gets answered, don’t delete it. Mark it resolved and note the answer. This preserves the reasoning trail.
Link, don’t duplicate. CONTEXT.md should point to artifacts, not contain them. Keep PRDs in the artifacts folder. Keep meeting notes in the meetings folder. The context file is a hub, not a repository.

Scaffolding New Projects

I have a slash command that scaffolds new project brains:

/new-project platform-observability

This creates the folder structure, generates a CONTEXT.md from a template, and fills out a rough draft based on whatever context I provide. Removing the friction of setup means I’m more likely to actually use the system. You can view the command here.

The template includes the standard sections (Quick Reference, Problem Statement, Success Metrics, etc.) with placeholder text. I fill in what I know and mark other sections as TBD. Even an incomplete project brain is more useful than scattered notes.

What I’ve Learned

A few observations from using this approach:

Structure beats volume. A well-organized project brain with sparse content is more useful than a folder full of undifferentiated documents. The AI (and future me) can navigate structure. It can’t navigate chaos.
Decision logs compound. Every decision I document now saves time later. When stakeholders ask “why didn’t we do X?”, I can point to a decision log instead of reconstructing my reasoning from memory.
CONTEXT.md is for humans too. I originally built this for AI assistance, but I reference these files constantly in my own work. The discipline of maintaining project context helps me stay oriented, not just the AI.
The folder structure is flexible. Some projects need more subfolders (like research/customer-interviews/). Some need fewer. The template is a starting point, not a requirement.

This approach requires discipline to maintain, and the upfront setup takes time. But for complex initiatives where context fragmentation is a real problem, project brains have been worth the investment. The AI becomes a more useful collaborator when it has access to the same context I do.

I’m still iterating on the structure. I suspect the template will look different six months from now as I learn what sections actually get used and which ones I skip every time. The point isn’t to get the folder structure perfect, but to stop losing context between conversations and start building on what you already know.

Thanks for still believing in RSS! Feel free to get in touch.

Why AI in Interviews Is Bad for Candidates, Not Just Companies

Rian van der Merwe — Mon, 26 Jan 2026 02:03:05 GMT

A quick post on LinkedIn about interviewing a candidate who used real-time AI got more engagement than is usual for me. And as often happens when something goes semi-viral, some folks took issue with what I said, so I want to expand on the point I was trying to make (it wasn’t that “AI is cheating”).

Here’s what I wrote:

I had my first experience interviewing a candidate who used real-time AI today. If you’re someone who uses AI daily, it’s so easy to spot. The pause before the answer, the constant eyes flicking to the other screen, the perfectly-manicured 3-point answer…

Friends, just don’t do this. It’s too easy to spot, and it will also set you up for failure, because it might get you a job that you’re not a good fit for, which is bad for everyone.

Use AI in your job, for sure. But don’t use it to get the job. The interview process is about you. Be you.

One response called this “absolutely myopic” (I had to double check I didn’t accidentally post on Hacker News) and asked why candidates shouldn’t use AI if it allows for “a better, more creative answer.” Another suggested that if candidates will use AI on the job anyway, then the “real you” isn’t going to be working, so what’s the difference?

Let’s dig into this.

What interviews are actually for

I don’t interview people to test whether they can produce a good answer to a question. I interview people to understand how they think, what they’ve actually done, and whether we’ll work well together.

When I ask “Tell me about a time you had to make a difficult prioritization decision,” I’m not looking for the theoretically optimal framework. I want to hear your story. The messy details and the trade-offs you wrestled with. The thing you got wrong and what you learned from it. AI can’t give me that. It can only give me a polished summary of what prioritization frameworks exist.

One commenter put it well: “It’s about both the company and the individual, so you will often talk about their real experience, what they did, how they felt, what did they learn, digging deeper into their real experience to find out the interesting things that could make them a good match.”

AI might help you phrase things more clearly. But if it’s generating your answers, you’re hiding the very thing I’m trying to evaluate.

The fit problem

Here’s the part that didn’t seem to land: using AI to get a job you’re not qualified for is bad for you.

Let’s say the AI-assisted interview works. You get hired. Now what? You show up on day one, and the expectations are set based on how you performed in those interviews. But that wasn’t you. That was a performance enhanced by a tool you won’t have in the same way during actual work conversations, whiteboard sessions, and quick chat exchanges where people expect you to just… know things.

I’ve seen what happens when there’s a mismatch between interview performance and actual capability. It’s not a fun experience for anyone, least of all the person who’s now struggling in a role they weren’t ready for. One person called it “artificial buzzword ventriloquism” in the comments. Harsh, but not wrong.

It’s about context, not absolutes

A few commenters suggested that interviews should evolve to assume AI assistance, since that’s how people will actually work. One person wrote: “By prohibiting AI during interviews, the interview environment diverges from actual job conditions and fails to evaluate a critical skill: the ability to effectively use one of the most powerful productivity tools available today.”

I think there’s something to this. In fact, our interview process includes a take-home assessment where we explicitly encourage candidates to use AI. We want to see how they approach a problem, how they structure their thinking, and yes, how they use modern tools to get to a good answer. That’s a legitimate skill worth evaluating.

But that’s different from what happened in my interview, where someone was clearly trying to hide their AI usage while answering questions about their past experience. That’s not “using AI as a tool.” That’s using AI as a mask.

I think candidates should absolutely use AI to prepare for interviews: research the company, practice answering common questions, refine their resume.

But in the interview itself, when I’m asking about your experience and your thinking, I need to hear from you. Not because AI is cheating, but because the whole point is to figure out if you are the right fit for this role and this team. If I can’t evaluate that, we can’t make a good hiring decision. And that’s bad for both of us.

Thanks for still believing in RSS! Feel free to get in touch.

How to Set Up OpenCode as Your Product Second Brain

Rian van der Merwe — Thu, 08 Jan 2026 18:20:11 GMT

This is the hands-on companion to How I Use AI for Product Work and How My AI Product Second Brain Evolved. Those posts explain the philosophy; this one gets you to a working OpenCode setup in 30 minutes.

By the end, you’ll have a folder structure, three useful slash commands, and a context file that makes the AI actually useful.

Prerequisites

You’ll need OpenCode installed and configured. Follow the installation guide to get started. If you can run opencode in your terminal and get a response, you’re ready.

Step 1: Create the Folder Structure

Create a new directory for your product second brain. I recommend keeping it in a git repo so you can version your prompts over time.

mkdir -p product-ai/{context,prompts/pm,.opencode/command}
cd product-ai
git init

Your structure should look like this:

product-ai/
├── .opencode/
│   └── command/       # Slash commands live here
├── context/           # Personal context files
├── prompts/
│   └── pm/            # PM-specific prompts
├── AGENTS.md          # Instructions for OpenCode
└── opencode.jsonc     # OpenCode config

Step 2: Create Your Context File

The context file tells the AI who you are and how you work. Create context/about-me.md:

# About Me

## Role
[Your title] at [Company], working on [your area].

## What I Care About
- [Your product philosophy, e.g., "Start with the problem, not the solution"]
- [Your working style, e.g., "Bias toward shipping and learning"]
- [Your communication preferences, e.g., "Direct feedback, no hedging"]

## Current Focus
- [Project or initiative 1]
- [Project or initiative 2]

Keep this updated as your focus changes. The more specific you are, the more useful the AI becomes.

Step 3: Create AGENTS.md

This file tells OpenCode how to behave in your repo. Create AGENTS.md in the root:

# Product AI Second Brain

Read this file before responding.

## Who I Am
Read `context/about-me.md` for personal context.

## Slash Commands
Run these by typing the command in OpenCode:

| Command | Purpose |
|---------|---------|
| `/prd` | Review a PRD |
| `/debate` | Stress-test a product idea |
| `/okr` | Review OKRs |

Step 4: Add Your First Commands

Slash commands are markdown files in .opencode/command/. Each command file is a thin wrapper that points to a full prompt file in prompts/pm/. This separation keeps commands simple while allowing prompts to be detailed and shareable.

Command 1: /debate (Stress-test an Idea)

Create .opencode/command/debate.md:

---
description: Stress-test a product idea with pro vs skeptic debate
---

# Product Debate

Read these files before proceeding:
- `prompts/pm/debate-product-idea.md` - **REQUIRED: Full debate framework**
- `context/about-me.md` - Your product beliefs and context

## Your Task

$ARGUMENTS

## Instructions

Then create the prompt file prompts/pm/debate-product-idea.md with your full debate methodology. The basic structure: define two personas (a Visionary who argues for the idea and a Skeptic who pokes holes), have them debate, then synthesize the strongest arguments from both sides.

Command 2: /okr (Review OKRs)

Create .opencode/command/okr.md:

---
description: Review OKRs for clarity and outcome-orientation
---

# OKR Review

Read these files before proceeding:
- `prompts/pm/review-okrs.md` - **REQUIRED: Full OKR review framework**
- `context/about-me.md` - Your product beliefs and context

## Your Task

$ARGUMENTS

## Instructions

Then create prompts/pm/review-okrs.md with your OKR criteria. Mine checks for outcome-orientation (are these outputs or outcomes?), measurability, and whether the key results actually ladder up to the objective.

Command 3: /prd (Review a PRD)

Create .opencode/command/prd.md:

---
description: Review a PRD for completeness and clarity
---

# PRD Review

Read these files before proceeding:
- `prompts/pm/review-prd.md` - **REQUIRED: Full PRD review framework**
- `context/about-me.md` - Your product beliefs and context

## Your Task

$ARGUMENTS

## Instructions

Then create prompts/pm/review-prd.md with your PRD review criteria.

Step 5: Try It Out

Navigate to your product-ai directory and run OpenCode:

cd product-ai
opencode

Test each command:

/debate Should we build a self-serve dashboard for customers to debug their own issues?

/okr [paste your OKRs here]

What’s Next

Once you’re comfortable with this setup, consider adding:

More commands: /retro for retrospectives, /feedback for drafting colleague feedback
Skills: Methodology files that OpenCode loads automatically based on context (see the skills documentation)
Daily summaries: A /today command that summarizes what you worked on
Project-specific context: Folders for major initiatives with their own context files

The key is to start small and add complexity as you identify repeated workflows. If you find yourself doing the same thing more than twice, it’s probably worth automating.

If you build something useful on top of this, I’d love to hear about it!

Thanks for still believing in RSS! Feel free to get in touch.

How My AI Product "Second Brain" Evolved

Rian van der Merwe — Tue, 30 Dec 2025 13:49:02 GMT

A couple of weeks ago I wrote about how I use AI for product work—the basic setup of context files, prompts, and the @ mention system in Windsurf. Since then the system evolved quite a bit, so I figured it’s time for an update.

The philosophy has shifted a bit. I still don’t use AI to do my core thinking—I write my own PRDs and strategy docs. But I’ve come to rely on it more as a helpful assistant for the work around the work: reviewing documents before I share them, researching technical questions, summarizing my week, preparing for meetings. It’s now less “sparring partner” and more “capable colleague who’s always available.”

From Windsurf to Claude Code / OpenCode

The biggest shift was moving from Windsurf to Claude Code, Anthropic’s terminal-based AI assistant. Claude Code runs in your terminal and has direct access to your filesystem, which changes how you can structure these workflows.

The key feature that made this worthwhile is slash commands. Instead of manually @-mentioning prompt files, I can type /ask-se and Claude Code automatically loads the right context, reads the relevant files, and knows how to respond. It’s a small thing, but removing that friction makes a real difference in how often I actually use these tools.

I also started using OpenCode, an open-source alternative that works similarly. Both tools read from the same instruction files, so I maintain one set of prompts that work in either environment.

Slash Commands

The prompts I described in the original post are now wrapped in slash commands. The files live in .claude/commands/ and look like this:

.claude/commands/
├── prd.md          # Review a PRD
├── okr.md          # Review OKRs
├── debate.md       # Stress-test a product idea
├── ask-se.md       # Research technical questions
├── briefing.md     # Calendar briefing
├── today.md        # End-of-day summary
├── weekly.md       # Weekly summary
└── ...

Each command file contains instructions for the AI, plus a $ARGUMENTS placeholder for any input I provide. When I run /debate should we build a developer portal?, Claude Code reads the debate prompt, substitutes my question for the placeholder, and runs through its process.

The commands I use most often:

/prd — Reviews a PRD I’ve written and pushes back on vague problem statements, missing success metrics, or unclear scope. I run this before sharing drafts with stakeholders.
/debate — Simulates a debate between an optimist and a skeptic about a product idea. This is probably the command I reach for most when I’m still forming an opinion about something.
/ask-se — Helps me answer specific technical questions about our products. For example, today I ran /ask-se On Gateway HTTP Logpush jobs, what would trigger "unknown" as the action? The command uses MCP (Model Context Protocol) servers to search our public documentation and internal wiki, then synthesizes an answer I can actually use. It’s how I learn the product deeply without having to interrupt engineers or dig through docs myself.

The mental overhead of remembering file paths and composing context manually has mostly disappeared. I just type the command and start the conversation.

Skills: Persistent Methodology

Commands are things I invoke explicitly. Skills are different—they’re methodology files that get applied automatically when relevant.

I have three skills set up:

pm-thinking — Applies my product philosophy to any PM-related work. When I’m reviewing a PRD, it automatically checks for problem-first thinking, measurable outcomes, and clear non-goals.
cloudflare-context — Loads knowledge about Cloudflare’s products and triggers proactive use of internal data sources (more on this below).
data-team-context — Specific context about my team’s priorities, current initiatives, and constraints.

The skill files live in .claude/skills/ and contain triggers (when to apply) and behaviors (what to do). For example, the pm-thinking skill flags anti-patterns like “vague success metrics” or “jumping to solutions without understanding the problem.”

This means even when I’m not explicitly running a PM-focused command, the AI still knows to apply my methodology. It’s like having a linter for product thinking that runs in the background.

Daily and Weekly Summaries

One of the more useful additions: automated work journaling. At the end of the day, I run /today. The command:

Finds files I modified that day using filesystem timestamps
Reads the key files to understand what I actually worked on
Asks if there’s anything else to add
Generates a summary focused on outcomes, not tasks
Saves it to a structured folder: work/cloudflare/weeknotes/2025/01/week-01/2025-01-06.md

The output follows a consistent format:

# Tuesday, December 16, 2025

## Summary
Focused on Q1 planning and customer research. Clarified success
metrics for data quality initiative and documented common Logpush questions.

## What I Worked On
- **Q1 Planning:** Reviewed OKR drafts, identified gaps in success metrics
- **Customer Research:** Documented Logpush egress IP questions for support docs

Then on Friday (or Monday morning), I run /weekly. It reads all the daily notes for the week and synthesizes them into summary—the kind of thing I can use to prepare for 1:1s or status updates.

This has been surprisingly effective for a simple reason: It’s sometimes hard to remember everything I did in the week when Friday rolls around... The daily notes capture work while it’s fresh, and the weekly summary rolls it up into something useful.

Calendar Briefings

The most custom piece of this system is the calendar briefing. I got this idea from an interview with Webflow’s CPO on Claire Vo's podcast, about building an AI chief of staff. Following her example I wrote a Python script that:

Connects to Google Calendar via OAuth
Fetches events for today, tomorrow, or the week
Generates a briefing that flags meetings that could be async, suggests prep work, and warns if the day is overloaded

I run /briefing tomorrow before wrapping up for the day. It gives me a head start on thinking about what’s coming and whether I need to prepare anything.

The briefing uses context from my about-me.md file, so it knows things like which recurring meetings are more important than others, and what kind of prep I typically need for different meeting types.

Syncing Between Tools

One wrinkle: Claude Code and OpenCode have slightly different formats for commands. Claude Code uses plain markdown; OpenCode expects frontmatter with a description field.

So I built a sync command. Running /sync-to-opencode compares the two folders and copies any changed commands, adding the frontmatter OpenCode needs. It means I can maintain one set of prompts (in .claude/commands/) and have them work in both tools.

This is the kind of meta-tooling that probably isn’t worth it for most people, but I switch between the tools often enough that keeping them in sync manually was annoying.

What I’ve Learned Since the First Post

A few things that have become clearer:

Automation compounds. Each individual piece—slash commands, skills, daily summaries—provides modest value on its own. But they compound. The daily notes feed the weekly summary. The skills apply across all conversations. The slash commands reduce friction enough that I actually use the system instead of just thinking about using it.
Building custom workflows is easier than ever. With slash commands and skills, I can create tools that work exactly how I want to work. The /ask-se command knows my products, our customers, and the kinds of questions I typically need answered. The daily summary knows my file structure and my preferred format. It’s not about adapting to a tool’s workflow—it’s about encoding my workflow into a tool.
Scripts fill the gaps. The calendar briefing couldn’t be a pure prompt—it needed to actually fetch data from an external API. Having a scripts/ folder for Python code that extends the system has been useful for anything that requires real I/O.
Keep work output local. The prompts and context files live in a private git repo so I can sync them between machines and version them over time. But the actual work output—weeknotes, briefings, any documents I’m working on—stays on my local machine, not in the repo. The AI helps me do the work, but the work itself doesn’t need to live in the cloud.

If you’re building something similar, I’d recommend starting with the basics from the first post: context files, opinionated prompts, and a tool that lets you compose them easily. The slash commands and automation came later, once I understood what workflows I actually used repeatedly.

The specific tooling matters less than the approach. Figure out where AI can genuinely help—reviewing your work, researching questions, reducing busywork—and then build the smallest system that makes those things easy to do.

Thanks for still believing in RSS! Feel free to get in touch.

Introducing TL;DL: AI-Powered Podcast Summaries

Rian van der Merwe — Mon, 22 Dec 2025 15:22:11 GMT

Do you ever listen to a podcast episode and wish you could have a summary you could reference later? Not the whole transcript or someone else’s review, just a concise breakdown of the key points in a format you can scan quickly when you need to remember what was covered. Well, that’s why I spent the weekend building TL;DL (Too Long; Didn’t Listen). It generates AI summaries from podcast episodes.

Beyond that, there were a few other podcast use cases I kept running into:

Catching up on episodes I missed. Sometimes a podcast gets 10 episodes ahead while life happens. A summary helps me decide which ones are worth going back to.
Getting a feel for a new podcast. Before committing to a full episode, I want to know if a new show covers topics in a way that works for how I think and learn.
Quick reference after listening. When I want to apply something from an episode—like a framework or technique—I don’t want to re-listen to an hour of audio to find the relevant 5 minutes.

So I built something for myself, and now I’m making it available to others.

How It Works

Registered users can submit an Apple Podcasts episode URL, choose a summary template, and the system does the rest. It transcribes the audio (using OpenAI Whisper), generates a summary (using GPT–5.2), and caches everything for a year.

The three templates are designed for different types of content:

Key Takeaways & Practical Steps — This is the default, and it’s what I use most. The summary includes an overview, key insights, actionable steps, and notable quotes. Best for professional development and craft podcasts where you want to walk away with something to implement.
Narrative Summary — For story-driven content and interviews. Instead of bullet points, this generates flowing prose that captures the arc of the conversation, including key moments and themes.
ELI5 (Explain Like I’m 5) — For technical or complex topics. It breaks down dense material using everyday analogies and simple language.

The ELI5 Template Passed the Real Test

My wife is a therapist. She listens to highly technical psychology podcasts about things like Transference-Focused Psychotherapy and pathological narcissism. When I ran a recent episode she listed to through TL;DL, she was genuinely impressed by the “Key Takeaways” summary. It captured the clinical nuances accurately.

I, on the other hand, didn’t understand a word of it.

So I generated another summary using the “ELI5” template, and suddenly I could follow along. Concepts like devaluation got explained as “when a patient puts down the therapist, the therapy, or anything connected to it.” The technical frameworks became accessible. Here’s the episode page if you want to toggle between the two summaries yourself.

A Note about Podcast Creators and Attribution

Attribution matters to me. Every episode page prominently displays the podcast name, creator names, and both a “Listen on Apple Podcasts” link and a “Website” link to the official podcast website. My hope is that TL;DL helps expand a podcast’s audience by making the content more accessible. Summaries should bring people to a podcast, not replace the experience of listening—most podcasts have transcripts available already after all.

That said, if creators would rather not have their podcast processed, they can opt out and I’ll add their show to the blocklist.

The Technical Bits

For those interested in the stack: TL;DL runs entirely on Cloudflare’s edge platform. Cloudflare Workers handles the serverless compute, Workers KV stores the cached transcripts and summaries, and Cloudflare Queues manages the background job processing.

One interesting technical challenge was job status consistency. When you submit an episode, you want to see the status update in real-time as it progresses from “queued” to “transcribing” to “summarizing” to “completed.” Workers KV is eventually consistent, which meant status updates could lag by up to a minute. Users would refresh and still see “queued” even after the job was done.

I solved this with Durable Objects, Cloudflare’s strongly consistent coordination layer. The job status gets written to both the Durable Object (for immediate reads) and KV (for persistence and fallback). The UI now updates instantly.

Audio file handling for long episodes was another challenge. OpenAI Whisper has a 25MB file size limit. For podcasts that exceed this, I implemented MP3 frame-aware chunking—splitting the audio at frame boundaries so transcription can be stitched back together cleanly. The overlap handling ensures no words get lost between chunks.

What’s Next

Beyond solving my own problem, this was one of those projects where the building itself was the reward. The technical challenges were interesting, the product felt useful from day one, and I got to learn Durable Objects properly.

Submitting new episodes is currently invite-only while I iron out the rough edges. If you’re interested in access, reach out. For now, you can browse existing summaries to see how it works.

Thanks for still believing in RSS! Feel free to get in touch.

Building a music discovery app (and what I learned about Product)

Rian van der Merwe — Fri, 19 Dec 2025 00:25:38 GMT

I miss liner notes. In the age of infinite streaming and algorithmic playlists I find myself longing for the days when you’d flip open a CD case and actually read about the music you were listening to. Who produced this? What’s the story behind the album? Why does this track feel different from everything else they’ve made?

Spotify and Apple Music are great at giving you more music. They're less good at helping you understand why you might love something, or what to explore next. So I built my own solution—and then rebuilt it twice.

The problem I was trying to solve

My relationship with Last.fm goes back to 2007. In case you’re not familiar, Last.fm is a service that “scrobbles” (tracks) everything you listen to, building a comprehensive history of your musical life. It’s become a wonderful archive of my taste evolution over nearly two decades.

Last.fm is great at telling you what you listened to. It’s less useful for helping you understand why you might love something, or what else you should explore. Spotify and Apple Music’s algorithmic playlists are fine, but they often feel like they’re optimizing for engagement rather than genuine discovery.

I wanted a tool that would:

Show me context about the artists and albums in my listening history
Help me discover music through similarity and connection, not just popularity metrics
Give me that “liner notes” depth I was craving
Work with my existing Last.fm data (18 years of listening history is a lot to throw away)

So I started building, first by copy-pasting from GPT–4 (the olden days!), and most recently with Antigravity + Claude Opus 4.5 (we’ve come a long way since 2023). Here’s where it all stands today…

Listen To More: three iterations and counting

Listen To More is the core project—a music discovery platform that combines real-time listening data with AI-powered insights.

The first version was simple: a personal dashboard that pulled my Last.fm data and displayed it nicely. Functional, but limited. The second version added some AI summaries using OpenAI’s API. Better, but still rough around the edges.

The current version—iteration three—is a complete rebuild focused on speed and multi-user support. What started as “a thing I made for myself” is now something anyone can use. Sign in with your Last.fm account, and you get:

Rich album and artist pages with AI-generated summaries, complete with source citations (so you know the AI isn’t just making things up)
Your personal stats showing recent listening activity, top artists and albums over different time periods.
Weekly insights powered by AI that analyze your 7-day listening patterns and suggest albums you might love
Cross-platform streaming links for every album—Spotify, Apple Music, and more
A Discord bot so you can share music discoveries with friends

The tech stack is Hono on Cloudflare Workers, with D1 (SQLite) for the database and KV for caching. The whole thing is server-side rendered with vanilla JavaScript for progressive enhancement. Pages load in about 300ms, then AI summaries stream in asynchronously.

I chose this stack partly because I work at Cloudflare and wanted to understand our developer platform better. More on that later.

Extending the ecosystem with MCP servers

MCP stands for Model Context Protocol. In plain terms, it’s a standard that lets AI assistants (like Claude) connect to external data sources and tools. Think of it as giving an AI the ability to actually use personalized data rather than just answer questions based on pre-training.

I built two MCP servers to extend my music discovery ecosystem:

Last.fm MCP Server

Available at lastfm-mcp.com, this server lets AI assistants access your Last.fm listening data. Once connected, you can have conversations like:

“When did I start listening to Led Zeppelin?”
“What was I obsessed with in summer 2023?”
“Show me how my music taste has evolved over the years”

The AI can pull your actual scrobble data, analyze trends, and give you personalized insights. It supports temporal queries (looking at specific time periods), similar artists discovery, and comprehensive listening statistics.

Discogs MCP Server

This one connects to Discogs—the massive music database and marketplace that’s especially popular with vinyl collectors. If you have a Discogs collection, the MCP server lets AI assistants:

Search your collection with intelligent mood mapping (“find something mellow for a Sunday evening”)
Get context-aware recommendations based on what you own
Provide collection analytics and insights

Both servers run on Cloudflare Workers and use OAuth for secure authentication. They’re open source if you want to poke around or deploy your own.

What I learned

I’m a Product Manager, not an engineer. But I’ve found that having more technical depth broadens the scope of things I am able to contextualize—and makes me more confident in my interactions with engineers. Here’s what building these projects reinforced for me:

Side projects are a low-stakes learning environment. When you’re building for yourself, there’s no pressure to ship by a deadline or meet someone else’s requirements. You can experiment, break things, and iterate freely. I tried approaches that would have been too risky to propose in a work context—some of them broke the site spectacularly, others worked beautifully.
There’s no substitute for using your own product. I use these tools every day. That constant exposure surfaces issues and opportunities that you’d never catch in a quarterly review or user interview. The feature prioritization becomes obvious when you’re feeling your own friction.
Building with your company’s tools is invaluable. I now have deep, practical knowledge of Cloudflare Workers, D1, KV, and the rest of our developer platform. When I’m talking to customers or evaluating feature requests, I’m drawing on real experience, not just documentation. I can empathize with the developer experience because I’ve lived it.
The fun matters. I keep coming back to these projects because I genuinely enjoy working on them. The satisfaction of solving a problem you personally care about is different from the satisfaction of shipping something at work. Both are valuable, but the former is what sustains a side project through the inevitable rough patches.

What’s next

I have a list of features I’d love to add—better recommendations, more sophisticated listening pattern analysis, maybe even integration with other music services. But I’m also learning to pace myself. These projects aren’t going anywhere, and part of the joy is the slow, steady improvement over time.

If you’re curious, you can check them out here:

listentomore.com — The main music discovery platform
lastfm-mcp.com — Connect AI assistants to your Last.fm data
Discogs MCP Server — Connect AI assistants to your Discogs collection

And if you’re a PM thinking about starting a technical side project: do it. Pick something you personally care about, use tools you want to learn, and give yourself permission to build slowly. The lessons transfer in ways you won’t expect.

Thanks for still believing in RSS! Feel free to get in touch.

How I Use AI for Product Work

Rian van der Merwe — Sun, 14 Dec 2025 23:11:15 GMT

Update! I wrote a follow-up post here: How My AI Product “Second Brain” Evolved.

I’ve been refining my approach to using LLMs for product work, and I figured it’s time to write up how I actually use them day-to-day.

I think the most valuable thing an AI assistant can do isn't to write your PRD or draft your strategy docs. It's to push back on weak reasoning, spot gaps you missed, and force you to articulate why your idea is actually good. It’s less a ghostwriter and more a skeptical colleague who shares your product philosophy. With the right prompts AI assistants are also really good at creating background and framing documents (such as explainers that synthesize complex topics, summaries of technical concepts, etc.).

So let’s walk through how I’ve set this up, what makes it work, and how you might build something similar for yourself.

The Philosophy: Sparring Partner, Not Ghostwriter

I believe LLMs are most useful when you give them two things: context and constraints.

Context tells the model who you are, what you’re working on, and what “good” looks like in your world.
Constraints keep the model from going off the rails with generic advice or hallucinated frameworks.

Every prompt I use is designed to provide both. They’re opinionated on purpose. I’d rather have an assistant that pushes back on bad ideas than one that says “Great idea!” to everything.

The goal isn't to have AI write presentations for me. It's to have a thinking partner that:

Challenges weak problem statements before I waste time on solutions
Spots missing success criteria I forgot to define
Asks "why?" when my reasoning gets hand-wavy
Points out when I'm jumping to solutions before understanding the problem
Helps me create background docs and explainers that set context for others

The Building Blocks

The system works because of how all the pieces fit together. Here’s an overview of the general folder structure I maintain with a series of Markdown files inside:

llm-prompts/
├── prompts/           # System prompts for different use cases
│   ├── pm/            # Product management prompts
│   └── technical/     # Technical/engineering prompts
├── context/           # Personal context files (who I am, how I work)
├── reference/         # Syntax guides and reference docs
└── work/              # Saved feedback and refined docs

The magic isn’t in any single prompt—it’s in how you combine them. Let me break down each layer.

Layer 1: System Prompts

These are the instructions that tell the AI how to behave for a specific task. I have different prompts for different jobs:

General PM sparring: A prompt that knows my product philosophy and pushes back on weak reasoning. I use this for thinking through tradeoffs, preparing for meetings, and sanity-checking my approach.
Document review: Prompts specifically designed to critique PRDs, OKRs, strategy docs, and other artifacts. These encode what “good” looks like and call out common anti-patterns.
Idea stress-testing: A prompt that I stole from my friend Stephen, which simulates a debate between an optimist and a skeptic to pressure-test new ideas before I get too attached to them.
Technical understanding: Prompts that help me understand systems, architectural decisions, and technical concepts well enough to lead effectively (I’m not an engineer, but I need to hold my own in architecture reviews).

The key is that each prompt is opinionated. They’re not generic “be helpful” instructions—they encode specific philosophies about what good work looks like.

Layer 2: Personal Context

This is where it gets powerful. I maintain files that describe:

Who I am: My role, my experience, my communication style
How I work: My product philosophy, my management approach, my values
What I’m working on: Current projects, team context, company priorities

When I start a conversation, I can pull in the relevant context files alongside my prompt. The model then has the background it needs to give me advice that actually fits my situation—not generic best practices from a blog post.

Layer 3: Reference Materials

Sometimes you need the model to follow specific formats or conventions. I keep reference files for things like wiki markup syntax, documentation templates, or internal style guides. These ensure the output is actually usable without a bunch of reformatting.

How I Actually Use This

I use Windsurf as my daily driver, and it has a feature that makes this whole system work: the @ mention. In the chat panel, I can reference any file by typing @ followed by the path. Windsurf then includes that file’s contents as context for the conversation.

This means I can compose my “assistant” on the fly by combining:

A system prompt for the task at hand
Relevant personal context files
The document or code I’m working on

Example: Document Review

When I need feedback on a PRD before sharing it with stakeholders, I’ll start a conversation and reference my PRD review prompt plus my product philosophy context. Then I paste in the PRD and ask for critique.

The model comes back with feedback grounded in my own standards—not generic advice. It’ll call out if my problem statement is vague, if my success metrics aren’t measurable, or if I’m jumping to solutions before properly framing the problem. Exactly the kind of pushback I’d want from a senior colleague.

Example: Brainstorming Partner

For early-stage thinking, I use a more conversational prompt that knows how I like to explore ideas. I’ll describe what I’m thinking about and ask it to poke holes, suggest angles I haven’t considered, or help me articulate why something feels off.

This is particularly useful before big meetings. I can rehearse my reasoning and get challenged on the weak spots before I’m in front of stakeholders.

Example: Technical Understanding

I’m not an engineer, but I work with technical teams. When I need to understand how a system works—well enough to ask good questions or spot when something doesn’t add up—I use prompts designed for technical explanation.

The key is that these prompts know to explain things without condescension but also without assuming I know the jargon. They cite specific files and line numbers when relevant, and they explain the “why” behind design decisions.

Connecting to Real Data

One feature that’s made a big difference is MCP (Model Context Protocol) servers. These connect the AI to external data sources—internal wikis, documentation sites, code repositories, APIs—so it can ground its responses in actual information rather than just its training data.

In my prompts, I tell the model which MCP servers are available and when to use them. For example, my technical prompts instruct the model to:

Search official documentation first to ground answers in verified information
Check internal wikis for known issues, edge cases, and workarounds
Look at code repositories when documentation is incomplete
Always cite sources with links so I can verify

This turns the AI from a general-purpose assistant into something more like an expert who has access to your company’s actual knowledge base. The difference in answer quality is significant—instead of generic advice, I get responses that reference real docs and real code.

Keeping a Record

One practical tip: save the conversation output somewhere useful.

I have a work/ folder organized by topic where I save feedback and refined thinking. When the model gives me good critique on a PRD, I’ll ask it to write a summary of the key issues to a Markdown file I can reference later. This keeps the insights from getting lost in chat history.

What I’ve Learned

A few things that have made this work better over time:

Context files are worth the investment. I have files that describe who I am, how I work, and what I value. Updating these takes time, but it pays off in every conversation.
Push back is a feature, not a bug. These prompts are designed to challenge bad thinking. If the model is pushing back on your approach, consider that it might be right.
Iterate on the prompts. I update these regularly based on what works and what doesn’t. If a prompt isn’t helping, change it.
Less context is often more. Including too much context can dilute the signal. Start with the minimum you need, add more if the model seems confused.

This setup isn't a silver bullet that makes thinking go away—it's just a way to encode my preferences and philosophies into something an LLM can use as a baseline for pushing back on my thinking. I still write my own PRDs, OKRs, and strategy docs—the artifacts that represent my actual thinking. But I let AI help me create background documents, explainers, and context-setting materials. And I have a sparring partner that catches the gaps I miss, challenges the assumptions I glossed over, and asks the uncomfortable questions before stakeholders do.

If you build something similar, I’d love to hear how it goes. The prompts are important, but what matters equally as much is the structure—context plus constraints, composed on the fly for the task at hand. That’s the thing that makes it work.

Update! I wrote a follow-up post here: How My AI Product “Second Brain” Evolved.

Thanks for still believing in RSS! Feel free to get in touch.

New side project: Discord Stock & Crypto Bot

Rian van der Merwe — Sat, 29 Nov 2025 19:09:20 GMT

Not sure how many people would be interested in this, but it was fun to make so I thought I’d share. This is a Discord bot that provides real-time stock and cryptocurrency information, 30-day price trends, and AI-powered news summaries through slash commands. When you add the bot to Discord you can use the /stock and /crypto commands to get information like this:

Want to add it to your Discord server? Head over here!

Thanks for still believing in RSS! Feel free to get in touch.

"The Mountain in the Sea", AI fears, and connectedness

Rian van der Merwe — Sun, 31 Aug 2025 15:31:39 GMT

(Mild spoilers ahead for The Mountain in the Sea by Ray Nayler)

I recently finished the novel The Mountain in the Sea by Ray Nayler (see Andrew Liptak’s excellent review here). On the surface it’s about discovering an octopus colony that evolved into a self-aware, intelligent community—and trying to communicate with them. But as with all good novels it’s actually about other things. It’s about loneliness, understanding each other, conservation—and yes, our relationship with AI.

First, to get the AI thing out of the way… I don’t want this blog to sound like I am anti-AI. I use AI every day both at the chat / thinking partner level and the prototyping / vibe coding level. I am a fan of using AI for the things that it’s good at. I just worry that we are not teaching people outside of the tech bubble what those things are. And that’s why we are seeing so many tragic stories right now about chat agents “guiding” people to horrific actions (see, for example, Let’s Talk About ChatGPT-Induced Spiritual Psychosis and ‘I Feel Like I’m Going Crazy’: ChatGPT Fuels Delusional Spirals).

With that as background, the book does a good job of highlighting some of the dangers of using AI for things it’s not good at. First, this is a good point about how with every new technology we have to think about what can go wrong, not just what can go right:

When you invent the ship, you also invent the shipwreck; when you invent the plane you also invent the plane crash; and when you invent electricity, you invent electrocution. Every technology carries its own negativity, which is invented at the same time as technical progress.[1]

Following from that, this quote about the main character “killing” their AI companion stood out to me…

That’s how this works. That’s how addictive this is—this need to feel like there is always someone there, unconditionally. Someone to talk to. Someone who understands. To not have to do the work myself to make myself understood. Instead, I just kept on with this self-deception, pretending I had someone when I did not. I know the doctors who prescribed you to me meant well. They thought they were helping me through a dark time. But in the end, you aren’t anything but a prosthesis. You can’t replace real support.

The other major theme in the book centers around our connectedness with each other and the world, how language can get in the way of connection, and how lonely we’ve become as a society[2]. I love this call to empathy as a way to get ourselves out of that dilemma (emphasis mine):

Are we trapped, then, in the world our language makes for us, unable to see beyond the boundaries of it? I say we are not. Anyone who has watched their dog dance its happiness in the sand and felt that joy themselves—anyone who has looked into a neighboring car and seen a driver there lost in thought, and smiled and seen the image of themselves in that person—knows the way out of the maze: Empathy. Identity with perspectives outside our own. The liberating, sympathetic vibrations of fellow-feeling. Only those incapable of empathy are truly caged.

A book about discovering intelligent life in an octopus species with its own language and culture might seem like a weird premise. But it works really well here. It gets pretty heavy-handed towards the end, but it still made me think a lot about the “loneliness epidemic”, our relationship with AI, and the continuing role of empathy in making sure we stay connected with each other. Recommended!

This line of thinking reminds me a lot of Kevin Kelly’s 2010 (!) book What Technology Wants in which he makes a similar point that technology is never “neutral”. That’s ok, but we have to be prepared for it. ↩
I don’t think that’s a controversial statement any more. See articles like The Anti-Social Century ↩

Thanks for still believing in RSS! Feel free to get in touch.

Automatic syncing from Raindrop.io to Wordpress link posts

Rian van der Merwe — Sun, 29 Jun 2025 19:43:28 GMT

I read Ethan Marcotte’s Link bug this week, which led me to Sophie Koonin’s Automated weekly links posts with raindrop.io and Eleventy, and that is such a cool idea that I had to do something similar.

Thanks to getting nerdswiped by Ethan and Sophie I now have a Cloudflare Worker that takes links that I tag with blog on Raindrop.io, and posts them (with excerpts taken from the Notes section) as link posts to this blog. You can just scroll down to see a bunch of examples.

It’s not fancy but it works beautifully! Every hour it checks for new links in Raindrop.io with the blog tag, and then it creates a posts like this:

Link title

This is my note about the article, with markdown support.

→ Article Title

If this is something that could be useful to you, you can view the source code here and deploy to Cloudflare Workers to make it your own.

Thanks for still believing in RSS! Feel free to get in touch.

Product Management: The Good, the Hard, and How to Know If It's Right for You

Rian van der Merwe — Sun, 22 Jun 2025 16:12:25 GMT

An engineer recently sent me some questions about the Product Management role. I took a long time to respond because I saw it as a great opportunity to reflect on the role and what it means to me. I decided to share my answers below, in case it’s useful for anyone else!

What did you like the most about your job as a PM? (I say past tense because Director can be different)

The joy of shipping, and shepherding products and features from ideas all the way through execution and user feedback and continuous iteration.

To me, the PM role is a people job. How do we get people to work together to do amazing work? How do we get the best ideas out, how do we make them real? How do we build things that people genuinely enjoy using, and don’t mind paying for? How can we understand how our products make people feel, and how can we make that better?

If you’re able to get into a product loop that does that over and over, it’s the best job in the world. You get to understand complex user, business, and technical needs, make sense of it all, and support a team of people to get useful products into the world. And then you get to talk to the people who use those products about how to make them even better.

Daniel Pink says we are all motivated by 3 things: autonomy (self-directed work), mastery (getting better at stuff), and purpose (serving a greater vision). At the best of times, I can’t think of another job that combines those 3 things as thoroughly as Product Management does.

What is the one aspect of the role that makes you from time to time (but consistently) say “I don’t think I want to do this any longer”? Or “I need a break from this”?

When we get caught up in the human tendency to forget about what we’re trying to do (that purpose from the previous question), and focus on our own needs instead. When I interact with teams and people who find their identity in their work to such an extent that it overshadows how cool it is that we get to do this stuff together. In short: when internal politics take over.

I don’t resent this tendency any more, to be honest. I used to, but not any more. This is normal human behavior—I am not immune to it, no one is. We want to feel heard, we want to feel useful, we want to be seen as competent and smart. But I now recognize very quickly when a discussion about a project or a product becomes about self-preservation vs. what is best for the team and the product and its users, and I am allergic to it. It makes everything more stressful. It requires having to “read between the lines” every minute of the day. It slows everything down. It makes everyone grumpy and wary of each other. It is poison to healthy teams and products, and it affects me deeply (too much).

I deal with it by losing myself in side projects, and spending deliberate time with the work people who don’t succumb to that behavior.

How do you advise me if I were considering either an EM or PM role to decide on which is more suitable to try out first?

I think the best starting point is to reflect on where you naturally find energy, especially when things get hard. Do you find satisfaction in crafting elegant systems and seeing the architecture click into place? Or do you come alive when you hear someone articulate a pain point and you can immediately imagine a better experience? Do you find yourself trying to optimize team throughput and code quality, or do you have an interest in clarifying ambiguity, getting people to work together happily and effectively, and shaping decisions through influence rather than control?

PMs and EMs both lead, but in different ways. Engineering Managers lead through technical insight, mentorship, and a responsibility for the velocity, health, and growth of the team. Their scope is often constrained by the product strategy/roadmap and what’s possible technically, and their main outcome is helping the team build the right thing in the right way.

Product Managers lead through context, clarity, and storytelling. They untangle complex ambiguity, and they create clarity when everyone sees the world differently (which happens on every project…). Their main outcomes are making sense out of too many chaotic inputs, aligning everyone on the problem to be solved (and how to solve it), and keeping the team connected to each other and customers.

Thanks for still believing in RSS! Feel free to get in touch.

"Ack, think, act"—building trust as a product manager

Rian van der Merwe — Sat, 15 Mar 2025 13:13:02 GMT

Many (oh my word, so many) years ago I wrote that I thought “fairness” is the most important characteristic of a good Product Manager. I still stand by that, but I had another thought recently about a related characteristic that forms the other side of that coin.

Jakob Nielsen’s 30+ year old usability heuristics remain true to this day, but it’s not just relevant to UI/UX. In particularly I think “Visibility of System Status” is one of the most important skills a PM can internalize. The principles states:

The design should always keep users informed about what is going on, through appropriate feedback within a reasonable amount of time.

When users know the current system status, they learn the outcome of their prior interactions and determine next steps. Predictable interactions create trust in the product as well as the brand.

A PM can do nothing without trust. And to build trust in an organization, applying “visibility of system status” thinking is the #1 way to gain (and keep) that trust. That means a PM needs to:

Ack: Acknowledge comments or questions as soon as reasonably possible (within hours, not days), even if it’s just to say, “I saw this and will get back to you.”
Think: Respond to the original comment/question—with ultimate clarity—in a timeframe that balances thoughtfulness and pragmatism (days, not weeks).
Act: Follow through on any commitments / next steps with regular proactive updates (for as long as it takes).

Note that the order is important here as well. Don't Ack only after you've taken the time to Think. Don't Act before you Think. That seems obvious, but I'm sure we recognize the wrong order all around us (and in ourselves!) all the time.

This all might sound hard, but once you’re in the rhythm of this cycle, it becomes second nature. “Ack, think, act” becomes just the way you go through your day. I think this is something we should all aspire to more in product (and probably beyond).

Thanks for still believing in RSS! Feel free to get in touch.

Regarding "missed" and "slipped" deadlines

Rian van der Merwe — Fri, 10 Jan 2025 20:10:23 GMT

I really like Basecamp’s concept of “Hill Charts”. The gist of it is that each project we work on has two distinct phases: a “figuring it out” phase and a “making it happen” phase:

To quote from their post about it:

First there’s an uphill phase where you figure out your approach. You have a basic idea about the task, but you haven’t figured out what the solution is going to look like or how to solve all the unknowns.

Eventually you reach a point where there aren’t any more unsolved problems. That’s like standing at the top of the hill. You can see clearly all the way down the other side. Then the downhill phase is just about execution.

“Figuring it out” is full of uncertainty, unknowns, and problem solving. “Making it happen” is all about certainty, confidence, and execution.

I bring this up because one of the issues with quarterly planning cycles and committing to due dates on that cadence is that teams are often asked to commit to dates during the “figuring it out” phase. There’s a lot of uncertainty and unknowns, so teams have to make best guesses. The problem with this is that these do not reflect what Cagan calls “high-integrity commitments”:

The key is to understand that the root cause of all this grief about commitments is when these commitments are made. They are made too early. They are made before we know if we can actually deliver on this obligation, and even more important, if what we deliver will actually solve the problem for the customer.

So what inevitably happens is that, for a lot of projects, the date that teams provided “slips”. I believe this language matters, and I think by framing it this way an org tells teams they did something wrong. But the irony is that in the majority of cases, if teams move a date after they reached the “top of the hill”, they are doing the right thing for the business. They are saying that they have now figured out all the unknowns and uncertainties, and they are ready to make a high-integrity commitment. Again, here is Cagan:

So the compromise is simple. The product team asks for a little time to do product discovery before commitments are made, and then after enough product discovery is done to consider the risks, we are willing to commit to dates and deliverables so our colleagues can effectively do their jobs as well.

I think it’s important to encourage behavior that does the right thing for customers and the business. The right thing would not be to try to cut corners to meet a date that was committed to during a “figuring things out” phase. I also don’t believe the right thing is to inherently communicate to teams that moving a date once they reach the top of the hill means they “missed” a commitment.

I think we should be very clear about the nature of commitments when we make them. What is our confidence in our dates? Are we still figuring things out? Or are we at the top of the hill and ready to make a high-integrity commitment? The health of any Product org can be improved if we say that it’s ok to communicate what we think we can accomplish early on in the quarter, and move to high-integrity commitments once teams reach the top of each project’s hill.

Thanks for still believing in RSS! Feel free to get in touch.

My 2024 in Music

Rian van der Merwe — Tue, 31 Dec 2024 15:35:50 GMT

I love reading end-of-year music wrap-ups from the personal blogs I follow (two highlights this year include the posts by Sarah K. Moir and Simon Collison), so I wanted to make an attempt at my own as well. I decided to wait until Dec 31 so I can have accurate data from my Last.fm profile, where all my listening stats go (I use Spotify and Roon for streaming, and I also send my physical media listening stats there).

So according to my listening stats, here are my favorite releases from 2024 (plus two standouts from earlier years that I discovered this year and became obsessed with). Links will take you to my side project site Listen To More with some more info about each album.

#1 - A LA SALA by Khruangbin

A return to super chill vibes from the Texas indie soul trio, this is #1 in listen count because it’s a beautiful album, but it’s also wonderful dinner / hangout music. So we put it on a lot over here.

#2 - Songs Of A Lost World by The Cure

Only #2 in listen count because it was released so late in the year… This is my personal Album of the Year. What a gift to get this absolute masterpiece so late in The Cure’s career. If Endsong is the last song they ever make, I will be happy. “Left alone with nothing at the end of every song”. Dang.

#3 - Kontrapunkt by Markus Guentner

This year I started to dive even deeper into the Dark Ambient and Drone genres, so there are 3 such albums on the list, starting with Kontrapunkt. Most folks (myself included!) think of ambient music as “background fluff”, but this is… not that. This is anxious music, and in a weird way I find that it calms me down. If you give this a try (you should!), don’t just turn it on and walk away. Immerse yourself in it. And that goes for the next one too…

#4 - RITUAL by Jon Hopkins

Most of us know Jon Hopkins from his collaborations with Coldplay and his harder dance albums. This is very different—it’s a dark ambient collaboration with several artists that flows like one continuous track. I love this thing. It gets really intense in the middle before settling down in the last couple of tracks to a beautiful, calm release.

#5 - Leon by Leon Bridges

I will gobble up anything this neo soul artist puts out, and Leon is another wonderful entry in his discography. Really chill but also intricate.

#6 - Ohio Players by The Black Keys

I know most people have kind of moved on from The Black Keys, but their last few albums have been a return to form in my opinion. Ohio Players is solid blues rock from start to finish.

#7 - Sonido Cósmico by Hermanos Gutiérrez

If you like #1, you’ll love this. These brothers manage to pull off a sound that reminds of Khruangbin, but is also its own thing altogether. That’s a lot of chill on the list, so let’s go to…

#8 - Vega by Anberlin

Ah Anberlin. The crown jewel of the Tooth and Nail label for years, before things happened. I still love this band—Cities is such peak 2000s emo hard rock. I didn’t expect much from their latest, especially considering that some songs feature a different lead singer. But this thing goes hard, y’all. It’s definitely their best effort in years.

#9 - Small Changes by Michael Kiwanuka

The self-titled album from Michael Kiwanuka remains my favorite, but the new outing from this (yes, another!) neo soul artist is a solid entry, and I enjoy it a lot.

#10 - FAÇADISMS by Rafael Anton Irisarri

The last of the dark ambient albums, and the most devastating. Rafael Anton Irisarri is my favorite ambient artists (check out Solastalgia), and his latest is another fantastic entry in his prolific discography.

And based on how much I listened to these two new discoveries (for me), I have to give them honorable mentions:

Every Moment, Everything You Need by Deserta (2022)

My most-listened song in 2024 was I’m So Tired by Deserta. I discovered this album early in the year, and it remained in constant rotation all year long. It’s shimmery guitar shoegaze at its best, with lyrics that feel just right:

Guess you'll know why I'm so tired
Too tired to be cool
Guess you'll know why I'm so tired

Dreams You Don’t Forget by NIGHT TRAVELER (2021)

This is an album that’s on the verge of being synthwave, but not quite. It’s just this side of pop, but it has that neon 80s DNA that I love so much (see also On the Corner Where You Live by The Paper Kites and Red Earth & Pouring Rain by Bear’s Den). Another one that was in constant rotation despite being a little older.

As for 2025… I don’t know? This has been a wild year (but it feels like they all are, these days). I enter 2025 with a fair bit of anxiety. But I also know that, as always, music will be there for me. A companion for every mood, a friend in every circumstance. I remain eternally grateful for this undying obsession of mine.

Happy New Year, everyone. May you find your Album of the Year early, and hang on to it steadfastly.

Thanks for still believing in RSS! Feel free to get in touch.

47 (no, not that one)

Rian van der Merwe — Sat, 09 Nov 2024 15:48:05 GMT

I turned 47 this week. There was also an election. It was also the 8th anniversary of my dad’s passing. I know this is a Product blog, but allow me to take a moment to just say, dang, y’all. What a week. What a decade. I don’t have words for the era we are about to enter in the US. So, as always, I turn to music. Some people eat their feelings, I listen to mine.

First, I made a post-election feels mixtape on Spotify. I am deliberate about calling it a mixtape and not a playlist. There’s no specific genre, it’s all vibes. And if you do decide to give it a go, don’t shuffle. There’s an arc here.

Second, as I often do, I used my birthday to do a listen-through of as many Genesis albums as I can fit in (if you know me and my unnatural obsession with Phil Collins, this won’t surprise you). The song Undertow has always been one of my favorites, but this week it hit especially hard:

Stand up to the blow that fate has struck upon you Make the most of all you still have coming to you Lay down on the ground and let the tears run from you Crying to the grass and trees and heaven finally on your knees

Let me live again, let life come find me wanting Spring must strike again against the shield of winter Let me feel once more the arms of love surround me Telling me the danger’s past, I need not fear the icy blast again

We are heading into—sorry for using the word everyone is using but I don’t think there’s a better one—unprecedented times. Brené Brown says we should focus on “micro-dosing hope”. I like that. I don’t know where we’re heading, but I have to believe that Spring must strike again. And that when it does, we’ll need not fear the icy blast again.

Stay strong, friends. ❤️

Thanks for still believing in RSS! Feel free to get in touch.

Thoughts and takeaways from the Lenny and Friends Summit

Rian van der Merwe — Fri, 25 Oct 2024 01:30:01 GMT

I spent the day at Lenny’s Summit with over 1,000 other product people. The line-up of talks was fantastic, but you never know how it’s really going to go. I am happy to say that the hit rate of good talks was quite a bit higher than some other conferences I’ve been to. I tried to write detailed notes, and below are my summaries and takeaways from 4 of the talks that I enjoyed the most.

There were also a couple of interviews that were really great—Lenny interviewing Shreyas Doshi, and Sarah Guo interviewing Mike Krieger and Kevin Weil (pretty cool to see two major competitors play nice on stage together)—but those were a little harder to summarize so I gave up on note-taking and just listened.

Product Management is Dead (or Will Be Soon) by Claire Vo (LaunchDarkly)

I’ll start with this one since the title is obviously pretty controversial. I expected to disagree with a lot of it, but it was actually really measured and interesting. Claire focused on the rapid transformation of product management due to AI, and outlined the need for product leaders and teams to adapt to these changes. She highlighted the evolving nature of product roles, driven by automation, and offered insights on how to prepare for an AI-powered future.

Key Insights:

AI Will Transform Product, Design, and Engineering.
AI is advancing faster than anticipated, reducing the need for traditional product management tasks and roles.
The key challenge is to not be caught off guard by these changes.

3 Requirements for an AI-Powered Team

Automate to Speed Up Delivery
- Use AI to accelerate common tasks such as:
  - Drafting documents, collecting feedback, writing updates, and creating agendas.
  - Monitoring goals (OKRs), tracking competitors, and preparing for interviews.
  - Creating customer stories, enhancing presentations, and explaining product functionality.
- Aim to achieve 75% progress quickly with AI assistance, rather than striving for 100% automation.
Add New Skills and Expand Capabilities
- The future of product management will include people with technical backgrounds (e.g., engineers) who use AI to gain product skills.
- AI will enable individuals to learn and contribute across multiple domains.
Multiply Your Impact by Teaching AI Skills
- Encourage your team to embrace AI for building products and improving efficiency.
- Normalize the use of AI in everyday tasks to enhance overall team performance.

Impact of AI on Product Teams

Time & Creativity
- With product work taking less time and requiring less mental effort, product teams can invest more time in creative problem-solving and direct user engagement.
Fewer PMs Needed
- AI will consolidate previously distinct roles, leading to a new model where one person, with the aid of AI, can manage design, engineering, and product functions—creating an “AI-powered triple threat.”

Evolution of Roles

From Product Triad to AI-Powered Generalists
The traditional “product triad” (PM, designer, engineer) is evolving into roles where AI-empowered generalists can handle multiple disciplines.
Teams will need to adapt to this shift without being intimidated by the collapse of traditional job boundaries.

Takeaways for Product Leaders

Prepare for the New World of AI-Driven Product Management
- Acquire more commercial and technical skills.
- Learn to budget for AI tools and agents that enhance hiring and team structure.
- Explore new team topologies beyond the traditional triad model.
Start Adapting Now
- AI-driven changes will happen fast. Begin integrating AI into team processes and management strategies immediately.

Summary

Product teams must embrace AI now to remain competitive and efficient.
AI will consolidate roles, but with the right approach, it won’t break your team—rather, it will strengthen and streamline it.
Product leaders must learn to navigate and manage this new, AI-driven world.

How to Do the Product Review Right by Yuhki Yamashita and Mihika Kapoor (Figma)

This was, unexpectedly, probably my favorite talk of the day. It was just so well executed: a CPO and IC PM riffing off the experience of doing product reviews. They offered a new perspective on product reviews, emphasizing that their true purpose is not about decision-making but about building trust with stakeholders. They shared key insights on how PMs can run effective reviews by shifting their focus from trying to impress to fostering confidence in their judgment and direction.

Key Insights:

Product Reviews Are Not for Making Decisions, but for Building Trust
- Traditional advice for product reviews focuses too much on pitching ideas and covering every detail, leading to ineffective presentations.
- The real goal is to gain trust, which allows PMs the time and space to execute on what truly matters—building great products.

What PMs Are Typically Told (but is Ineffective):

Build up Context First
- Most attendees won’t care about background details.
Cover All Bases
- Trying to explain everything dilutes your message—“if you say everything, they hear nothing.”
Circle Back Later if Unsure
- Deferring answers creates uncertainty and erodes confidence.
Make a Big, Bold Pitch
- Emphasizing a grand vision over clarity and precision can backfire.

What PMs Should Actually Do (for Winning Trust):

Lead with the Punchline
- Present the most controversial or important point first. This sparks honest reactions early and avoids drawn-out discussions.
Create an Internal Brand
- Use humor or memorable analogies (“Make a meme”) to spread your idea and make it stick with your team. This can generate internal momentum.
Share Your Gut Feelings
- Don’t wait for perfect data. Share your instincts and anticipated learnings upfront, demonstrating decisiveness and confidence.
Be Your Own Biggest Critic
- Show you’ve thoroughly considered all options and potential challenges. Structure your presentation as:
  - Pain Point → Solution → Proof Point
  - Lay out the solution space and address anticipated concerns to preempt pushback from leadership.

Summary:

The Product Review Isn’t the Most Important Part
While product reviews feel critical, what matters more is what happens outside the review. Building trust during the review gives PMs the freedom to focus on what truly counts: creating and delivering valuable products.

By focusing on trust-building rather than decision-making, PMs can create more impactful product reviews and set the stage for successful product development.

How to Win Friends and Influence Decisions by Julie Zhou

Julie outlined a structured approach for moving from having a strong personal opinion to shaping better collective outcomes in decision-making. She provided practical steps to navigate disagreements and arrive at informed, collaborative decisions that benefit the entire team.

Key Steps:

Step 1: Draw a Circle Around the Team, Not Yourself
- Frame the decision-making process as a collaborative effort, not a personal mission to convince others.
- Encourage open dialogue by focusing on shared goals: “What we really want is X, so let’s explore various ideas.”
Step 2: Assume Everyone Sees Part of the Truth
- Use the analogy of the “blind men and the elephant” to acknowledge that everyone holds part of the truth.
- Differences in perspective should be seen as valuable pieces of a larger, more cohesive understanding.
Step 3: Uncover the Truth from Multiple Perspectives
- Facilitate discussions that explore the rationale behind each person’s perspective. Ask questions like:
  - “What would have to be true for us to believe this is the right approach?”
  - “What data or scenario would convince us that the other option is better?”
Step 4: Turn the Problem Into a Data-Driven Question
- Shift the debate to evidence-based thinking. Seek out relevant data by asking:
  - “How can we know that it’s really true that…?”
  - “What evidence do we already have, and what do we need?”
Step 4b: When Data Isn’t Available, Rely on People
- If data is unavailable, delegate the decision to someone who is deeply invested, knowledgeable, and trusted to make the best call. Trust the judgment of someone with the right context and skills.
Step 5: Review and Learn from Decisions
- Regularly revisit past decisions to assess their outcomes. This practice helps identify whether decisions led to success or failure.
- Set calendar reminders to review decisions at regular intervals and document areas of disagreement or learning.
- The layers of learning from past decisions:
  - What did we learn about our customers and their needs and preferences?
  - What did we learn about the levers that drive our product usage?
  - What did we learn about the best measurement proxies for our goal?
  - What did we learn about making better and more efficient decisions?
  - What did we learn about the quality of our individual judgments?

This framework emphasizes collaboration, evidence-based decision-making, and continuous learning to improve both individual and team outcomes.

How to Craft an Elite Career by Nikhyl Singhal (Former VP of Product at Meta)

This talk offered insights on managing a successful career, viewing it as a product to build over time. Nikhyl provided a framework for progressing through different stages of a career while highlighting key pitfalls to avoid and strategies for developing a strong personal brand and maintaining balance.

Key Insights:

Your Career is Your Most Important Product
- Careers span multiple jobs, typically 2–3 years each, which can result in 20–30 jobs over a lifetime.
- Treat your career like building floors in a structure, with distinct phases to navigate.
Career Phases:
- Foundational: Gaining experience and stories.
- High Impact: Driving measurable value and influence.
- Joyful Giving: Contributing to others and sharing your knowledge.
Collect Stories and Build Expertise
- Aim to accumulate stories from diverse experiences (different companies, markets, and cultures).
- The ability to say, “I’ve seen this problem and here’s how I solved it,” is key to advancing.
- Continuously ask yourself: What story will I tell in 12 months? If it’s the same as today, it may signal career stagnation.
Establish a Strong Reputation
- Develop a reputation of hard work, being a team player, and offering strong opinions that are open to change.
- Your reputation today forms the brand that can open future opportunities.
- Focus on being a builder and a giver—someone who elevates others rather than acting solely for personal gain.

Avoiding Leadership Pitfalls

Avoid Burnout
- Over-investing in work can lead to resentment when sacrifices (e.g., missed family events) aren’t reciprocated.
- Enforce boundaries early to prevent burnout—success often leads to more responsibilities without additional rewards.
Beware of Superpower Shadows
- Identify and manage the downsides of your strengths. For example, being great at storytelling might come at the cost of overlooking important details.
- The skills that got you where you are may not be the ones that propel you forward.
Recognize You Are Not Alone
- Build a network of product leaders for mutual support and collaboration. Helping others is a key part of career longevity and satisfaction.

Summary

Divide your career into phases: foundational, impactful, and giving.
Accumulate diverse stories that show your growth and problem-solving abilities.
Your brand is built on your current reputation—focus on being a builder and contributor.
Set and enforce boundaries to avoid burnout and resentment.
Leverage your superpowers, but be mindful of their potential downsides.
Cultivate a community of peers for long-term support and shared learning.

By focusing on storytelling, reputation-building, and self-awareness, you can craft a career that grows over time, with a strong foundation in both personal and professional fulfillment.

Thanks for still believing in RSS! Feel free to get in touch.