- Writing a PRD is central to develop a good product, therefore use a lot of effort
- Fewer features lead to more use of the important ones, which then seems more powerful to customers
- Customer is usually much less tolerant to complexity. Don’t think that you are your customer!
Product Requirement Proposal:
- Describes the Product the company will build, drives effort of entire team/company
- Needs to clearly and unambiguously articulate the product’s purpose, features, functionality and behavior
- Is not a market requirement or a roadmap or a vision
- Do your homework
- Define the product’s purpose (Value Proposition). Are you able to explain in an elevator pitch (30s)?
- Define user profiles, goals and tasks
- Define product principles
- Prototype and test product concept: feasibility and usability
- Identify and question your assumptions: astronomy was defined as the study of how the sun and planets revolve around the earth
- Write it down: product purpose, features (with use case, requirement and objective), release criteria, schedule
- Prioritize: must-have, high-want, nice-to-have & rank-order
- Test completeness: let an engineer read the PRD
- Managing product, update PRD
- Usability testing too little too late
- You are not your customer!
- What versus how (specify what problem the product should solve, not how it solves the problem)
- Too little/too much detail
- Less is more (Only have as many features as necessary)
- Requirements too much engineering-driven or too much customer-driven
- Emotion can be logical (build a product that creates an emotional response)
- Standard is actually better than better (only change for real innovation, don’t change the way a phone dials)
- Do necessary system work with every release
- Recommendation: include Design in PRD
- How do you write PRDs in your start-up/business?
- What are your best practices in writing a PRD?
- How can you use this knowledge in your job?