Blog

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?

“Every memorable product begins with someone who refuses to be reasonable.”

The Ordinary Meeting

The conference room at Victorinox was full. Marketing wanted another Swiss sports watch. Sales wanted something familiar. Finance wanted something inexpensive to manufacture. Engineering was quietly drawing on a notepad.

His name was Hans.

The Inspiration

Nobody knows exactly what happened. Some say Hans was walking through the factory. Some say he was changing the wheel on his car. Others insist he was tightening a bolt on a production machine.

Whatever the truth, he stopped. He looked at a large hexagonal wheel nut. Then he looked at a watch. Then back at the wheel nut. He smiled.

The Proposal

Hans placed a socket wrench on the meeting table.

“I think,” he said, “our watch should look as if it was assembled with one of these.”

Silence. Marketing blinked. Someone from Finance quietly reached for the coffee. Engineering leaned forward.

The First Prototype

The bezel looked absurd. Far too large. Far too industrial. Far too unapologetic.

Someone suggested making it smaller. Hans declined.

Someone suggested rounding the corners. Hans declined again.

Someone asked whether customers would understand it. Hans asked a different question.

“Will they remember it?”

The Accident

The I.N.O.X. watch was launched. People disagreed. Some loved it. Some hated it.Nobody confused it with anything else.

Years later, nobody remembers the movement reference. Nobody remembers the case diameter. Nobody remembers the exact weight.

They remember:

“The one that looks like a wheel nut.”

The Promotion

Success changes people. Hans was promoted. He now attended board meetings. The CEO gently explained that perhaps not every customer wanted to wear heavy machinery on the wrist.

Hans listened. He nodded. Then he quietly inverted the hexagon. The Concept One was born.

The engineers smiled. Marketing sighed with relief. Hans considered it a compromise.

The Lesson

Most products are improved by optimization. Some products become memorable because somebody refuses to optimize away the original idea.

Customers rarely remember specifications. They do remember conviction.

Reflection

Maybe every organization needs a Hans. Not because every idea is good. But because memorable products seldom emerge from committees trying to avoid mistakes.

They emerge when someone has a point of view strong enough to survive the committee. The difficult part is recognizing which ideas deserve protecting.

Because today’s “strange” idea may become tomorrow’s icon.

Postscript

These watch models exist. There may never have been a Hans. There was almost certainly, however, someone who looked at a conventional watch bezel and asked:

“Why does it have to be round?”

That question mattered far more than the answer.

Recently, while looking across the increasingly varied subjects of these Practice Notes, I noticed something that I had not consciously set out to create. The notes range across quality management, assessment, Product Continuity, reference models, watches, clothing, model trains and whatever else happens to make me wonder about something. At first glance, there is not necessarily much connecting those subjects.

Yet the way I approach them seems remarkably consistent. The subjects change. The method does not.

I seem to keep doing three things:

Reveal the Why → Reveal the Inconsistencies → Reveal the Path

I am not sure I ever deliberately chose this as a method. It may simply be how I make sense of things.

Reveal the Why

It usually begins with Why. Not necessarily the first Why, because the first answer often explains only the immediate situation. That answer tends to invite another question. Why do we perform this activity? Because we need this outcome. Why do we need that outcome? Because something else depends upon it. Why does that matter?

Following the chain gradually moves the discussion away from the visible activity and toward the purpose it is intended to serve.

This is where apparently simple questions can become unexpectedly interesting. A Definition of Done stops being a checklist and becomes a mechanism for establishing confidence in completion. Testing stops being merely an activity performed by testers and starts looking like one way of producing evidence for assessment. A watch stops being something that must fit a conventional category and becomes something that must be suitable for the situations in which its owner actually intends to wear it.

The What remains important, but it becomes easier to understand once the Why beneath it is visible.

Reveal the Inconsistencies

Something interesting tends to happen once that underlying purpose becomes clearer: inconsistencies become easier to see.

A practice may still exist even though it no longer performs the function for which it was introduced. An assessment may reward compliance with a process without establishing whether the organization possesses the capability that process was supposed to create. A transformation may successfully implement a framework while failing to develop the organizational abilities that motivated the transformation in the first place. The visible What and the underlying Why have drifted apart.

Perhaps this is why I keep finding inconsistencies in apparently unrelated subjects. I am not necessarily looking for mistakes. I am comparing what something has become with what it appears to be trying to accomplish.

That is a useful distinction. Something can be internally consistent and still be poorly aligned with its purpose. A process may operate exactly as designed. Every required artifact may exist. Every ceremony may take place. Everyone may be following the rules. And yet the original problem may remain unsolved.

Once the Why is visible, that kind of inconsistency becomes much harder to overlook.

