Strategy
How to identify assumptions in a business proposal
Review a business proposal with an assumption register: separate evidence from expectations, choose a useful test and explain how findings could change the plan.
A polished proposal can still depend on an unanswered question
A proposal can explain the offer, the timeline and the delivery process while leaving its most important uncertainty unstated. Perhaps it assumes that customers want a particular format, that a supplier will be available or that the team can absorb additional work. A confident sentence does not remove the need to check what makes it plausible.
This guide offers a practical way to inspect those assumptions before a commitment grows. It belongs to the business-strategy themes explored by the George Antonio Nehme editorial project. The worksheet and example are original editorial suggestions, not accounts of his personal work or a method that promises commercial success. The aim is to make the next decision easier to examine.
Separate what you know, expect and need to find out
Read the proposal once for its main argument. Then review sentences that imply a future behavior or a dependable capability. Customers will complete the form, the team can deliver within the requested window and the partner will provide support all deserve a second look. They may be reasonable expectations, but they are not automatically established facts.
For each important statement, add a note describing its basis. An observation might come from a particular customer conversation or a completed delivery. An estimate might combine previous work with a new workload assumption. An unanswered question may have no direct evidence yet. Keep those categories distinct. A past example can inform a new proposal without proving that different customers or conditions will behave the same way.
Create a small assumption register
A simple register can contain five fields: the claim, why it matters, the evidence currently available, what remains uncertain and the next decision. Describe the assumption as a specific statement that could turn out to be wrong. Avoid entries such as customers like quality, which are too broad to tell you what to examine.
Consider instead: the intended customers can attend a live session during their normal working day. If that statement is wrong, the delivery format may need to change. The evidence field could record the relevant conversations and their limits. The uncertainty field might note that the people responsible for approving staff time have not been consulted. The decision field then explains why resolving that gap matters before a date is announced.
Choose the uncertainty that could change the plan
You do not need to investigate every sentence with equal effort. Ask what would happen if an assumption failed. Would the proposal need a different audience, a different format, another capability or a later start? Give attention to questions that affect the underlying offer and to dependencies that cannot easily be changed after work begins.
The GOV.UK Service Manual recommends turning unsupported assumptions into research questions when planning user research. That public-service guidance is a useful reference for asking clearer questions; it is not a business approval standard. Here, the practical application is to replace a vague confidence claim with a question whose answer could alter a specific choice. Record that choice before selecting an activity to investigate it.
A hypothetical example: proposing a booking workshop
Imagine a small team proposing a live workshop to help local businesses organize appointment requests. The proposal assumes that participants need training, that they can attend the suggested session and that they are allowed to change their current process. This is a fictional example. None of those assumptions is presented as a verified fact about a real market.
Before preparing every workshop asset, the team could ask prospective participants to describe a recent appointment request and where it became difficult. That conversation might reveal a training question, an unclear responsibility or a limitation in the existing system. Those are possible findings, not predicted results. The team should avoid treating enthusiasm for a presentation as evidence that the proposed workshop addresses the actual difficulty.
A separate question concerns attendance. The person interested in the topic may not control the working schedule. A conversation about availability therefore answers something different from a conversation about the underlying problem. Keeping those questions separate prevents a positive response to one from quietly becoming support for all of the proposal's assumptions.
Match the evidence to the claim you want to make
Choose an activity that can answer the selected question without creating an unnecessary commitment. A discussion can clarify someone's account of a problem. A walkthrough can reveal how a task is currently performed. A limited trial can examine whether a delivery step is workable under the conditions of that trial. Each produces a different kind of information.
Be explicit about the limits. A favorable comment is not a completed purchase. One smooth trial is not proof of capacity at a larger scale. A conversation with an existing customer does not automatically represent people who have never used the service. Explain what the evidence supports and what still needs investigation. Avoid extending a narrow observation into a broad market claim simply because that claim makes the proposal more persuasive.
Write the consequence before reviewing the result
For the important assumption, state what you would do if the evidence supports it, challenges it or remains inconclusive. The options might be to continue with the same format, revise the offer, run a different test or postpone the decision. This gives the investigation a purpose beyond collecting encouraging comments.
Also name who will review the evidence and which information they need. If a dependency belongs to a supplier or another team, identify it as a dependency rather than assigning yourself control over it. Record the review point in the proposal so that an open question does not disappear when the document moves into delivery.
Make uncertainty visible without making the proposal unreadable
The final document does not need to become a catalogue of every imaginable risk. Summarize the assumptions that materially affect the offer, describe the evidence available and explain the next check. Supporting detail can remain in the register. Readers should be able to distinguish a confirmed arrangement from a planning expectation.
Finish the review with a practical question: if this assumption proves wrong, does the proposal already explain our next choice? Where the answer is no, add a clear decision point. A useful proposal communicates both an intended direction and the limits of what is currently known. That makes it a working basis for discussion rather than a confidence claim that nobody can inspect.
Sources and context
- George Antonio Nehme — editorial profile and business strategy
- GOV.UK Service Manual: Plan user research for your service
This is an editorial guide, not a statement of personal experience by George Antonio Nehme.
