This note is deliberately speculative. It takes a pattern that emerged through work on Product Continuity and organizational capabilities and asks whether that pattern might point toward something more general. I do not know whether the generalization holds, and I am certainly not proposing a new universal definition of management.
But the pattern has become interesting enough to record.
Starting With Product Continuity
None of this began as an attempt to understand management.
It began with Product Continuity and a relatively practical problem: products often live much longer than the organizational understanding that created them. People leave, responsibilities move, decisions accumulate and circumstances change. The product continues to develop, but the understanding connecting its purpose, design, operation and evolution can become increasingly fragmented.
That led to the idea of a Product Reference Model: an explicit representation of the significant understanding needed to develop and assess the product over time.
Initially, that seemed primarily like a continuity mechanism. If important intent, expectations, assumptions, boundaries and rationale could be made explicit, future development would not have to depend entirely on organizational memory.
But once the reference existed conceptually, it became difficult to limit its role to preservation.
The same understanding that describes what the product is intended to accomplish can guide its development. It can also provide the reference against which the realized product is assessed. Assessment produces evidence and judgment, which in turn create learning. That learning may change not only the product but our understanding of what the product should become.
The result is a continuing cycle rather than a static document:
Reference → Development → Realization → Assessment → Learning → revised Reference
And because the cycle continues as people, circumstances and products change, someone must preserve its coherence over time.
That is where Product Continuity began to look remarkably like something we already have: Product Management.
Looking Again at Product Management
Product Management is already concerned with many of these things. It maintains product direction, connects products to customer and business needs, guides priorities and development, considers evidence from the market and the realized product, and continues doing so as the product evolves.
Product Managers do not personally perform all the activities involved. They are not necessarily the architects, developers, testers, designers, analysts or operators. Specialist responsibilities remain distributed.
What Product Management provides is continuity around the product itself.
Seen through the lens of Product Continuity, those familiar responsibilities appear to form a recognizable architecture. There is some understanding of what the product should accomplish. The product is deliberately developed against that understanding. The resulting product and its outcomes are continually observed and judged. Evidence produces learning. That learning influences subsequent direction and development. And throughout this process, Product Management provides continuing stewardship of the subject while specialist disciplines contribute to it.
This does not redefine Product Management. If anything, it offers a possible explanation for why responsibilities that may otherwise appear quite different belong together.
Then the Same Pattern Appeared Somewhere Else
The interesting part came when thinking about organizational capabilities.
A capability also needs some explicit understanding of what organizational ability is required and why. That can be represented through a Capability Reference Model. The capability can be assessed against that reference to understand the organizational ability that actually exists. It can be deliberately developed where change is needed. Assessment and experience create learning, which may change both the realized capability and our understanding of what capability is required. And because improvement projects eventually end while the organizational capability continues, somebody may need to preserve its development and coherence over time.
That led to the speculative idea of Capability Management. At that point, the similarity became difficult to ignore. The subject had changed. The architecture had not.
Is the Product Special?
That raises a question I had not originally intended to ask. What if Product Management and Capability Management are not merely two unrelated disciplines that happen to contain similar activities? What if they are two specializations of a more general pattern? For lack of a better term, I will call that pattern Subject Management.
A subject, in this sense, is simply whatever we are deliberately trying to preserve, understand, develop and assess over time. A product can be such a subject. An organizational capability can be one. A portfolio may perhaps be another.
Subject Management could then be tentatively understood as the continuing stewardship of such a subject through an explicit reference, recurring assessment, deliberate development and learning.
The reference describes the significant understanding against which development and judgment can take place. Development deliberately changes the subject. Assessment establishes what has actually been realized and how well it satisfies the reference. Learning feeds the resulting understanding back into future decisions. Stewardship preserves coherence across that cycle as circumstances change.
This is not necessarily a sequence of management activities. Stewardship may be better understood as the responsibility surrounding the whole cycle.
Where the Generalization Stops
There is an obvious danger in taking this too far. Management is an enormous concept. Organizations manage people, money, resources, suppliers, risks, operations, conflicts and countless other things. I have no basis for claiming that all of management can be reduced to reference models, assessment, development and learning.
Nor does this idea imply that established disciplines such as Product Management are merely implementations of a new abstract theory.
The observation is much narrower.
Some subjects persist over time while both the subjects themselves and the circumstances around them change. Where organizations deliberately care about the continued suitability of such a subject, a recurring pattern appears plausible: maintain an explicit understanding of what matters, assess reality against that understanding, deliberately develop the subject, learn from the resulting evidence and preserve continuity across the whole process.
I have seen enough of that pattern in products and capabilities to wonder whether it is more general. I have not seen enough to conclude that it is. That distinction matters.
An Abstraction That Emerged Afterwards
Perhaps the most important reason to record this idea is the way it appeared. I did not begin by defining Subject Management and then search for examples that fitted it. I began with Product Continuity.
Product Continuity led toward explicit Product References. Those references turned out to support both development and assessment. Assessment introduced evidence and learning. The continuing cycle created a need for stewardship. Only then did the resulting structure begin to resemble an underlying architecture of Product Management.
When essentially the same pattern appeared while thinking about organizational capabilities, the possibility of a more general abstraction emerged. The abstraction therefore came afterwards. Whether it survives further examination is another question.
It may turn out that products and capabilities are similar in ways that make the pattern appear more general than it really is. Other subjects may expose important missing elements. Existing management theory may already describe the same pattern using better concepts. Or the idea may prove useful only within the narrower theory of Continuity from which it emerged.
Any of those outcomes would be useful.
For now, the observation is simply this:
Product Management appears to provide continuing stewardship of a product through reference, development, assessment and learning. Capability Management may require a remarkably similar architecture.
If that similarity is not accidental, perhaps the next question is no longer only what Product Management or Capability Management means. Perhaps it is:
What kind of subject requires management in the first place?
Leave a Reply