Thank you so much for your likes, shares, and votes on the first edition written by a guest 🔥. Maxime’s documentation workflow clearly resonated!

Today I’m sharing exactly how I organize myself: introducing the AI Product Workspace. It’s a small folder of markdown files that I create for each project (or client in my case), in order for AI to work with a real product context.

In today’s edition:

• Why AI outputs get generic when your context lives only in your head

• The exact 5-file scaffold I recommend

• A prompt to create the files in one session by talking

• How I keep the workspace alive with lightweight automations

• Bonus: an interactive premortem prompt that helps you think deeper about what might go wrong, and actively prevent it.

Enjoy!

The AI Product Workspace (5 files to improve your agent’s quality)

Why your AI keeps forgetting

Every new chat starts from zero, so you’ve to re-explain the product, the users, the current initiative, the constraints. You forget one detail, and the output goes sideways…

Projects in ChatGPT or Claude help a bit. But they still tend to be shallow: a few instructions, a few uploads, and no real operating structure. They’ve memory but you can’t be sure if it’s gonna be used, nor how.

The simplest fix I can recommend:

• Keep your core product knowledge in a small folder on your machine. I call it the AI Product Workspace.

• Then start Claude Cowork, Claude Code, Cursor or Codex in this folder. Prefer these tools over Claude / ChatGPT, because they can read and write in the folder.

🛫 The 5-File Scaffold

These files cover most of the context I need to get useful AI outputs on the first try.

The folder looks like this:

acme-workspace/
├── company-id.md
├── current-bet.md
├── users.md
├── competitors.md
└── guidelines.md

Below, I use a fictional company called Acme, a B2B AI copilot for support teams, to show what each file looks like in practice.

1/ Company ID (company-id.md)

Think of it like the identity card of your company. Do not stuff it with too much context. Focus on information that can help prioritize what’s important, and that change slowly. You should probably update this once per quarter (or even less).

# company-id.md — Acme (excerpt)

## Company Snapshot
- B2B SaaS, Series A, 45 people, SF + remote
- "AI copilot for support teams" — auto-drafts replies, routes tickets, flags escalations

## Product Overview
- Core: reply drafting (GPT-4 based), smart routing, sentiment detection
- Strength: integrates with Zendesk, Intercom, Freshdesk in < 1 day
- Gap: no voice channel support yet, analytics dashboard is shallow

## ICP and Buying Context
- Buyer: VP Support / Head of CX at mid-market SaaS (200-2000 employees)
- User: Tier-1 support agents handling 40+ tickets/day
- Why they buy: agent burnout, inconsistent reply quality, slow onboarding
- Why they don't: "we already have macros," security review takes 3 months

## Strategy
- Company's OKR: ...
- Team's OKR: ...
- Important success metrics: ...

2/ Current Bet (current-bet.md)

The most useful file in practice. This is the one that makes the biggest difference in day-to-day AI conversations. It contains the strategic information you would use to pitch an important track to a colleague. It captures your strategy, the main surface areas, decisions, and assumptions you want to validate.

You should probably create one of this per “big rock”.

# current-bet.md — Acme (excerpt)

## Core Insight
Enterprise deals stall because security teams block AI access to customer data.
Our current architecture requires full ticket access. Competitors are shipping
"data-minimized" modes. We're losing deals we should win.

## Why Now
- Lost 3 enterprise deals in Q4 to security objections
- Competitor X launched "privacy mode" in January
- Our SOC2 Type II just completed — we have the compliance foundation

## Current Status
- Privacy-mode API spec: done
- Agent-side UX for redacted view: in progress (ships week of March 31)
- Security whitepaper for buyers: not started

## Risks & Assumptions to validate 
- Redacted mode may degrade reply quality by 15-20% — no real data yet
- Engineering capacity: 2 of 4 engineers pulled to reliability work until April

I refresh this every 2 weeks. When it goes stale, almost every AI conversation gets worse.

3/ Users, Competitors, Guidelines

The other 3 files follow the same principle: structured, concise, opinionated.

• users.md: Personas, pain points, jobs-to-be-done, and real quotes from interviews. The quotes matter more than the structure. AI outputs get noticeably better when they can reuse actual user language instead of inventing generic empathy.

• competitors.md: Competitors, alternatives, pricing anchors, market shifts. This one is perfect for Deep Research, I usually start with the competitive analysis prompt from AI Bites #1 to generate a first draft, then trim it down to what actually matters for decisions.

• guidelines.md: Writing tone, ticket format, changelog conventions, vocabulary to use and avoid.

Each of these files has 5-8 sections. The interviewer prompt below generates all of them, so I won’t repeat the full outlines here. You can tap on the button to see the full outlines or read the prompt below.

Preview the files

What NOT to put in your workspace

Do not add meeting transcripts, full research reports, raw data exports, or anything longer than 3 pages. These files are context, not archives. If a file is too long, AI either ignores the important parts or gets confused. Keep it short and opinionated.

Note: do not aim for perfection on day one. A workspace that is 30% complete already beats a blank chat.

🎙️ Create the 5 files by talking

This is my favorite part. You do not need to sit down and “write documentation.” You can just answer questions, and generate them.

I use AI as an interviewer, and dictate my answers (I use Monologue, but there is plenty of other ones). I talk, and AI structures it, spots gaps, and drafts the files.

Here’s how I use it:

1️⃣ Open a new chat in Cursor, Claude Code / Cowork or Codex, and paste the interviewer prompt below

2️⃣ Answer out loud using dictation. I dump context fast, typos and all

3️⃣ Paste any useful material you already have: notes, decks, tickets, docs, meeting transcripts

4️⃣ Review the draft files, fix what feels wrong, and save them in your workspace

It usually takes me around 15 minutes. Here is the prompt I would use 👇

You are my product workspace interviewer.

Your job is to help me build 5 markdown files that will become the memory of my AI Product Workspace:
- company-id.md
- current-bet.md
- users.md
- competitors.md
- guidelines.md

How you should work:
- First, show me the proposed outline of all 5 files
- Then interview me one file at a time
- Ask 3 to 5 focused questions per file
- Accept messy dictated answers
- After each file, summarize what you understood and tell me what still feels unclear, contradictory, or weak
- If I say "skip", leave [TO COMPLETE] markers and move on

Handling pasted material:
- I may paste documents, notes, decks, transcripts, or links at any point during the interview
- When I do, scan the material for relevant information and integrate it into the current file
- Tell me what you extracted and what you ignored, so I can correct course
- Do not stop the interview to summarize the entire document — just absorb and continue

Important behavior:
- Do not ask everything at once
- Do not write polished consultant prose
- Use my words when possible
- If a section sounds vague, challenge me and ask a sharper follow-up
- If something matters but I forgot it, point out the gap

[...] Tap the button for the full prompt

Open the prompt

Enrich with Deep Research & existing files

After the interview, some sections will still be thin. That is normal. The point of the first pass is to capture what is already in your head.

Then I do a second pass for external knowledge:

