PMI-ACP Actively Engage Customers: Customer Needs, Acceptance Criteria and Collaboration

Actively engaging customers means involving the people who fund, use and are affected by a product throughout delivery: understanding who they are and what they actually need, checking every finished piece of work against criteria they helped write, and keeping them working alongside the team rather than waiting at the end for a sign-off. The PMI-ACP Examination Content Outline makes it Task 6 of the Delivery domain, with three enablers:

1. Identify and analyze customer and their needs.
2. Validate that iteration deliverables meet acceptance criteria.
3. Encourage collaboration between customer and team.

The task rests on the Agile Manifesto value customer collaboration over contract negotiation. A contract still matters, but agile teams treat the customer as a partner who shapes the product as it emerges, not as a party who states requirements once and then judges the result. The tools PMI lists for agile analysis and design, including personas, story maps, workshops, modeling and user stories, are the practical means of doing that.

Neighbouring tasks cover related ground, so this lesson points to them rather than repeating them. Measuring customer satisfaction and releasing small increments to gather feedback belong to Seek early feedback (Delivery Task 1). Ordering and estimating the backlog belong to Refine product backlog (Product domain). Defining what value and success mean for the product belongs to Manage value delivery.

A product's customers are everyone whose needs it must meet: the people or departments who fund it, the people who use it, and the people whose work it affects. Analyzing only one of these groups produces a product that satisfies the budget holder but frustrates the users, or the reverse. Take a library room-booking system: the city council pays for it, residents book rooms in it, and librarians manage the rooms and resolve double bookings. Each group needs something different, and all of them belong in the analysis.

Three groups are easy to miss:

• Internal customers. A team whose work is consumed by other teams, such as a shared customer database, a reporting service or a design system, has customers even though nobody outside the company sees its work. The consuming teams belong in its reviews and refinement like any other customer.
• People who avoid the product. Eligible people who phone a call centre, use a competitor or keep a spreadsheet instead of the product know something its current users cannot tell you: why they stay away. Their needs are part of the analysis.
• People who handle the product's output. Drivers who receive the dispatch lists, accountants who reconcile the exports, staff who answer the complaints: they live with what the product produces even if they never see its main screens.

A sponsor's documents, a policy or a proxy's opinion are useful starting points, but they are second-hand. Wherever possible the team meets the actual groups directly. The product owner represents customers in the backlog and decides priorities; the product owner is not one of the customer groups whose needs are being analyzed.

Analyzing customer needs means finding out what problem a request is meant to solve before deciding how to solve it. Customers usually describe a solution ("add a print button to the dashboard", "text me yesterday's sales every morning") because that is the easiest way to express a need. The need itself may be met far more simply, or may call for something quite different.

The most useful questions are about what happens around the request:

• What do you do with the result? What happens next once you have it?
• What problem are you trying to avoid or fix today, and how do you handle it now?
• How would you know this had worked?

Questions about how the requested solution should look or behave are useful later, but asked first they assume the solution is right and reveal nothing about the need. Asking "what for?" first is not obstruction: a printed dashboard may turn out to be a weekly conversation that a single shared chart would serve better.

Needs are sometimes discovered only after delivery, for example when usage data or interviews show that an accepted feature is hardly used and people actually need something else. The principle is the same as for any accepted work: the accepted story stays accepted, and the newly discovered need becomes a new backlog item for the product owner to order. The more lasting lesson is about process: the team reviews with the product owner how it explores needs before it writes stories, so that the next need surfaces during analysis rather than after release. Agile teams respond to late discovery by shortening the learning loop, not by asking customers for more complete specifications up front.

The right technique is the one that reveals the information the team is missing. Some techniques give depth on a few people; others give breadth across many; some show what people do rather than what they say. The table compares the common choices.

Three principles guide the choice:

• What people say and what they do can differ. People describe their work as they believe it happens, and they stop noticing their own workarounds. When reported behaviour and evidence such as support tickets, analytics or improvised tools disagree, watching the work in its real setting gives the more reliable picture.
• Depth first, then breadth. A handful of interviews or observations finds the issues; a survey of the wider customer base then shows how common each one is. Neither replaces the other.
• Shared knowledge needs a shared setting. When each group knows only its own part of a process, problems tend to sit in the handoffs between them. Bringing the groups together in a facilitated session, and building a visual model of the flow with them as they talk, lets each side correct the others in real time.

A persona is a short, realistic description of one group of users, covering their goals, context, skills and frustrations, written so the whole team shares the same picture of who it is building for. A persona helps the team ask "would this work for him?" during refinement and design. It does not record acceptance criteria, rank backlog items or identify budget approvers; other tools do those jobs.

A persona is only as good as the research behind it:

• Base personas on evidence. Personas written from the team's assumptions are hypotheses: a reasonable start, but they must be tested against real users.
• Revise when evidence contradicts them. If field research shows, say, that most users share one terminal at a busy front desk and no persona reflects that, the personas change. The product is designed for real users; the persona serves that, not the other way round.
• One persona per distinct group. When research finds a group whose goals, skills and frequency of use differ from an existing persona's, for example occasional volunteers alongside full-time coordinators, it gets its own persona. A blended persona describes nobody and hides the trade-offs the team must make between the groups.

A story map arranges user stories along the customer's journey so the team and customer can see the whole product and plan releases that let users finish real tasks. It answers a common complaint about flat backlogs: each delivered feature works, but the customer still cannot complete anything end to end and cannot see when they will.

A story map is laid out in two directions:

• Across (left to right): the user's activities in the order they happen. For a takeaway-ordering app: browse the menu, place an order, pay, track the delivery. This row is often called the backbone.
• Down: under each activity, the stories that support it, ordered by priority, with the most essential at the top.
• Horizontal slices: lines drawn across the map group stories into releases. Each slice takes some stories from every activity.

Build the map with the customer: they know the journey, and the team learns it by mapping together. The key release decision follows from the layout. The first release should be the thinnest slice across the whole journey, the simplest story under every activity, so a real user can complete the task themselves, even crudely. Later slices add depth. Building early activities in full before touching later ones leaves users unable to finish anything and delays the feedback that real use provides. Jeff Patton, who popularized the technique, calls this first end-to-end slice a walking skeleton.

When customer groups make conflicting requests, the team first brings them together to explore the needs behind each request; the product owner then decides, based on value. Conflicts often shrink once each side understands why the other wants what it does. Suppose marketing wants a long registration form to capture customer data and the support team wants the shortest form possible to cut abandoned sign-ups: once both explain their goals, the team may find that most of the data can be collected later, after the account exists.

The sequence matters:

1. Bring requests into one place. Competing requests should reach the product owner and a joint conversation, not individual team members. Private lobbying bypasses the product owner and pulls the team in different directions.
2. Explore the underlying needs together. Each group explains what it is trying to achieve, not just what it wants built.
3. Gather evidence cheaply if the choice is still open. Low-cost experiments, such as paper prototypes or clickable mock-ups tested with the people involved, show which option works before either is paid for in full.
4. The product owner decides on the value each option gives the business.

Customers explain needs; the product owner owns the decision. Moving straight to a decision, by any route, skips the analysis that might have dissolved the conflict.

Acceptance criteria are the conditions a story must satisfy for the customer to accept it, and they work best when the customer, developers and testers agree them together as concrete, testable examples before the work starts. When each party reads written criteria alone, each forms a different picture, and stories fail acceptance even though everyone did what they understood. A shared conversation about examples closes those gaps in a way that more documentation does not. This is the core idea of specification by example; closely related practices include acceptance test-driven development (ATDD) and behaviour-driven development (BDD).

A widely used format is Given / When / Then:

Given a library member has two overdue books, when she tries to borrow a third, then the loan is refused and the screen lists both overdue titles with their due dates.

Good criteria share three properties:

• Observable from the customer's side: they describe what a user sees or can do, not how the system does it internally. "Overdue status is cached" is a design choice, not an acceptance criterion.
• Objective: two people checking them reach the same verdict. "The page should be user-friendly" is an opinion; a stated outcome, threshold or example is not.
• Specific: they include the data, conditions and thresholds that matter.

Criteria also need care during the iteration. When a developer finds an ambiguity, for example whether a date range includes its end date, the right move is to raise it with the product owner straight away and update the criterion, so the answer is shared rather than guessed. If the product owner cannot be reached, a customer subject-matter expert who helped shape the criterion can answer a question of detail, and the product owner is kept informed of the answer. The rule of thumb: questions of detail can go to the people who know; decisions about priority and scope stay with the product owner.

Validating iteration deliverables means the product owner, on the customer's behalf, checks each finished story against its acceptance criteria and accepts or rejects it, as soon as it is finished rather than in a batch at the end. Acceptance criteria are specific to one story; the team's definition of done is the quality bar every item must meet, and it is never waived for one story. (The definition of done is covered in the Manage increments lesson in the Product domain; this lesson looks at acceptance from the customer's side.)

The rules that follow:

• Validate continuously. Acceptance checks held only at the end of an iteration turn every miss into carry-over, because nothing is left to fix it with. Checking each story as it meets the definition of done turns a miss into a fix within the same iteration. The fix is to move validation earlier, not to change the iteration around a late check.
• No partial credit. A story that misses any acceptance criterion is not accepted. It earns no velocity points and returns to the backlog for the product owner to prioritize. Iterations are timeboxed and are not extended to finish it.
• Criteria can change, done cannot be skipped. If the business no longer needs what a criterion describes, the product owner can remove that criterion and accept the story as built, provided it still meets the definition of done.
• Accepted means accepted. A new wish raised about an accepted story ("could it also show this as a chart?") becomes a new backlog item. The accepted story stays accepted.
• Meeting criteria is not the same as meeting the need. A story that meets its criteria and the definition of done is done, even if the customer then says it misses their real problem; the real need becomes new work. The lasting fix is upstream: involve the customer in writing the criteria for future stories.

Two general practices shorten the feedback loop, especially when the product owner's time is limited. Automated acceptance tests turn the agreed examples into tests that run on every change, so the team knows within minutes whether a story still meets its criteria. Frequent, short acceptance reviews, held whenever the product owner is available rather than saved for the iteration review, keep finished work from waiting. Acceptance itself remains the product owner's responsibility.

Encouraging collaboration means arranging time, channels and contracts so customers and the team work together continuously. Customers involved only at sign-off discover problems when they are most expensive to fix.

Securing customer time

Busy customer representatives often prefer to be involved only at the end. The practitioner explains the cost of late feedback and agrees a small, regular, realistic commitment: realistic for the customer, frequent enough for the team. One long requirements session up front is the waterfall pattern this task is meant to replace. When time is scarce, spend it on what only the customer can do: using the latest increment and giving feedback, and shaping what comes next with the product owner and team. Status information can be shared in other ways.

Direct channels for detail, one voice for priorities

Developers and users should be able to talk directly about the details of the stories being built; routing every detail question through one person makes stories stall. What does not change is that the product owner remains the single voice for priorities. Users clarify how something should work; they do not reorder the backlog or add work to the current iteration. When stakeholders try to add work by going around the product owner, the practitioner redirects the requests into the backlog and gives those stakeholders a proper place to be heard, such as refinement sessions and reviews, so they stay engaged without disrupting the iteration.

Contracts that support collaboration

A contract that fixes price and scope up front pushes both sides into negotiation whenever learning changes the plan. The Agile Practice Guide describes contract structures that let the customer learn and adjust:

The combination of dynamic scope and early cancellation is sometimes called "money for nothing, change for free", a pattern described by Jeff Sutherland. Whatever the contract, the collaborative response to a mid-project change request is a conversation about value and trade-offs with the customer, for example what lower-value work the change might replace.