How to Run a Pre-Build Assumption Review With a Non-Technical Board

Boards approve builds they do not fully understand. This is a structural problem. The people sitting around that table bring commercial instinct, financial discipline, and strategic experience, but they rarely bring deep familiarity with how digital products are made, what they rest on, or where the hidden risk lives. So they ask about timelines and budgets, nod at wireframes, and the meeting ends with a green light nobody is fully equipped to give.

A build approved on untested assumptions does not become risky at launch, it was risky from the first vote.

The result is that the most consequential moment in a product's life, the decision to commit budget and build, passes without the assumptions underneath it being tested. Not because anyone is being careless, but because there is no structured way for a non-technical board to interrogate what they cannot see.

Simon's defining question for founders considering whether to push ahead is: are you solving a real problem that people will pay for, or are you in love with the solution? That distinction matters before a single line of code is written, and it matters especially in a boardroom where enthusiasm for a vision can move faster than scrutiny of what that vision rests on.

This article is a working guide for product owners, founders, and anyone responsible for presenting a build to a non-technical board. It covers the assumptions that need surfacing, the questions that surface them, and how to run a session that produces genuine alignment rather than polite agreement.

Why Boards Ask the Wrong Questions (and What to Do About It)

A board member's job is to protect the organisation. But without a framework for evaluating a digital product, that protective instinct tends to collapse into the questions they can answer confidently: how much will it cost, how long will it take, and who are the competitors. These are real questions, but they are not the questions that will determine whether the product works.

The deeper questions, does a genuine user need exist beyond the founding team's own experience, can someone complete the first meaningful action in the product without help, does the value proposition land within the first minute, rarely get asked. They are harder to quantify, harder to ask without sounding obstructive, and easier to assume have been answered somewhere else.

The Gap Between Intent and Understanding

Board members are not trying to avoid scrutiny. They simply do not know what they do not know. A product owner who presents confidently, with polished slides and a clear roadmap, signals that everything is under control. The board responds to that signal rather than probing beneath it. The assumption review exists to change that dynamic, to give board members a structured way to ask the questions they would ask if they knew which questions mattered.

The practical fix is to make the assumptions explicit before the meeting, not during it. When the right questions are built into the agenda rather than left to chance, the conversation shifts from approval theatre to genuine risk assessment.

The Five-Question Script for Your Board Session

The goal of the session is to pressure-test what the build is resting on. Five questions, asked in order, will surface the assumptions that matter most. They are designed to be asked by people who are not technical, and answered by people who are.

Frame the session at the start. Tell the board that these questions are not about whether the product is a good idea, that decision has been made. They are about whether the assumptions underneath the build have been tested enough to give the team confidence to proceed.

The Five Questions

1. What evidence do we have that real users, not just the founding team, experience the problem this product solves?
2. Has anyone outside the team attempted to use the product, and what happened when they did?
3. Can a first-time user reach the point where the product delivers its core value without assistance?
4. What would cause us to stop or significantly change the build after launch?
5. Which of our current assumptions has the least supporting evidence?

The fifth question is the one that does the most work. It asks the team to identify their own weakest ground, which is a very different thing from being asked to defend their strongest. A team that cannot answer it has not thought carefully enough about where the risk lives.

The question that does the most work is always the one that asks where confidence is thinnest, not where the case is strongest.

Run the session with the questions visible to everyone in the room. Do not read them aloud and move on, give the board time to sit with each one and respond before the product team does. The order in which people speak matters as much as what they say.

The Five Assumptions Every Build Rests On

Every digital product, regardless of category or complexity, is built on a small set of assumptions that the founding team holds to be true. These assumptions rarely get articulated explicitly. They are embedded in the brief, the roadmap, and the confidence with which the team presents the product, but they are rarely written down and tested as a group.

Surfacing them before a board session means the conversation has something concrete to work with. Here are the five assumptions that appear on almost every build.

• The problem is real and widespread, not just experienced by the founder or a small group.
• The target user will find the product and understand its value quickly enough to stay.
• The user can complete the first meaningful action in the product without friction or guidance.
• The current way people solve this problem is inadequate enough to make them switch.
• The team's internal view of what feels intuitive matches how a new user actually experiences the product.

That last assumption is the one that trips up the most builds. People who know a product deeply will naturally find it intuitive because they already understand its logic. A new user approaching the same product without that prior knowledge will have a completely different experience. Boards rarely ask about this gap, and product teams rarely volunteer it, because it requires acknowledging that the internal team is not a reliable judge of their own product's usability.

Before the board session, ask each member of the product team to write down the three assumptions they are least confident in. Compare the lists, the disagreements are more useful than the agreements.

When Silence Is Not Agreement

A board session that ends without challenge is not the same as one that ends with genuine alignment. Silence from a board member can mean they are satisfied, but it can also mean they did not follow a section closely enough to formulate a question, or that they did not want to appear uninformed, or that they assumed someone else had already raised the concern.

We worked with a pre-investment client whose investor conversations were covering technology, marketing, and market size, but never touching on how the product would feel to use or what user retention looked like. The silence was being read as approval. In fact, the investors had not grasped the emotional dimension of the product at all, and the team had to go back and build that case explicitly rather than taking the absence of questions as confirmation. The session had ended. The alignment had not happened.

Reading the Room More Carefully

The practical lesson is that a facilitator running a board assumption review needs to actively draw out the board rather than wait for questions to emerge. After each of the five questions, name a board member and ask what they heard, what reassured them, and what would make them more confident. This is the difference between a meeting that looks like agreement and one that actually produces it.

