PRD: Name of Product
PRD: Name of Product
Vision
Motivation
Key Path Scenarios
Detailed Design & Features Description
Design Principles
Suggested Information Architecture
Features
Roadmap
v1 aka Minimum Viable Product
vNext
vLongterm
Milestones / Timing
Metrics
Projected Costs
Engineering Costs
Marketing / other Costs
Operational Needs
Risks
International
Group Members
Vision
1-2 sentence description of target customers, their unmet needs, and your proposed solution.
Consider using Geoffrey Moore’s positioning statement from Crossing the Chasm, i.e., “For
[target customer segments] who must [problem to be solved], our product is a new [category
name] that provides [solution to the problem]. Unlike [current solutions], we offer [key
differentiating factor].”
Motivation
Copy this section from your MRD (including personas, unmet needs, existing solutions,
differentiation, and why now?), yellow highlighting any new material added since your MRD
was completed.
Key Path Scenarios
Key Path Scenarios describe how personas interact with the product; they are called “use
cases” in many product development processes.
Adapting the use scenarios from your MRD as appropriate, describe the key pathways that your
primary personas will take through the product’s user interface with the greatest frequency. Use
a step-by-step narrative approach to describe how the persona will interact with the product,
interspersing user interface wireframes and/or detailed mocks throughout your text narrative. Be
sure to specify your product’s modality, e.g., whether it is a native mobile app, a responsive
website, desktop client software, etc.
PRD key path scenarios are more task oriented than MRD use scenarios, which focus on
personas’ goals. Also, remember that while MRD use scenarios should be feasible with existing
technologies, they do not describe which specific technologies should be employed in the
product, nor do they describe the user interface. PRD key path scenarios, by contrast, should
depict your user interface and should be compatible with the specific technologies that are likely
to be used in what is described below as vLongTerm, i.e., the mature version of your product.
While the narrative should focus on users’ interactions with the product, it should also include
some description of server-side activities required to support those interactions. For example,
“After user clicks ‘Buy,’ server checks database for user’s credit card and shipping address. If
present, then server presents...”
If your product serves a two-sided network, be sure to include key path scenarios for both sides.
If your product has separate features for site administrators, consider including key path
scenarios for them.
Detailed Design & Features Description
Design Principles
State any overarching design principles.
● Examples of principles: “we are willing to omit incremental features to maintain ease of
use,” “We must preserve backward compatibility with earlier versions”
● For ideas, see the lists of principles collected by adactio; chapter 13 in Marty Cagan’s
Inspired, as well as statements by Microsoft, OPOWER, TiVo, etc.
● Consider citing some products with design elements you admire and would aspire to
emulate
Suggested Information Architecture
Describe, at a high level and preferably using the MVC model, your information architecture.
List the key tables of your database and their main data elements; the key views of your
display; and the key logic components/algorithms that control how user inputs are processed,
how data is retrieved/transformed, how appropriate displays are invoked, etc. Consider
organizing these elements in a table with columns labelled “model,” “view,” and “controller,”
and rows contain specific database tables, their corresponding display views, and the relevant
algorithm/processing logic module.
Features
What are the product’s features and how should they work? You should make your
descriptions in this area as complete as possible.
Present features in a table with columns presenting 1) the feature name; 2) a description of
what the feature does; 3) a list of dependencies (these might take the form of data, logic, or
display elements required to use the feature, if you haven’t linked these elements in the info
architecture section); and 4) priority for the feature -- using the v1, vNext, vLongTerm
distinction described below.
Roadmap
Provide a summary of the functionality proposed for your MVP, the next version of your
product, and the mature product.
v1 (aka Minimum Viable Product)
What constitutes the minimum viable product for launch?
vNext
What functionality will your next version provide?
vLongterm
What functionality will the mature product provide that won’t be available in your first two
versions? This is likely just a bullet point list of placeholder features.
Milestones / Timing
Describe the planned timing of releases and key activities for your first release. What are your
major milestones (internal demo, beta launch, full launch, etc.)? Are there natural points for
reassessment? Consider linking to a spreadsheet with a PERT / gantt chart.
Describe the major elements of your Go-to-Market plan. What marketing methods do you plan
to leverage, in what sequence, etc?
Metrics
What are the key metrics for tracking success? Please indicate how you will compute them
(e..g, with log data etc.). This will likely link off to a spreadsheet along with your expected
hypotheses on where the metrics will be after X Days, Months, etc.
Projected Costs
Engineering Costs
How many engineers * weeks will the project require? How much will different components,
individuals, or usage cost you for storage and compute resources?
At some point, you will need to get estimates from engineers (or via oDesk / eLance) on the
amount of time and potential costs for your project.
Marketing / other Costs
What costs will you incur in marketing and launching your product?
Operational Needs
Describe any ongoing customer service or other operational support that will be required, and
how you plan to provide it.
Risks
How will you address each of the risks identified in your MRD, and any new risks identified
since you completed MRD?
Consider presenting risks in table format with columns providing detailed description and
possible mitigants for each risk .