Glossary
The words this book uses in a precise sense, in alphabetical order.
Architect of context
The role the book assigns to the Product Manager: turning scattered knowledge — interviews,
sales objections, support, decisions, data, sources and weak signals — into a reusable
organisational asset.
The point is not to produce more pages, but to make available what someone needs to decide
without reconstructing all the reasoning from scratch.
Bottleneck
The point in the chain that limits what the organisation can actually deliver.
AI does not make the other activities unnecessary: it shifts the bottlenecks. What used to be
obscured by the slow pace of implementation becomes visible — the quality of the problem chosen,
the clarity of the intention, trade-offs, validation, coherence, the ability to learn after
release. The new bottleneck is judgement.
Decision-making framework
What replaces part of the detailed instructions: the information that guides local decisions
without fixing every solution in advance.
It may include the priority customer, the problem to solve, the expected outcome, the limits of
the scope, important constraints, the standard of quality expected, what the organisation
accepts not doing, and the thresholds beyond which a decision must be escalated.
This is the book's paradox: the more autonomy we want to distribute, the more explicit the
framework must be. Autonomy does not come from having no rules, but from being able to act
without constantly asking permission.
Escalation
The third of the three levels of control.
The decision changes the boundaries of the system itself: fundamental architecture, security,
sensitive data, a significant new interaction, a change of target market, value proposition or
pricing. The owner is no longer deciding within the framework: they are proposing to change it.
The situation calls for a Guarantor or a more senior level of decision-making.
Green, amber and red levels
The grid the teams at Malorean Corp. write down to know who decides.
- Green: you decide alone when the choice remains local, reversible, consistent with known
rules and involves no new promise to a customer.
- Amber: you consult when facing something new, conflicting objectives or a significant
doubt.
- Red: nobody decides alone when it involves changing a fundamental rule, committing the
company, touching sensitive data or taking a major risk that would be difficult to reverse.
This is the lived version of the three levels of control: local autonomy, targeted approval,
escalation.
Guarantor
The person or team that remains accountable for the coherence and quality of a domain.
The Guarantor is not necessarily the one who does the work in that domain, nor the one who
approves every minor decision. They are the one the organisation turns to when an important
choice affects that domain, when a boundary is crossed or when something goes wrong.
The book proposes at least three:
- Product Guarantor: product coherence, major product choices, target customers, value
proposition, major trade-offs, alignment with strategy.
- Design Guarantor: Design System, consistency of the user experience, accessibility, new
patterns and UX standards.
- Engineering Guarantor: architecture, security, performance, maintainability, technical
quality and release conditions.
The principle: anyone can contribute across several domains, but each domain retains someone
who is accountable for it. The Guarantor protects the framework rather than approving every
move: if they must inspect everything, they become a bottleneck again.
Not to be confused with the owner.
Local autonomy
The first of the three levels of control.
The decision stays within known objectives and standards. It is reversible, its possible
consequences are limited and it does not change a fundamental rule.
The owner decides alone.
Middle layers
The levels of management whose function is to coordinate decisions between senior leadership
and teams.
The book distinguishes the functions from the people who hold them. Passing on information,
consolidating progress reports or organising repetitive approvals may lose some of its weight.
Making trade-offs, resolving conflict, passing on experience and answering for results must be
taken on in other ways. What is being questioned is not necessarily management, but hierarchy
as the compulsory mechanism of coordination.
Owner
The person who carries a piece of work.
They need to understand the problem, move the work forward, make local trade-offs, coordinate
what needs coordinating, check the result and ensure the work reaches its intended outcome.
The owner and the Guarantor are not the same person: the owner owns a piece of work, the
Guarantor owns a level of consistency, quality or risk within a domain. A Product Engineer can
own a feature without becoming accountable for the entire architecture.
Product Decision Record (PDR)
The record of product decisions important enough to guide several teams, several products or
several future situations.
It preserves the context, the alternatives considered, the decision taken, the reasons for it,
its consequences, the risks accepted, the conditions that would justify revisiting it and the
people who made the call.
It does not document every minor trade-off. A decision without a record of its reasoning soon
becomes open for debate again: code records what was built, the PDR records why.
Safeguards in the system
The repetitive rules the organisation moves out of human approval and into its tools: tests,
CI, Design System, standards, security rules, templates, instructions for agents, metrics.
A Guarantor need not repeat the same rule across fifty pull requests if it can be checked
automatically. Human expertise can then focus on exceptions. This is no guarantee that
automation alone is enough to ensure quality.
Shared context
What enables a person to decide locally: what customers actually said, the assumptions already
tested, the constraints that matter, the important decisions made, the trade-offs accepted, the
metrics that judge the result.
The book treats it as infrastructure. An organisation cannot ask more people to make decisions
while keeping most of the context in the heads of a few specialists: it would be distributing
the ability to act without distributing the ability to understand.
Soft decisions
Decisions vague enough to maintain the appearance of agreement.
Each person can project their own priority onto them; implementation later reveals that the
constraints were incompatible. They make explicit neither the choice, nor the accepted loss,
nor the person who makes the call.
They are particularly dangerous in a highly autonomous system: each team can make a decision
that is locally reasonable but inconsistent with the whole.
Targeted approval
The second of the three levels of control.
The decision introduces something new, an exception or a significant risk within a domain. The
relevant Guarantor gets involved. They do not necessarily take over the initiative: they
contribute the specialist judgement it lacks.