Product owners often feel that a smooth session is a successful one. The sessions that are most useful are usually the uncomfortable ones, where a board member asks the question nobody had prepared for and the team has to sit with it rather than deflect it.

After the session, send each board member a single-question follow-up: "Is there anything from today's conversation you would like to understand better before we proceed?" The answers are often more revealing than anything said in the room.

The Assumption Scoring Rubric

Once the five assumptions have been named and discussed, the board needs a way to evaluate them consistently. Without a shared scoring system, feedback is subjective and hard to act on. One board member's "I'm comfortable with that" is another's "that still feels uncertain to me, " and the product owner leaves the room not knowing where the real confidence sits.

The rubric below gives the board a common language. Score each assumption across three dimensions.

An assumption scoring nine across all three dimensions is well-supported and can proceed without further work. An assumption scoring three or four needs more investigation before the build goes ahead. The board does not need to run the investigation, they just need to agree on which assumptions require it and what form it should take.

Using the Rubric in the Room

Distribute the rubric at the start of the session rather than at the end. Ask board members to score each assumption as the conversation progresses, then compare scores at the end. The gaps between scores are where the real conversation starts.

How Unchallenged Assumptions Stall a Build

The cost of skipping this kind of review is not abstract. We worked on a grassroots football product where the founding team built based on what they believed the product should do, rather than what the market was telling them. We advised against overcomplicating the build and adding too many features before the core experience was validated, but the product grew in complexity until development had to stop entirely. We were no longer involved at that point, but the consequences were visible: more than a year later, there was still no marketable release, only a series of "coming soon" announcements on repeat.

The product had plenty of board-level enthusiasm. What it lacked was a structured moment where the assumptions underlying the build were scored, challenged, and either validated or addressed. By the time the complexity became unmanageable, too much had been committed to change course without significant cost.

Why Founder Conviction Is Not Enough

It is very easy to think: I have this problem, therefore everyone has this problem. That logic feels sound from the inside. It is the kind of reasoning that gets a product into a boardroom with polished slides and a compelling story. But conviction is not evidence, and a board that approves a build on the strength of a founder's certainty has not done its job, however warm the room felt afterwards.

After every product launch we have been involved in, user feedback has taken the product in directions the internal team did not anticipate. That is how products develop. But it argues strongly for involving real users in the conversation before the build, not only after it.

Running the Session: Facilitation Tips for Product Owners

The person running this session is usually the product owner or the lead consultant, and their job is harder than it looks. They need to create enough psychological safety for board members to admit uncertainty, while keeping the conversation focused enough to produce a decision. Those two things can pull in opposite directions.

A few practical approaches make this easier.

1. Send the five assumptions and the scoring rubric to board members 48 hours before the session. People who have had time to think give better responses than people reacting cold.
2. Start the session by naming what you are trying to achieve: a clear view of where confidence is high, where it is low, and what needs to happen before the build proceeds.
3. When a board member says something is unclear, do not immediately clarify, ask what would make it clearer. Their answer usually points to the assumption that actually needs work.
4. Keep a visible log of what is said in real time. Seeing their own words reflected back to them helps board members build on each other's thinking rather than repeating concerns in different language.

Resist the urge to fill silence. When a board member is thinking through a score or formulating a concern, the most useful thing a facilitator can do is wait. The instinct to reassure is understandable, but it tends to short-circuit the reflection that produces genuine insight.

Managing the Tension Between Time and Depth

Most board sessions are time-constrained, and assumption reviews can feel like they are slowing down a decision that has already effectively been made. Frame the session as risk reduction rather than delay. A 90-minute review that surfaces one significant untested assumption has paid for itself many times over compared to discovering the same assumption mid-build.

What to Do With the Results

The session produces three outputs: assumptions that are well-supported and can proceed, assumptions that need more evidence before the build goes ahead, and assumptions that are so thinly supported they represent a genuine risk to the build's viability. The product owner's job after the session is to translate those three categories into a clear action plan.

For assumptions that need more evidence, name the method and the timeline. If the user need assumption scored low, the answer is a round of structured user conversations or a survey before development begins. If the onboarding assumption is uncertain, the answer is a prototype test with people outside the founding team. The board does not need to run these activities, they need to see that there is a plan to address each gap before the build proceeds.

Creating a Living Assumptions Document

A single assumption review at the start of a build is useful. A document that tracks which assumptions have been tested, what the testing found, and how the build has responded is more useful still. It gives the board something to return to at each milestone, and it creates accountability for the team to keep their assumptions current rather than treating the pre-build review as a box to tick and forget.

The document does not need to be long. One page, updated at each significant milestone, with the assumption, the evidence behind it, and its current confidence score. That is enough to keep the board genuinely informed rather than periodically updated.

Conclusion

A pre-build assumption review is the moment where a board that cares about outcomes gets a structured way to ask the questions that actually matter, and a product team gets to find out where their confidence is real and where it is habit.

The five assumptions, the scoring rubric, and the five-question script are not complicated tools. They work because they give non-technical board members a language for engaging with a product they cannot evaluate on technical grounds, and because they force the product team to articulate what they know, what they believe, and what they have not yet tested.

The grassroots football product we worked on had none of this structure in place. The assumptions stayed implicit, the complexity grew unchecked, and the product stalled. That outcome was not inevitable, it was the result of a series of decisions that a structured review would have challenged much earlier.

Boards approve builds they do not fully understand because nobody has given them a better way to engage. This is the better way. Run the session before the build starts, not halfway through it, and the conversation you have in that room will save time, money, and the kind of rework that compounds every month it goes unaddressed.

Start the conversation about your pre-build review

Frequently Asked Questions