On applying product definition principles outside software
Premise
Most working definitions of product architecture misframe the discipline as inherently tied to software. They describe it through artifacts native to engineering delivery: PRDs, state models, RBAC, service boundaries, API contracts. This framing is convenient, but incorrect. It confuses the method with its most visible outputs.
Product architecture is not about software. It is about defining a system before its output, so that the output becomes a predictable consequence of the system rather than a sequence of ad hoc decisions.
This distinction matters because it determines what transfers across domains and what does not.
What Actually Transfers
If you remove software-native vocabulary, product architecture reduces to a small set of operations:
- modeling constraints before designing solutions
- defining roles, states, and transitions as explicit rules
- replacing reactive decisions with system-level governance
- segmenting participants by behavior rather than attributes
- treating edge cases as first-class elements of the system
None of these operations require code. They require a system with entities, constraints, flows, and decision points. Every non-trivial business has these. Software is one way to implement them. It is not their source.
Constraint is not a limitation. It is the primary design input.
The Misreading
When product architecture is taught through software examples, it is interpreted as a delivery discipline. Teams learn to produce PRDs, define APIs, model states — and these artifacts become the perceived evidence of architectural thinking.
They are not. Artifacts are evidence, not the thinking itself.
The discipline is the reasoning that produces them. If the reasoning is sound, the artifacts can take any form: PRDs, BPMN diagrams, pricing rules, intake scripts, operational policies. The format adapts to the domain. The method does not.
PRDs are not architecture. APIs are not architecture. Diagrams are not architecture. They are representations of decisions made elsewhere.
This misreading confines product architecture to software teams and evaluates it through proxies: familiarity with tools, formats, and engineering processes. The capability itself exists far beyond that boundary but remains unnamed and therefore unrecognized.
Applied: A Capacity-Constrained Service
A recent engagement applied these principles to a domain with no software layer: a private restorative service practice operating across two locations under a strict physical capacity ceiling of 110–120 working hours per month.
This constraint was not treated as a limitation. It was treated as the primary design input.
In such a system, the unit of product is not the service itself, but the occupied time slot. Each slot can be allocated once. Its quality determines the performance of the entire system.
The business initially existed as a set of services without a system behind it. Pricing was intuitive. Client intake was uncontrolled. Operations depended on manual decisions made under load. The visible problem was pricing misalignment. The actual problem was structural: there was no product layer translating demand into controlled allocation of capacity.
The work did not produce a PRD. It produced:
- a client architecture with priority and excluded segments, defined by behavior rather than demographics
- a pricing model defined as a function of system state (utilization, waitlist size, operator load) rather than a static rate
- an operational framework with explicit capacity ceilings, intake limits, prepayment policy, and predefined responses to disruption
- a customer journey designed for correct selection rather than conversion
- a financial model tested across scenarios, where stability was defined by the minimum viable case, not the maximum
Each of these mirrors structures familiar from software: segmentation logic, rule-based triggers, state transitions, governance layers. The domain differs. The method does not.
The system was implemented in practice, but not atomically. Adoption was constrained by human factors. Price increases introduced hesitation. Some rules were delayed or only partially enforced. The system entered reality incrementally rather than as a complete abstraction.
Despite this, the structural shift was observable. Pricing was repositioned upward at launch. Intake began to move from uncontrolled demand to filtered entry. Early acquisition aligned more closely with intended segments. The business transitioned from a fragile model dependent on maximum workload to one where reduced-capacity scenarios remained viable.
Growth stopped being a function of volume and became a function of selection.
Why This Matters
If product architecture is treated as a software-only discipline, it gets confined to environments where code is shipped and evaluated through proxies: tools, artifacts, and delivery formats. This is a category error.
The actual capability is domain-agnostic. It is the ability to define systems before outputs, to model constraints explicitly, and to replace ad hoc decisions with governed behavior.
The test of product architectural thinking is not whether the output resembles a PRD. The test is whether the system behaves predictably:
- under load
- under reduced load
- under constraint
- under its own edge cases
Software makes systems visible. It does not create the thinking required to design them.
Domain is secondary. The method is not.