Product Analysis

Scope technique · See it on the map

Runnable here

Turning a stated product idea into a defined, actionable set of requirements and deliverables.

When to use it

Use it during Define Scope when the product itself -- not just the project's process or timeline -- is under-specified: you have a product concept or a one-line description and need to work out its functions, components, and requirements before Create WBS can decompose anything.

When to avoid it

It applies to product deliverables, not to every project. A project that is entirely process, event, or service work with no product being built or modified has nothing for product analysis to analyze -- don't force a value-engineering pass onto a deliverable that's actually an activity or a service outcome.

Steps

1. Start from the stated product description or concept, however informal, and name its major functions -- what it has to do, not how.
2. Break each function into the components or subsystems that deliver it (product breakdown) so the product's structure, not just its purpose, is visible.
3. For each component, ask whether it earns its cost relative to the function it serves (value engineering/value analysis) -- flag anything that looks like it costs more than the function is worth.
4. Turn each function and component into specific, testable requirements (requirements analysis) -- 'the checkout flow completes in under 5 steps', not 'checkout should be easy'.
5. Validate the resulting requirement set with the people who stated the original product concept before it feeds Create WBS.

What it produces

• A structured breakdown of the product's functions and components.
• A set of specific, testable requirements derived from the product description.
• Flags on any component whose cost looks disproportionate to the function it serves.

Common pitfalls

• Treating product analysis as an abstract exercise -- naming generic functions ('user management', 'reporting') without ever converting them into requirements someone can build or test against.
• Applying it to non-product deliverables (a training rollout, a process change) where there's no product structure to analyze, producing busywork instead of clarity.
• Skipping the value-engineering pass and accepting every stated component at face value, missing the chance to drop or simplify something that costs more than it delivers.

Worked example

A community college is told to build 'a student advising portal'. The PM runs product analysis: breaks the concept into functions (schedule an appointment, view degree progress, message an advisor), then components under each (a calendar service, a degree-audit data feed, a secure messaging channel). Value engineering flags the secure-messaging channel as expensive relative to its use -- advisors already use campus email -- so the PM proposes dropping it in favor of a mailto link, saving a build the sponsor agrees wasn't earning its cost. The remaining functions become specific requirements ('a student can book an advising slot at least 48 hours out, in under 3 clicks') that feed Create WBS.

Source

• PMBOK-6 §5.3.2.5

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