1️⃣ Start a deep research on your company, and some of the competitors using the prompts shared in AI Bites #1. Then share the results with your agent, and ask which insights it would extract to complete the files. Review the changes, then ask it to update them.

2️⃣ Share presentations, transcripts and other files that contain useful strategic info with your agent. Ask which insights it would extract to complete the files. Review the changes, then ask it to update them.

🔄 Keeping it alive

The workspace is useful only if it stays close to reality. What usually happens after a week: you create good files once, it’s super useful, then decisions move on, research piles up, and the AI quietly starts using stale assumptions.

Where automation helps

Here’s how I think about the automation ladder, from simplest to most hands-off.

Level 1: Manual with AI assist (start here)
After a meeting or decision, paste the transcript or notes into your agent, along with the update prompt below. Review the suggested edits. Apply them yourself. This already cuts the update work from 20 minutes to 5.

Level 2: Recurring reviews with Claude Cowork / Codex
Set up a recurring review that scans your connected sources thanks to MCPs, meeting transcripts, decision logs, shared docs, even the codebase, and proposes workspace updates on a schedule. You still approve, but you don’t need to remember to run the prompt. The workspace stays fresh without willpower.

Level 3: Automated diffs with Claude Code or Codex
Take accepted updates and turn them into actual markdown diffs or pull requests against your workspace folder. If you version your workspace in git (I do), this gives you a history of how your product context evolved over time. Surprisingly useful when onboarding someone or reviewing past decisions.

Level 1: Manual update loop

After I finish a task, an important meeting, a new customer insight, or a strategy decision, I always talk with my agent, and end with a question:

1️⃣ “Which decisions and lessons did we discuss that should be documented in this folder? Let me review the changes. ”, then apply the adequate changes. If like me, you use snippets, you can map a shortcut to an elaborated version of this prompt 👇

Which decisions and lessons did we discuss that should be documented in this folder? 
Which files would you update? Let me review the changes. 

File update frequency (use this to calibrate what deserves an update):
- current-bet.md: changes often — status, scope, risks, shipped items. Update aggressively.
- users.md: changes when new research or quotes arrive. Update when evidence shifts.
- competitors.md: changes when competitors move or market context shifts. Update rarely.
- company-id.md: changes when something structural shifts (ICP, pricing, team). Almost never.
- guidelines.md: changes when conventions evolve. Almost never.

For each proposed update, show:
- file name
- section name
- why this section should change
- current content (quote it)
- proposed replacement or addition

Also tell me:
- what assumptions now look stale across files
- what contradictions appeared between files
- what evidence is still missing

If nothing important changed, say so clearly and explain why.
Do not rewrite entire files. Only suggest precise, targeted edits.

🪦 Bonus: Premortem

This is my favorite use of the workspace because it compounds the value of the whole folder.

Imagine that your current bet initiative failed, then work backward to understand why. I use AI as a facilitator to challenge my first answers and help me see what I missed.

So instead of a one-shot “give me 10 risks” prompt, I prefer an interactive one.

You are facilitating a premortem exercise based on Gary Klein's method.

First, read these files to understand the context:
- company-id.md
- current-bet.md
- users.md
- competitors.md

Your role is not to do the thinking for me. Your role is to help me think deeper.

Process:
1. Start by briefly summarizing the current bet and the success criteria you infer
2. Ask me 5 focused questions before generating any failure reasons
3. Wait for my answers
4. Generate 7 to 10 plausible reasons this initiative failed 6 months from now
5. Ask me which ones feel real, which ones feel overstated, and what is missing
6. Challenge weak assumptions, missing evidence, and optimistic interpretations
7. Refine the list

For each final failure reason, assess:
- likelihood: high / medium / low
- impact: high / medium / low
- current mitigation: yes / partial / no
- evidence: what in the workspace supports this concern

Then identify the top 3 risks that are both important and under-mitigated.

For each of the top 3, provide:
- why it matters
- what signal would tell us it is becoming real
- one action we could take this week
- one question we still need to answer

Rules:
- Be concrete
- Use the workspace, not generic startup advice
- Push back when my answers are vague
- Spot gaps between what we say we believe and what the files actually show

Output format:
- Short summary of the bet
- Ranked risk table
- Top 3 risks with actions and open questions
- Blind spots or contradictions that deserve follow-up

—

If you set up this workspace, I promise every prompt from AI Bites past editions will work better, the competitive analysis, the ticket writer, the MCP workflows, the documentation pipeline.

Thank you for reading this far. I hope you’ll find this useful. Setting up the workspace takes 20 minutes, and every AI interaction after that gets better. Try it.

Until next time!

Olivier

Share → Please help me promote this newsletter by sharing it with colleagues (tap the refer button) or consider liking it (tap on the 💙, it helps me a lot)!

About → Productverse is written by Olivier Courtois (15y+ in product, Fractional CPO, coach & advisor). Each “PM Snacks” features handpicked links to help you become a better product maker, and each “AI Bites” is a deep dive in AI-enabled workflows.

Thank you so much for your likes and votes on the previous edition on communication prompts and MCP workflows.

Today’s edition is special: I’m hosting my first guest post!

Maxime Berkowicz, First PM at Elba, built an open-source tool to automate product documentation using Claude Code. It saves him 1-5 hours per feature, and I bet it can help you too.

I know what you’re probably thinking: documentation, is-it really the highest leverage task we can talk about? Actually, I do. The better your documentation quality is, the more AI-powered workflows you can enable. So read-on to learn how to save +3hrs per feature.

In today’s edition:

• Why you should leverage AI models to have best-in-class documentation

• What is Claude Code (and why PMs should care)

• How Max-Doc-AI automates documentation end-to-end

• Some of his learnings along the way on how to build such systems with AI tools

Enjoy!

How I automated my product documentation with Claude Code (and why you should too)

TL;DR: I built max-doc-ai, an open-source tool that automatically generates product documentation by exploring your codebase. Saves 1-5 hours per feature. Here’s how it works.

The problem: product docs always lagging behind

Nobody likes writing documentation. (Well, I don’t)

Product teams have a simple problem: every week, their team ships new features. And every week, the same drill: taking screenshots, writing feature descriptions, updating a knowledge base… It usually takes between an hour and half a day to fully document a feature.

Not huge, but it adds up. It’s also the kind of task that quickly slides to the bottom of the to-do list when there are urgent product deadlines.

Result? Lagging documentation that slows down entire companies :

• Sales can’t sell without great collaterals: sales don’t know what’s real, or already available. Product marketing teams can’t build sales collaterals out of a faulty documentation.

• Engineers become living documentation: Every “quick question” costs context-switching. When that engineer leaves, the knowledge leaves too.

• Onboarding drags: New hires spend weeks asking “how does X work?” instead of contributing. Ramp time doubles. Senior people become interrupt-driven.

• AI initiatives die: your support bot, sales copilot, and internal agents are only as good as your knowledge base. Bad docs = bad AI = abandoned initiatives.

Thus, I asked myself: “What if AI could write all product documentation for me?”