Reveal the Path

The final step is less certain. Understanding the Why and identifying the inconsistency does not automatically reveal a solution. There may be several possible solutions. Important evidence may be missing. Constraints may prevent the most obvious change. Sometimes the honest conclusion is simply that we do not yet know enough.

But the direction often becomes clearer. Instead of asking how to optimize the existing What, we can ask how to bring it into better alignment with the Why.

That is a subtly different form of improvement. If a Definition of Done has become a ritual, the question is not necessarily how to improve the checklist. It is how confidence in completion should be established.

If a process assessment rewards the existence of prescribed practices rather than organizational ability, the question is not necessarily how to improve the process model. It is how that organizational ability should be understood and assessed.

If a transformation has become an exercise in implementing a framework, the question is not necessarily how to implement the framework more faithfully. It is which organizational capabilities need to change and which interventions might help them change.

The path does not emerge because the answer was hidden inside the Why all along. It emerges because understanding the Why gives us a more meaningful direction against which possible changes can be judged.

The Recurring Method

Looking back across the Practice Notes, I now suspect that this pattern has been present for much longer than I realized.

Much of my work around capability assessment begins by asking what organizational ability a process was intended to create. The work on reference models asks what a subject is supposed to accomplish before judging its current realization. Product Continuity keeps returning to the reasoning that explains why products became what they are.

Even the apparently less serious subjects seem to follow the same pattern. Watches, clothing and model trains have repeatedly turned into ways of exploring purpose, assumptions, boundaries and the strange consequences that appear when those things are forgotten.

Perhaps those subjects were never as unrelated as they appeared. They were simply different places in which to ask the same kind of questions.

Reflection

I have used Method in the Madness as a working name for the possibility that recurring patterns might eventually be discovered across this growing body of notes.

I had imagined that as something to do later: preserve enough observations, look back across them and see whether a coherent method of thinking emerges. Perhaps that process has already started.

One pattern, at least, seems increasingly difficult to miss:

Reveal the Why.
 Reveal the Inconsistencies.
 Reveal the Path.

It is not a universal method, and it does not guarantee an answer. Sometimes the path remains uncertain. Sometimes the evidence runs out. Sometimes understanding the Why merely reveals how much we still do not understand.

But it does seem to describe something about how I approach problems. And perhaps that is exactly what Method in the Madness was supposed to reveal.

Curiosity has probably driven more of this blog than anything else. I like asking why. Why does this process exist? Why was this decision made? Why does this product behave this way? Why did an organization choose one path rather than another?

Quite often, asking Why is rewarding. One answer reveals another question, and following the chain can expose assumptions, explain strange decisions, reveal inconsistencies or lead somewhere entirely unexpected. Much of what I find interesting begins this way.

For a long time, I think I also carried an implicit assumption: if I kept asking long enough and searched hard enough, eventually I would find the answer.

I am less certain of that now.

When the Evidence Runs Out

Some questions do not resist answering because we have not investigated them thoroughly enough. Sometimes the available evidence simply runs out. The people who knew may be gone. The decision may never have been recorded. The surviving sources may contradict one another. Several explanations may remain plausible without any way to establish which one was actually true.

There is always the temptation to continue. Perhaps one more source will resolve it. Perhaps another interpretation will make everything fit. Perhaps if we reason carefully enough, the missing answer can still be reconstructed. Sometimes it can.

But there comes a point where further reasoning stops producing knowledge and starts producing speculation. Recognizing that boundary is difficult precisely because speculation can be convincing. A plausible explanation can become a likely explanation, and a likely explanation can gradually acquire the status of fact. The more effort we have invested in finding an answer, the harder it may become to accept that we have not found one.

Yet there is an important difference between saying that there is no answer and saying that I cannot justify an answer. The first makes a claim about reality. The second acknowledges the limits of what I know. Often, the second is all the evidence allows.

The Discipline of Curiosity

Curiosity is valuable because it refuses to accept unexplained things too easily. It keeps asking when the first answer is superficial. It challenges assumptions that have become invisible through familiarity. It encourages us to look behind the artifact, process or decision and understand what it rests upon.

But perhaps rigorous curiosity also requires knowing when to stop. If every question must eventually produce an answer, then uncertainty becomes something that has to be eliminated. Once the evidence can no longer do that for us, we become tempted to eliminate it ourselves.

That is where curiosity can undermine the very understanding it was supposed to create. The objective was never merely to have an answer. It was to have an answer we have sufficient reason to believe. Sometimes those are not the same thing.

Becoming Comfortable With Unknown

