A PRD is a “Product Requirements Document” that describes a customer problem in a market, proposes a set of features that might meet their need, and provides tangible criteria for measuring success and enabling future product iterations.

This document outlines what should be included in a standard PRD for an early stage product idea. Feel free to use it as a template if helpful for your project. An example PRD can be found here.

<1-2 sentences succinctly describing what the product or service will do. It should fit in a tweet and catch the reader’s attention.>

<1-2 paragraphs describing a problem that you or someone you know has experienced. Quickly describe how the current offerings on the market are not effectively solving the problem.>

<Bullet points describing the people that experience the problem above, separated out by role>

For example:

• DAOs & crypto teams want to send crypto payments to reward contributors, pay contractors, issue vesting tokens, and more.

• Crypto-native employees want to easily get paid in crypto for their contributions.

<Several paragraphs, bullet points, and/or diagrams going in depth about the problem and what a solution might look like for your target users. Use plan language and avoid technical jargon or going too much into implementation details. Your Target Users (above) should be able to read this section like a website and say “Aha! I’d love to have that!”>

<If the product description above was live today, how would you know if it was effective? List some bullet points on quantitative measurements of success. Metrics like sign ups, customer commitments, indications of interest, net promoter score, deposited capital, etc.>

<Similar to your Description section, describe your solution but focus more on “how” the problem can be solved in a first iteration. Your customer doesn’t need to understand this section, it’s for sharing internally with your dev+design team. Propose solutions where you can but remain flexible with your language and thinking so the wider team can weigh in with their expertise and help shape the solution.>

<What is needed to build a Proof of Concept (v0.1) solution that you can start testing with customers? Can you do some of the steps manually without coding anything? Can you mockup the designs of the app? For the coding pieces, what technologies could be used to build and iterate quickly? Include a diagram describing the high-level architecture if possible (frontend, backend, smart contracts, integrations, etc.)>

<What features are not needed for the PoC but are likely to get built out in future iterations? Include them in succinct bullet points. Conversations with customers will ultimate refine and prioritize this list but include your best educated guess on the features they’ll likely need over the next 6 months of product iterations.>

<A list of links and bullet points that informed your thinking in this PRD. These could include links to analytics that informed the need, user complaints describing the pain points, Github repos, articles, diagrams, or anything else.>

Happy building! 🙂

A PRD is a “Product Requirements Document” that describes a customer problem in a market, proposes a set of features that might meet their need, and provides tangible criteria for measuring success and enabling future product iterations.

This document outlines what should be included in a standard PRD for an early stage product idea. Feel free to use it as a template if helpful for your project. An example PRD can be found here.

<1-2 sentences succinctly describing what the product or service will do. It should fit in a tweet and catch the reader’s attention.>

<1-2 paragraphs describing a problem that you or someone you know has experienced. Quickly describe how the current offerings on the market are not effectively solving the problem.>

<Bullet points describing the people that experience the problem above, separated out by role>

For example:

• DAOs & crypto teams want to send crypto payments to reward contributors, pay contractors, issue vesting tokens, and more.

• Crypto-native employees want to easily get paid in crypto for their contributions.

<Several paragraphs, bullet points, and/or diagrams going in depth about the problem and what a solution might look like for your target users. Use plan language and avoid technical jargon or going too much into implementation details. Your Target Users (above) should be able to read this section like a website and say “Aha! I’d love to have that!”>

<If the product description above was live today, how would you know if it was effective? List some bullet points on quantitative measurements of success. Metrics like sign ups, customer commitments, indications of interest, net promoter score, deposited capital, etc.>

<Similar to your Description section, describe your solution but focus more on “how” the problem can be solved in a first iteration. Your customer doesn’t need to understand this section, it’s for sharing internally with your dev+design team. Propose solutions where you can but remain flexible with your language and thinking so the wider team can weigh in with their expertise and help shape the solution.>

<What is needed to build a Proof of Concept (v0.1) solution that you can start testing with customers? Can you do some of the steps manually without coding anything? Can you mockup the designs of the app? For the coding pieces, what technologies could be used to build and iterate quickly? Include a diagram describing the high-level architecture if possible (frontend, backend, smart contracts, integrations, etc.)>

<What features are not needed for the PoC but are likely to get built out in future iterations? Include them in succinct bullet points. Conversations with customers will ultimate refine and prioritize this list but include your best educated guess on the features they’ll likely need over the next 6 months of product iterations.>

<A list of links and bullet points that informed your thinking in this PRD. These could include links to analytics that informed the need, user complaints describing the pain points, Github repos, articles, diagrams, or anything else.>

Happy building! 🙂