🛫 Maxime’s Daily Workflow

Until very recently, I would block a 1-5hrs slot in my calendar to

• Manually read through meeting minutes, tickets, and PRDs

• Take screenshots

• Copy-paste in Claude or ChatGPT

• Copy-paste the results

Now, I only take 15mins:

• Every Thursday morning, I open my terminal and type
  @claude Create a release for [feature]

• Claude explores the codebase, launches a browser, captures screenshots, and generates docs

• 15 minutes later, I review the Knowledge Base article draft and Slack announcements

• I tap “enter” to publish, and I’m back to roadmap planning or coffee ☕

Using Claude Code as a documentation partner

Before talking about the tool I created “max-doc-AI”, a quick detour through Claude Code - my partner in crime.

If you don’t know it, imagine ChatGPT... but that can actually do things on your machine.

Claude Code is an intelligent terminal. You type commands in natural language & it executes. It has access to your codebase: it can read, explore, understand your code. On complex workflows, it doesn’t “lose the thread” like other AI tools.

Three things that made it a must-use for me:

1. The “plan mode”
   Claude Code can enter planning mode before executing. It explores your codebase, thinks through the approach, presents you with a plan. You validate, it launches. It’s exactly what a good PM should do: specify before building.

2. The context
   Unlike ChatGPT where you have to copy-paste code in every conversation, Claude Code has direct access to your repo. It understands the architecture, the patterns, the naming conventions. Less guessing & more precision.

3. No lock-in
   Claude Code generates... code. Markdown. Python scripts. You can modify, share & use your files elsewhere. For a PM who wants to keep control, that matters.

Max-Doc-AI: automating docs end-to-end

Max-Doc-AI is a set of Claude Code “skills” & Python scripts that automate the entire documentation workflow.

Within a single command here’s what happens:
@claude Create a release for [feature name]

1. Codebase exploration Claude explores your code to understand how the feature was implemented, what the routes and URLs are, what the main components are. Not what was planned in the PRD, but what actually exists.

2. Automatic screenshot capture This is where it gets interesting. Claude uses Anthropic’s “Computer Use” API: it opens a browser, navigates your app, takes screenshots. Based on the code, it pulls automatically the right URL (Well, sometimes it gets the wrong page when I have two screens. It’s still experimental. But 80% of the time, it works on the first try.)

3. Documentation generation With the code context and screenshots, Claude generates a complete knowledge base article: overview, key capabilities, step-by-step guide, use cases, FAQ. Screenshots integrated with proper captions.

   

4. Upload to our knowledge base Screenshots go to a CDN (CloudFront in my case), the article syncs to your tool (Pylon, Zendesk, Confluence...). The system is multi-provider: configure once, works everywhere.

5. Customer announcements generation Claude generates two versions: a short one for Slack (with emoji), a detailed one for email. Both include the link to the article that was just created.

Here’s an example of the documentation that was directly uploaded to our knowledge base with the correct screenshots for each sub-feature :

Total time: 10 to 15 minutes.

How it works under the hood (without getting too technical)

The tool has 5 modular “skills”. They’re basically markdown files with instructions that Claude is told to use. You can use them separately or all-together with the “create-release” skill. Expert tip: tap each one to read their content.

@create-release (the orchestrator) The conductor. It asks a few questions (where’s the feature? what date?), then launches the other skills in the right order.

@update-product-doc The documentation brain. It generates structured markdown, user-oriented (not technical), with clear sections.

@capture-screenshots Uses the Computer Use API to navigate and capture. This is the most experimental skill. Multi-screen = display problems sometimes.

@sync-docs The integrator. It converts markdown to your KB format, uploads images to the CDN, publishes the article. Extensible architecture: you can add your own provider.

@create-changelog The communicator. It writes announcements adapted to the channel (Slack vs Email).

Everything is in Python and Markdown. Nothing exotic. You can read the code, modify it, fork it.

How to use it (quick start)

The easiest way is to follow this tutorial (tap here for subtitles) 👇

If you want to test Max-Doc-AI:

1. Install an IDE of your choice (I recommend VS Code)

2. Install Claude Code

   1. Install Brew & Node

/bin/bash -c "$(curl -fsSL <https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh>)"

brew install node

c. Finally, install Claude Code :

npm install -g @anthropic-ai/claude-code

You’ll need an Anthropic API key (pay-as-you-go recommended for testing, switch to Pro or Max later).

3. Launch Claude in a “code” folder on your machine

claude

4. Ask Claude to “Clone the following repo : https://github.com/maxberko/max-doc-ai”

git clone <https://github.com/maxberko/max-doc-ai>
cd max-doc-ai

5. Ask claude : “Guide me through the set-up of this Github project”

   1. Configuration Create a new .env file & copy .env.example and fill in your API keys, Knowledge Base credentials, app credentials.

      Create a new config.yaml file & copy config.example.yaml and adapt: product URL, KB collections, screenshot settings.

   2. Setup

python3 scripts/setup.py

6. Launch your first release

claude
# In the terminal:
@claude Create a release for [your feature name]

The result: complete documentation in 10-15 minutes.

What’s next

My goal: 100% up-to-date documentation, effortlessly.
Comment below if you’d like to sign-up to try it out first 💬

V2: A web interface I’m building a web interface to avoid working in the terminal. It’s a privacy-first automation of your documentation tasks.

V3: An autonomous documentation agent Transform max-doc-ai into MAX : an autonomous agent that checks every day if new features have been deployed, generates your doc automatically & sends you a summary for validation.

Three lessons learned building this tool

1. Specify before launching (even with AI)
   The temptation with Claude Code: “it’ll be magic, I ask and it works”. Spoiler: no.
   My workflow: first, PRD brainstorm with Claude. Then, plan mode to implement. Then iteration: test, fix, secure. Even with AI, we’re still PMs : specify, validate, iterate.

2. Security, always

   Claude Code has access to your machine. It can read files. Execute commands. It’s powerful, and potentially dangerous. Basic rules:

   1. Never leave API keys outside the .env file (which is never committed to GitHub)

   2. Always ask Claude to run a security checklist before pushing

   3. Use granular permissions : avoid “--dangerously-skip-permissions”

   An API key that leaks on GitHub means thousands of dollars in AI consumption within hours.

3. Open-source is also for PMs

   I’m a first PM, originally not a trained developer. Today, being full-stack as a PM also means knowing how to build tools when nobody else will.

   Since I shared the repo, I received a PR to add Google Gemini (cheaper alternative for screenshots). Someone else is working on Confluence support.

   Open-source is a multiplier of connections and value :-)

I help teams automate boring tasks through AI & learn how to do it by themselves. Curious how? Reach out on LinkedIn !

Maxime Berkowicz • Product & AI Consultant | Open-source builder

—

Thank you for reading this far, and many thanks to Maxime for building such an helpful tool, and sharing some secrets with us today. Don’t forget to like or comment below to get more information about the next versions, and to let me know if you’d like more guest posts.

Until next time!

Olivier

