Chapter 12: Defining and Designing the Product Access Chapter 12 templates and tools from The Product Manager’s Desk Reference (3rd Edition). Learn how to define products using PRDs, elicit and validate requirements, and connect customer needs to product design. Download the chapter abstract and illustration insights. Core Concepts Product definition documentation Requirements elicitation and management Structuring product requirements Prioritizing and validating requirements Evolving product design Preparing for definition reviews Executive Summary Ideas for new products and enhancements come from a variety of sources, including intensive market analysis, observation, and even structured ideation activities. There are always going to be more ideas than there are resources to commercialize them. Not all ideas will make good business sense, so a solid Business Case is needed. Clear goals and strategies and solid customer and market insights provide the fuel to effectively plan and prioritize your work. Chapter Abstract The Definition phase, the final phase of (linear) product planning, is the most important linkage between the needs of customers and the designs and capabilities of products. The details of product content, function, and design first become focused and articulated in the Product Requirements Document (PRD). The PRD is a business- and market-driven document that describes the characteristics of a product—both functional (the basic intent of the product) and nonfunctional (the characteristics, properties, or qualities that the product should or must exhibit)—and reflects business, market, or customer needs. It may be written by a business analyst, systems engineer, or a product manager. Requirements can be elicited through highly structured interviews from customers or other experts, customer advisory boards and surveys, information gathering from the cross-functional team, conversations with industry analysts, reviewing competitive product features and attributes, potential customers or current customers or product users, brainstorming, architectural and product quality reviews, and storytelling (scenarios based on customer personas). Prior to publication, the PRD should be reviewed. Types of review include inspections (systematic, rigorous review to look for areas of ambiguity, inconsistency, and achievability), team reviews (developers and product managers look for clarity of intent or purpose and consistency in language), and walk-throughs (the product manager presents the essence of all the sections of the PRD to a group of peers or others, or sometimes customers, to ensure that the logic, intent, and desired outcomes are understood by all stakeholders). Once baselined, the PRD should be examined for relevance as the product development process begins. This is important because market conditions change. In fact, both the Business Case and the PRD should be re-evaluated from time to time, especially with longer-duration product development projects. If the product definition isn’t clear from the start, the product may not achieve its envisioned success. Download the Chapter Abstract > Templates and Diagrams for Chapter 12 Figure 12.1 – Product Definition Document (PRD) Structure Figure 12.2 – Requirements Elicitation Techniques Figure 12.3 – Functional and Nonfunctional Requirements Model Figure 12.4 – PRD Review Types and Objectives Figure 12.5 – Product Definition Baseline and Change Review How These Templates Help Product Managers The templates in Chapter 12 help product managers translate customer needs and business goals into clear, actionable product definitions. They provide structure for eliciting and organizing requirements, reviewing and validating intent with stakeholders, and maintaining alignment as development progresses. Used together, these tools reduce ambiguity, improve cross-functional understanding, and increase the likelihood that the product delivered matches its intended value and design. Download Illustration Insights > What is the purpose of a Product Requirements Document (PRD)? The PRD defines what the product is and what it must do, translating customer, market, and business needs into clear functional and nonfunctional requirements. Who is responsible for writing the PRD? The PRD may be written by a product manager, business analyst, or systems engineer, depending on organizational structure and skills. Why are PRD reviews important? Reviews ensure clarity, feasibility, consistency, and shared understanding before development begins, reducing rework and risk. Should a PRD ever change after it is baselined? Yes. Market conditions evolve, and longer development cycles require periodic reassessment to ensure continued relevance. The Product Manager’s Desk Reference, 3e The Product Manager’s Desk Reference, Third Edition is the definitive guide to product management for today’s fast-moving, digital-first business environment. Steven Haines presents a complete, practical body of knowledge covering strategy, execution, cross-functional leadership, and product portfolio management. Updated with modern tools, analytics, and development approaches, it equips product managers and product teams with a repeatable framework to run products as businesses and deliver measurable results. Buy the Book Explore Product Management Training Get In Touch First Name(Required)Last Name(Required)Email(Required)Phone NumberCompany NameMessage(Required) Training a Team? Customized Corporate Training Supercharge Your Team (6+): We tailor proven product management training content to your specific goals, offering a customized program delivered online or in-person to ignite your team’s potential and drive results.
