Don’t skimp on your PRD

Robert Smith-Gillespie, Riverwood Solutions, Menlo Park, CA

NPDP is beginning at idea generation and moving on through assessment, conceptual design and evaluation, detailed design, and eventually pilot- and mass-production. During the idea generation stage, a company captures a market need and attempts to direct a product position in a Market Requirements Document (MRD).

The MRD provides the vision for the product detailing at a high level the market requirements for a perceived product. These include descriptions of the product market, the competitive landscape and a prediction of market success. The MRD is primarily intended for making a business case to pursue a product. However, product features and user needs might be discussed to highlight why the product would be successful.

Much has been said of the importance of the initial steps of the NPDP – idea generation, idea screening, market assessment and competitive analyses. However, there are numerous opportunities to go off course during the next step in the process, i.e. the “productization” phase of development. It is during the product development phase that the disciplined use of a detailed PRD provides the structure needed to ensure success. Unfortunately, the generation of a comprehensive Product Requirements Document is often sped through using an MRD as the guiding instrument leaving design and engineering teams to fill in the requirements holes during the design process.

Failing to invest the time and discipline into creating a detailed PRD can result in significant impacts on the development process including:

In the product development world, it’s not what you ask for that you get but what you specify. The PRD helps prevent a „this is what I thought you wanted“ scenario replacing it with „here is what you specified“.

So what exactly is a PRD and how should it be managed? The PRD is a comprehensive document detailing product requirements that can and should be used to drive the NPDP cycle. Authored by the product manager with input from the marketing team, the PRD outlines general product goals and market targets as well as specific performance criteria for the product. A well-crafted PRD should include the following details:

– Defines target markets/customers & why product is being developed

– Provides key product milestones

Introduction & Product Overview

– Provides technical/functional overview detailing problem being solved & product discriminators

Technical Requirements

– Environmental

– Functional Performance

– Mechanical/Electrical Interface

– Test & Qualification

– Security

Support Requirements

– Documentation & Training; Maintenance

Program Requirements

– Contractual obligations

– Constraints (resources, facilities, etc.)

– Workflow, timelines & milestones

While the product manager is typically responsible for the writing the PRD, it is clear from the list above that inputs are needed from numerous outside sources. It is vitally important that the requirements do not simply flow down to engineering but also derive from the experience of engineering on previous products. As such, engineering, R&D, and operations teams should be involved in the early phases of the crafting the PRD. It really doesn’t make sense to plan a product only to find out that it is impossible to meet a target deliverable due to supplier lead-times, component availabilities, or manufacturability constraints.

While it is the role of the product development team to push the technical envelope to meet the MRD goals and intent, it is essential that the technical team fully assess the feasibility of the goals and limitations of the required technologies before spinning them into the PRD. For example, the push to integrate consumer product-like appearance in ruggedized display products caused program delays and cost escalation when deficiencies of the consumer product approach (i.e. strengthened glass cover sheets; think shattered iPhone display) failed in product qualification testing. Had engineering performed some basic testing prior to PRD sign-off, millions of dollars in lost revenue, scrapped product, and engineering time could have been saved.

Early dialog with key stakeholders will reduce the likelihood of a false start. To avoid unnecessary costs and delays, engineering and program management teams need to carefully review PRDs to ensure all major elements of the product are adequately defined.

In addition to authoring the PRD, the product manager is responsible for updating the PRD as strategy or performance objective changes are realized or design trade studies completed. Communication of changes should be shared with stakeholders via timely revisions to the PRD.

In the traditional design-build company where the product concepts are organically derived, it might have been possible to short-cut the PRD development process and engineer the product on-the-fly. However, in the increasingly outsourced product world where product companies may be halfway around the world from the design and build functions, the effectiveness of design-on-the-fly approaches goes to zero. It is in this environment especially that a solid PRD and the supporting structure pays maximum benefits instilling discipline on both the product and the design/production sides of the NPD cycle.

In the fast paced technical product development environment companies may choose to outsource various components of the product development process. The extent to which outsourcing is employed depends on business factors including the ability to leverage expert human capital to develop key components quickly while maintaining low operating overhead. While the PRD is a standard tool for in-house development at many large corporations including Apple1 smaller companies leveraging outside assistance for many traditionally captive functions can use the PRD or a derivative for managing these activities.

For each of the development path options, the PRD provides the management tool for defining requirements and deliverables. How to manage outsourced NPDP activities using the PRD is the subject of a follow-on article.

Regardless of the development pathway followed (OEM, CM, ODM, or a hybrid), definition of product design and performance and program requirements in a single PRD will provide a roadmap for directing the NPDP and a gauge for assessing product performance to expectations. For now just remember, the PRD should be the Rosetta stone for the product development process. Be sure to provide sufficient detail for all stakeholders to self-manage their contribution to development of a successful product.

Since almost all products incorporate some form of custom or semi-custom components and subassemblies, in a follow-on article we will look at how to structure PRDs to control development of outsourced subassemblies. Here, it is about achieving a balance between allowing the supplier to add their expertise while ensuring end-product performance goals are met.

1 http://thenextweb.com/apple/2012/01/24/ this-is-how-apples-top-secret-product- development-process-works/

Der Weg von einer Idee bis zum verkaufsfähigen Produkt ist oftmals mit manch Problemen behaftet. Doch mit der Verwendung von wichtigen Unterlagen mit den Anforderungen an das Produkt, macht die Entwicklung und auch Einführung eines neuen Produkts zu einem überschaubaren Risiko, wie der Artikel aufzeigt.

Le chemin qui même d’une idée jusqu’au produit prêt à la vente est souvent affecté de nombreux problèmes. Mais avec l’utilisation des bons documents concernant les exigences pour le produit, le développement et aussi la mise sur le marché d’un nouveau produit en font un risque mesurable, comme le démontre l’article.