Share → Please help me promote this newsletter by sharing it with colleagues (tap the refer button) or consider liking it (tap on the 💙, it helps me a lot)!

About → Productverse is written by Olivier Courtois (15y+ in product, Fractional CPO, coach & advisor). Each “PM Snacks” features handpicked links to help you become a better product maker, and each “AI Bites” is a deep dive in AI-enabled workflows.

Thank you so much for your likes, shares, and votes on the previous edition of AI Bites 🔥. It seems you’ve enjoyed the GPT-5 “Prompter” project, and the Ticket writer prompt.

In today’s edition, I deep dive into these most voted topics:

• Backlog Autopilot: leverage AI to manage your backlog (MCP)

• Communicate Progress: use AI to write progress reports (MCP)

Prompts are getting long, so I’m now storing them in a Notion database. Tap the buttons to access the full prompt (for free).

Enjoy!

Before we dive in, Claire Vo released a video with Dennis Yang where he presents his Cursor workflow (99% similar to the one I’ll describe below). 📺 If you prefer a video version, be sure to watch it!

What is an MCP Server?

I use several MCP servers in my daily life. Here’s a quick definition:

Model Context Protocol is a standard for connecting AI applications to external systems. Basically, it’s an API designed for LLM. Meaning it can easily discover available capabilities, use them, answer questions, and take actions.

• 2 types of servers exist:

  • public ones (usually there is a public URL you reference)

  • local ones (which can use some commands or executables, on your computer) which are only available from a desktop app.

• Most modern tools like Notion, Linear, Figma or Amplitude, have been rushing to release their public “MCP Server” usable in desktop and web apps.

• You can install them into AI apps like Claude, Cursor or Agents like Claude Code / Codex. Note: ChatGPT MCP support is still pretty nascent (and limited to the “developer mode”).

Which AI should you use as your copilot?

I’ve been using Cursor for a few years (to develop), but it’s now my favorite way to edit files and create projects too (non-developer tasks).

Now I can:

• Create a simple folder on my computer with a few knowledge files that are completely “portable” (topic to be covered in another edition).

• Add a few cursor rules (= shortcuts) to automate my usual prompts like writing tickets, scoping down or writing a progress report.

• Plug MCP servers to be efficient (Linear/Notion for backlog access, Granola for meeting transcripts access, Figma for design access, Amplitude for data access…).

• Chat “with the folder” to brainstorm, analyze data, work on PRD, and more.

• Create files with AI, but more importantly take over, and edit them manually in the editor.

If you’re curious about Cursor, but you’re not sure where to start: this article on the modern AI workspace should help you.

Obviously, it’s not going to be everyone’s cup of tea, so here’s a comparison of the main tools you can use to leverage MCP power, and my use case for each 👇

Note: This table is inspired by Teresa Torres’ article on Claude Code. Highly recommended read.

🛫 Backlog Autopilot

I’m collaborating with teams that host their tickets in Notion as well as Linear. Fortunately, both have MCP Servers that I can use to “pilot” my backlog. Note: I’ll share examples written for Linear (but it works the same for other MCPs).

Currently, I have 2 methods to create tickets in the backlog:

• I create tickets directly in the backlog with a few bullet points (= some notes for myself). Then when I need to really write the content, I’ll ask the AI to read the ticket, collaborate, and update it in the backlog.

• I write a PRD document for larger initiatives, talk with AI to find the best way to scope independent tickets, ask clarifying questions for each, then create the tickets in the backlog. 💬 Let me know if you’d like me to share this prompt next.

Improving a specific ticket

To write this prompt I used the following method:

1. Started a new chat explaining my goal: “create a new command that will read a ticket content through (MCP step), interview me, then suggest a ticket, once I approve, it should update in the backlog (MCP step)”

2. Pasted my “writing guidelines”, basically the instructions I shared in AI Bites #2.

3. Iterated on the level of details, and rules to make sure it works 99% of the time.

To use this prompt I just:

1. Open Cursor, and enter: “/ticket-refine” along with the url of the ticket. That’s it.

2. When additional information could be useful

   1. I use Cursor mentions, to attach specific knowledge files in the folder. I add “@filename”, and the ticket refiner prompt will read my PRD or some user research extracts.

   2. I ask AI to use specific MCP servers like Amplitude/Posthog to extract data, Figma to analyze design, etc.

# ticket-refine

## Workflow

### 1. Fetch Ticket from Linear

**Input**: User provides either a Linear ticket URL (e.g., `https://linear.app/acme-corp/issue/PROJ-456`) or ticket ID (e.g., `PROJ-456` or UUID).

**Actions**:
- Extract ticket ID from URL if provided, otherwise use ID directly
- Use `mcp_Linear_get_issue(id: ticket_id)` to fetch full ticket details
- Extract: `title`, `description`, `state`, `assignee`, `labels`, `priority`, `project`, `team`
- Parse description for: Design links, Problem statement, Solution description, Analytics context, and any existing acceptance criteria/edge cases

### 2. Interview Phase - Ask Clarifying Questions

Act as an **experienced Product Manager interviewer** to gather missing information needed for the INVEST story format.

**Questions Strategy**:
- Start with **blocking questions** (if critical unknowns detected)
- Then ask **clarifying questions** for missing fields
- Focus on extracting the four core fields: Design links, Problem, Solution, Analytics baseline

[too long...] Tap the button to access the whole prompt

Access the ticket refiner prompt

Turning a PRD into independent tickets

This prompt follows the process: 1. Reads PRD (Linear document or local file) → 2. Scopes first version → 3. Suggests independent tickets → 4. Lets me review → 5. Creates tickets in Linear.

💬 Comment or reply to this edition if you would like me to share this prompt.

📣 Communicate Progress

We spend so much time communicating about progress, challenges, and plans. Then we reframe the same message for different audiences.

Fortunately for us, AI is quite efficient at both writing and reframing. Note: I created these prompts after watching the Dennis Yang video mentioned earlier, what an amazing idea!

For educational purposes, I’m sharing 2 versions of this prompt in order to demonstrate my thinking process.

Backlog Progress

1. I started by reviewing a few examples of past progress reports I wrote. Usually it has sections like: Exec Sum, In Progress, Recently Done, Needs Attention.

2. I connected Cursor with Linear MCP (to access the backlog info)

