How to Write a Product Requirements Document as a Non-Technical Founder

Published Sep 11, 2017Last updated Mar 21, 2018
How to Write a Product Requirements Document as a Non-Technical Founder

Why You Need a Product Requirements Document

Let’s say you’ve suddenly thought of your million-dollar idea in the middle of the night. You’re excited and can’t wait to begin, but you're not sure what the next steps are.

In order to be “the next big thing,” you need to have a detailed vision, not just a great idea (although the great idea helps).

Not only that, you need to be able to clearly express your big idea to other people: the people who are going to invest in your idea and the people who are going to build it for you.

After researching what the next step is, you arrive at the conclusion that before you do anything, be it hiring a developer or fundraising, you need to write a Product Requirements Document (PRD).

A PRD, a quasi-combination of a Business Requirements Document (BRD) and a Systems Requirements Document (SRD), will help you explain to a developer what your vision is and what needs to happen for it to become a working product.


With a PRD in hand, your developer has a better sense of what your requirements are and how they can help you build it. By knowing in detail what you want, you can save yourself a lot of time and money.

While it’s certainly possible to build a successful product without a PRD, going through the process of writing a PRD can strengthen your own understanding of your target audience, goals, and future product.

We’re going to guide you through how to write a PRD, step-by-step.

In order to provide a detailed walkthrough, we’re going to approach the process from the point of view of a startup founder writing their first PRD.

In this scenario, our startup founder wants to build an app and website for SafePark, a tool to help people find parking spots in cities across the world.*

*SafePark is a hypothetical startup for the purposes of this walkthrough. Any resemblance to real companies/services was unintentional and coincidental.

The Five W’s to Think About Before Writing the PRD


  1. Who is my product’s target audience? Car owners in big cities.
  2. Why does the audience need my product? Everyone who has a car wants to find convenient parking with minimum hassle when they go out.
  3. When do I need it by? I would like to launch SafePark in six months.
  4. What do I want to build? A mobile app (for iOS, Android, and Windows phones) and website.
  5. How do I build it (using what languages)? Consult with developer, but generally Swift or Objective-C for iOS, Java for Android, C++ for Windows phone, and Ruby on Rails for the website.

The Components of a Product Requirements Document

  1. Overview
  2. Target Users
  3. User Problems Solved
  4. User Stories
  5. Competitors
  6. Technical Process and Specs
  7. Release Criteria

The Product Requirements Document Template

Below, we’re going to go through the different sections of the Product Requirements Document and fill it in as if we were the founder of this parking spot locating app and website, as described earlier.


This describes the product you’re going to build, so you want to clearly describe the product’s purpose, features, and functionalities.

From London to Chicago, Taipei to Rio De Janeiro, if you’ve ever lived in a big city, you know how hard finding parking can be.

SafePark can fix this problem for urbanites around the world. SafePark is a freemium app and website that will locate open parking spots in cities all across the world.

The free app will show you the unoccupied parking spot nearest to you (although it won’t show whether the spot is metered or free of charge) while the premium version will display the cost of the parking spot in 15 minute increments.

SafePark will use the geolocation and GPS capabilities in your phone to show you where you can legally park and allows you to report to other users when a space becomes available.

The website uses the same geolocation services as the mobile app but will show more possible locations because of the bigger screen size.

When it’s released, SafePark will be the next revolution in urban living.


This description is a good example of an overview because it describes the users’ pain point, why they need your product (difficulty finding parking in a big city), and shows how the product will solve their problems (helping users find parking).

It discusses the product’s main features and functionalities: finding open parking through the user’s phone’s geolocation and GPS capabilities and user reports for open spots.

In other words, the overview clearly and concisely describes why the product is needed and what it will do.

Target Users

This helps you answer who your audience is, what they can do with your product, when they might use your product, and how they will access it.

Who: Car owners, aged 18-70, who live in major cities and need to find a parking spot.
What: This app will allow users to find an unoccupied parking spot nearest to them using the GPS capabilities of their phone. They will also be able to report unoccupied spots (or to flag the spot they just left as unoccupied) after they leave.
When: Urbanites who need parking spots will use this app.
How: Web and mobile app.

User Problems Solved

