Validation, confirmation, and skipping the thinking
If you think a PRD should be replaced with a prototype, you probably don’t understand what either is for.
That was the opening line of a LinkedIn post I shared this week — and it hit a nerve. Not because prototypes are bad (they’re not), or because PRDs are great (they’re also not.)
Prototypes help confirm that a solution works for the problem you believe exists. But they don’t tell you whether that problem is real, meaningful, or worth solving. That work happens earlier, through validation.
Somewhere along the way, the practice of writing things down became unfashionable. Apparently, now we can skip it all and go straight into AI and built whatever solution we desire.
By no means am I suggesting we need to go back to 20-page documents that nobody reads. But teams still need a way to align. Something that captures what has been validated, what’s still uncertain, what assumptions are in play, and how those will be tested. Call it a PRD, a brief, a discovery doc, or a product problem outline. The format doesn’t matter. What matters is that the thinking has happened, and it’s visible to the team.
This week I wrote about the difference between validation and confirmation, and why the sequence matters. When you mix them up, it becomes very easy to build things that look right but don’t solve anything, but because too often, teams skip the product thinking and jump straight into design.
👉 Read it here
Hope it helps sharpen your thinking! And if anybody tells you otherwise, they know nothing.