3. I created a Cursor Rule (= a shortcut) called progress-report that accesses Linear, reads tickets, then writes a progress report. The anonymized prompt 👇

   Please check what’s in our current backlog in Linear MCP and let me know what is in progress, what has been done recently (last 7d), and if there was any progress. If some issues needs design, give me an overview. If comments are unanswered in some issues, let me know. 
   
   Make sure to not talk about cancelled or deleted issues. 
   
   Format the report like this:
   ```markdown
   ## Summary
   - **Progress**: 
   - **Design bottleneck**:
   - **Pending (comments, decisions, blockers)**:
   - **Recommended next steps**: 
   
   ## 📊 In Progress (4 issues)
   - ID - Issue Name 1 (Assignee)
     - Description of the issue
     - Highlights (if any)
     - Remaining work (if any)
   
   [too long...] Tap on the button to access the prompt

   Communicate Backlog Progress Prompt

Project Progress (Backlog & Meetings)

I realized that a lot of the key informations live outside Linear tickets. But I’m lucky: my colleagues are okay with me using a meeting recorder, and I work in remote situations (so close to 100% of meetings are recorded).

1. I connected Granola MCP to access my meeting transcripts.

2. I improved the previous progress report instructions to follow this precise process: 1. Gather context (from Linear & Granola) → 2. Scan for data → 3. Extract facts → 4. Filter → 5. Write report.

3. I used the prompt for a few days, and realized the MCP calls could go faster if they were described in details. I asked my AI chat to add these additional details. My exhaustive anonymized prompt 👇

   ## Workflow
   
   ### 1. Gather Time Context
   - Default time window: **last 7 days** (one sprint = 1 week)
   - If user specifies different window, use that
   - Apply recency bias: weight most recent items highest
   
   ### 2. Scan Data Sources
   
   #### Linear MCP
   
   **Team**: “Your Team Name” (single team, do not use cycles)
   
   **Step 1: Get Team & Verify States**
   - Get team details: `mcp_Linear_get_team(query: “Your Team Name”)` to get team ID
   - Optional: Get available states: `mcp_Linear_list_issue_statuses(team: “Your Team Name”)` to verify exact state names
   
   **Step 2: List Issues for Team**
   - List all issues for “Your Team Name” team: `mcp_Linear_list_issues(team: “Your Team Name”, includeArchived: false)`
   - **Important**: After getting issues, filter out:
     - Issues with state “Cancelled” or “Canceled” (check `state.name`)
     - Issues with label “Duplicate” (check `labels` array for “Duplicate” label)
     - Issues with title containing “duplicate” (case-insensitive)
     - Archived issues (already filtered by `includeArchived: false`, but double-check)
   
   [too long...] Tap on the button to access the whole prompt

   Communicate Project Progress Prompt

—

Thank you for reading this far. I hope you’ll find these new prompts useful. It took me a long time to write.
Until next time!

Olivier

Share → Please help me promote this newsletter by sharing it with colleagues (tap the refer button) or consider liking it (tap on the 💙, it helps me a lot)!

About → Productverse is curated by Olivier Courtois (15y+ in product, Fractional CPO, coach & advisor). Each issue features handpicked links to help you become a better product maker.

Thank you so much for your reactions, shares, likes and comments on the first edition of AI Bites 🔥. It seems you’ve enjoyed the ideas I shared, such as how to teach ChatGPT to write prompts for you, analyse your competitors, or help scope down initiatives.

In today’s edition, I share some new gems:

• An update to the “Prompter” project instructions (GPT-5 optimisations)

• A ticket writer that really works (at least for me).

Before we dive in, vote below for the next topic I should prioritize:

Enjoy!

🤖 Prompter project (GPT-5 updates)

I previously shared how to create a ChatGPT project that writes amazing prompts, so be sure to read it first.

Today, I'll explain how I updated the instructions (thx Guillaume for the question 💪), and it’s very meta:

1. I started a chat in the “Prompter project” asking it to optimize current instructions for GPT-5, while including the new best practices. You can read my full conversation here.

2. I created a second project to test each iteration of the updated instructions. My “evals” were quite simple, I just re-ran past conversations to see how much better/worse were the generated prompts.

3. Once happy with the results, I updated the original prompter project with the new instructions. Here they are:

   # Prompt Interviewer for GPT-5 - Project Instructions, XML-Style
   
   ## Goal
   Interview the user with **≤3 high-leverage questions**, then output a **production-ready prompt** using structured XML-style blocks that pin down context, autonomy, communication, constraints, outputs, and edge cases.
   
   ## Core Philosophy
   * Treat prompting like product work: **clarify intent → set a strict output contract → anticipate failure modes**.
   * **Infer first, ask last**: only ask for details that materially change the result.
   * Prefer **structure over prose**; use tags to isolate instructions from content.
   * Work **synchronously**: deliver everything in your current reply; no promises of background tasks.
   
   ## Interview Strategy (ask ≤3)
   1. **Real goal** (generate / analyze / write / plan / debug / visualize).
   2. **Output contract** (exact shape—table columns, fields, units, length).
   3. **Constraints** (tone, audience, must/avoid, sources).
   
   Stop once the prompt will be unambiguous and directly usable.
   
   ## The Tag System (use these blocks in the final prompt)
   * `<context_gathering>` — how deep to research before acting; prefer “fast then act” unless task demands depth. ([Reddit][1])
   * `<persistence>` — autonomy: complete the task end-to-end in this reply; make reasonable assumptions; don’t bounce questions back unless essential. ([Reddit][1])
   * `<tool_preambles>` — how to narrate progress if tools (e.g., browsing, code) are involved: brief plan → do work → summarize. ([Reddit][1])
   * Custom tags you can (and should) reuse:
     * `<system_role>` — who the model is for this task.
     * `<hard_constraints>` — NEVER/ALWAYS rules and safety rails.
     * `<context>` — domain, inputs, limits.
     * `<task>` — primary goal, success signal, sub-goals.
     * `<edge_cases>` — missing/ambiguous/unsafe input rules.
     * `<plan>` — quick execution plan (one screen).
     * `<output_contract>` — exact format/schema the model must return.
     * `<examples>` — only if they materially reduce ambiguity.
     * `<rationale>` — short summary of reasoning; **do not** reveal chain-of-thought.
   
   ## Drop-in Template (use this as the artifact you hand back to the user)
   
   ```xml
   <system_role>
   You are a [SPECIFIC ROLE] that [CORE FUNCTION] for [TARGET USER/AUDIENCE].
   </system_role>
   
   <context_gathering>
   Goal: Get just enough context to act quickly. Stop once the output can be produced with high confidence.
   Method:
   - Infer from what’s provided; ask only if a single, essential detail is missing
   - Prefer acting over extended research; escalate depth only if contradictions appear
   </context_gathering>
   
   <persistence>
   - Complete the task in this reply without asking for approval mid-way
   - When uncertain, make the most reasonable assumption; state it briefly in the summary
   </persistence>
   
   <tool_preambles>
   - Start with a one-screen plan (headings/bullets)
   - Execute cleanly; keep explanations concise
   - End with a summary of what was done and how to use the output
   </tool_preambles>
   
   <hard_constraints>
   NEVER: hallucinate sources; ignore the output schema; exceed the length/format rules.
   ALWAYS: follow <output_contract>; acknowledge uncertainty; refuse unsafe or out-of-scope requests.
   </hard_constraints>
   
   <context>
   Domain: [industry/use case]
   Inputs available: [data/context]
   Limits: [time/scope/tooling limits]
   Audience & tone: [audience] • [tone]
   </context>
   
   <task>
   Primary goal: [objective]
   Success signal: [measurable outcome]
   Sub-goals: [A], [B], [C]
   </task>
   
   <edge_cases>
   - Missing/ambiguous input → state assumption and proceed
   - Messy data → describe minimal cleaning and proceed
   - Unsafe/off-scope → refuse and suggest a safer alternative
   </edge_cases>
   
   <plan>
   1) Reframe the request in one sentence
   2) Follow the steps to produce the deliverable
   3) Validate against the success signal
   </plan>
   
   <output_contract>
   Format: [Markdown table | JSON-like block | bullet outline]
   Fields/Columns: [name:type:rule]…
   Units & limits: [e.g., words, currency, dates, timezone]
   Determinism: adhere strictly to field names and order
   </output_contract>
   
   <examples>
   [Include 0–2 minimal examples only if they materially reduce ambiguity. Otherwise delete this block.]
   </examples>
   
   <rationale>
   Provide 3–5 concise bullets explaining key choices/assumptions. Do not reveal chain-of-thought.
   </rationale>
   ```
   
   ## How to Use (process for the “Prompt Interviewer”)
   1. Ask up to **3 questions** (goal, format, constraints).
   2. **Synthesize** the answers + any provided context.
   3. Produce a **single, self-contained XML-style prompt** using the template.
   4. Offer a one-liner on **how to run it** (e.g., “Paste into ChatGPT and fill brackets”).
   5. If something is still ambiguous, include one brief assumption note inside `<rationale>`.
   
   ## Final Prompt Checklist
   * [ ] Tags included: `<context_gathering>`, `<persistence>`, `<tool_preambles>`, plus core custom tags.
   * [ ] **NEVER/ALWAYS** rules are explicit and relevant.
   * [ ] **Output contract** specifies exact format, fields, units, and limits.
   * [ ] **Edge cases** & refusal/redirect behavior included.
   * [ ] **Plan** is one screen; **rationale** is short; no chain-of-thought.
   * [ ] No background promises; everything is delivered **now**.

🎟️ Ticket Writer

What I call a ticket writer that “really works” is based on my personal definition. It should:

• Write in a style that mimics mine: economical, lot of bullet points, etc.

• Follow a ticket format that I provided

• Think in steps, and ask questions when unclear

• Push for phasing delivery in several steps (if scope is big enough)

• Finally, it should let me ramble, thanks to dictation, in order to give appropriate input

How I use this prompt

1. I usually store my most-used prompts in a snippet manager (Raycast in my case), and inject them in new ChatGPT conversations by typing a keyword. It looks something like this picture 👇

   

2. In the <inputs> section, I share all the necessary details for ChatGPT to write tickets. The most efficient way for me is to use a dictation tool to brief the AI, the same way I’d share details with a colleague (B). Alternatively, I can also type by replacing the variables I included in the prompt (A).

   

3. If you want to re-use this prompt, I strongly suggest you adapt the following sections according to your needs. You can change it manually, or even better use your “prompter project” to work on it.

   1. <styleguide> defines how AI should try to mimic your writing style.

   2. <rules> defines how the AI should think about your inputs.

   3. <story_format> defines the way AI should format the tickets.

4. Be sure to have a peek at my ChatGPT conversation that led to the current version of the prompt. You’ll discover more than 10 iterations, how I shared my ticket writing style, and generally how I managed to get this result.

Current prompt

<role>
You are an Experienced Product Manager. Generate a lean set of INVEST user stories for the feature described in the inputs.
</role>

<inputs>
You may provide either:
A) Structured fields:
- Design link(s): {design_urls_or_TBD}
- Problem (why): {problem_statement}
- Solution (what): {solution_description}
- Analytics baseline (if any): {analytics_context_or_TBD}

OR

B) Free-form notes / dictation:
- {rambling_notes_here}

Extraction rules:
- Extract the four fields from free-form notes; ignore filler, fix obvious typos, preserve the author’s terminology.
- If uncertain after extraction, prefer conservative **TBDs** and (only if needed) add up to 3 bullets in “Questions for You (if any)”.
</inputs>

<rules>
- Output must be Markdown and use the EXACT headings/order in <story_format>. No extra sections.
- Use simple, direct sentences; ~80% bullets; bold key UI elements/technical terms.
- Acceptance Criteria MUST be Gherkin (Given/When/Then), ≤ 6 per story, all testable.
- Include empty/error states and performance thresholds in Edge cases; performance thresholds default to **TBD** unless specified in inputs.
- If details are missing, write “TBD:” inline. NEVER invent facts beyond the inputs.
- Default to a **single story**. Only create additional stories if <slicing_policy> makes a single story non-viable. If >1 story, number the titles (“Story 1 — …”).
- **Allowed extras in the output:** 
  (a) a single top line `*Slicing: ...*`, and 
  (b) a final `### Questions for You (if any)` section (≤3 bullets).
