Author: Marcel

When I first began thinking about a Product Reference Model, I imagined it as something new. Over time, I have become less convinced that it is.

Perhaps I have simply been rediscovering ideas that Enterprise Architecture has explored for decades—but applying them at a different scale and with a different objective. Enterprise Architects rarely begin with source code. They think about relationships. Business capabilities support strategic objectives. Applications realize capabilities. Technology supports applications. Information flows between systems. The architecture is not merely a collection of artifacts. It is the set of relationships that makes those artifacts meaningful.

That sounds surprisingly familiar. My Product Reference Model has gradually evolved into something that also emphasizes relationships. Business objectives relate to capabilities. Capabilities relate to features. Features relate to requirements. Requirements relate to BDD scenarios. BDD scenarios relate to implementation. Implementation relates to architecture. Architecture relates to operational procedures. Assessments relate back to business outcomes. Rather than replacing individual artifacts, the Product Reference Model attempts to make those relationships explicit.

Perhaps that is exactly what Enterprise Architecture has always tried to achieve—only at enterprise scale. If that is true, then perhaps the Product Reference Model should not be viewed as a competing framework. Instead, it may simply be Enterprise Architecture viewed through the lens of a single product.

The emphasis is different. Enterprise Architecture asks:

How does this product fit within the enterprise?

The Product Reference Model asks:

How does every important aspect of this product fit together?

That distinction may appear subtle, but it changes the audience. Enterprise Architects often think across portfolios, organizations and technologies. Product Owners, developers, testers and operations engineers think about one product. The underlying architectural principles remain remarkably similar.

What also changes is the purpose. Traditional Enterprise Architecture often focuses on describing structure. The Product Reference Model attempts to preserve understanding.

Every relationship should ultimately help answer one of the questions future teams inevitably ask: Why does this capability exist? Why was this architectural decision made? Why is this business rule still here? Where is the evidence that this requirement is implemented? Which assessment concluded that this capability was fit for purpose? How do all these artifacts relate to one another?

Perhaps the Product Reference Model is therefore less concerned with documenting a product than with making the product understandable.

It becomes a navigational model rather than merely a descriptive one. That observation also changes my own perspective. Instead of inventing another framework, perhaps I should learn more from Enterprise Architecture. Architects have already spent decades thinking about repositories, viewpoints, traceability, relationships, stakeholders and governance.

The Product Reference Model may simply extend those principles into the daily life of a product team. Its contribution would not be another modeling language. Its contribution would be placing product understanding at the center.

Perhaps the Product Reference Model can therefore be described quite simply:

The Product Reference Model applies Enterprise Architecture principles to a single product, with particular emphasis on preserving product understanding throughout the product’s lifecycle.

If Enterprise Architecture asks how an enterprise remains coherent…

…perhaps the Product Reference Model asks how a product remains understandable.

When I first began thinking about a Product Reference Model, I assumed it would become another documentation framework.

As a Product Owner, that was not particularly attractive. Most Product Owners already spend their days balancing stakeholder expectations, refining the backlog, making priority decisions and answering questions from delivery teams. Another repository sounded like another responsibility.

But perhaps that is the wrong way to think about it. As Product Owners, we rarely inherit a greenfield product. We inherit decisions. Business rules. Architecture. Operational procedures. Quality concerns. Technical debt. And, perhaps most importantly, we inherit understanding—or the absence of it.

One of the most common questions a Product Owner asks is remarkably simple:

Why?

Why does this capability exist? Why do these customers receive different treatment? Why was this integration introduced? Why is this feature impossible to remove? Why was this architectural decision made? Why is this quality requirement so important?

Those answers rarely exist in one place. Some are hidden in Jira. Some in architecture documentation. Some in source code. Some in BDD scenarios. Some in assessment reports. Many remain only in the memories of people who happened to be there.

The Product Reference Model begins to make sense when it is no longer viewed as documentation. Instead, it becomes a map of product understanding. The Product Owner continues owning the backlog. Architects continue owning architecture. Developers continue owning source code. QA continues owning assessments and quality strategy. Operations continues owning operational knowledge.

