Notion Fundamentals | Building a product roadmap

A product roadmap in Notion becomes far more useful when it’s built as a database: each roadmap item lives as a row with structured properties, and the same underlying data can be rearranged into multiple views for different teams and planning needs. The core idea is simple—treat every roadmap item (bug, task, epic) as an object with fields like status, deadline, and owner—then let sorting, filtering, templates, and advanced database features turn that structure into day-to-day workflow.

The session starts with a quick history of databases to ground why this object-and-properties model matters. Relational database thinking traces back to the 1970s, credited to IBM computer scientist Edgar F. Codd, and it frames data as objects with associated attributes. In Notion, that translates directly into a table where each row represents one roadmap item and each column represents a property tied to that item. Instead of scattering details across separate documents, the roadmap row becomes the central place where the team can keep names, tags, and additional information—and then open each row as its own page for richer context.

From there, the walkthrough builds a “Product roadmap” workspace page and turns it into a full-page table. Rows begin with sample items, then the table grows properties that make the roadmap actionable: a single-select “status” (for example, Not started, In progress), a “deadline” date property (including optional end dates for ranges), and a “person responsible” field. It also adds auto-calculated metadata like “created by” and “created time,” which become useful once the dataset expands. With those properties in place, Notion’s sorting and filtering work by property—such as sorting by deadline to surface the most urgent work, or filtering to show only bugs whose “type” contains “bug.”

Consistency is handled through database templates. Instead of asking people to guess what information belongs in every new item, templates pre-fill the right sections. A “new bug” template can require fields like description, steps to reproduce, and recommendations, while a “new task” template can include more design-heavy inputs such as a problem statement, Figma mockups, and proposed work. When someone opens a row using the template, the structure arrives with it.

The roadmap’s flexibility comes from views. The same dataset powers a board view grouped by status or owner (a Jira-like kanban), a timeline view for scheduling with drag-and-drop planning, a calendar view for date-based review, plus simpler list and detail-rich gallery options. This avoids duplicating data across multiple tools or pages.

Finally, the session introduces advanced database “superpowers.” Relations connect the roadmap to another database—here, meeting notes—so each roadmap item can pull in related meetings. Roll-ups then analyze related data, such as calculating the earliest meeting date for a project to flag stalled work. Formulas provide automation and logic; the demo builds an “is overdue?” formula using an if statement comparing “now” to the deadline, returning overdue vs. not overdue. The result is a roadmap that’s not just a static plan, but a structured system that supports planning, reporting, and management signals across the organization.