How deeply does Everyday Data Visualization cover product requirements document?

Explains concrete PRD sections and change handling, without prescribing a formal template or exhaustive discovery method.

Product requirements document in Everyday Data Visualization

A product requirements document is a formal document that specifies a product's intended capabilities, requirements, and scope.

A product requirements document (PRD) turns scattered stakeholder interviews, user notes, and early data findings into one agreed plan. For a dashboard, it states the purpose, the questions to answer, intended users, deliverables, requirements, and—just as importantly—what the project will not do. Think of it as an elevator pitch with enough detail to prevent surprise elevators later. section 8.2.3

Make a dashboard PRD specific enough to guide decisions and negotiations:

State the dashboard purpose in one or two sentences and limit its main questions to a manageable few. section 8.2.3
Name stakeholders and target users, then prioritize the needs of the people who will use the dashboard most. section 8.2.3 section 9.3.1
Separate in-scope deliverables from exclusions, including publishing location, data-pipeline responsibility, device layouts, languages, and documentation. section 8.2.3
Specify filters, controls, parameters, visuals, interactivity, accessibility, and the data needed to support them. section 8.2.3 section 9.3.1
Record changes openly: explain their effect on timing or cost, then let stakeholders choose whether to reprioritize other work. section 9.3.1

A dashboard metric checklist

A requirements table can make data assumptions visible before design begins. For a housekeeping dashboard, list each metric, its calculation, whether the data exists, and notes about importance or display—for example, distinguishing trended checkouts from heavily prioritized fully booked nights. section 8.2.3

Approval is not a ceremonial final page. Use the PRD in an iterative cycle: gather feedback, revise when requirements are rejected or changed, and carry the accepted requirements into design, prototypes, and development. Near the deadline, bring it back to feedback sessions as evidence that the agreed work is complete. section 8.4 section 8.4.2

Table 8.2 A table of metrics that must be visualized in the Housekeeping Dashboard of our case study. (view table figure)

Metric name	Calculation	Does the data exist?	Notes
Reservations checking in	Count of reservations whose stay begins on a particular day	Yes	Can be deprioritized since these rooms will not require housekeeping per se
Reservations checking out	Count of reservations whose stay ends on a particular day	Yes	Trended only
Reservations stayed over	Count of reservations whose stay is not beginning or ending on a particular day	Yes	Trended only
Nights fully booked	Count of nights when all rooms in the hotel are reserved	Yes	Aggregate and trended—most important!
Nights >90% booked	Count of nights when more than 90% of the rooms in the hotel are reserved	Yes	Aggregate and trended—most important!
% Nights fully booked	Nights fully booked/Count of nights in the time window	Yes	Aggregate only
% Nights >90% booked	Nights >90% booked/Count of nights in the time window	Yes	Aggregate only

Browse the metric table to see how calculations, data availability, and priority notes can turn dashboard needs into reviewable requirements. section 8.2.3

How Everyday Data Visualization covers it

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Everyday Data Visualization. The section links point to the parts of the book it draws on.