I have therefore become increasingly comfortable with I don’t know as a legitimate conclusion. That does not mean the investigation failed. Establishing that something is genuinely unknown can itself be useful. It tells us where justified understanding ends. It prevents an inference from quietly becoming historical fact. It leaves uncertainty visible instead of hiding it behind a convincing explanation.

Nor does I don’t know mean nobody will ever know. New evidence may appear. Someone may remember something. Another source may surface. A different line of investigation may eventually resolve the question.

Stopping simply means recognizing that, with the evidence currently available, I have reached the limit of what I can honestly justify. The question can remain open without requiring me to fill the space where its answer should be.

Reflection

I still ask why. Probably too often. I still enjoy following questions further than is strictly necessary, particularly when one Why unexpectedly reveals another. I do not think that will change.

What has changed is my expectation of where that journey must end. I no longer believe that every Why owes me an answer. Sometimes the evidence leads to a confident conclusion. Sometimes it supports only a hypothesis. And sometimes, after all the questioning and searching, the most accurate conclusion available is simply:

I don’t know.

Knowing when to ask Why matters.

Knowing when to stop may matter just as much.

Over the years, I have had the opportunity to return to several organizations after long periods away. In three cases, the gap was around ten years. These were large, established organizations. They had existed long before I first worked with them and would presumably continue to exist long after I left. When I returned, I therefore expected a certain degree of familiarity. I was, after all, returning to the same organization.

And in some ways I was. The company name was the same. A few familiar people were still there. Some things were immediately recognizable. But the organization itself felt remarkably different.

Ten Years of Ordinary Change

There was nothing mysterious about this. People had left and new people had arrived. Leadership had changed. Teams had been reorganized. Products and systems had evolved. Priorities had shifted. New initiatives had appeared and old ones had disappeared. None of this required a dramatic transformation. It was simply what happens when an organization continues operating for ten years.

From inside the organization, those changes probably happened gradually. One person left. Another was hired. A team was reorganized. A system changed. A new manager arrived. A different priority emerged. Each change became part of normal organizational life.

Returning after ten years was different because I encountered the accumulated result all at once. The company was still there. The organization I remembered largely was not.

The Same Company?

This made me wonder what we actually mean when we talk about the same company. Institutionally, there is little difficulty. The company has a name, a history and a legal identity that persist over time. We can talk quite comfortably about a company that has existed for fifty, a hundred or even several hundred years.

But the organization that people actually experience is much less permanent. Imagine taking a snapshot of an organization today: its people, leadership, teams, products, systems, priorities, responsibilities and ways of working.

Then take another snapshot ten years later. Even in a very large and relatively slow-moving organization, how much would still be the same? Probably much less than the continued use of the same company name suggests.

An Organizational Generation

There is another way of looking at those ten years. When we talk about generations of people, we usually think in terms of several decades. Thirty years is a reasonable approximation.

An organizational generation may be considerably shorter. Ten years can be enough for much of the leadership to change, large numbers of employees to leave, new people to arrive, organizational structures to evolve, systems to change and priorities to shift.

In that sense, returning after ten years may mean returning not merely to an older version of the organization, but to another organizational generation. The interesting part is that there is no clear boundary between those generations.

One organizational generation does not leave on Friday so that another can arrive on Monday. People overlap. Systems span generations. New structures inherit parts of old structures. Some practices continue while others disappear. New people learn from people who themselves learned from an earlier generation.

The replacement is gradual. There is no handover ceremony between one organization and the next. The company simply continues.

The Ship of Theseus at Work

There is something of the Ship of Theseus in this. If the parts of a ship are gradually replaced until none of the original parts remain, in what sense is it still the same ship?

Organizations make the question even more complicated because they replace far more than their physical parts. They replace people, structures, technologies, products, priorities and ways of working, while continuing to operate under the same institutional identity.

A company that has existed for a hundred years may therefore have passed through many organizational generations.

And yet we still experience continuity. Customers continue dealing with the company. Employees inherit responsibilities from people who came before them. Products continue developing. Decisions made by one generation affect another. Commitments survive the people who originally made them. Somehow, the organization crosses those generational boundaries.

Reflection

Returning after ten years made something visible that is much harder to notice while working inside an organization. Organizations change continuously, and the cumulative change can be enormous.

The company I returned to was unquestionably the same company. Yet in many practical respects, it was a different organization from the one I had left. Perhaps that is entirely normal. Perhaps even the largest and slowest-moving organizations have generations measured not in decades, but in years.

That leaves me with a question rather than a conclusion. If an organization may exist for fifty, a hundred or several hundred years, while an organizational generation may last less than ten, how is continuity preserved across those generations?

I do not think returning to the same organizations answered that question. It simply made the question much harder to ignore.