# Experimental Context Brief Use this experimental brief before or alongside a Domain Context Brief when a project needs a wider map of the world around the product. The Domain Context Brief defines the product world: concepts, relationships, rules, states, sources of truth, user values, and AI authority boundaries. The Context Brief defines the surrounding conditions that shape what the product can responsibly attempt: stakeholder power, organizational incentives, economic pressures, geography, technology constraints, internal delivery constraints, evidence, adoption risks, and areas of likely sensitivity or disagreement. This is a working canvas, not a public research report. It can be adapted into different versions for different audiences. > Model the messy context honestly. Share the useful context responsibly. ## When To Use It Use the Context Brief when a product effort touches: - multiple stakeholder groups with different incentives - policy, compliance, institutional, or community trust concerns - geographic, infrastructure, or jurisdictional constraints - economic or labor conditions that shape adoption - AI, automation, or data use that may create anxiety or disagreement - business model, procurement, governance, or operating-model questions - internal ownership, technical, roadmap, or stakeholder constraints that affect delivery - unclear evidence, weak signals, conflicting claims, or discovery gaps - sensitive language, contested outcomes, or possible winners and losers Do not use it to collect confidential, personal, or politically risky detail unless the storage location and audience are appropriate. For workplace experiments, keep examples sanitized and remove names, private data, internal politics, customer details, and proprietary strategy. ## 1. Situation ```text The larger situation is... This matters now because... The relevant market, institution, community, policy, or organizational moment is... The project is happening in the context of... The conditions that make this hard to understand are... ``` ## 2. Stakeholder Landscape ```text The people, groups, organizations, systems, or affected parties are... The groups with decision power are... The groups with operational knowledge are... The groups most affected by the outcome are... The groups likely to benefit are... The groups likely to feel exposed, displaced, burdened, or ignored are... The absent voices that should be considered are... ``` ## 3. Incentives And Constraints ```text The business or organizational incentives are... The economic pressures are... The budget, procurement, staffing, or operating constraints are... The incentives that may conflict are... The behaviors the current system rewards are... The behaviors the proposed product might accidentally reward are... ``` ## 4. Sociopolitical And Trust Context ```text The trust issues are... The institutional, community, cultural, or policy sensitivities are... The language that may create defensiveness is... The topics where stakeholders may disagree are... The history or baggage that may shape interpretation is... The equity, access, dignity, labor, safety, privacy, or accountability issues are... ``` ## 5. Geographic And Physical Context ```text The relevant places, regions, facilities, routes, or jurisdictions are... The physical or geographic constraints are... The infrastructure dependencies are... The local practices or environmental factors are... The ways location changes the product need are... ``` ## 6. Technology And Data Context ```text The existing technologies, systems, tools, and platforms are... The data sources are... The sources of truth are... The integration, security, privacy, reliability, or access constraints are... The AI capabilities that may help are... The AI uses that may be risky, misleading, premature, or unacceptable are... ``` ## 7. Internal Delivery Context Use this section when the organization delivering the product has its own constraints, ownership lines, stakeholder sensitivities, or technical realities that shape what can actually be designed, shipped, or responsibly promised. ```text The internal teams, owners, or decision-makers involved are... The existing ownership boundaries are... The systems, platforms, data models, APIs, or integrations that constrain this work are... The design system, content, research, analytics, or operational constraints are... The roadmap, sales, customer, leadership, or support commitments are... The stakeholder sensitivities inside the company are... The decisions that have already been made are... The decisions still open are... The designer or product team can influence... The designer or product team cannot change... The risks of proposing beyond the current boundary are... The internal context signals that should shape product scope are... ``` This section is often useful for the builder or internal team version and risky for broader circulation. Translate it carefully before sharing with stakeholders who do not need candid internal operating detail. ## 8. Evidence Base Use this section to separate what the team knows from what it suspects, has been told, or still needs to learn. Treat every important project claim as something with a source, confidence level, and discovery gap. ```text The claims being made are... The evidence supporting those claims is... The evidence comes from... The evidence is recent or stale because... The evidence represents these users, customers, markets, workflows, or situations... The evidence may not represent... The strongest evidence is... The weakest evidence is... The evidence that conflicts with or complicates the claim is... The important assumptions are... The evidence gaps are... The discovery, research, analytics, support review, field observation, or expert input still needed is... The product decisions that should wait for more evidence are... The product decisions that can proceed with current evidence are... The evidence signals that should shape the Domain Context Brief are... ``` If there is little or no evidence, say that directly. Lack of evidence is useful context because it may mean the team should run discovery, inspect analytics, review support data, interview users, consult domain experts, or narrow the product decision before committing to a solution. ## 9. Sensitivity And Dissension Map Use this section in the candid internal version. Translate it carefully for broader audiences. ```text The issues most likely to create disagreement are... The stakeholders may disagree about... The project may be perceived as... The product choices that could create winners and losers are... The assumptions that may be challenged are... The decisions that require explicit alignment are... The issues that should not be collapsed into a product feature are... The places where human judgment, governance, or facilitation are required are... ``` ## 10. Outcome Hypotheses ```text If the product succeeds, users may experience... If the product succeeds, the organization or business may experience... If the product succeeds, affected stakeholders may experience... The outcomes that should be protected are... The outcomes that should be avoided are... The assumptions behind these hypotheses are... The evidence needed to test them is... ``` ## 11. Product Boundary Implications Use this section to connect the Context Brief to the Domain Context Brief. ```text Because of this context, the product should... Because of this context, the product should not... The product should make visible... The product should keep internal... The product should avoid taking sides on... The product should require human judgment when... The product should escalate when... The product should cite evidence when... The product should use careful language around... The riskiest product assumption is... The context signals that should move into the Domain Context Brief are... ``` ## Audience Variations Create separate versions when the same context needs to serve different uses. ### Builder Or Internal Team Version Use candid language for orientation and product judgment. This version may name tensions, incentives, disagreement, sensitive assumptions, adoption barriers, ownership boundaries, technical constraints, roadmap pressures, stakeholder sensitivities, and risks. Keep it in an appropriate internal location. Do not include private names, confidential details, customer data, screenshots, source code, proprietary metrics, or employer-owned strategy in a personal public repository. ### Stakeholder-Safe Version Use constructive, alignment-oriented language. This version should be sanitized but not misleading. Possible translations: - "likely blocker" becomes "adoption risk" - "political conflict" becomes "decision area requiring alignment" - "group may feel threatened" becomes "stakeholder impact to validate" - "sensitive topic" becomes "area requiring careful language and review" - "unclear ownership" becomes "governance question" ### AI Context Version Use only the parts that should constrain AI behavior. This version should include: - relevant sources of truth - evidence-backed claims and known evidence gaps - sensitive language to avoid - internal constraints that affect what AI should or should not suggest - areas requiring evidence - actions AI may not take - escalation triggers - assumptions to preserve as assumptions - boundaries between analysis, recommendation, and decision ## Output Options The Context Brief can produce: - an internal context map - a stakeholder-safe context memo - an evidence and confidence map - a sensitivity and dissension map - an internal delivery context map - a product boundary canvas - an AI behavior and review-gate appendix - selected inputs for the Domain Context Brief The artifact should help the team orient before product decisions harden. It should not become a substitute for research, legal review, policy judgment, stakeholder engagement, or domain expertise.