PRD - Write down and visualize your solution #

While it's not smart to delay too much actual design and building, there is one document that is important to have, and that is the Product Requirement Document (PRD).

A PRD allows founders/teams to think systematically about the product and to address very important questions.

Remember that writing and visualization are just better ways to think through any problem, as we have very limited memory and cognitive skills to keep everything in our heads.

A good PRD should contain the scope, visualizations of the products (e.g. link to figma prototypes), release plans and answers to other key questions. It is the "source of truth" for product, design, engineering and management at large to answer very common questions about the scope of the product being built, release plans and other questions.

This document will increase understanding, alignment and trust across the team. It is also a natural place where people can collaborate, ask questions and challenge the product hypothesis, design etc.

PRDs and thinking about your product in a structured way will prove very useful for AI-assisted workflows as well.

What makes a good PRD #

A good PRD document should describe the product scope, problems that are being solved and demonstrate a clear action plan to deliver a solution.

We believe that this document must contain the following sections:

• Why - Problem to be solved
• Who - Target Audience / Customer Segments
• Competitive analysis, research and differentiation
• Release plans, Scope/Features (epics/stories) for next version and visualization of those features
• Go to market strategy

Optional sections to include could describe non-functional requirements (this can also be a separate TRD document), assumptions/constraints, risks and other sections that you find useful.

To keep the document concise it is best to link to visualizations stored in another document (e.g. wireframes, mockups, prototypes in Figma).

There is a solid probability that the document will get too complex, long and hard to understand, so we believe that these principles should be applied when creating PRD's:

• Keep it simple and short - start from a 2-pager. People will not read 50-page documents
• Visualize as much as possible - text is important, but inferior to visualizations to describe the product being built with sufficient detail
• Update continuously - any document that doesn't get updated continuously is worthless and should be deleted
• Co-create it with the team - the product should be co-created with the team to use collective intelligence and create alignment

Examples #

A great example of a PRD that works is the famous PRD that was used to build ProductHunt (https://www.producthunt.com/)

Link to the full example from ProductHunt here.

How to get started #

You can use this template to get started, and follow the steps below.

1. Set aside dedicated time: Schedule 2-3 hours of uninterrupted time to focus on crafting your initial PRD draft.
2. Start with a template: Use a simple PRD template or create a basic structure with the essential sections mentioned earlier (Why, Problem, Who, Competitive Analysis, Release Plans, Go-to-Market Strategy).
3. Begin with the problem statement: Clearly articulate the problem your product aims to solve. This will guide the rest of your document.
4. Define your target audience: Describe your ideal users or customer segments in detail.
5. Outline key features: List the core features or functionalities that will address the problem and serve your target audience. Focus on "painkillers" and not "vitamins".
6. Create simple visualizations: Use tools like Figma, Miro, or even pen and paper to sketch out basic wireframes or user flows. Link or embed these in your PRD.
7. Draft a release plan: Outline a high-level timeline for development and launch, breaking it down into manageable phases if necessary. Make the first version as simple as possible.
8. Analyze the competition: Research similar products and briefly describe how yours will differentiate itself.
9. Outline your go-to-market strategy: Provide a basic plan for how you'll introduce and promote your product to your target audience. 10.** Review and refine:** Read through your draft, ensuring it's concise, clear, and covers all essential points. Aim for a 2-3 page document initially.
10. Share with your team:Distribute the draft PRD to key team members for feedback and collaborative input.
11. Iterate and update:Based on feedback and new insights, revise and refine your PRD. Remember, it's a living document that should evolve with your product.
12. Set up a review schedule:Plan regular intervals (e.g., bi-weekly or monthly) to revisit and update your PRD as your product development progresses.

Remember, the goal is to create a clear, concise document that aligns your team and guides product development. Don't aim for perfection in the first draft; it's more important to get your thoughts down and start the collaborative process.

FAQ #

Are startups not supposed to launch and iterate without any documents? #

Feel free to do that if you want, but it might be less effective. We believe that writing a concise and short document will just result in better thinking about your product strategy. You can write a PRD in 2-3 hours to bullet-proof your thinking and co-create it with others and then proceed to prototyping, validations and building your product with a more solid foundation.

Why do i need a PRD if I have a Figma file? #

The figma file (or any other prototype) is important and can be linked into a PRD, but it's not a substitute for a PRD, as it does not describe many of the details required to think through the product (e.g. describing the problem, target audience, go to market strategy etc.)