The Product Requirements Document (PRD): The Swiss Army Knife of App Development

By John Houghton on January 13, 2014

The Product Requirements Document (PRD) is the Swiss army knife for getting software built, and that includes mobile apps.  It’s a basic software design document.  I remember working with a billionaire software investor.  He always wanted a good Product Manager because they could write a PRD, and a PRD is all you needed to hand to a developer to get your software built.  He was pretty much right.  If you have a PRD, you have the roadmap that a developer can use to develop your software for you.  See my previous article on, The role of the Product Manager on a Mobile App Development Team.

At a big company where there is time for a lot of dialogue about market strategy and technical direction, there are a lot of different documents that can be produced alongside the PRD.  Here they are (and here is where the PRD fits):

— Market Requirements Document (MRD) – Market landscape and what the market wants.  This can be written by a Marketing Manager or the Product Manager.
— Product Requirements Document (PRD) – What the app is required to do in a mid-level of detail.  This is written by the Product Manager.
— Functional Specification – Written by developers, this is the technical response to the PRD detailing how the app will interact with the user.
— Technical Requirements Document – Written by developers, this outlines how the app will be built, which APIs it will use, and which services it will call.

There are different names for these documents, and these are just the main design documents.  There are lots of other documents used in different phases of software development.  The debate continues to rage over how much documentation is needed, as each of these documents can take weeks to write.  Excessive documentation means that apps don’t get to market as fast, and on the other end, you have the rest of the company feeling out-of-touch with what this fast-coding and non-communicating team is doing.  With time-to-market being a pressing requirement, a happy medium is to write only the PRD, include chapters on the market, and talk a little about technical requirements.  The functional specification is sometimes left out, as there is less need for it if you have a seasoned developer working on the project.  This deals with all of the detailed interactions, “If you tap this, a message is displayed…”  You can leave it in their capable hands, see how the product turns out (it’s usually close), and adjust it from there.

The PRD usually contains the following information:

— High level market requirements
— Market problem and opportunity
— Features with priorities
— User profiles / personas
— Use cases
— Wireframes
— Technical summary
— Schedule

Here is the rule with documentation – the longer everybody has worked together, and the more they have done this certain type of app, the less need there will be for detailed design documents.  Conversely, if you are working with new developers on a new team, you should err towards more documentation.  The main idea of such documentation is to give all parties sufficient information to do their jobs.  The “fail” you’re trying to prevent with documentation is a loss of time, productivity or money and it’s pretty easy to have a “fail” if you’re running without documentation.  Without documentation, people can feel like they’re working in a vacuum, especially new team members.  Documentation is also a great way to protect continuity, so that if a key team member quits, you can more quickly bring their replacement up-to-speed and get back on track.

One other thing about the PRD, it typically doesn’t contain any graphics.  Decades ago, someone must have noticed that people tend to get hung up on the look and feel of software rather than its functionality, so in order to talk about the features of a software product, they noticed everybody was more productive if the graphics were designed separately, after the main features were decided when the PRD was approved.  I hope that helps you understand a little more about how to design mobile apps.

MobileCast Media offers services to design apps and write PRDs.  PRDs I have written have specified software that has make hundreds of millions of dollars in revenue.  Contact us today to find out what we can do for you.

Posted in Android Apps, App Development, iOS Apps, iPad Apps, iPhone Apps

Comments

Comments