Product Gym FAQs | How Do You Come Up with PRD (Product Requirements Document)?

Due to the vast differences between one Product Manager to another, the answers may come in varying responses. One such question would be: “How do you come up with PRD (Product Requirements Document)?”

Many people ask Product Managers a variety of questions pertaining to their role in the business and technological world. Due to the vast differences between one Product Manager to another, the answers may come in varying responses. One such question would be: “How do you come up with PRD (Product Requirements Document)?”

Here at Product Gym, we had a few of our instructors and coaches answer the question.

 

Product Manager A

I like to follow an iterative 5 stage research and definition process with PRD in the middle.

  1. Initially, I meet with business stakeholders to identify the problem they’re seeking to solve. We’ll then detail the data driving us to believe that there is a market for the solution. We’ll then take validated ideas to stakeholders across the business to assess the strategic and revenue value of the solution, and capture any hard requirements the solution must meet.
  2. Next, if the solution will require users to interact with software, I initiate user interviews in order to identify the user personas involved, and develop navigation and other interface requirements that go immediately into design execution.
  3. With the business and UX constraints established, we document the Product requirements: I write out an overview of the solution, followed by a detailed list of Job Stories that are then translated directly to JIRA tickets with Interface mockups and prototypes as needed. A strategy for measuring usage, and key performance metrics are defined at this point and ticketed out as well.
  4. With the Product requirements fleshed out and the validated solution being designed, JIRA tickets are reviewed by the Engineering team for technical details such as data models and architectural constraints and documented along with any Testing requirements from the QA team.
  5. Finally, we develop Go-to-Market requirements that make sure the solution is offered to the correct user personas with the right amount of educational material to drive adoption and gather feedback.

 

Product Manager B

  1. Define the purpose of the product. Stakeholders should also agree on its purpose.
    • What problems does this product solve?
    • Who will use this product?
    • Why is it important?
  2. Break the purpose down into features.
    • Define feature requirements into themes and initiatives.
  3. Set the goals for the release criteria.
    • Functionality
    • Usability
    • Reliability
    • Supportability
  4. Determine the timeline.
  5. Have stakeholders review it.
  •  

Share this post

Share on facebook
Share on google
Share on twitter
Share on linkedin
Share on pinterest
Share on print
Share on email