Product Breakdown Structure: PBS vs WBS & Example [2026]

Ask a clinic owner what their new website includes and you will hear a list of things: a home page, an online booking form, patient accounts, maybe a blog. Nobody mentions the testing, the hosting setup, or the weekly status calls, because customers picture the result long before they picture the work. A product breakdown structure turns that natural way of thinking into a disciplined planning tool. This guide explains what a product breakdown structure is, how it differs from a WBS, and how it appears on the PMP® and CAPM® exams.

What is a product breakdown structure?

A product breakdown structure (PBS) is a hierarchical chart of everything a project will produce. It starts with the final product at the top and breaks it down, level by level, into the components and sub-components that make it up. Because it lists products rather than activities, a PBS describes what the project will deliver before anyone plans how the work will be done.

Each level of a PBS answers one question about the level above it: "What is this made of?" The entries are written as nouns or as completed outcomes (for example, "booking system" or "approved floor plan"), never as tasks such as "design the booking system." Decomposition stops when each product is small enough to be described clearly, assigned to an owner, and checked against quality criteria.

A PBS normally distinguishes two kinds of products:

• Internal products. Products that the project team creates itself, such as custom software or a training manual.
• External products. Products that come from outside the project, such as a payment service from a provider or equipment delivered by another project. They are not built by the team, but the final product cannot work without them.

Consider Lakeside Physiotherapy, a clinic that hires a web agency to build a patient website. The top of its PBS is "patient website." The second level lists the booking system, the clinic information pages, the patient accounts, and the online payment service. The payment service is an external product, because the clinic's payment provider supplies it and the agency only connects it. Marking it as external tells the project manager, on the first day of planning, that one part of the result depends on a third party.

Where the product breakdown structure comes from

The product breakdown structure comes from product-based planning, the planning technique at the heart of the PRINCE2 method, which is widely used in the United Kingdom, Europe, and Australia. In product-based planning, the team first defines the products, then plans the work needed to create them. The PBS is the first of three linked tools:

1. The product breakdown structure lists every product in a hierarchy.
2. Product descriptions define each product's purpose, composition, and quality criteria, so everyone knows what "finished" means for it.
3. A product flow diagram shows the order in which the products must be created, since some products depend on others.

PRINCE2 also separates specialist products (the things the customer will use, such as the booking system) from management products (the plans, reports, and logs that the project itself needs). Both kinds can appear in a PBS, which is one reason it suits projects that need tight control over documentation.

PMI's standards use different vocabulary. The PMBOK® Guide includes product breakdown among the product analysis techniques a team can use while it defines scope, but PMI's planning artifact for scope is the work breakdown structure. In other words, a candidate studying for the PMP will meet the idea of breaking a product into parts much more often than the term "PBS" itself. The UK's Association for Project Management publishes a useful briefing on how the two structures work together.

Ready to take the next step in project management?

200,000+ Professionals Taught by Our Instructors

PMP® Certification Training

PMP Training →

CAPM® Certification Training

CAPM Training →

Learn Project Management

PM Course →

Product breakdown structure vs. work breakdown structure

A product breakdown structure shows the products a project will deliver, while a work breakdown structure (WBS) decomposes the total scope of work, including project management, testing, and other work that produces no standalone product. The PBS answers "what are we delivering?" The WBS answers "what work is needed to deliver it?"

Note that a PMI-style WBS is also deliverable-oriented, so its upper levels can look very similar to a PBS. The difference appears lower down and around the edges. The WBS must contain all the work in scope (the 100% rule), so it adds branches the PBS never shows, such as project management, integration and testing, and training delivery. Its lowest level is the work package, which carries estimates, a schedule, and an owner. The WBS is also one of the three parts of the scope baseline, alongside the WBS dictionary and the project scope statement, and a PBS has no such formal role.

The two structures also check each other. If a product in the PBS has no work package in the WBS, nobody is planning to build it. If a work package contributes to no product and to no project management need, it is probably unnecessary work. For that reason, many teams build the PBS first, agree it with the sponsor, and then derive the WBS from it.

Product breakdown structure example

The example below continues the Lakeside Physiotherapy website. The final product, "patient website," sits at level 1. The table shows the level 2 products and the level 3 components beneath each of them.

Notice what the PBS does not contain. There is no line for user testing, for the weekly meetings with the clinic, or for training the receptionists to manage bookings. Those are activities, so they appear in the WBS. When the agency's project manager, Daniel Osei, derives the WBS from this PBS, he adds a project management branch, a testing branch, and a training-delivery branch. He also links every level 3 component to at least one work package, so that nothing on the product list is left without planned work.

How to create a product breakdown structure

You create a product breakdown structure by naming the final product, listing every product that makes it up, and arranging those products into levels until each one can be described and checked. The steps below work for most projects, predictive or hybrid.

1. Name the final product and agree on it with the sponsor. One clear top-level product prevents the team from building a structure around the wrong goal.
2. List the products with the people who know them. Run a short session with the team, the customer, and subject matter experts, and capture every product they mention. Grouping a long, messy list with an affinity diagram works well at this stage.
3. Consolidate the list. Merge duplicates and rename vague entries ("website stuff") into specific products ("clinic information pages").
4. Arrange the products into levels. Place each product under the larger product it belongs to, and keep decomposing until every product at the bottom can be owned and quality-checked.
5. Mark internal and external products. External products signal dependencies on suppliers or other projects, which the project manager should track as risks.
6. Write a short description for each product. Include its purpose, what it consists of, and the quality criteria it must meet. These descriptions often draw directly on the requirements from requirements gathering.
7. Review the PBS with stakeholders, then derive the WBS. Confirm that the structure is complete, and then plan the work packages needed to create each product.

