How to automate PRD generation without getting bogged down in the process
8 min readOct 27, 2025
–
Press enter or click to view image in full size
Photo by Patrick Perkins on Unsplash
I work on a team with seven other engineers, and we don’t really have a full-time product team. We haven’t always had a Product Requirements Document (PRD) as a starting point for projects we take on. When we did have them, they varied wildly in detail and structure. Sometimes it was a paragraph in Slack. Sometimes it was a comprehensive document. Usually it was somewhere in between, and always different.
We tend to be pretty engineering-led, which I li…
How to automate PRD generation without getting bogged down in the process
8 min readOct 27, 2025
–
Press enter or click to view image in full size
Photo by Patrick Perkins on Unsplash
I work on a team with seven other engineers, and we don’t really have a full-time product team. We haven’t always had a Product Requirements Document (PRD) as a starting point for projects we take on. When we did have them, they varied wildly in detail and structure. Sometimes it was a paragraph in Slack. Sometimes it was a comprehensive document. Usually it was somewhere in between, and always different.
We tend to be pretty engineering-led, which I like. But I’ve found this to be a challenge, especially with larger features. We have to assume the engineer will know, or will learn, all the workflows and what features will be needed. They might go interact with some users, or maybe not.
We also tend to not have a lot of red tape or formal processes. Our culture is often to just give engineers a quick prototype from Replit or something and let them go to town and figure it out. The culture kind of frowns on extensive research, planning, writing things down. It’s get-it-done and focused on getting something built that will impress and motivate customers as quickly as possible.
Generally we have a high tolerance for fail-fast-and-break-things. But I happen to focus…