WHAT IS A PRODUCT REQUIREMENTS DOCUMENTS?

So, what is a product requirements document? A product requirements document (PRD), fully defines the value and purpose of a mobile app to your product and development teams. This document is the foundation of a successful product, outlining business logic, listing technical specifications, and ultimately helping your development team transform your early concept into a fully functional app.

Product teams use a PRD to communicate what to build, who the product is for, and how it benefits the end-user. This document guides the development of a product by providing a common understanding of the intent behind a product. If your product and development teams don’t understand your audience and their pain-points, how can they deliver products that solve the right user problems? A product requirements document clarifies all of your ideas before any development work begins.

While there are different ways to organize the document, we find it beneficial to include business requirements and technical requirements, as well as a few other considerations that will prepare your engineering team to get your product to market.

This article will walk you through the process of writing a PRD, and serve as an example of what makes an impressive requirements document.

BUSINESS REQUIREMENTS

Business requirements are criteria that are necessary to meet organizational objectives. Typically, they outline how the product or solution will address the needs of the company and its users.

• The following considerations to include when mapping out business requirements:
• What is the purpose of the app or product? What are you trying to accomplish?
• What is the current problem(s) it will solve?
• How will it improve the current process? Will it facilitate a new process?
• What is the product vision statement?
• Will the app need to be started from scratch, or can you leverage existing assets?
• What should the app be able to do? What is the product’s core functionality?
• What features will it need?
• What is the monetization or business model?
• Are there branding and design guidelines to follow?
• Is the ask feasible?

INCLUDE USER JOURNEYS

In your product requirements document, you need to include the user flow of your app for each type of user (admin, regular user, and guest users, for example). From start to finish, how will each user group interact with the product?

Creating detailed user journeys is a collaborative process and should include a business analyst, a user experience designer, a developer, and a product manager. Mapping user journeys help communicate all of the possibilities within the app from the user’s perspective. Establishing proper narrative touchpoints is essential to refining the functionality of the product.

MOBILE APP OBJECTIVE(S)

First, your product requirements document requires you to describe what you want the product to do, as well as the core objectives of the product. For the first version of any mobile app, it’s recommended to focus on a single problem your target users are experiencing. By concentrating on a core problem, it’s easier to create a concise product vision for the mobile app and establish precise success metrics.

WHAT IS YOUR PRODUCT VISION STATEMENT?

A vision statement defines a clear direction towards the end goal of the mobile app. On top of that, a vision statement describes the solution to the problem your intended users are facing. In your vision statement, you need to include who the product is for, what the user is trying to accomplish, how the product will solve the user’s pain points, and how the product is different from competing apps in the market.

CREATE A LIST OF FEATURES

The first version of your mobile app needs to offer a simple and intuitive user experience. Choosing features for your mobile app is a planning process that requires you to define the product vision, objectives, and themes fully. Some standard features can include:

• Sign-up and login
• Onboarding
• Splash screen
• Navigation
• Image galleries
• Forms
• Social media integration
• Social Feeds
• Product menus

• Shopping carts and payments
• Loyalty cards
• Booking systems
• Calendar integrations
• Push notifications
• Native video
• Native maps
• Device hardware access
• App analytics

The list above is only a small list of potential features you might require. Understanding how a user will navigate through your app is critical for identifying the necessary features that will allow for a seamless user experience.

WHAT IS YOUR MONETIZATION MODEL?

There are several monetization strategies worth exploring. The strategy you choose will depend on the type of app you’re developing, your target user, and even the mobile operating system you want to utilize. There are five conventional monetization models:

1. Advertising
2. Pay per download
3. In-app purchases
4. Freemium
5. Subscriptions

PRODUCT & TECHNICAL SPECIFICATIONS

Product and technical specifications outline the systemic and functional needs to meet for the product to achieve the desired features and functionalities.

Determine the following within the product/technical specifications for your mobile app requirements document:

• What platforms will the app will you use (iOS, Android, or Windows)?
• What operating system versions should support it?
• What are your current services, servers, databases?
• What are your maintenance needs? Do you need to support it for the future?
• How long should the app function before an overhaul is needed?
• Do you have current API/services documentation?
• Do you have current Apple, Google, or other developer accounts/credentials?
• Do you have existing provisioning profiles?
• Are there other credentials that are needed or already exist (analytics systems, or platforms)?

