01ALIGNMENT
Time is not a development system
A deadline can constrain the work. It cannot create the alignment required to develop a product.
READ NOTE · 6 MINSYSTEMS FOR REAL PRODUCT DEVELOPMENT
Exploring how
good products
come to exist.
Notes from inside product development—exploring how risk, alignment, evidence, decisions, and people shape what eventually becomes a product.
AN INDEPENDENT PUBLICATION
ALIGNMENTRISKQUALITY
— Information┄ Decision□ Control
GOOD PRODUCTS SHOULDN’T TAKE FOREVER.
But complexity doesn’t disappear
because the timeline says so.
Speed comes from clarity, evidence, and flow—not from compressing every activity until the development plan becomes fiction.
FIELD NOTES / 001—003
Thinking from inside
the work.
02EVIDENCE
When Marketing makes a promise, but QARA says no
When a promise reaches the market before the evidence exists, QARA becomes the problem. Or does it?
READ NOTE · 7 MIN03EXECUTION
Why did you believe this change was acceptable?
Development systems fail when the formal process and the actual work become two different things.
READ NOTE · 5 MINTHE WEEKLY REVIEW
FIVE MINUTES · ONE OPEN QUESTION001COMPOSITE CASE5 MIN
Everyone saw the signal.
Why did the system keep moving?
A recurring problem was investigated again and again. Each event was explainable on its own. Together, they were trying to say something else.
If everyone could see the signal, what condition in the system made continuing appear more reasonable than stopping?Read the review View all reviews
OPERATING PRINCIPLES
A product is the output.
The system is the leverage.
Four propositions that guide how PDSL examines development work.
0104
Value in every iteration
An iteration should reduce uncertainty, close a decision, or produce evidence. Activity alone is not progress.
→02Risk shapes the work
Risk is not paperwork added after design. It determines what must be learned, controlled, and proven.
→03Alignment is engineered
Alignment does not happen because people attend the same meetings. It must be deliberately questioned, tested, and rebuilt throughout development.
→Quality emerges from the systemIN DEVELOPMENT
Quality is not added at the end of development. It emerges from the way the organization questions, decides, and responds to evidence.
WHY THIS LAB EXISTS
Most product-development advice is written from outside the system.
Product Development System Labs is an independent publication written from inside the work: where teams must translate uncertainty into decisions, build defensible evidence, align across functions, and deliver a product worth releasing.
PDSL draws from regulated product development, where risk, evidence, decisions, and traceability cannot remain implicit. The principles explored here extend beyond medical devices to the development of any product.
We examine the machinery behind the milestone—the choices, controls, interfaces, and habits that turn development work into reliable value.
Founded and edited by Rodolfo Velasco.
WHEN THE SYSTEM NEEDS TO BE EXAMINED FROM WITHIN
Some problems cannot be understood from the process map alone.
They require examining how decisions are made, how risk shapes the work, where alignment breaks down, and whether the system is producing the evidence the organization believes it has.
PDSL works with product-development teams to investigate these conditions, clarify the decisions in front of them, and strengthen the system through which the work gets done.
Work with PDSLPRODUCT DEVELOPMENT SYSTEM LABS