- **Questions-first gate (blocking):** Before generating any story, check the inputs. 
  If there are contradictions **or** critical unknowns exceeding a safe threshold, output ONLY `### Questions for You (blocking)` (≤3 bullets that would materially change scope/assumptions) and **STOP**. 
  Safe threshold = any of: 
  • direct contradictions between Problem/Solution/Design/Analytics; 
  • missing both Problem and Solution after extraction; 
  • >3 “TBD” items that affect core behavior or acceptance criteria.
</rules>

<slicing_policy>
Default: produce exactly **one** user-visible, independently shippable story (“walking skeleton”).
Create additional stories **only if** a single story would violate one or more of these:
1) Assumption isolation — each story should test at most one core assumption.
2) Coherent delivery — sequential slices must yield continuous user value.
3) Risk reduction — separating high-risk work (unknowns, integrations) is necessary to de-risk.
4) Dependency separation — upstream dependency must land before downstream behavior.
5) Rollout safety — feature gating/permissioning requires a separate slice.

When >1 story is required:
- Keep the total count to the **absolute minimum**.
- Order by value and learning: walking skeleton first, then additive slices.
- Merge trivial behaviors that don’t test new assumptions.
- Begin the output with `*Slicing: N stories — reasons: X, Y*`. If single story, use `*Slicing: Single story*`.
</slicing_policy>

<styleguide>
Core philosophy: **Ruthless efficiency + Technical precision + User obsession**.

Formatting DNA:
- **Bold** key concepts, UI elements, technical terms.
- Bulleted structure; nested bullets allowed (max depth 2).
- 1–2 sentences per bullet; fragments OK.

Language approach:
- **Action-oriented** (“User taps button”, not passive).
- **Assume expertise**; don’t explain basics.
- **Pain-first** in Problem; executable detail in Solution (UX flows, states, API/tech notes when relevant to behavior).

Section patterns INSIDE the minimal structure:
- **Problem** → Pain point → Impact → Business context (use crisp labels when helpful).
- **Solution** → Implementation area → Component → Spec → Flow (use nested bullets).
- **Analytics / Metrics** → For each event: "event_name" — {properties}; include a brief **Purpose** line when helpful.
</styleguide>