Nothing changes. Except that all these pieces become visible to one another. The Product Owner is no longer expected to know everything. The Product Owner is expected to know where the understanding lives.

That changes the role in an important way. The backlog is no longer the product. It is merely one viewpoint of the product. The Product Reference Model allows the Product Owner to navigate the complete product landscape without becoming responsible for maintaining every artifact personally. Perhaps that is the real value.

The Product Owner becomes the steward of product understanding rather than merely the owner of the backlog.

Stewardship is different from ownership. Ownership often implies creating and maintaining artifacts. Stewardship means ensuring that future Product Owners inherit enough understanding to continue making good decisions.

The Product Reference Model therefore does not make the Product Owner responsible for more documentation. It makes the Product Owner responsible for ensuring that the important answers remain connected. Perhaps continuity is not ultimately about preserving software. Perhaps it is about ensuring that every new Product Owner can understand the product they inherit before deciding how it should evolve.

When I first imagined a Product Reference Model, I thought of it as another repository for product knowledge. I no longer think that is the right mental model.

A product already contains many repositories:

• The Product Owner maintains the backlog.
• Enterprise Architects maintain architecture models and Architecture Decision Records.
• Developers maintain source code.
• QA maintains assessments, test strategies and quality evidence.
• Operations maintains runbooks and operational procedures.
• Security teams maintain security documentation.

Every discipline already has tools and repositories that support its own work. The Product Reference Model should not replace them. Instead, it should index them. For every significant artifact, it should make clear:

• What is this artifact?
• Where can it be found?
• Who owns it?
• Why does it exist?
• How does it relate to the rest of the product?
• Who depends on it?
• Can everyone who needs it access it?

The detailed knowledge remains within the artifact itself. The Product Reference Model provides the shared navigation structure through which that knowledge can be discovered and understood.

This distinction is important. The Product Reference Model is not another documentation repository.

It is a lightweight knowledge architecture.

Perhaps Enterprise Architecture provides the right inspiration. Enterprise Architects have spent decades thinking about repositories, viewpoints, relationships, governance and traceability across an enterprise.

The Product Reference Model applies many of those same principles at the scale of a single product. Rather than describing how an enterprise fits together, it describes how one product remains understandable throughout its lifecycle.

Preserve knowledge where it belongs

The Product Reference Model should duplicate as little information as possible. Every artifact should preserve its own knowledge.

Requirements should explain the need behind them. Architecture Decision Records should preserve the trade-offs behind important decisions. BDD scenarios should preserve expected behavior. Operational procedures should explain the situations they were created for.

Whenever an artifact already contains sufficient rationale, the Product Reference Model simply links to it. Whenever the rationale is missing, the Product Reference Model becomes the place where that missing understanding is preserved.

The objective is therefore not more documentation. The objective is preserving understanding.

A federated knowledge model

The Product Reference Model also changes how I think about collaboration. Initially I believed that every stakeholder simply contributes information and everyone benefits.

That is true, but incomplete: every stakeholder already possesses unique understanding. The Product Owner understands business intent. Architects understand structural decisions. Developers understand implementation. QA understands quality and evidence. Operations understands behavior in production.

No single discipline possesses the complete understanding of the product. The Product Reference Model therefore creates a federated knowledge model.

Each stakeholder maintains ownership of their own artifacts while making that understanding discoverable to everyone else. Ownership remains distributed. Understanding becomes shared.The Product Owner does not become an architect. The architect does not become a tester. QA does not become an operations engineer. Every discipline remains responsible for its own expertise.

The Product Reference Model simply allows everyone to benefit from the expertise maintained by every other discipline.

Knowledge amplification

This also reveals the true value of the Product Reference Model. It does not create new knowledge. It amplifies the value of knowledge that already exists. Without the Product Reference Model, every discipline works largely within its own information space. With the Product Reference Model, each discipline gains visibility into the understanding maintained by all the others. The Product Owner better understands architectural constraints. The architect better understands business intent. QA better understands operational realities. Operations better understands the reasons behind design decisions. Developers better understand business priorities.