To illustrate step 6, the description for Lakeside's "confirmation emails" component might state its purpose (tell patients their booking details), its composition (date, time, therapist, and a cancellation link), and its quality criteria (sent within one minute of booking and readable on a phone).

Why use a product breakdown structure?

A product breakdown structure helps a project agree on its outcome early, in language the customer understands, and it gives the team a complete product list against which to check the plan. The main benefits include the following:

• Shared understanding with the customer. Customers can review a list of products far more easily than a list of tasks, so gaps and misunderstandings surface before the work starts.
• Fewer missing deliverables. Decomposing the final product level by level exposes components that nobody had mentioned, such as the privacy notice in the Lakeside example.
• Clear quality criteria. Each product gets a description that defines when it is acceptable, which supports formal acceptance later.
• A solid foundation for the WBS. The product list becomes the skeleton of the work breakdown, which in turn drives estimates and the schedule.
• Visible dependencies. External products show early where the project relies on suppliers or other teams.

Consider a hospital that commissions a new outpatient wing. A PBS that lists the building, the medical equipment, the IT network, and the signage makes it obvious that the equipment comes from a separate procurement project. The project manager can then plan the handover dates with that project instead of discovering the dependency during construction.

Product breakdown structure template

A simple product breakdown structure template needs only a few columns: an identifier, the product name, its parent product, whether it is internal or external, and a short description with quality criteria. A spreadsheet works well for this, and the same structure can be drawn as a tree diagram for presentations.

Keep the numbering consistent with the WBS when you derive it, so that every work package can be traced back to a product. Many teams also add an owner column once the WBS assigns responsibility. Mind-mapping software, a whiteboard, or the WBS feature of a project management tool can all produce the tree view, as long as the entries stay products rather than tasks.

Other breakdown structures in project management

The product breakdown structure is one of several hierarchical charts that project managers use, and each one breaks down a different subject. Knowing which structure answers which question helps you pick the right one and avoid confusing them.

The PMBOK® Guide also includes a value breakdown structure (VBS), which assigns an expected value to each element of the WBS. A VBS helps a team decide which deliverables are truly essential when time or money runs short.

Product Breakdown Structure on the PMP® and CAPM® Exams

In the PMP® exam, the term "product breakdown structure" appears rarely, because the exam uses PMI's vocabulary. The idea behind it, however, appears often. Scenarios describe a customer's list of deliverables, a product description, or a hybrid project where a client brings its own planning documents. If a question asks how to make sure the plan covers everything, remember that a product list is not yet the full scope. The WBS must also contain the project management work, the testing, and any other work the agreement requires. Note that a common distractor treats an approved product list as complete, or reaches for a change request when the missing work is already inside the agreed scope and nothing has been baselined yet.

The CAPM® exam covers the same idea through its predictive, plan-based domain, which carries 17% of the questions. CAPM questions are also situational, with no definition questions, and the scenarios are simply shorter. Our best-selling PMP Complete Study Guide, the most complete study guide on the market, explains scope decomposition the way the exam tests it, and our CAPM Complete Study Guide does the same for entry-level candidates.

PMP Practice Question: Product Breakdown Structure

A project manager at a technology vendor is planning the rollout of patient self-service kiosks for a regional hospital network under a signed contract. The hospital's project office, which follows PRINCE2, supplied a product breakdown structure that its sponsor approved. It lists the kiosks, the check-in software, the network links, and the floor signage. The project manager's team copied this structure into the WBS and built the first cost estimate from it. During the estimate review, a team lead points out that nothing in the estimate covers user acceptance testing, project management, or the staff training sessions, all of which the contract lists as the vendor's responsibility. The scope baseline is scheduled for approval next week.

What should the project manager do next?

a) Decompose the testing, training, and project management work into the WBS so that it covers the full contracted scope, and then update the cost estimate before the baseline is approved.

b) Submit a change request with an impact assessment to add the testing, training, and project management work to the project scope, and present it to the change control board.

c) Ask the hospital's project office to add the training sessions and the testing to its product breakdown structure, and have the sponsor approve the revised structure.

d) Keep the WBS aligned with the sponsor-approved product breakdown structure, and fund the testing, training, and project management work from the contingency reserve.

Correct answer: A.

Rationale: Two facts decide this question. The contract already lists the testing, the training, and the project management as the vendor's responsibility, so this work is inside the agreed scope. In addition, the scope baseline has not been approved yet, so the WBS is still a planning document that the project manager's team can complete. Option a) does exactly that: it applies the 100% rule by adding the missing branches of work, and it corrects the estimate before the baseline locks it in. Option b) is the strongest trap, because a change request with an impact assessment is the right answer when approved scope must change. Here, nothing is changing, since the work was always in the contract, and there is no baseline yet to change. Option c) mistakes where the gap lies. A product breakdown structure lists products, and testing and project management are work, so the fix belongs in the WBS that the vendor owns, not in the customer's product list. Option d) misuses the contingency reserve, which covers identified risks. Known, contracted work must be estimated and included in the baseline. For full-length, realistic, scenario-based practice with detailed explanations, built to train the PMI® mindset, take our PMP practice exams or, at the entry level, our CAPM practice exams.

Ready to take the next step in project management?

200,000+ Professionals Taught by Our Instructors

PMP® Certification Training

PMP Training →

CAPM® Certification Training

CAPM Training →

Learn Project Management

PM Course →

Frequently asked questions