Scoping & Proposals

A proposal is a promise with a price on it. Getting there responsibly takes the same discipline Discover and Define apply internally, aimed at a client’s problem instead of our own roadmap.

Understand before you propose#

The instinct with a client is to answer fast: they describe a need, and it’s tempting to sketch a solution in the same conversation. Resist that. A solution proposed before the problem is understood is a guess wearing a proposal’s clothes.

The same questions Discover asks internally apply here:

Who actually has this problem, and what are they trying to accomplish?
What’s blocking them today, specifically: not “the process is slow,” but where and why?
What happens if it doesn’t get solved?

A client’s first framing of their need is a starting point, not a spec. Sometimes what they ask for and what they actually need are the same thing. Sometimes they aren’t, and the job in this stage is to find out which, before a number gets attached to anything.

Size honestly#

Once the problem is understood, size the work before promising a shape. Systeric sizes everything (internal or client-facing) against the same three categories from Half Strategy:

Size	Rough scale	What it means for a client engagement
Sand	Under 1 person-sprint	A small, contained fix, rarely its own proposal
Pebble	1–2 person-sprints	A well-scoped piece of work with a clear deliverable and timeline
Rock	More than 2 person-sprints	A significant bet: needs the first pebble carved out and proven before the rest is committed to

Honest sizing means resisting the pull to shrink a rock to make it sound approvable, and resisting the pull to pad a pebble because the client seems willing to pay for more. If an engagement looks like it will take months with no clear milestone before then, the same question applies as it does internally: what’s the first pebble? Usually it exists, and it becomes the first phase of the proposal rather than a vague promise to figure out the rest later.

Write a proposal that states the bet#

A good proposal isn’t a quote. It reads like a point of view, not an order form. At minimum it states:

The problem. In the client’s terms, specific enough that someone reading it cold understands what’s actually being solved and why it matters. The same bar Discover holds internal problem statements to.
The bet. The approach we believe solves it, and why, including the tradeoffs we chose and the ones we didn’t. A bet is a stated belief, not a guarantee, but it should be a real point of view: this is the shape we’d build, and here’s the reasoning.
The shape of the work. What ships, in what order, over what timeframe. Milestones the client can actually see, not internal task breakdowns.
What’s explicitly out of scope. As specific as what’s in scope, with the reason. “We are not building X in this phase, because it requires Y and would double the timeline” is a real scope decision. “We’ll handle the advanced stuff later” is not; it’s a door left open for a dispute six weeks in.

This mirrors what Define requires internally before anything moves to Build: an explicit in-scope and out-of-scope list. A proposal that skips the out-of-scope section isn’t more generous; it’s a future disagreement, deferred.

What separates a proposal from an order-taker’s quote#

An order-taker’s quote restates what the client asked for, attaches a price, and stops thinking. It reads well because it agrees with everything, and fails later because agreeing with everything means never testing whether the request was the right one.

A real proposal has a point of view. It can say “here’s what you asked for, and here’s why we’d build it slightly differently” without being asked to. It names the risk it sees and states the assumption it’s making, the same standard Operating with Clarity holds internal work to: state your position in one sentence, and don’t hedge behind “we’ll figure it out as we go.”

The test is simple: if a proposal could have been written without ever talking to the client (just restating their words back with a number attached), it’s a quote, not a proposal. If it required understanding their problem well enough to disagree with parts of their framing, it’s the real thing.

Where this fits#

Scoping doesn’t replace Discover and Define: it’s those same stages, run against a client’s problem before an engagement is signed rather than against an internal roadmap item after it’s chosen. The proposal is the artifact that comes out the other side: the equivalent of a definition doc, written for someone who hasn’t seen our process and needs it to stand on its own.

Once a proposal is agreed, the work it describes runs through the same cadence as everything else: see Running an Engagement for what happens next.