CHOOSING A PLATFORM

The ideal approach to development is to launch on both platforms; however, that’s not always feasible. Sometimes, you will have to develop for one platform first and introduce a second platform later for reasons like time constraints, budget, and resource limitations.

Both iOS and Android offer distinct advantages, but also attract contrasting users. When deciding what platform is best for your mobile app, a key question to ask is: what is the goal and purpose of your application? Is the sheer volume of users the main identifier of success for your app, or is your focus on driving engagement? Choosing the appropriate platform will depend on the goal you’re trying to achieve and how you plan to monetize your mobile app.

INCLUDE YOUR MAINTENANCE & UPGRADE REQUIREMENTS

Don’t make the mistake of thinking your project finishes after launch. At the very least, you need to plan for the cost of maintaining your app to fix bugs and meet system upgrade requirements. In your PRD, include a long-term product vision that accounts for user demands, product improvements, and new features for future iterations of the product.

DEPENDENCIES

Dependencies are any aspect that the product or product team relies on to meet objectives. These may include:

• Hardware that the app will run on/communicate with (for example, beacons)
• Service/API documentation
• Profile/account/platform credentials
• Any third-party software your app relies on
• Any flowcharts, documents, or information related to the product

ASSUMPTIONS

Assumptions typically relate to how product teams suspect users will behave or interact with their product. However, it’s important to include assumptions surrounding the business and technical aspects of the product in this section. In the early stages of a project, knowledge, experience, or current information form assumptions. Examples of these assumptions can include:

• X% of users will see enough value in the product to become regular users
• Technical requirement A will work on the latest operating system
• We can develop the product within a proposed time frame

CONTSTRAINTS

Constraints are the limitations that teams must work within, typically related to scope, budget, and time. However, they may also include aspects like risk tolerance, resources/staff, and quality requirements.

SUBMISSION

Your mobile app requirements document should include all technical assets and information required for Apple’s App Store submission and Google Play submission. Defining these requirements in the early stages of a project will significantly expedite the submission process when the product is ready for release. While these will vary depending on the app stores being submitted to, below are the assets and information to include for the Apple App Store and Google Play.

GENERAL ASSETS

• Icons of supported sizes (iOS: @1x @2x @3x images | Android: mdpi, hdpi, xhdpi, xxhdpi)
• Splash screens of recommended sizes (iOS: @1x @2x @3x images | Android: mdpi, hdpi, xhdpi, xxhdpi)
• Screenshots in the correct dimensions and required languages
• App descriptions in required languages
• Search keywords in required languages
• List of supported devices and OS versions

APPLE APP STORE

• iTunes Connect Account access
• Company/Entity Name
• App Store app listing name
• Search keywords
• Bundle id / SKU
• Demo account for reviewers
• Description
• Support URL
• Marketing URL
• Privacy policy
• App category
• Copyright information
• Contact information
• App icon (1024×1024)
• App Store distribution provision profile
• App Store distribution code signing identity
• Screenshots (correct sizes based on devices)

GOOGLE PLAY

• Google Play Developer access
• Store listing name
• Paid/free
• Short description
• Full description
• App icon (512×512)
• Feature Graphic (1024×500)
• App type
• App category
• Content Rating
• Contact Email
• Privacy Policy
• Screenshots (correct sizes based on devices)

THINGS TO KEEP IN MIND FOR YOUR PRODUCT REQUIREMENTS DOCUMENT

While writing your product requirements document, some considerations should be kept in mind. Firstly, it is crucial to leverage a variety of experience and insight that comes from multiple team members. Gathering this input will help you develop comprehensive definitions for different sections of the PRD template.

Secondly, as you fill in the PRD template, be sure to keep your responses and definitions for each outlined section high-level. While detail is helpful, keep in mind that while specific requirements might seem obvious to you, others viewing the document may have an entirely different perspective. Eliminating industry-specific terms will ensure that everyone can easily understand the document. As the product evolves and requirements change, ensuring everyone understands what you are trying to communicate is key to developing a successful mobile product.