Introduction
johnpcutler.github.io · article · 2026-04-10 source ↗ Reader 🖥️
Organizations suffer because the words, categories, and representations they use to describe product development work systematically flatten, filter, and distort reality as information moves across levels -- and the solution requires treating operational language as information architecture and ontology design rather than simple labeling.
practical · guide introduction / manifesto — Introduction to a practical guide on naming, representing, and communicating about product development work. Frames the problem space and previews the guide's structure.
Structure
| Part | Role |
|---|---|
| Opening rhetorical questions (paragraphs 1-4) | Problem framing via shared pain points |
| Core observation (paragraph 5) | Thesis statement |
| Stakes clarification (paragraph 6) | Scoping the damage |
| Audience section | Reader qualification |
| Guide overview and table of contents | Structural preview |
Key terms
- visibility Organizational Legibility
Genuine understanding of what is happening in a system, as opposed to mere access to dashboards and status reports. - flattening Organizational Legibility
The loss of nuance, context, and variability that occurs when complex work is forced into simplified representations for reporting or governance purposes. - legibility Organizational Legibility
The formal clarity that organizations impose on complex work to make it readable at a distance -- often in tension with local understanding (metis). Draws on James C. Scott's usage. - ontology Organizational Legibility
The system of categories, names, and relationships an organization uses to represent and reason about its work -- not a philosophy exercise but a practical design choice. - metis Organizational Legibility
Local, experiential, contextual knowledge that resists formal capture -- the practical understanding that people on the ground have versus what dashboards show. From James C. Scott via Greek concept. - endurant vs. perdurant
A distinction between stable things (endurants) and unfolding activities or processes (perdurants) -- used to clarify what kind of entity work items actually are.
Propositions
- explicitExecutive teams lack real visibility into what is happening despite being surrounded by dashboards, slides, RAG statuses, and data.conf: high
- explicitTeams are overwhelmed by reporting obligations that they doubt reach the right audience or convey real priorities.conf: high
- explicitdevelopedInformation degrades systematically as it moves upward through organizational layers -- it gets flattened, filtered, or whitewashed.conf: highextends ←TBM 426: The Trouble With Mirrors · p8 — Cutler's earlier structural claim that information degrades, is flattened or whitewashed as it rises through layers is extended with a motivational and political mechanism: people prefer flattering mirrors and negotiate what is foregrounded, so the distortion is chosen (frosting on the mirror), not merely a passive artifact of layering.
- explicitStandardizing definitions creates a double bind: without them there is chaos, but imposing them strips out the variability, context, and reality they were meant to represent.conf: high
- explicitOperations in complex product domains is fundamentally an information architecture and ontology design problem, not a manufacturing-style process optimization problem.conf: high
- explicitThe naming and categorization of work in product development is more art than science, because the underlying concepts are inherently variable and contextual.conf: high
- implicitMost operating problems in product development are actually problems of representation, interpretation, and scale -- not problems of execution or process.conf: high
- implicitThe factory/manufacturing mental model is the default frame most organizations bring to product development operations, and it is the wrong frame.conf: medium
Arguments
Product development operations requires an information-architecture approach to naming and representing work, not a manufacturing-operations approach. strength: high
Explicit premises:
- Operations in complex domains involves information architecture and ontology creation.
- Product development concepts are 'slippier' than manufacturing concepts.
- Flows and feedback loops are more variable than in deterministic settings.
- Naming is extremely important but is more art than science in this domain.
Implicit premises:
- Most organizations default to manufacturing-derived operational models (stages, statuses, cascades).
- These manufacturing-derived models systematically distort the reality of product development work.
- The distortion is not merely inconvenient but causes real organizational dysfunction (misalignment, wasted motion, false confidence).
Inferences:
- Therefore, the guide must teach a different way of thinking about operational language, categories, and representations.
The visibility problem is a representation problem, not a data-access problem. strength: high
Explicit premises:
- Executives are 'surrounded by slides, dashboards, RAG statuses, and data' but still lack real visibility.
- Status information gets 'flattened, filtered, or whitewashed on the way up.'
Implicit premises:
- If the problem were data access, more dashboards would solve it.
- More dashboards have not solved it.
- The problem lies in how information is structured, named, and summarized -- not in its availability.
Inferences:
- The solution must address how work is represented and how those representations travel, not simply add more reporting.
Narratives
- The executive surrounded by dashboards who still doesn't know what's going on.
→ Opens the guide by evoking a universally recognized failure mode -- the 'visibility paradox' where more data produces less understanding. - The team in 'swivel-chair mode' reporting without confidence that it matters.
→ Shows the same dysfunction from the other side -- reporting is costly and low-trust from the producer's perspective too. - The leader who 'assumes context that is not really there' because a status was whitewashed on the way up.
→ Illustrates the information-degradation mechanism that connects the executive's false confidence to the team's wasted effort. - Someone tries to set definitions and it 'took the life and variety out of the thing itself.'
→ Introduces the central double bind: formalization is needed but destructive. This foreshadows the legibility-vs-metis tension that structures the guide.
Questions addressed
- ⭕ Why do organizations lack real visibility despite investing heavily in dashboards and status reporting?
Framed but deferred to later chapters -- the introduction asserts it is a representation/ontology problem. - ⭕ How should operations in complex product domains differ from manufacturing-style operations?
The guide promises to explore this through endurant/perdurant distinctions, legibility/metis tensions, and ontology shifts. - ⭕ How can you standardize language without destroying the contextual richness it is meant to capture?
Explicitly raised as a tension; 'Twelve Practical Moves' chapter promises concrete answers.
Gaps
- empiricalNo evidence is offered for the claim that product development is categorically different from manufacturing operations. The introduction relies entirely on the reader's experiential recognition. Later chapters may supply theoretical grounding (endurant/perdurant, Scott's legibility) but the introduction treats the distinction as self-evident.
Read next: Read chapters on endurant vs. perdurant and metis vs. legibility for the theoretical backing. - scopeThe guide targets 'product development operations' but never defines where the boundary of that domain lies. Many of the same representation problems exist in policy, healthcare operations, and other complex domains. The introduction does not address whether the framework generalizes.
Read next: Consider applying the ontology lens to adjacent complex domains to test generalizability. - implicit_premiseThe argument assumes that the manufacturing mental model is the dominant frame organizations bring to product operations. This is plausible but unstated and undefended. Some organizations may already operate with complexity-aware models and still suffer the same visibility problems for structural or political reasons unrelated to ontology.
Read next: Look for whether later chapters address political and power-dynamic causes of information distortion alongside representational causes. - tensionThe introduction implicitly promises that better ontology design can resolve the visibility problem, but also acknowledges that 'words alone will rarely sink the ship.' This creates tension about how much explanatory weight ontology can actually bear versus organizational politics, incentives, and culture.
Read next: Track how the guide handles the relationship between naming/representation and the social/political dynamics of organizations.
Related documents
- What 60 Years of Data Reveals About How Men and Women Experience Leadership
- TBM 426: The Trouble With Mirrors
- TBM 440: The Problem With Putting People in Boxes
- The engineering manager role is splitting in two
- 4) Morten Eikeland: Det finnes alltid et hierarki
- Experience Mapping Matters More the Faster You Move
- Netflix CPTO on AI and the future of product and tech roles | Elizabeth Stone
- Managers Are Not Overhead: They Are Infrastructure
- TBM 414: Legibility and Legitimacy
- TBM 423: Why Defining Teams Is So Hard