Prototypes

Scope technique · See it on the map

Runnable here

Building a working model of a product early, so stakeholders can react to something real.

When to use it

Use it when stakeholders genuinely can't agree on, or can't articulate, what they want until they see or use something -- a new user interface, an unfamiliar workflow, a physical layout. A prototype settles arguments a spec review keeps circling on.

When to avoid it

Skip it when requirements are already well understood and well-precedented -- prototyping a form field that behaves exactly like every other form field in the system burns time on feedback nobody needs. Also watch the build cost: a prototype meant to be throwaway is only cheap if it's actually kept throwaway; don't commission one you can't afford to discard.

Steps

1. Pick the specific unresolved question the prototype needs to answer -- 'does this navigation pattern make sense to a first-time user', not 'build the app'.
2. Build the minimum fidelity that answers that question -- paper sketches or clickable mockups for a workflow question, working code only if the question is about real behavior or performance.
3. Put it in front of the actual stakeholders or users it's meant for, not just the project team, and capture their reaction as structured feedback, not just impressions.
4. Revise and repeat progressive elaboration -- most prototyping is iterative -- until the specific question is answered.
5. Convert what you learned into requirements or scope decisions, and explicitly decide and document whether the prototype itself is discarded or becomes a starting point for real development.

What it produces

• A tangible model (sketch, mockup, working sample) stakeholders have reacted to.
• Requirements or scope decisions sharpened by that reaction.
• An explicit decision on the prototype's fate -- discarded, or carried forward as a build starting point.

Common pitfalls

• A throwaway prototype quietly becoming the product -- built quickly with shortcuts that were fine for a demo, then shipped under deadline pressure without anyone deciding to accept that debt.
• Building higher fidelity than the question needs, so the prototype takes as long as building the real thing and the 'fast feedback' benefit disappears.
• Showing the prototype only to the project team instead of the actual users, so the feedback validates the builders' assumptions instead of testing them.

Worked example

A regional theater company wants a new seat-selection flow for online ticket sales but the marketing lead and the box-office manager keep disagreeing in meetings about what 'simple' means. The PM has a designer build a clickable prototype of three seat map interactions in an afternoon -- no real backend -- and runs it with five recent ticket buyers. Two of the three interactions confuse every tester; the third is clear. That settles the internal argument in one session, and the PM explicitly logs the prototype as throwaway -- development will build the chosen interaction against the real seat inventory system from scratch, not extend the demo code.

Source

• PMBOK-6 §5.2.2.8

Where it comes from: this technique is named by the PMBOK Guide, 6th edition.