Sponsored by
What 2,000 SaaS Companies Reveal About Growth in 2026
Is your growth in-line with your peers in B2B SaaS & AI?
Benchmark yourself against actual billings data for Maxio’s 2000+ global customers, alongside firsthand company perspectives to understand how growth varied by company size, business model, and strategic focus.
Key takeaways from the report:
Average growth across 2,000 companies
Growth by revenue band
AI-led vs AI-enhanced. Who performed better?
👋 Hey friends,
Most PMs write PRDs for their team.
I've been thinking about that differently lately.
What if your PRD wasn't written for your engineers? What if it was written for Claude?
That's the shift I made this week. And the output I got was completely different from anything I've built before.
Here's the workflow.
The old way vs. the new way
Most AI-assisted prototyping looks like this: you describe an idea in a chat window, something gets generated, it's kind of close, you iterate in circles for an hour, and you end up with something that looks like what you wanted but doesn't quite behave like it.
The problem isn't the tool. It's the input.
A vague prompt gets a vague prototype. But a well-structured PRD? That's a precise set of instructions. It has user context, problem framing, success criteria, edge cases, and constraints already baked in.
When I started treating my PRD as the primary input for my Claude Project rather than an afterthought, the quality of what came out jumped significantly.
💡 Insight: Your PRD is already doing half the work of a prototype brief. Most PMs just never connect the two. The shift isn't learning a new tool. It's pointing the tools you already know at the documents you already write.
The two-track prototyping workflow
Here's the specific workflow I landed on this week. It uses the same PRD as a starting point but splits into two tracks depending on what you're trying to learn.
Track 1: The technical prototype
If there's already a public project on GitHub that's close to what you're building, you don't have to start from scratch.
Fork it. Claude Code or Claude CLI can do this for you. Then feed your PRD directly into the session and tell it to optimize the fork toward your specific problem, your users, and your constraints.
What you get is a working technical prototype shaped around your actual requirements, not a generic template. And because you started from something that already exists, you skip the scaffolding entirely.
🕰 When to use this: when you're testing whether something is technically feasible, or when you want to show engineering a proof of concept before writing a full spec.
Track 2: The design prototype
Take the same PRD. Strip out the technical requirements. Keep the user context, the jobs to be done, the key flows, and the success metrics. This becomes your FE-focused PRD.
Plug that into Lovable.
Because Lovable is optimized for frontend output, giving it a design-focused brief gets you a much cleaner UI to react to. You're not fighting the tool to ignore backend constraints it can't handle anyway.
🕰 When to use this: when you're testing whether something is usable, or when you need something a stakeholder can actually click through.
Learn AI in 5 minutes a day
You don't have to scroll every AI thread, track every new tool, or watch every demo.
The Rundown AI breaks it all down for you — the latest AI news, tools, and tutorials in one free 5-minute email every morning.
Trusted by 2M+ professionals at Apple, Google, and NASA.
Why two tracks?
Because a technical prototype and a design prototype answer different questions.
The technical prototype tells you if it's buildable. The design prototype tells you if it's right. You need both. And the same PRD can generate both if you write it with that intention from the start.
🎯 Try this: Take a PRD you already have (or a spec you're working on right now). Split it into two versions: one that keeps all the technical context, one that strips it back to user needs and flows only. Feed each version into the right tool. Claude Code or Claude CLI for the technical fork. Lovable for the FE version. See what you get.
Bottom line
Everyone is telling PMs to use AI to write PRDs faster.
That's fine. But it's the wrong direction.
The real unlock is using your PRD to make AI build better.
Your PRD already has everything a prototype needs. Stop treating it as documentation. Start treating it as instructions.
See you next week,
- Stef
P.S. I'm building a structured program for early-career PMs called the PM Launchpad. If that sounds like you, join the waitlist below. In the meantime, if you want to talk through where you're at right now, I still have free 30-minute slots on ADPList.
Every Friday, I do the job hunting work for you.
Fresh PM roles every Friday. Remote-friendly flagged. Direct apply links. No searching required. $7/month, cancel anytime.
I'm in, unlock full access