September 7, 2026 · 6 min read
TL;DR: Prototypes, pilots and proofs of concept appear in 31 of the bank's answer options: 10 keyed, 21 wrong. Every keyed instance has the same precondition, which is that people have already tried to describe something to each other and failed. When the gap is trust or concern rather than comprehension, the prototype loses.
Building something rough to settle an argument is one of the genuinely strong moves in project management, and the bank keys it. It also offers it constantly in situations where nothing is unclear, which is where candidates lose the mark.
Divergent mental models of the same thing. The clearest item states it in the stem: while gathering requirements you find people picture the same feature very differently.
Keyed: sketch a storyboard or prototype of the requirement so stakeholders can see it, adjust it, and agree. The explanation is worth reading twice, because it identifies why the tempting answer fails. Asking the stakeholders to elaborate more clearly and booking a meeting for next week changes nothing, because it produces more words about the same unshared mental model. Words have already failed once.
A storyboard, wireframe or throwaway prototype replaces description with something everyone can look at, and the disagreement becomes visible and specific: two people who both said "a summary screen" can now point at what they each meant. It is also fast, because a sketch can be redrawn inside the same conversation that exposed the problem.
The same logic beats a stronger-looking option elsewhere. A sponsor says the development team does not fully grasp the requirements. Showing them the project management plan with the scope baseline is offered, and it is the closest miss. Keyed is having the team build a high-level prototype and review it with all stakeholders, because a comprehension gap closes against something concrete rather than against a better description. Divergent understandings survive any number of readings of the same document; they surface within minutes when everyone is looking at the same artifact.
In the real environment, which is a separate lesson the bank teaches with an unusually physical example.
An agile team builds quality-checking software for workers on a footwear assembly line. The IT department approves the mid-project demonstration enthusiastically. In use, the software is unusable, because the workers' gloves are too thick to register on the on-screen buttons.
Keyed for preventing this in future: have customers test prototypes and incremental releases in the environment the product will be used in. The distractors are each a step short. Building a realistic simulation of end-user conditions for developers to test against still depends on the team imagining those conditions correctly, which is exactly what failed. Dealing directly with the customer department that writes the requirements repeats the arrangement that produced the miss, since IT approved the demo. Shipping adjustable accessibility settings addresses a different problem than gloved hands.
A demo to the people who commissioned the software is not a test. A test happens where the work happens.
Common trap: proposing a pilot to answer a stakeholder's doubt. At the start of a watershed restoration project, a key stakeholder worries the chosen approach will miss the environmental goals and overrun the forecast. Launching a pilot phase to prove the approach and adjust from early results sounds like exactly the empirical move the exam rewards. It loses to meeting the stakeholder to understand the concerns and find ways to involve them. The stakeholder has raised two distinct doubts, and neither can be answered until the project manager knows what sits behind them: a technical objection, distrust of the estimate, or a stake the plan has not reflected. A pilot proves something to somebody whose objection you have not yet identified. This bank keys going and asking first, and offers the build-something option as the trap.
Build something rough when nobody can agree what a thing is. Go and ask when somebody has already told you what worries them.
| The gap in the stem | Prototype option | Keyed |
|---|---|---|
| Stakeholders picture the same feature differently | Storyboard or prototype | Storyboard or prototype |
| Team does not grasp the requirements | High-level prototype reviewed with stakeholders | The prototype, over showing the scope baseline |
| Product unusable in the real workplace | Test prototypes in the target environment | Test in the target environment |
| Stakeholder doubts the approach and the forecast | Launch a pilot phase to prove it | Meet them to understand the concerns |
| PMO rolling out a new way of working | Pilot to the PMO, then the organisation | Enable per-project tailoring and ongoing improvement |
The distinction across those rows is consistent. When nobody can agree what a thing is, build a rough version of it. When somebody has told you what they are worried about, go and find out what they mean.
When is building a prototype the keyed answer on the PMP exam? When stakeholders picture the same requirement differently. Words have already failed at that point, and the bank keys a storyboard, wireframe or throwaway prototype that turns an abstract requirement into something everyone can point at.
Why does a prototype beat showing people the scope baseline? Because a comprehension gap does not close against a better description. In one bank item the sponsor says the team does not grasp the requirements, and showing them the plan with the scope baseline is the closest miss to building a prototype.
Where should prototypes be tested? In the environment the product will actually be used in. One bank item turns on assembly-line workers whose gloves were too thick for on-screen buttons, a defect no developer-side simulation would have surfaced.
Is a pilot the same as a prototype? Not on the exam. A prototype settles what a requirement means before much is built. A pilot runs a real version at limited scale, and the bank treats it more sceptically, rejecting it when the underlying objection has not been understood yet.
PMP Practice's 2,141 questions are certified against PMBOK 8 and the July 2026 ECO, with every wrong answer explained rather than just marked wrong. Start the free 20-question sample — no card, no signup required to try it.
Related reading: Requirements Elicitation: Which Technique the Scenario Actually Wants and Stakeholder Resistance: 17 Scenarios, and the Answer Is Always to Go and Ask Them Why. Scope is mapped on the Process domain study page.
When is building a prototype the keyed answer on the PMP exam?
When stakeholders picture the same requirement differently. Words have already failed at that point, and the bank keys a storyboard, wireframe or throwaway prototype that turns an abstract requirement into something everyone can point at.
Why does a prototype beat showing people the scope baseline?
Because a comprehension gap does not close against a better description. In one bank item the sponsor says the team does not grasp the requirements, and showing them the plan with the scope baseline is the closest miss to building a prototype.
Where should prototypes be tested?
In the environment the product will actually be used in. One bank item turns on assembly-line workers whose gloves were too thick for on-screen buttons, a defect no developer-side simulation would have surfaced.