Collective understanding increases without requiring everyone to become an expert in every discipline. Its value is therefore not additive. It is multiplicative. Every additional viewpoint increases the value of all the others.

A practical implementation

The Product Reference Model could simply exist as a structured wiki or similar workspace. Rather than storing all product knowledge itself, it provides a consistent structure through which stakeholders expose the artifacts they already own. Each section contains references to relevant artifacts together with any rationale that is missing from those artifacts themselves. The Product Reference Model therefore becomes the product’s navigation layer rather than its documentation repository.

A simple definition

Perhaps the Product Reference Model can be summarized as follows:

The Product Reference Model is a federated knowledge architecture that indexes the significant artifacts of a product, preserves their relationships and rationale, and amplifies collective understanding by allowing every stakeholder to contribute the understanding they already possess while gaining access to the understanding maintained by every other stakeholder.

Design principles

• The Product Reference Model should contain as little duplicated information as possible.
• Knowledge remains with the artifact that owns it.
• Understanding is created by connecting those artifacts.
• Every significant artifact should preserve not only what it contains, but also why it exists.
• Every stakeholder contributes local understanding.
• Every stakeholder gains systemic understanding.

While watching the TV-show Pluribus, one particular idea stayed with me long after the story ended.

The series imagines that the accumulated knowledge of an individual could be transferred into something larger than themselves. In the story, this becomes a collective intelligence. Whether such a future is desirable is another discussion entirely.

What fascinated me was the question behind it: How much of what a person knows disappears when that person dies?

A few months before my mother passed away, we discussed a question that has remained with me ever since:

“How can I dump everything in my head into something external so that it will survive me?”

We were not talking about books or photographs. We were talking about understanding. The memories. The explanations. The reasons behind decisions. The connections between seemingly unrelated events. The answers to questions nobody had yet thought to ask.

Since then I have begun noticing the same pattern everywhere. When my parents died, many possessions remained, but not always the stories that explained why they mattered. In software, source code often survives while the business rationale disappears. Organizations inherit systems but lose the people who understood them.

Perhaps this is not really a software problem. Perhaps it is a human problem. Pluribus imagines one possible answer: preserve everything. Reality is unlikely to offer such a perfect solution.

Yet perhaps we do not need to preserve everything. Perhaps we simply need to become better at preserving the answers to the important questions while the people who know those answers are still able to tell them.

Artificial intelligence may eventually become the interface to that preserved understanding. But it cannot preserve what was never recorded. That responsibility still belongs to us.

As children, we ask endless questions. Why is the sky blue? Why do birds fly? Why do we have to go to school?

At some point, most of us stop asking. Perhaps we have built a sufficiently complete mental model of the world to function without constantly questioning it. We become occupied with doing rather than understanding.

I have noticed something else. The real problem is not that people stop asking. It is that we stop preserving the answers.

I experienced this personally after both my parents passed away. They left behind many possessions, but not always the stories that explained why those possessions mattered. Some objects remained meaningful because I already knew their history. Others became impossible to interpret. Without their explanation, they became little more than objects.

I have seen exactly the same phenomenon in software. In one company, existing business process descriptions were discarded because they were considered unnecessary. Later, during acceptance testing, we had to reconstruct those very processes from scratch because nobody could confidently explain how the business was supposed to work.

The software survived. The answers did not. That experience made me realise that documentation is often misunderstood.

We tend to think documentation exists to describe systems. Perhaps its deeper purpose is to preserve the answers to the important questions, like:

• Why does this product exist?
• Why was this architectural decision made?
• Why does this business rule exist?
• Why is this object important?

The answers may be preserved in different places. BDD scenarios preserve answers about expected behavior. Architecture Decision Records preserve answers about technical choices. Business documentation preserves answers about organizational intent. Even personal stories preserve answers about why certain possessions became meaningful.

No single document can answer every question. What matters is that the answers survive somewhere. Increasingly I find myself thinking that good stewardship—whether of software, products or personal history—is not about preserving artifacts. It is about preserving the understanding that makes those artifacts meaningful.

Perhaps every generation inherits objects. Our responsibility is to ensure they also inherit the answers.