Got No Time For PRD
PRDs aren't dead, but they assume you already know the hill you're climbing. Here's a six-line alternative for when you're still exploring which is short enough to hand straight to an AI agent.
🏕️ I’m on holidays this week for a little summer camping, so here’s a little thought for this week while the kettle’s on.
Everyone keeps telling me the PRD is dead but I think they’re just in a hurry.
I have a real soft spot for them. If you hadn’t noticed, I like writing, so I always relish the chance to explore an idea this way. They’re genuinely useful for aligning large teams, in organisations that want to be careful with their bets and sure they’re storming the right hills. They have their place. I still believe that slowing down to get your thoughts in order, then writing them up to test their clarity, is one of the most useful things you can do.
Claire Vo built ChatPRD, and it’s wonderful. A hundred thousand product people use it. It drafts a sharp PRD from a sentence, coaches you like a chief product officer who reads your doc, and it wires straight into Linear and v0. If you are going to write a PRD, it makes sense to write it there.
PRDs mattered even more when software moved slowly, cost a fortune to build, and being wrong cost you months. I’m not going to tell you to throw planning out the window and vibe your way to production.
Here’s the thing that’s really changed though: a PRD assumes you already know the hill you’re planning to climb. You’ve picked the target, and now you’re aligning everyone to storm it together. Exploration is the exact opposite. You don’t know the target yet, you’re trying to find it, running several bets at once with a million ideas in your head. Write the full doc now and you’ve set in stone a decision you haven’t earned yet.
So here’s my little handbrake. Not to stop you, just to slow you down enough to make progress while still going broad. You can chuck at your favourite agent and collaborate together as well.
Intent: the change we want, and who will feel it.
Bet: the riskiest thing we’re assuming is true.
Bar: what good enough means here, and what we’re not building.
Scope: the one thing this build is focused on, and where its edge is.
Loop: the smallest build that tests the bet, the signal that says iterate, pivot or capitulate, and the point where you stop.
You need a guardrail, because brakes are what let you go fast in the first place.
Never: the lines the build must not cross.
As Pedro Bacelar and his team said: you need a kill switch. The Loop keeps you moving, but a loop with could end up just running forever, so give it a timebox. Decide up front how long, or how many turns this bet gets before you choose to iterate, pivot or capitulate.
In its distilled form, it’s a single sentence:
For [who], build the smallest thing that tests [bet]. Good means [bar], and this build only covers [scope]. Keep going while [signal], and stop at [timebox]. Stay inside [guardrail].
That sentence is short enough to hand straight to an Agent. It's not just a brief for you and the team, it's also a brief effective Agentic collaboration. A model can pick up those five lines and run. It works much better than a twelve-page doc, which if we’re honest, most people won’t read.
A modern model can happily swallow a twelve-page doc. The problem is that the long doc freezes you in a decision you haven’t earned yet, and it can bury the sharpest thinking while you’re still exploring. A short, well-crafted instruction gives you and the model the same thing: room to move.
A quick thank you to Pedro Bacelar, who read the first version of this and sharpened it with his product and design teams. The timebox, the positive framing on Scope, and the nudge to write guardrails as a line to stay inside rather than only a line not to cross are all his.
That’s all. Try it on the next thing you build!
Thanks for sharing this learning! It’s a clean mental model for early exploration, and I appreciate the effort to simplify something that’s often overcomplicated (I hate reading/writing long PRDs since they were invented).
I've shared with my product/design teammates and I’d like to share some of our feedback/thoughts:
Probably add a Timebox component (every experiment needs a kill switch) and explicit Pivot criteria beyond just “iterate/pivot/capitulate.”
We also disagree that agents need shorter briefs than humans, modern LLMs can handle long, well-structured docs just fine, the input can be massive as long as the output is brief so humans can review.
Finally, I’d replace your definition of Scope ("what we're explicitly not building yet.") and also the “Never” with positive constraints, since LLMs generally follow affirmative and directive instructions more reliably than negative ones ("do this" vs "do not do this"). Negative ones have proven to be more confusing in my experience, it ends up understanding that as a requirement rather than negative scope depending on the model/effort you're using.
Hope this sparks good discussion, again kudos for sharing :)