# How to prioritise assumptions before building your next idea. Find the belief that could change your next commitment. A practical assumption map for a small mission-driven project, with an example, evidence boundaries, and a worksheet. ## The direct answer Prioritise assumptions by writing each belief clearly, asking what would fail if it were wrong, and checking what relevant evidence you actually have. Investigate important, weakly supported assumptions before committing to a larger build. Choose a method that can answer the specific question, define its limits and decision rule in advance, and record the result without treating a completed test as proof of demand or impact. - Author: Daniel Ziedins (https://www.danielziedins.com) - Published: Oct 20, 2026 - Updated: Oct 20, 2026 - Scripture: Luke 14:28 - Read: 7 min - URL: https://www.agent-six33.com/journal/how-to-prioritise-assumptions-before-building > For which of you, desiring to build a tower, does not first sit down and count the cost > — Luke 14:28 An idea can have a compelling mission, an elegant design, and a long feature list while depending on one unexamined belief. Perhaps people cannot access the format you chose. Perhaps the person who would maintain the information has no capacity to do so. More polished delivery will not repair a promise that depends on something untrue. An assumption map makes those dependencies discussable before a bigger commitment. The method here is an original planning aid for a small, low-risk project. It is not a numerical risk model, a formal evaluation, or a way to bypass legal, safety, safeguarding, or professional review. Some uncertainties must be resolved through qualified review, not through an experiment with people who could be harmed. ## 1. Name the next commitment you might change. Start with a concrete decision: whether to build an account system, print a first batch, recruit a pilot group, or ask a coordinator to maintain a resource. A broad question such as will this mission succeed is too large for a useful assumption map. You need a decision that could reasonably change when new evidence arrives. Write what the commitment would require in time, effort, money, or responsibility, without inventing precise figures you do not know. Then name the part that is hard to reverse. You may learn something with a draft before ordering a full print run, or confirm an operational owner before promising weekly updates. The map should influence an actual choice, not become another document that sits beside an unchanged plan. ## 2. Turn a broad belief into specific assumptions. GOV.UK's alpha guidance focuses attention on the assumptions that could prevent a service from working. Use that principle without importing a government delivery timetable into a small project. Ask what must be true about the person's need, the proposed experience, the delivery arrangements, and the conditions for keeping the promise over time. Separate people need help choosing a role from people will use our new page and the team can keep the page current. Each is a different belief and may need different evidence. Avoid combining them into people want our solution. One interview account cannot automatically support all three, and a working prototype cannot confirm that someone has accepted an ongoing maintenance responsibility. ## 3. Compare the consequence of being wrong with the evidence available. For each assumption, ask what would change if it were false. Would you adjust wording, change the format, stop a planned feature, or withdraw the promise? Then record the most relevant evidence you have and its limits. A dated observation with likely users is different from a colleague's confident opinion; an old observation in a different context may still leave the current question open. You can discuss importance and support in plain language rather than multiplying invented scores. For example: important because the promise fails without current information; weakly supported because no maintenance owner has agreed to it. Keep the reason beside the judgement. A low-looking score must never be used to wave away a safety or access concern that requires specialist attention. ## 4. Match the learning method to the uncertainty. Use an interview to understand a recent experience, an observed task to examine whether someone can use a proposed version, and an operational check to confirm a dependency with the people who own it. These methods answer different questions. Asking whether a page looks helpful is not the same as watching someone use it; a friendly reaction does not establish a future purchase or repeated use. Write the question, method, decision rule, and limitations before the test. Keep the effort proportionate, but do not make a promise incomplete simply to make a test small. If a person would rely on information that has not been checked, resolve that dependency before inviting them to act on it. Choosing another method, asking for qualified review, or stopping can each be the right next step. **Define the small test before running it:** Keep the question, observations, decision rule, and limits together. https://www.agent-six33.com/journal/how-to-plan-a-small-pilot ## 5. Work through a hypothetical assumption map. Imagine a team considering a searchable volunteer-role directory. This is a hypothetical example, not a SIX33 result. The proposed directory depends on three beliefs: people need help finding a suitable role, a searchable list helps them choose, and coordinators can keep availability accurate. The team has recent accounts about unclear options but no observed use of a directory and no agreement about maintenance. The maintenance assumption matters before a public pilot: stale availability would make the promise unreliable even if search worked perfectly. A first action is to ask the responsible coordinators what updating would involve and whether anyone can own it. That is an operational dependency check, not evidence that the directory has demand. If nobody can maintain the information, the team may need a smaller, dated resource or a different service arrangement. If the dependency can be resolved, the next uncertainty is whether the proposed list helps people complete the task. A bounded prototype session can investigate selection and confirmation, recording assistance and confusion. It cannot establish long-term participation, the size of the wider market, or impact on the community. The map has earned its place if it changes the order or scope of the work before a costly commitment. ## 6. Record what changed, including what remains unknown. After the learning step, keep the result and interpretation separate. Record which version was involved, what happened, who or what the evidence describes, and whether the original decision rule was met. If you change the rule afterward, retain the original and explain why. Otherwise an ambiguous result can be quietly rewritten as the answer the team hoped for. Update the assumption's status in bounded language: supported for this context, contradicted in this test, or still unresolved. Do not mark an assumption permanently proven. A different audience, a larger delivery, or a new operating arrangement may change what is relevant. Give unresolved assumptions an owner and a review trigger so uncertainty stays visible rather than disappearing from the document. Finally, state the next decision: proceed with a limited commitment, change the response, gather different evidence, or stop. A completed map is not the outcome. The useful result is a better sequence of responsible commitments, with fewer unsupported beliefs hidden inside a public promise. Keep completed worksheets private when they refer to participants, internal constraints, or material that was not agreed for publication. **Revise the brief from what you learned:** Change the scope, owner, or promise when the evidence calls for it. https://www.agent-six33.com/journal/how-to-write-a-one-page-project-brief ## Assumption map and next-test worksheet Copy this blank template into your private working document. It contains no journal notes or tool drafts. ```markdown # Assumption map and next-test worksheet Project, version, and date: [name / version / date] Next commitment this map could change: [specific decision] Hard-to-reverse part of that commitment: [detail / unknown] Owner and review date: [person / date] ## Assumption — repeat for each important belief ID and clear belief: [A01 / one belief] Category: [person's need / proposed experience / delivery dependency / ongoing care] What fails or changes if this is false: [consequence] Relevant evidence and private source IDs: [source / date / context] Limits, contradictions, and missing perspectives: [details] Current support: [supported in a stated context / weakly supported / unknown] Why investigate this before another commitment: [reason, not an invented probability] Safety, access, and required review: [constraints / reviewer / resolve before testing] ## Next learning step Question: [specific uncertainty] Method and why it can answer this question: [interview / observation / operational check / review] Experience or version: [version] Decision rule written before the test: [continue / change / stop / investigate conditions] What this method cannot establish: [limits] Evidence access and permission boundary: [who sees what / agreed use] ## Review after the learning step Observed result or account, kept separate from interpretation: [result / source] Interpretation and alternative explanations: [bounded conclusion] Status in this context: [supported / contradicted / unresolved] Next decision, owner, and review trigger: [decision / person / trigger] Revision record: [date / change / reason] This worksheet does not calculate risk or verify demand, causation, or impact. Keep identifying information private and obtain appropriate review for higher-risk work. ``` > **The short version:** Test the belief that could change the commitment, not the one that is easiest to make look successful. ## Questions ### What is an assumption map? It is a record of the beliefs a proposed commitment depends on, the consequence if each is wrong, and the evidence currently available. Its purpose is to choose a responsible next learning step, not to give a speculative plan a scientific-looking score. ### Which assumption should I test first? Start with an important, weakly supported belief that could change the next commitment. Resolve dependencies that make a test unsafe or the promise unreliable before inviting people to rely on it. The right order depends on the actual decision, context, and required reviews. ### Is an assumption map the same as a risk register? No. This worksheet organises learning about beliefs behind a proposed project. A formal risk register may have different governance, assessment, and control requirements. Do not use a simple assumption map to replace a required safety, legal, safeguarding, or professional review. ### Does a successful prototype validate the whole idea? No. A prototype can provide evidence about a particular task with a particular version and group. It does not automatically establish wider demand, long-term use, operational feasibility, causation, or impact. State what the method could and could not answer. ## Sources - GOV.UK Service Manual: how the alpha phase works: https://www.gov.uk/service-manual/agile-delivery/how-the-alpha-phase-works — Reference for investigating consequential assumptions with proportionate prototypes. The worksheet, prioritisation questions, and directory example are original illustrations, not a government risk model. - GOV.UK Service Manual: how the discovery phase works: https://www.gov.uk/service-manual/agile-delivery/how-the-discovery-phase-works — Further reading on understanding a problem and its constraints before committing to a solution. No endorsement of SIX33 is implied. ## Explore the wider topic - Research and testing: https://www.agent-six33.com/journal/topics/research-and-testing — Daniel Ziedins · https://www.danielziedins.com · AGENT SIX33 https://www.agent-six33.com/journal/how-to-prioritise-assumptions-before-building