What you license · 02
The PDLC
The Product Development Lifecycle is the written way of working: the practices, agreements, roles, and decision rights that govern how an idea becomes consumable value, authored so that people and Notion’s AI answer every “how do we do this here” from the same pages.
It is a product development lifecycle, and the distinction from a software development lifecycle is the point. An SDLC covers how software gets built, from a requirement arriving to code shipping. The PDLC covers the whole investment: how direction becomes investable work, how work is chosen and committed at honest capacity, how it is built through phases that end on evidence, how it becomes consumable, and how the result is confirmed. The craft of designing, building, and testing stays with the teams. What the PDLC adds is everything around that craft which most organizations leave to interpretation, and that is where product and value delivery are won or lost.
One end-to-end flow
From strategic direction to value realized, every practice placed on it.
The flow has three zones with different paces. The organizational zone sets direction annually or semi-annually. The strategic side of flow, running on quarterly planning cycles with continuous discovery, translates that direction into investable work. The tactical side, running on the iteration cadence, turns committed work into consumable value. The intake queue is the boundary between “what should we build and why” and “how do we build it and when does it ship,” and nothing crosses it vague.
Ten attributes
What defines the PDLC.
- One end-to-end flow. A single journey from strategic intent through the strategic side, across the intake queue, through the tactical side, to consumed value and measured results.
- Value-first at every level. Objectives, initiatives, increments, features, and stories each carry a measurable outcome and defined acceptance criteria.
- Living agreements. The Definitions of Ready and Done at value stream and team level, the Definition of Value, and the Threshold Register are versioned, dated, and ratified.
- Named accountability. Every practice names who is accountable and who supports, and every decision has a named owner under a published decision-rights table.
- Preconditions before practices. Each page says when it applies and what must already be true, so a practice is never applied to a situation it was not built for.
- Phases with evidence. Inception, Construction, and Transition end on milestones that are demonstrated, not declared.
- Familiar practices, placed. Sprints, stand-ups, reviews, retrospectives, and big-room planning keep their place; the PDLC says where each one lives in the flow and what it feeds.
- Lean governance. Decisions sit where the information lives, guardrails are agreed in advance, status is a lookup rather than a meeting.
- Controlled guidance. The pages are a controlled document set, registered, owned, reviewed, and changed only through Guidance Change Control.
- Written for two readers. Every page carries a one-sentence definition, preconditions, the questions it answers, and its key terms, so a person can read it and Notion’s AI can answer from it in your vocabulary.
Phases and milestones
Three phases, each ending on evidence rather than ceremony.
Inception is the short, upfront work to be ready to build: features decomposed into stories, stories sized, the backlog ordered to confront risk first, subject matter experts engaged and dependencies surfaced, the team’s agreements confirmed, and the implementation plan made through Value Flow Planning. It ends at Stakeholder Vision, when the people who will consume the increment and the people who will build it agree on what is being built and why. Construction builds the increment across short iterations, passing Proven Architecture when the approach has been demonstrated to hold under real conditions and ending at Increment Acceptance Criteria Met, when the criteria written during discovery are satisfied by working software. Transition makes the value consumable and confirms it landed, passing Value Consumable and ending at Delighted Stakeholders, when the outcomes are armed for measurement and the accountable business owner confirms the result. Reaching Done at the value stream level starts the measurement clock, and the verdicts that follow feed the strategic side’s next ordering, which is what makes the flow a loop rather than a pipeline.
From PRD to VRD
Your PRD is not wasted. It is the first third of a Value Requirements Document.
A Product Requirements Document is requirements-first: it begins with what one product should do, and the reason lives in a background section. The increment page in the Delivery OS is value-first, and it is in effect your Value Requirements Document. It begins with the measurable outcome, written before any feature is named, with its baseline, target, data source, and the window in which the signal becomes readable. The features are whatever it takes to reach that outcome, and its acceptance criteria are written at the increment level, so they describe the observable result rather than any one product’s behavior.
The order matters because it changes what gets cut. When scope pressure arrives, a requirements-first document loses the requirements that are hardest to build. A value-first increment loses the features that contribute least to the outcome and keeps the ones the outcome cannot do without, even when they belong to a product that was not the original focus.
The scope changes too. A PRD describes one product. A Complicated or Complex increment routinely spans two or more products and two or more teams, and that is deliberate: it is decided, planned, and delivered as one investment, so its parts land together and its value arrives once. A set of PRDs for the same change, each approved and scheduled on its own, lands in pieces, and the outcome waits for the last piece while the finished ones accrue cost of delay.
What happens to the PRD you already wrote is that it becomes the input. The Discovery Workflow accepts an existing PRD or project brief and mines it: the problem statement, the users, the feature thinking, and the constraints become the increment’s substance. Discovery adds the outcome sentence, the increment-level acceptance criteria, the scope widened to every product the result needs, the dependency map, and the complexity class. It removes nothing. The Increment Discovery skill runs this evolution as a facilitated session.
Practices, roles, and governance
Roughly ninety-five pages, in families.
The agreements family holds the Definitions of Ready and Done at both altitudes, the Definition of Value, and the Threshold Register, with the retrospectives that revise them. The requirements family holds the hierarchy from objective to story, the three increment types (customer-facing value increments, technical value increments, and innovation increments with their hypotheses and timeboxes), right-sizing and splitting, acceptance criteria in the Gherkin style at increment and story level, measurable outcomes, and the workflows that carry each level from Notion into Linear. The flow family holds the strategic and tactical side pages, the Investment Loop, the intake queue, the portfolio backlog and its refinement, product roadmaps, Value Delivery Planning, investment and capacity allocation, and the phase and milestone pages. The metrics family holds portfolio and team flow metrics and active portfolio monitoring against the register.
Roles are defined for the delivery side and the business side alike: the Portfolio Manager, Product Manager, Engineering Manager, Delivery Manager, Tech Lead, Quality Owner, and Team Member each have a page stating what they are accountable for and what they support, and the business roles, led by the Accountable Business Owner named at discovery for every increment with a business outcome, close the loop between where value is funded and where it is confirmed. Governance is lean by design: Lean Governance sets the decision-rights table, Requirements Approval and Change and Requirements Change Control govern how scope moves once committed, Classes of Service and the Expedite Path govern how urgent work enters without breaking flow for everyone else, and Guidance Change Control governs the pages themselves.
Written for two readers
Ask the practice question where the work is happening.
Every guidance page opens with the practice in one sentence and its preconditions, defines its terms in place, names its roles, closes with the questions it answers and a glossary of key terms, and carries keyword and alias lines so Notion’s AI retrieves it accurately. The practical effect is that anyone in the delivery organization can ask a plain question where they are working, whether an increment is ready for the intake queue, how to order a product’s backlog, what Transition needs before Value Consumable, and the answer comes back grounded in the relevant page and cited to it, in your vocabulary. Questions about numbers go to the Metrics Registry on purpose: the PDLC says how you work, the registry says how you measure it, and the Delivery OS is where both are operated. There is no custom agent to build for either.
See it running
The guidance answering a question inside the BigBank workspace.
Is this increment ready?
A plain question asked in Notion, answered from the Definition of Ready page with the citation attached, then the increment page itself checked against it.
What the license contains
The estate, ready to be yours.
The complete guidance estate with its database properties and the keyword and alias values that make it answerable by Notion AI; the introductions; the Glossary of Terms and Cross-Map, which maps the methodology’s vocabulary to the terms your people already know; the nano pages that teach a practice in two minutes at the moment it is needed; the strategic and tactical practice cards; and Guidance Change Control, so the estate stays a controlled document set as you tailor it. How the tiers are shaped.