PMI-ACP 2026 Exam Domains and Weightings

The current PMI-ACP blueprint

The March 2026 Examination Content Outline (ECO) organizes the PMI-ACP exam into four domains. Mindset and Delivery each account for 28% of items, Leadership accounts for 25%, and Product accounts for 19%. The March 2026 outline is a substantial change from older PMI-ACP domain maps. Candidates should study its tasks and enablers rather than trying to translate old domain labels into the current structure.

The percentages indicate the proportion of exam items assigned to each domain. They are not an exact item-count promise for each sitting, and they do not tell you whether a particular item is scored or pretest. Use the weights as a broad study guide, then adjust based on your ability to apply the tasks under scenario conditions.

Mindset: learning and adapting in a system

Mindset covers experimentation, agile principles, collaborative team environments, transparency, psychological safety, feedback loops, and response to change. The outline expects practitioners to experiment early, create increments that test a solution or market need, and help teams learn. It also names systems thinking and agile suitability: practitioners should understand how complexity affects the approach and tailor agile models to the needs of a team, project, or organization.

In practice, a team may be uncertain whether a workflow change will reduce customer abandonment. A large rollout would expose every user to an untested assumption. An early, bounded experiment can test the riskiest part, create evidence, and guide what the team builds next. Mindset is not a preference for experimentation regardless of risk. The test should be safe, ethical, appropriately small, and meaningful to the question the team needs answered.

The domain also asks how to make work and learning transparent. An information radiator is useful when it makes progress, risks, impediments, process, or learning visible to the people who need the information. Transparency means that stakeholders can understand the state of work; it does not mean publishing every detail to everyone without regard to privacy or security. Distributed teams need deliberate communication practices because informal hallway conversations do not reach all members.

Psychological safety matters because people need to report defects, uncertainty, and mistakes early. A no-blame response treats an incident as something to understand and improve, while still preserving accountability for agreed responsibilities. If a team member finds an error late in a release, the practitioner should help surface its effect and learn how the process allowed it through. Publicly shaming the person makes future reporting less likely and leaves the system defect unexamined.

Mindset also includes shortening feedback loops and embracing change. A team that waits months to show a product can learn too late that the solution misses the user’s need. Regular stakeholder contact, design exercises, small releases, and observation can shorten the cycle between an assumption and evidence. When feedback changes priorities, the team should inspect the new information and adapt the work through the product and team decision process.

Leadership: create conditions for team capability

Leadership covers empowering teams, facilitating problem resolution, promoting knowledge sharing, reinforcing agile principles, communicating shared purpose, and managing conflict. The practitioner’s role is not to take every decision away from the people doing the work. Effective leadership creates trust, supports experiments, coaches people, and helps the team own shared goals.

Training, coaching, and mentoring address different needs. Training teaches a defined skill or body of knowledge. Coaching helps a person or team think through a challenge and choose its own action. Mentoring offers guidance based on experience. If a newly formed team cannot use its board, focused training may help. If experienced team members disagree about a recurring handoff, coaching and facilitation may uncover the cause. If someone asks how the practitioner handled a similar challenge, mentoring may be useful, provided the current team still evaluates its own context.

Problem resolution begins by investigating the cause with the team. A recurring defect could stem from unclear acceptance criteria, missing test coverage, an external dependency, or work arriving faster than it can be reviewed. A blame-first intervention selects a person before the cause is known. Root-cause tools such as the Five Whys or a cause-and-effect diagram can structure a conversation, but they do not replace evidence or guarantee a single root cause.

Knowledge sharing includes retrospectives, lessons learned, communities of practice, and organizational knowledge assets. The point is to make useful learning available and to reserve time to update what people rely on. Copying another team’s process without checking whether its constraints match can create friction. A practitioner should identify what lesson is transferable, what depends on local conditions, and how to try it safely.

Shared purpose links team activity to product and organizational goals. A team may be completing tickets quickly while customer outcomes remain flat. Reconnecting the work to the intended result helps the team and stakeholders reconsider priority, definitions of success, or the increment being delivered. Conflict is not automatically dysfunction. The practitioner should identify whether a disagreement concerns task details, process, values, authority, or scarce resources, then facilitate a collaborative resolution appropriate to its cause.

Product: select work for value and learning

Product is the smallest-weight domain at 19%, but it covers decisions that shape what the team builds. The outline includes refining the product backlog, managing increments, visualizing work, and managing value delivery. Practitioners should clarify backlog items, prioritize with customers or stakeholders, decompose work when useful, and size it collaboratively with the people who will do it.

A backlog is an ordered set of possible work, not a contract to build every entry. Refinement turns vague requests into items the team can understand, estimate, and test. If a stakeholder says ‘make reporting better,’ the product conversation might ask which user needs the report, what decision it supports, what is wrong with the current report, and what outcome would show improvement. The team can then split a broad idea into smaller testable items.

Managing increments means defining a goal, keeping it aligned with business priorities, demonstrating usable work, and measuring whether it creates value. A feature can meet its technical acceptance criteria yet fail to produce the desired outcome. For example, a new search filter may pass tests but customers may not use it. The team should inspect adoption or user feedback and determine whether to improve, reposition, or stop investing in the feature.

Work visualization helps a team and stakeholders see status and flow. The display must be updated consistently and interpreted in context. A board that shows every task but hides blocked work creates a misleading picture. Product decisions may also need success criteria for sustainability, security, privacy, and compliance. Those conditions belong in the value discussion from the start, rather than being treated as optional polish after delivery.

