Introducing PRL — Blue Aspirations' Product Readiness Level Framework

The Problem with "Almost Ready"

In product development, the most expensive word is "almost." A product that is almost ready for market, almost validated, or almost compliant consumes resources without generating returns. Worse, different teams or companies often use different vocabulary to describe the same state of readiness, creating friction between engineering, commercial, and operations.

At Blue Aspirations, we have addressed this by formalizing PRL—our Product Readiness Level framework. It is now the single standard applied to every product in our portfolio, and we are committed to operating it with full transparency.

What PRL Is

PRL describes where a product sits in its maturity lifecycle. The lifecycle runs from PRL-0 (Idea) through PRL-1 (Demo), PRL-2 (Trial), PRL-3 (Pre-commercial), PRL-4 (Commercial), and PRL-5 (Excellence). Two exit states exist: Retired (R) for natural end-of-life, and Terminated (T) for products that fail to meet gates and will not be revived.

PRL is not a project schedule; it is a state of readiness. A product at PRL-2 has demonstrated something fundamentally different from a product at PRL-4, and the framework makes that difference explicit and verifiable.

How It Works

Each level has defined entry conditions. For example, entering PRL-1 requires commercial and technical feasibility validation, plus risk and resource assessments. Moving from PRL-1 to PRL-2 requires a working demo, at least one signed trial intent, and clear risk ownership. PRL-3 demands seed-user validation, data-sheet approval, and the absence of any fatal risks.

Critically, every level specifies activities with RACI accountability. Roles are not decorative; they are assigned as Responsible, Accountable, Consulted, or Informed. When a product enters PRL-2, the PO executes and owns seed-customer trial management, BD executes, and Quality and HSE consult. Everyone knows their lane.

The Definition of Done is defined by the Product Owner per product upon entering each level. Upgrade reviews validate completion of the previous stage’s DoD. This prevents products from drifting forward on momentum rather than evidence.

Governance and Execution

PRL governance operates through our PRL management platform. Execution, however, remains in Agile management systems like Jira. This separation is intentional: strategic oversight and Agile delivery should be connected but not conflated. The framework manages lifecycle state; the team manages project velocity.

Quality and HSE can stop a project at key stages. A product cannot pass PRL-2 without a design qualification review. This makes compliance part of the process, not just a final check.

Transparency as Policy

We are applying PRL to every product in our portfolio without exception. More importantly, we will publish the PRL status for each product. This means customers, partners, and internal stakeholders can see exactly where a product stands. No product will be marketed as "generally available" while sitting at PRL-2. No roadmap will claim PRL-4 maturity without the customer base and operational metrics to support it.

This transparency is not merely ethical; it is operational. It forces discipline. When a product's level is visible, there is no incentive to inflate readiness. It aligns sales, delivery, and support teams around a shared, verifiable truth.This also serves as an external trust mechanism for customers and partners.

Why this Matters

For complex products in international markets, the gap between "built" and "ready" is where most value is lost. PRL closes that gap by making readiness visibleverifiable, and valuable. It ensures that capital, talent, and customer trust are deployed against products that have actually earned them.

We are sharing this framework because we believe product maturity should not be a black box to customers. If you are grappling with similar challenges, the structure is straightforward: define the levels, assign the accountability, verify the evidence, publish the result, and pursue continuous technical and operational excellence.

Next
Next

Fake Constants and Fake Variables: Adding Dynamics to POTS