Scope correction

Refusing to fix the price when discovery had changed the product

Discovery did its job too well — the product concept moved. Rather than fixing a price on a design that no longer matched, I inserted a short phase to finish the design first.

A short, bounded phase rather than an open-ended extension
~2 weeksA short, bounded phase rather than an open-ended extension
Patient, guardian, clinic, provider and administrator flows closed
5 actorsPatient, guardian, clinic, provider and administrator flows closed
Fixed price deliberately not quoted against a moving design
Price held backFixed price deliberately not quoted against a moving design

The client

A paediatric clinic in the United States building a live patient queue product, founder-led, where discovery sessions kept surfacing new flows because the founder was learning her own operation as the sessions ran.

The engagement

A short design-finalisation phase inserted between discovery and build, with the fixed-price MVP quote deliberately held back until the flows were closed.

The problem

A good discovery changes the product — that is what it is for. But the commercial machinery expects discovery to end with a fixed-price quote, so the standard move is to quote against the design as it stood on the last day and absorb the difference later as change requests, arguments, or margin. In a queue product the risk is concentrated in the unglamorous states: no-shows, guardians, arrivals out of order.

What I did

I said plainly in the proposal that the concept had changed during discovery and that fixing a price was therefore not responsible, which is a sentence most proposals avoid. The alternative offered was small and bounded: roughly two weeks to close the flows for all five actors, define the behaviour for the scenarios that actually decide whether a live queue works, and bring the backlog to a state a developer can start from. The edge cases were named explicitly rather than left as 'error handling', because in this product they are the product. Only after that phase would the MVP be quoted — against a finished design rather than against a moving one.

What was built

A design-finalisation phase covering the flows for every actor — patient, guardian, clinic, provider, administrator — with explicit behaviour defined for the scenarios that decide a queue product: check-in, queue updates, arrivals, no-shows, guardians and patient communication, plus a backlog brought to development-ready.

On the table at the end

  • Design-finalisation proposal with the reason for the extra phase stated plainly
  • Updated scope across five actor flows
  • Defined behaviour for check-in, queue updates, arrivals, no-shows and guardians
  • Development-ready backlog and finished prototype

What it changed

Protected both sides from a fixed price set against a moving design: a two-week phase to close the flows and edge cases, after which the MVP could be quoted against something real instead of against a snapshot everyone already knew was stale.

How it ran

  1. 01

    Say why the price is not ready

    The concept changed during discovery, stated plainly in the proposal rather than absorbed silently into a fixed quote.

  2. 02

    Bound the extra phase

    Roughly two weeks with a defined output, not an open-ended design extension.

  3. 03

    Close every actor's flow

    Patient, guardian, clinic, provider and administrator — because a queue is a multi-actor system and gaps hide between roles.

  4. 04

    Name the edge cases

    Check-in, queue updates, arrivals, no-shows, guardians and patient communication specified as behaviour, not as error handling.

  5. 05

    Quote against something finished

    The fixed-price MVP proposed only once the design and backlog were development-ready.

Something similar on your plate?

Thirty minutes, no deck. I will tell you whether it is worth doing at all.