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.
Leave a Reply