How will your product solve users’ main problems?

  1. User Need: User needs to find a parking spot for their vehicle.

    Resolution: SafePark can use the users’ phone’s GPS to find the closest unoccupied parking spot. Only legal parking spots will be shown.

  2. User Need: User needs to know how much parking would cost in a given location.

    Resolution: In the premium version, users can see how much a parking spot costs, in 15 minute increments, in locations all over the city.

  3. User Need: Tourists need to find parking and don’t know where they can park.

    Resolution: SafePark can use the users’ phone’s GPS to find the closest unoccupied parking spot. Only legal parking spots will be shown.

  4. User Need: User gets frequent parking tickets/fines for (unknowingly) parking in illegal parking spaces.

    Resolution: SafePark use the users’ phone’s GPS to find the closest unoccupied parking spot. Only legal parking spots will be shown.

    giphy-downsized (1).gif

User Stories

Here, you can describe the key functions users can carry out with your product. This section should focus on functionality rather than design.

All premium users will have access to freemium version features, but only premium users can use additional features.

  1. As a user, I can create an account linked to my email.
  2. As a premium user, my account can save a list of parking spots that my phone will search for first.
  3. As a user, I can see parking spots all over the city, both occupied and unoccupied on the website version.
  4. As a premium user, all parking spots will have a cost displayed in 15 minute increments in locations all over the city.
  5. As a user, my phone will show me the nearest parking spot using GPS geolocation.
  6. As a premium user, the website and phone versions will alert me to events in the city that may affect my preferred parking locations.
  7. As a user, my phone allows me to alert other users to empty parking spots.
  8. As a premium user, I can alert other premium users to empty spots, which they will receive before non-premium users.



List your main competitors, describe their market position, and product availability in this section. Writing this information down will not only give you a better idea of the market you’re entering into, but knowing more about your competitors can help you consider how else you could improve your product for better reach, product market fit, or edge over your competition.

Parking Spot

Parking Spot is one of the few parking locator apps out there. It’s an Android app made by Aabasoft Android Development Division. Its interface is simple, with a find button and a list of parking spots based on their distance from your location.

Target audience is the same as SafePark: anyone who wants a nearby parking spot
Core functions available: find parking spots by distance, works with and without GPS
Pros: simple UI, easy to use, free
Cons: only for Android devices
Pricing: free


VoicePark is a hands-free turn-by-turn guidance app that will lead users to the closest available parking spot to their pre-determined destination. It uses real time data from on-street sensors, off-street parking availability, and predictive analytics.

Target audience is the same as SafePark: anyone who wants a nearby parking spot or tourists who need are unfamiliar with a new city and need guided assistance to find a parking spot
Core functions available: turn by turn guidance to parking spot near your destination
Pros: multi-platform, includes Android and iPhone, provides guidance to the parking spot, free
Cons: UI is clunky looking, uses Apple Maps
Pricing: free


Parker helps users find open, available parking spots for on-street parking spaces, garages, and lots. It also offers GPS navigation to real-time available parking. Parker shows prices, a built-in timer for meter expiration, and filter capabilities.

Target audience is the same as SafePark: anyone who wants a nearby parking spot and people who have a hard time remembering where they parked
Core functions available: turn-by-turn guidance to parking spot near your destination, meter expiration timer, saves parking location, displays prices
Pros: available on Android and iPhone, provides guidance to the parking spot, free
Cons: limited number of cities supported
Pricing: free

Technical Process and Specs

Here, we’re going to walk through the technical processes behind the product and its basic capabilities. The more you know about what you’d like to happen or how your product should work, the easier it will be for your developer to help you.

If you’re unsure about the complex technical aspects, however, don’t fret. Try to be as clear as possible while being open to suggestions and feedback.

Below, we’re going to write tech specs and a list of technical processes from the point of view of a founder who might not know how the development works but has an idea of what they want.

In this section, points 6-8 are examples of a feature that wasn’t mentioned before. The founder hopes to implement these features but isn’t sure about its feasibility.


  1. The app needs to be able to access geolocation and GPS services from the users’ phone in order to find nearby parking spots.
  2. The app should be able to connect to public parking APIs in order to tap into information on public parking, such as rates and availability.

Some major cities, like San Francisco, have their city parking spot information available online. If SafePark can sync with that information, it adds to the number of legal, open spots available.

  1. The app should be able to access privately owned lots as well to give more detailed information on parking rates.
  2. The app should have a function like Waze, where users can report open parking spots on the street. This will encourage user participation and increase the number of parking spots that users see.
  3. The app should be able to sync across mobile and desktop so that users can look up information at home, on their computers, and be able to access it on the go.
  4. Ideally, a user will open the app, press their “find me” button, and see the parking options nearest to them, color coded by type: blue for user reported, yellow for free parking, green for private lots, and orange for public parking.
  5. Premium users will be able to see the rates for public and private parking closest to them. They will also be able to get preferential alerts, so the back-end needs a database of premium users.
  6. The user should have some sort of easy to find button to report an empty space, and quickly choose what kind of parking category it belongs to. The app will color code the information automatically.

