An evolving practice
Connect
context.
Shape product
behaviour.
WORKING METHODBefore the interface,
understand the decisions.
CDAM helps teams turn an unclear product question into explicit decisions and behaviour they can build and test. It connects what is known, what is assumed and who is responsible, so those choices remain visible as the product takes shape.
CDAM — Context and Decision Architecture Methodology. My evolving working method for connecting context, decisions and product behaviour.
The problem it addresses
The same screen.
Different assumptions.
A team agrees on a screen, but describes different rules behind it. Requirements accumulate, but their reasons are difficult to trace. An AI or automated process is expected to act, but nobody has agreed when it should ask, stop or hand a decision to a person.
I developed CDAM to make those questions part of the product conversation. The aim is a shared product model: a description of intended behaviour that product, design, engineering and domain specialists can question, build from and test.
You can enter through a new product question, an uncertain workflow or a problem in an existing experience. Start with the smallest useful scope. A single decision may be enough to expose what needs attention.
How I use it
Connect what the team understands about the situation with the decisions a product needs to make, then follow those decisions into behaviour and interaction.
Keep the reasoning connected: which evidence supports the choice, who owns it and what would make the team reconsider it.
An evolving practice
From context to behaviour
01Understand the context.The situation, the purpose and the evidence behind the next decision.
START WITH REALITYWho is involved, what are they trying to do and what is happening today? Separate what has been observed from what the team assumes. A plausible explanation can still be wrong.
WHAT BECOMES CLEARERThe product’s purpose, the constraints that matter and the unknowns that could change the direction. Research is useful when it can inform a decision, rather than simply add material.
02Make decisions explicit.The rules, trade-offs and responsibility that shape the product’s choices.
NAME THE CHOICEA requirement often contains a decision that has not yet been made. When may a task proceed? Which information is necessary? Who can approve an exception? These choices need an accountable owner.
CONNECT THE REASONINGKeep the choice connected to the evidence and constraints behind it. If those change, the team can see which decisions may need to be reconsidered.
03Model the behaviour.What the product does in ordinary, incomplete and failure situations.
FOLLOW THE CONSEQUENCEA decision has to become behaviour: what the system knows, which state it is in, what actions are available and what happens next. Missing information and recovery belong in that description.
MAKE IT TESTABLEUse concrete scenarios to challenge the intended response. The interface, prototype and implementation give that behaviour a form; they also provide evidence that can change the model.
04Choose where to begin.Discover a problem, model a direction or audit an existing experience.
DISCOVER & MODELDiscover clarifies the problem, competing explanations and what needs to be learned next. Model turns that understanding into explicit decisions, responsibilities and intended behaviour.
AUDITWhen an experience is failing, trace it back from the visible interaction to the behaviour, decision or assumption behind it. Change the deepest incorrect layer that can realistically be changed. These are ways into the work, not fixed phases of a waterfall.
05Give AI a clear role.Use AI within the work while keeping judgement and responsibility visible.
AN INSTRUMENT IN THE PROCESSAI can help explore alternatives, challenge assumptions, make prototypes and examine scenarios. Its output still needs to be checked against the product’s context and relevant expertise.
KEEP THE DISTINCTIONSAI helping a team design a product is different from AI making decisions inside that product. Each needs a clear scope, limits and human responsibility. CDAM also applies to products without AI.
06Learn from what happens.Compare the intended behaviour with what people and the system actually do.
OBSERVE & REVISEA model is a starting point for learning, not proof that a product will work. User feedback, tests and observed behaviour can expose a missing constraint or an incorrect assumption.
FOLLOW THE CHANGEUpdate the reasoning and the affected parts of the product together. The useful outcome is a better decision or a more coherent experience; the number of documents produced is not a measure of success.
Make the decisions explicit.
Make the behaviour testable.
One decision in practice
Ask for the missing fact.
Make the next step clear.
The document shows what was purchased, but not why the purchase was made for the business. Before designing a warning, the team needs to decide what information is missing, who can supply it and who can assess the explanation.
Understand the situation.The invoice records the purchase. Its business purpose still needs an explanation from the person who made it.Keep the document’s evidence separate from the explanation someone adds.
Ask for the missing fact.Ask the purchaser for the missing explanation. Make it clear who is responsible for assessing whether it answers the question.In this example, adding an explanation does not automatically resolve the review.
Make the next step clear.Keep the original document, the added explanation and the unresolved question visible together.If the explanation is insufficient, show what still needs an answer and who can provide it.
Try the difficult case: an explanation has been added, but it does not answer the question. Does the product keep the review unresolved, preserve the original evidence and make the next action clear? Design and engineering now have a specific scenario to build and test.
A model
the team can use.
Evidence it can question.
A useful model connects the situation to a choice, an accountable owner and observable behaviour. For the example above, a small decision record could look like this:
01Situation & evidence
The invoice records a purchase; its business purpose is not documented.
02Assumption to check
The purchaser can provide the missing explanation. Check this before making them the only route to resolution.
03Decision & responsibility
Request the explanation from the purchaser. The person responsible for review assesses whether it is sufficient.
04Expected behaviour
Retain the original document and the explanation. Keep the question unresolved until the responsible reviewer has assessed it.
05Test scenario
An explanation is submitted but does not answer the question. The product must still show what is missing and who needs to act.
The wider work may also produce behaviour scenarios, a record of open questions and a prototype. Check their usefulness by asking: can the team find the reason for a decision, identify its owner and test the intended response?
Start with one decision.
Follow what it changes.
Choose one real task where your team is uncertain. Write short answers to these six questions; mark what you do not yet know.
01PurposeWhat is the person trying to achieve?
Describe one real task and what a useful outcome would mean for the person doing it. Keep the task specific enough to walk through.
02EvidenceWhat do you know, and what are you assuming?
Separate what you have observed from what you believe to be true. Mark the unknown that could most change your next decision.
03DecisionWhat needs to be decided, and who is responsible?
Name the choice the task depends on. Identify who can make it and what information they need before proceeding.
04BehaviourWhat should the product do as a result?
Describe the expected response in a concrete scenario: what the person can do, what changes and what the product makes visible.
05RecoveryWhat happens when information is missing or the expected action fails?
Walk through a missing-information or failure case. Describe what remains unresolved, who can act and how the person can continue.
06LearningWhat observation would show that your model is wrong?
Identify a result or observation that would challenge your reasoning. Use what happens in practice to revise the affected decision and behaviour.
Walk through one ordinary case and one difficult case with someone who knows the work. Resolve or assign the unknown that could most change the decision. Use what you learn to revise the model before expanding its scope.
This is a starting exercise for applying CDAM to your product. The depth should follow the consequences of getting the decision wrong.
Learn CDAM / Apply it with your team
01Learn the method.A practical introduction for people who want to apply CDAM in their own work.
WHAT WE WORK THROUGHWe use a concrete product example to practise connecting evidence, assumptions, decisions and behaviour. We look at where to begin, what to question and when more detail is useful.
WHAT YOU CAN TAKE FORWARDA worked example and a clearer basis for trying the method on your next product question. We can shape the introduction around your experience and the work you want to do.
02Work through it as a team.A facilitated workshop around different interpretations of the same product or workflow.
WHAT YOU BRINGA product question, workflow or upcoming change where the team has different assumptions. Bring the people who understand the task and those responsible for the decisions.
WHAT WE MAKE VISIBLEThe evidence you share, the choices that need an owner and the questions that remain open. We work towards a model and concrete scenarios the team can challenge together.
03Untangle a product problem.Hands-on consulting for a complex, uncertain or stalled product experience.
WHERE I CAN HELPWe trace a visible problem back to the behaviour, decision or assumption behind it. I help connect product priorities, design and implementation with the people who own the domain decisions.
HOW WE SET THE SCOPEWe agree on the question to investigate and the next useful commitment. The work can involve research, modelling, prototyping or testing, depending on what the decision needs.
A practical introduction
Bring one product question.
Work through it together.
Tell me what your product does, where the team is stuck and what you need to decide next. We can use that to explore whether an introduction, a team workshop or hands-on support would be useful.
