Building An MVP? Prepare A Product Requirements Document First

“Is the glass half-empty or half-full?” That isn’t simply a cute riddle to ask children or a tired cliché used by armchair psychologists.

When a number of people are involved in the app development process, particularly when they’re coming from different backgrounds (for example a product development team, a financial manager and an app designer), they’re bound to view things quite differently.

Time is one of the greatest obstacles a company faces when building an app.

The product must be fine-tuned and ready for market before any potential competitors enter the same space.

And nothing wastes more time than confusion over the goals and specs for an app; misunderstandings or miscommunications often send a designer back to the drawing board time after time, in order to “correct” problems that never should have arisen in the first place.

Proper communication is crucial when developing an app.

One of the best ways to facilitate that communication is by creating a products requirements document (PRD) before work actually begins.

How Do You Construct a PRD?

In reality, there are two key reasons for creating a products requirements document.

The first is to ensure that all members of the in-house team, from business experts to “idea” people, are on the same page.

The second gives the designer a clear roadmap to the functionality and features he needs to include.

The best way to construct a PRD is to answer a series of important questions in written form, to make sure that nothing is left out.

Some of the answers will undoubtedly be valuable for everyone involved in the process, but to make things easier we’ll break them down into the “business” and the “technical.”

Business Questions to be Answered in a PRD

All of these questions should be discussed and agreed upon (as much as possible) by the members of the in-house development and business teams, although preliminary participation by the designer on functional issues can definitely be helpful.

As you’ll see, many of the answers give the designer important information he’ll need — particularly the ones dealing with functions and features.

· Why do we want to build this app? What problem will it solve? What user needs or desires will it fill? In short, what’s the overriding vision?

· Exactly how will the app work, and who is the target audience? What functions and features will it provide and what level of expertise will users need to use it? Sample user profiles and a general flow chart can be enormous assets here.

· Does the same or a similar app already exist?
If so, would ours be an improvement or advancement that people would actually be motivated to download? Can we take the existing product and build on its functionality or the successes and failures of its developers?
If not, has someone already gone down this road and failed? If they have, was it because of technical or design failures, or was the market simply not interested in the app?

· Do we already have a platform or similar product which can be modified or added to, in order to build the new app?

· How big is the prospective market for this app, what marketing channels will we use to promote it, what’s the proposed financial model and is the project economically viable?

· How important is the success of this app to our company goals?

· What assumptions are we making which may have to be revised during the development process?

Once these questions have been answered, it’s time to move on to the second part of the PRD — which will largely determine whether you end up with a success or a turkey.

Technical Questions to be Answered in a PRD

A few of the major technical considerations for an app have already been addressed in the “business” section of the products requirement development, such as the target users and the features to be included.

Much more specificity is needed in the “technical” section, and here are key questions to answer in that part of the PRD.

· Which platforms must the app operate on, and are there multiple platform/OS versions to be supported?

· Are there current company or third-party software and standards to be accommodated, or are there existing hosting, developer and analytics accounts, APIs or other services (such as GPS locators) which must be utilized for development? If new services or credentials must be acquired, which ones are necessary and/or preferred?

· How will the app be supported after its release and will future versions be provided? If so, how long will the initial version be viable, and on what timetable will updates be required?

· Will there be a premium or members’ area, and how will the verification process work with the company’s servers or outside providers? Will there be e-commerce functionality and which provider(s) should be used? Does there need to be an offline mode?

· Does the app need to be compatible with existing third-party app distribution stores or models?

· What company and user documentation will be required?

· Are there any budgets or financial constraints to be aware of?

· What is the timeline for creation of a prototype (if desired), an MVP, further iterations and final release? What criteria must be met at each stage?

One final ingredient must be included in a PRD — and it can’t be expressed by a sentence or paragraph.

The general flow chart for the app discussed earlier is helpful for in-house and preliminary use, but its non-specific nature can cause a designer to either flounder or go off in an unanticipated direction.

A detailed sitemap (with wireframes, if possible) will ensure that the designer has a clear picture of the layout, user experience and functionality you envision.

And descriptions of each page in the map will avoid the “I just assumed that you’d include a search box” conversations that cost a great deal of time (and often expense) in discussion and redesign.

Detailed sitemaps and descriptions also provide a baseline for the weekly update meetings or conversations you should be having with the designer.

When inevitable problems crop up and changes are needed, the documentation allows everyone involved in the process to visualize the alterations being considered, and agree on the best way forward.

Need a hand with getting your PRD constructed? Don’t have the time or budget to hire an in house developer and designer? Let us take the stress off of your shoulders, visit Ideaction.io to schedule a call today