Release Criteria

Here, talk about how you would like your product to be tested for quality assurance and documented before and after its release. This will facilitate conversation between you and your development about how you want to communicate and collaborate.

Testing/QA: Before SafePark is released, I would like to complete alpha and beta testing to make sure there are no bugs, the GPS functions are accurate, the parking rates are displayed accurately, and the app does not crash, like those of my competitors.

I will consult with my developer on how they will complete QA trial runs for the alpha and beta testing, as well as the final version before release. I will also discuss with them what happens if QA testing fails.

In addition, I will talk to my developer about the time frames for alpha testing and then beta testing. With a launch date of six months from now, I would like alpha testing to be completed at least three months into the project, beta testing five months into the project, and a final version to be tested for a month prior to launch.


Note: While you don’t have to know when exactly you want your product to be alpha or beta tested — which you should plan to do to get user feedback and to better grasp your product market fit — you should think about and discuss product testing and quality assurance issues with your developer.

Documentation: I would like to make sure that my developer documents his/her code religiously. While that may cost me more in terms of time spent on the project, I would like other developers working on this project in the future to be able to read changes to the code.

This not only avoids technical debt — where choosing a short-term easy fix right now creates more problems down the road — especially if I decide to scale the product. Good documentation also ensures continuity between developers working on the project.

I would also like to be updated on possible changes to features, either via a project management tool or email. I would like to be briefed on a bi-monthly basis, rather than simply view a finished product.

Support: I would like to ask my developer what support will be offered after the initial product is built. I will also make sure that the developer I hire will be available on standby basis (and will be compensated accordingly) for at least the first 48 hours after launch, to ensure that any unforeseen glitches will be taken care of.

Note: While not all products require extended support, you should consider what happens after your product is built and launched.

Even though your freelance developer is, well, freelance, if you’re worried about problems during launch, it’s worth making sure your developer will be available to help you, or leave good documentation behind, after he or she is done building your product.

As for the 48 hours after launch standby, this is a semi-arbitrary time period that is not strictly necessary. In this hypothetical, we suggested a 48 hour standby period in case there are problems after launch that need immediate resolution.


Although you have tested this product, there could be unforeseen issues, server overloading etc., that can happen if the product is very popular and the back-end systems are not prepared to handle it. Therefore, it would be safer to ensure someone is on hand to help.

Obviously, there is always the chance of bugs and glitches, even after extensive testing, but if something is going to go wrong, there is a greater chance it’s going to go wrong immediately after launch.

PRD Templates and Resources

Sample Product Requirements Document
How to Write a Good PRD
How to Write a Painless Product Requirements Document

A Word to the Wise Before You Write Your PRD

Congratulations, we’ve just completed one version of a product requirements document template.


A few words of advice before you go off to make your million-dollar app a reality!

First, don’t worry if you don’t know any programming lingo or terminology. If you’re unsure how to describe what you want to happen to your developer, you can write a user story, which basically describes what you want the customer to experience.

Second, do let your developer know what you’d like your app to do (in general terms). If you know what features you want, divide them into two categories: requirements (must-haves) and bonuses (nice to haves, but not requirements).

Keep in mind that not all features are created equal (or feasible). However, having made this list will at least force you to think about what you really need to bring the product to market.

Finally, when interviewing a developer, ask which of your required or bonus features can be short-circuited, i.e. which features can be carried out using a basic script for your prototype, so you can decide whether you want to try this feature at all before investing too much time into it.

Remember, the more you know about what you want and the more specific you are in your PRD, the easier it is for the developer to help you.

If your PRD is ready, read more about SafePark's adventures to learn how to estimate your monthly website costs and Everything You Need to Know Before You Hire a Freelance Developer for a detailed guide to the hiring process. Once you're ready to hire a developer, sign-up for an account to get started with the hiring process. Good luck!


In addition to finding the right developer, if your product is successful, eventually you'll need to hire a product manager. Check out this post on How Startup Founders Can Approach the Product Management Role.

Hire a top developer for your teamHire A Developer