4 ms·
Product Requirements Document It is a fairly standardized way of capturing the essens of a new feature. It covers most important aspects of what the feature is
by iagooar 1y ago
Product Requirements Document
It is a fairly standardized way of capturing the essens of a new feature. It covers most important aspects of what the feature is about, the goals, the success criteria, even implementation details where it makes sense.
If there is interest, I can share the outline/template of my PRDs.
- canadiantim 1y agoI'd be very interested
- iagooar 1y agoThere you go: https://gist.github.com/matisojka/aebf75ea33439e540eb0f74026a9d3d8 https://gist.github.com/matisojka/aebf75ea33439e540eb0f74026...
- canadiantim 1y agoWow, very nice. Thank you. That's very well thought out. I'm particularly intrigued by the large bold letters: "Success must be verifiable by the AI / LLM that will be writing the code later, using tools like Codex or Cursor." May I ask, what your testing strategy is like? I think you've encapsulated a good best practices workflow here in a nice condensed way. I'd also be interested to know how you handle documentation but don't want to bombard you with too many questions
- iagooar 1y agoI added that line, because otherwise the LLM would generate goals that are not verifiable in development (e.g. certain pages to render <300ms - this is not something you can test on your local machine). Documentation is a different topic - I have not yet found how to do it correctly. But I am reading about it and might soon test some ideas to co-generate documentation based on the PRD and the actual code. The challenge being, the code normally evolves and drifts away from the original PRD.
- devstein 1y agoI think the only way to keep documentation up-to-date is to have it as part of the PR review process. Knowledge needs to evolve with code. We working on this at https://dosu.dev/ https://dosu.dev/ (open to feedback!)