PMP · Question #55
A medium-sized company has been exploring new marketing tactics with regard to launching a new product. New product creation is no small task. In the end, it was too big of an expenditure for the comp
The correct answer is B. Train the team to first find the minimum viable product (MVP) that will deliver value to the. To mitigate large expenditures and manage risk in new product development, project managers should focus teams on identifying and delivering a Minimum Viable Product (MVP) first.
Question
Options
- AMake use of kanban boards so all stakeholders have a clear view of the project and provide their
- BTrain the team to first find the minimum viable product (MVP) that will deliver value to the
- CIncrease the contingency reserve and prepare the team for applying fast-failing techniques when
- DAdopt a chain management approach, developing products based on the same platform and
How the community answered
(60 responses)- A2% (1)
- B85% (51)
- C5% (3)
- D8% (5)
Why each option
To mitigate large expenditures and manage risk in new product development, project managers should focus teams on identifying and delivering a Minimum Viable Product (MVP) first.
While Kanban boards enhance visibility, they do not inherently address the problem of excessive initial expenditure or ensure product viability without an MVP approach.
An MVP strategy involves developing a product with just enough features to satisfy early customers and provide feedback for future product development, which significantly reduces initial expenditure and risk by validating market interest before large investments are made. This agile approach prevents over-investment in unproven product ideas, aligning with lean startup principles.
Increasing contingency reserve and preparing for fast-failing techniques addresses risk management but does not prevent the initial large expenditure on a product that might ultimately fail, which an MVP aims to avoid.
Adopting a chain management approach for platform-based products doesn't directly address the initial large expenditure risk for new product creation in the same way an MVP does.
Concept tested: Minimum Viable Product (MVP) strategy
Source: https://www.scaledagileframework.com/minimum-viable-product/
Topics
Community Discussion
7B is correct. The stem screams agile mindset, and MVP is the go-to move for new product work where you need to validate value before committing big money. C trips people up because fast-failing sounds agile, but the real lesson here is finding the minimum viable product early so you do not overspend.
I first leaned toward C because fast-failing sounds like exactly what you do when a project bombs on cost, but re-reading the stem changed my mind. The real issue is they sunk too much money into a full product build before discovering it was unaffordable, which is a classic scope and value problem. B fixes that at the root by training the team to find the MVP first, so you deliver value early and avoid the giant expenditure trap altogether. This one is a 45-second read and answer, do not overthink it, flag and move on.
B. Saw this last month, MVP is the agile answer they want every time.
Agree on B but watch your clock because if the stem mentions discovery or market testing they want MMF, not MVP, and that distinction can eat 90 seconds if you overthink it.
I first leaned toward C because the fast-failing part sounded like a good way to avoid big expenditures, but then I realized the question is really about preventing that huge investment in the first place. B makes sense because finding the minimum viable product means you deliver value without committing to the full expenditure, which is exactly the lesson here.
B is correct and you should bank it in under 20 seconds, but watch for a trap variant where they swap in "iterative development" as a distractor, that one eats your clock if you overthink it.
B is the right call here because the stem basically screams "too big" which points straight to starting small with an MVP. Anyone know if the exam tends to frame MVP as an agile-only concept or does it show up in predictive project contexts too?