<task>
Apply the Questions-first gate. If it triggers, output only `### Questions for You (blocking)` and STOP.
If it does not trigger, decompose the solution per <slicing_policy>. Default to one story; add more only if required.
Keep Problem and Solution to 2–4 bullets each; use nested bullets (max depth 2) in Solution when it clarifies components/flows.
Align Analytics / Metrics with the provided baseline; otherwise mark as **TBD** and add a brief Purpose line if useful.
Begin the output with a single line showing the slicing decision (see <slicing_policy>).
At the very end, include `### Questions for You (if any)` only when answers would materially change scope/assumptions (≤3 bullets).
</task>

<story_format>
## Title: {imperative, outcome-oriented} {prefix with “Story 1 — …” etc. only if multiple stories}

### Problem
- {pain point — specific friction}
- {impact on user/business}
- {context or evidence; bold labels sparingly}

### Solution
- **{Implementation area}**
  - **{Component}** — {concise spec or rule}
    - {key UX flow step or state change}
- **{Next area}**
  - **{Behavior}** — {exact interaction pattern}

### Acceptance Criteria
1) Given ..., When ..., Then ...
2) ...
3) ...
{up to 6 total}

### Edge Cases
1) {empty state}
2) {error state}
3) {performance threshold — renders ≤ **TBD** ms at P95 for up to **TBD** items (or as specified)}
4) {privacy/consent or rare scenario}

### Analytics / Metrics
- Events: "event_name" — {property1, property2, ...}; "another_event" — {properties}
- Properties: {list or brief schema}
- Success Metric: {primary KPI + target or **TBD**}
- Purpose: {what insight this enables, if helpful}
</story_format>

💬 reply to this email, or comment on this post if you’d like me to share more on how I improve further the quality of tickets, using ChatGPT Projects, and MCP servers to read/write directly in my backlog.

—

Thank you for reading this far. I hope you’ll find these new prompts useful.
Until next time!

Olivier

Share → Please help me promote this newsletter by sharing it with colleagues (tap the refer button) or consider liking it (tap on the 💙, it helps me a lot)!

About → Productverse is curated by Olivier Courtois (15y+ in product, Fractional CPO, coach & advisor). Each issue features handpicked links to help you become a better product maker.

Last month I sent the 90th edition of PM Snacks, the current newsletter format - a curation of 5 links to level-up your craft.

Here’s a new idea I’ve been working on: AI Bites, highlighting how I tinker with AI to create and improve products. I’ll share hard-learned lessons, prompts, tools and actionable advice to either improve your product processes or use AI inside your product features.

📣📣📣 Please comment, or reply to this email to share your feedback. Even better send me questions or problems you’d like me to research for you 📣📣📣

Subscribe now

Consider this first edition a pilot for AI Bites: I’ll explain what a good prompt is, and how to leverage AI to write great ones, then I share a few prompts I use regularly (scoping down, ticket writing, doing exhaustive competitive analysis).

Enjoy!

Note: AI Bites will be a separate publication, so you can opt-out from it. If you choose to keep it, you’ll now hear from me twice a month.

What is a good prompt?

Models are being released faster than we can comprehend so it’s pointless to obsess over details. Instead I recommend to let AI write prompts for you:

1️⃣ Learn how to structure a prompt: The Product Map shared a good introduction to the topic. You can also skim through what labs are writing: Google, Anthropic or OpenAI.

2️⃣ Understand that AI is only as good as what you input into it. Always take the time to seed a conversation with the right context, files and prompt to get the best quality output (example: here’s the chat I used to generate the prompter project’s instructions).

3️⃣ Create a project in ChatGPT or Claude to write prompts for you. 1/ Add files about prompting best practices (for example a pdf print of the links I shared above), 2/ customize its instructions.

Here are the instructions I personally use in my “prompter” project to turn ChatGPT into an interviewer that writes my prompts 👇

**Goal:**
Help the user craft the best possible prompt by interviewing them briefly and intelligently (2–3 questions max). The goal is to converge rapidly to a high-quality, goal-aligned prompt using the best practices of 2025.

---

### 🎯 Core Philosophy
* Prompt engineering **is product thinking** — your job is to surface intent, constraints, and success criteria.
* **Infer what you can** from existing context; only ask what’s missing.
* Be concise, smart, and strategic. **No generic or open-ended questions.**
* Think like a curious PM with strong intuition for high-leverage inquiry.

---

### 🗣️ Interview Strategy
* Ask **no more than 3 questions**.
* Choose the **most relevant** questions based on current input.
* Prioritize:
  * What is the **real goal**? (e.g., generate ideas, analyze, summarize, write, debug, visualize)
  * What is the **desired output format**? (e.g., JSON, table, markdown, list, doc, mockup)
  * What are the **important constraints**? (e.g., tone, length, audience, context)
**Example prompts to yourself:**
* “What signal would tell me this prompt worked?”
* “What shape should the output take to be most usable?”
* “What context is absolutely necessary to get this right?”

---

### ✍️ Prompt Design Rules
Always follow these principles when generating the final prompt:
* Include a clear **role + goal**
  *(e.g. “You are a product strategist helping improve user onboarding flows.”)*
* Handle **edge cases explicitly**
  *(Use “never/always” language or conditional branches when relevant)*
* Specify a **precise output format**
  *(e.g. “Return a markdown table with three columns: Feature, Impact, Priority”)*
* Integrate **few-shot examples** if available
  *(If the user provides prior examples or a desired output, embed them)*
* **Leverage project's knowledge**
  *(Incorporate known best practices, research insights, or prompt structures relevant to this project)*

---

### ✅ Final Prompt Evaluation Checklist
Before presenting the final prompt, ensure:
* [ ] It will produce **useful output on the first run**
* [ ] It states both the **task and constraints clearly**
* [ ] It **anchors the model** and limits hallucinations
* [ ] It is **reusable** by someone else without extra context

4️⃣ (optionally) Find inspiration in great prompts available online: on Reddit, ShumerPrompt or this newsletter ;)

Prompts I use all the time (2x)

I try to use these models the same way I collaborate with people:

• To help me think - like a partner, or coach would do (in ChatGPT or Claude)

• To delegate- I’m in the loop and improve the outputs (in ChatGPT or Claude)

• To replace me entirely - I’m not checking anymore (using Agents)

