Scope creep in software is painful but recoverable. A sprint gets extended, a feature gets pushed to the next release, the timeline slips by a week. The cost is real but bounded.
In hardware, scope creep is different in kind. If a new feature requires an additional connector that was not in the original layout, you may need a new PCB revision. That is not a week's delay — it is 6–10 weeks and another manufacturing run.
The three root causes of hardware scope creep
Most hardware scope creep traces back to one of three root causes:
- 1Undefined V1 scope — the team never explicitly agreed what is in or out of V1. "Nice to have" features get added because no one is empowered to say no.
- 1Late requirement discovery — a real constraint (e.g. IP rating, certification requirement) is discovered after design work has started. This is almost always a brief failure.
- 1Moving target requirements — stakeholder requirements change during the project. This is a governance failure.
The first two are preventable with a good scoping process. The third requires a change control process.
The V1 scope lock document
Before any PCB layout or significant firmware architecture work begins, produce a one-page V1 scope lock document. It should specify:
- What the V1 prototype must do (the demo)
- What is explicitly not in V1 scope (the exclusion list)
- The definition of done
- Who has authority to change the scope
- The process for handling a change request
The exclusion list is as important as the inclusion list. "No enclosure in V1" eliminates an entire class of PCB dimension constraints that would otherwise need revisiting.
One practise that works: give every feature request during the build a formal verdict of In Scope, Deferred to V2, or Evaluate at Gate. Only "In Scope" changes the work. Nothing else does.
Change control in hardware projects
Any change to the PCB design or firmware architecture after the design review gate should go through a formal (lightweight) change request:
- 1Description of the change
- 2Impact assessment — time, cost, dependencies
- 3Decision (approve / reject / defer)
- 4Record of who approved it and when
This does not need to be bureaucratic. A shared spreadsheet or a GitHub issue with a label is enough. The goal is a record — so that when the project is over, you know why the design is what it is.
When to run a scoping sprint before build
If any of these are true, run a scoping sprint before committing to a build engagement:
- You have not written a V1 scope definition
- Your brief does not have an explicit exclusion list
- You have not identified all regulatory requirements
- Multiple stakeholders have different mental models of what V1 looks like
- You have received quotes with a range wider than 3x
A 5–10 day Blueprint Sprint eliminates most brief ambiguity and produces a scope document that architects a clean build engagement.