Delivery: improve flow, quality, and outcomes

Delivery accounts for 28%. Its tasks include seeking early feedback, managing agile metrics, managing impediments and risk, recognizing and eliminating waste, performing continuous improvement, actively engaging customers, and optimizing flow. The domain connects plans and team habits to actual delivery performance.

Early feedback comes from delivering in small increments, checking customer satisfaction, and incorporating stakeholder input regularly. ‘Done’ should mean that an increment meets agreed quality and acceptance conditions, not merely that development has stopped. If a release contains incomplete work that cannot be safely used or evaluated, the team has not necessarily produced a valuable increment. Small delivery reduces the time before the team discovers that its assumptions were wrong.

Metrics should match the question and audience. Cycle time can help a team understand how long work takes after it starts. Throughput describes completed work over a period. Work-in-progress and cumulative flow can reveal queues or bottlenecks. A stakeholder may need outcome measures such as customer satisfaction or adoption. A single metric should not be used to rank individuals or pressure people into hiding work. Metrics are signals for decisions, not a substitute for discussion.

Risk and impediment management asks the practitioner to identify threats early, engage the team in choosing a response, prioritize mitigation or removal, monitor results, and learn from recurrence. Some risks call for a small experiment or technical spike. Others require coordination with security, compliance, or external providers. Agile work does not eliminate the need to plan for risk; it makes learning and adjustment part of the response.

Waste reduction begins with the end-to-end flow of value. Unnecessary approvals, repeated handoffs, waiting for scarce specialists, partially completed work, and features no one uses can all delay outcomes. Map where work waits and use data and feedback to choose an improvement. Avoid simply telling a team to work faster when the constraint sits elsewhere in the system.

Optimizing flow includes limiting work in progress at multiple levels, protecting the team from disruptive interruptions, and using metrics to improve how work moves. If many items are started but few are finished, starting even more work usually makes the queue harder to manage. A practitioner can help make current work visible, identify the main bottleneck, and work with stakeholders on a policy that keeps the system focused.

How the domains work together

The domain labels organize the outline, but real problems often touch several at once. Consider a product team with rising customer complaints and a large backlog of partially completed changes. Product work is needed to clarify which outcomes matter. Delivery work is needed to understand flow and quality. Leadership may be needed to facilitate a difficult conversation about priorities. Mindset may be needed to create a safe way to test a smaller improvement and learn from customers.

When an exam scenario crosses domains, answer the question actually asked. If it asks how to resolve a team conflict, do not jump straight to a product roadmap. If it asks how to prioritize a backlog, do not answer with a generic retrospective. The strongest response often addresses the immediate decision while preserving the ability to learn and collaborate across the broader system.

Use weights to plan study time

Mindset and Delivery together make up 56% of the outline, so they deserve substantial attention. That does not mean a candidate should ignore Product because it carries 19%. A weaker domain can still determine whether your overall preparation is balanced. Build a checklist of tasks, then rate yourself on explaining the idea and applying it to a new scenario. Use practice errors to update the plan rather than allocating hours solely from the percentages.

For example, a candidate with strong Scrum vocabulary but little experience interpreting flow metrics may need targeted Delivery practice. A product manager who routinely orders backlogs may still need work on psychological safety, conflict facilitation, and organizational knowledge sharing. A technical lead may understand quality and delivery but need to practice customer-value and stakeholder decisions. The ECO is broad enough that professional experience does not guarantee equal strength across domains.

A scenario linking Product and Delivery

A team released a dashboard feature that passed its acceptance tests, but few customers return to it. A senior stakeholder wants the team to add more charts. A strong first response is to clarify what user decision the dashboard should support, review actual usage and customer feedback, and decide with the product decision-maker whether a small usability change or experiment can test the issue. The team should preserve its quality standard and measure whether the change improves the intended result. Adding charts without evidence may increase scope while leaving the problem untouched.

This example tests Product value definition and Delivery feedback and measurement. It may also call on Mindset because the team needs to learn from results and adapt, and Leadership because the practitioner must facilitate a conversation with stakeholders. Domain mapping helps identify the knowledge involved, but the answer still depends on the prompt’s requested next action.

What the enablers mean for candidates

The ECO groups responsibilities into tasks and gives enablers as examples of work associated with each task. Enablers are illustrative, not an exhaustive checklist. This matters because studying only the named tool examples can produce brittle recall. Learn the purpose behind a task and understand when an example tool fits. For instance, a cumulative flow diagram can make queues visible, but the exam may describe the same flow problem without naming that chart.

The outline also has a Tools and Techniques section that broadens the vocabulary across domains. It includes practices and methods such as retrospectives, value stream mapping, work visualization, quality practices, risk tools, and prioritization techniques. Knowing a tool’s name is not enough. Be able to explain the problem it helps address, the evidence it provides, and the limits of using it outside its proper context.

A domain-based review routine

1. For each task, summarize the responsibility in your own words.
2. Choose one work situation where the responsibility matters and identify the evidence you would use.
3. Write the first action and name who should be involved in the decision.
4. Explain why one tempting shortcut would fail or create a new risk.
5. Practice the concept in more than one interaction type, including exhibits and multiple response where available.
6. Review misses by task and reason, then revisit only the concepts that need work.

This approach connects the outline to applied judgment. It also makes study more efficient: a candidate who consistently chooses a technically plausible but stakeholder-blind response can focus on feedback and value decisions instead of rereading every framework description.