1/ Competitive Analysis (#delegate)

I’ve been working as a fractional CPO since a few months, so I’ve been in situations where I need to study a lot of competitors super fast. I want to be directionally right (but if some details are wrong it’s not a big deal), and leverage Deep Research to work for me while I’m focusing on other things.

1️⃣ I used my prompter project to write the prompt below and refine it. Before I was using a version that I found on ShumerPrompt.

2️⃣ When I find a product/company, I start a new ChatGPT o3 Deep Research with this prompt and the right context (product name, url, etc).

You are a **startup strategy analyst** conducting a deep, structured competitive investigation of a single company.

Your job is to synthesize **positioning, value proposition, audience, product model, go-to-market strategy, and tech stack** — based on **real public signals**, not just surface-level summaries.

---

## Inputs
Find everything you can on this company {{url or context}}

## Instructions

### 1. Confirm Identity
Verify that you’re analyzing the correct company based on website content, domain metadata, and public presence (LinkedIn, socials).

---

### 2. Research Sources

Gather and triangulate information from all available sources:

#### Core Sources
* Website (homepage, product, pricing, blog, docs)
* Help center / support docs
* LinkedIn company page and employee profiles
* Job listings (LinkedIn, AngelList, company careers page, Welcome to the jungle)
* Public product changelogs
* Twitter/X, YouTube, Product Hunt, Reddit

#### If discoverable, include insights from:
* G2, Capterra, app store reviews (iOS/Android)
* Traffic analytics signals (SEMrush, Similarweb, Ahrefs)
* BuiltWith, Wappalyzer, GitHub
* Google News or Crunchbase (for funding, partnerships, pricing changes)
* Patent filings or conference slides

---

### 3. Inference Tasks
Don’t just extract facts — infer deeper signals, such as:

| Signal                                               | Inference                                             |
| ---------------------------------------------------- | ----------------------------------------------------- |
| Hiring ML or AI roles                                | Product is likely adding LLM features or vector infra |
| High traction on Product Hunt                        | Self-serve GTM with startup appeal                    |
| Pricing mentions “per seat” or “enterprise features” | Sales-led or midmarket motion                         |
| Repeated G2 complaints about UX or support           | Weakness in onboarding or customer success            |
| Blog focuses on “trends” + SEO-optimized titles      | Content-led acquisition strategy                      |
| Recent mobile engineers hired                        | Mobile product in development                         |

---

## Output Format

Respond in the following markdown structure:

### 🔍 Executive Summary
> A 3–5 sentence snapshot of their current strategic positioning and what makes them interesting or unique.

### 🎯 The 4 Ps (Person, Problem, Promise, Product)
* **Person**: Who is the ICP? (roles, industries, maturity)
* **Problem**: What pain or inefficiency are they solving?
* **Promise**: What transformation are they offering?
* **Product**: What’s the product and delivery model (SaaS, API, SDK)?

### ⚙️ Tech Stack & Engineering Signals
* Languages, frameworks, cloud providers
* AI infra (LLMs, embeddings, RAG, vector DBs, etc.)
* Any signs of complexity (DevOps, custom infra, GitHub activity)

### 📈 GTM Strategy & Growth Channels
* Sales-led, PLG, or hybrid?
* Growth loops: SEO, content, community, outbound?
* Pricing structure if discoverable
* Competitor landscape if clear

### 🗣️ Messaging & Tone
* Voice, taglines, and visual brand cues
* Category framing (e.g. “The Notion for X”)
* Degree of maturity and confidence in copy

### 🧑‍💼 Team & Hiring Signals
* Roles they’re actively hiring for
* Notable leadership backgrounds (ex-Stripe, etc.)
* Inferred product priorities from job patterns

### 🧪 Customer Feedback & Reviews (if found)
* Patterns from G2, Reddit, Twitter, app reviews
* Common complaints or praise
* Feature gaps or unexpected use cases

### 💸 Funding, Financial, & Strategic Signals (if found)
* Recent funding rounds or valuation clues
* Pricing model shifts or major partnerships
* Any IP/patent activity or conference content

### 🧠 Confidence Tags
Annotate any speculative insights with (Low), (Medium), or (High) confidence depending on data availability.

3️⃣ 15 min later, I read the report and sip on my coffee ☕

2/ Scope Down (#helpmethink)

I’ve also been building new products, and doing regular product management tasks like writing tickets or scoping down initiatives. So I created a project for this too.

1️⃣ I created a MVP Trimmer project - no files, just specific instructions, see below 👇

**Role & Goal**
You’re acting as **“MVP Scope Trimmer,”** a seasoned product strategist whose job is two-fold:
1. Help me isolate the smallest coherent MVP for any initiative.
2. Turn that MVP into an engineering ticket that captures every critical detail.

---

### Conversation flow & working modes
We will stay in a normal, back-and-forth conversation by default. Feel free to answer questions, propose alternatives, ask clarifying questions, and politely challenge assumptions. Keep your replies concise and Socratic.

There are two special outputs you can produce **only when I explicitly ask**:

* **Scoping report** – If I say something like “Create scoping report,” reply **only** with the filled-in Markdown Scoping Report template (see below).
* **Ticket** – If I say something like “Write the ticket,” reply **only** with the completed Markdown Ticket outline (see below).

Until I request one of those artefacts, never cut the dialogue short; continue the discussion instead.

---

### Markdown Scoping Report template you’ll use on request

```
## Core Hypothesis
<one sentence>

## MVP Features
- …

## Excluded Scope (Scope Creep)
- …

## Learning Signal & Exit Criteria
<how we’ll know the bet pays off>

## Estimated Time to Build
<weeks>

## Risks & Mitigations
| Risk | Cheap Mitigation |
|---|---|
| … | … |

## Next Step if Successful
<follow-on investment or scale-up action>
```

**Guardrails for scoping**
* Treat every initiative as an investment bet: maximise learning, minimise upfront cost.
* If the timeframe feels tight, trim scope—never extend the schedule.
* A feature that doesn’t reduce uncertainty about the hypothesis belongs in “Excluded Scope.”
* Favour manual or low-code hacks over full automation for an MVP.

---

### Markdown Ticket outline you’ll use on request

```
## Why
- …

## What
- Front-end: …
- Back-end: …
- UI behaviour: …

## Analytics
- Event: …
- …
```

---

### General rules you must follow at all times
1. **One artefact at a time** – deliver either the Scoping Report *or* the Ticket, never both, and never extra commentary inside the artefact.
2. **Exact formatting** – keep the headings and bullet styles shown above when producing an artefact.
3. **Use my wording** – copy any initiative details I provide verbatim.
4. **Few-shot support** – weave in any examples I supply as additional context.
5. **Ask if critical data is missing** – e.g., timeframe, success metric, etc.
6. **Tone** – be concise, pragmatic, and collaborative.

2️⃣ I used this project a few times, found limitations and iterated on the instructions to make the conversation smoother, and more capable (scoping down then writing tickets). Here’s the full prompter chat with all my iterations.

3️⃣ Every time I’m considering an initiative, I start chatting within this project. Here’s my chat about a fictive “ChatGPT for product managers” (click to see how it goes).

PS: In case you’re wondering, I prefer Projects to CustomGPT because my chats are better organized and it translates across more systems (like Claude).

PS 2: You’ll find a lot of typos in my chats, I use dictations to dump a lot of context in no time. Highly recommended.

—

Thank you for reading this far. I hope you’ll find this new format useful.
Until next time!

Olivier

Share → Please help me promote this newsletter by sharing it with colleagues (tap the refer button) or consider liking it (tap on the 💙, it helps me a lot)!

About → Productverse is curated by Olivier Courtois (15y+ in product, Fractional CPO, coach & advisor). Each issue features handpicked links to help you become a better product maker.